Cyber Threat Hunting - Proaktive Bedrohungssuche im Netzwerk

Cyber Threat Hunting ist die proaktive Suche nach Bedrohungsakteuren die bereits in einem Netzwerk aktiv sind, aber noch nicht von automatisierten Systemen erkannt wurden. Im Gegensatz zu Incident Response (reagiert auf Alerts) geht Threat Hunting von der Hypothese aus: “Wir könnten bereits kompromittiert sein - lass uns aktiv suchen.” Erfahrene Angreifer können Monate im Netzwerk verweilen bevor sie entdeckt werden.

Das Problem: Dwell Time

Warum proaktives Hunting notwendig ist:

Dwell Time (Verweildauer des Angreifers):
  Durchschnitt 2024: 16 Tage (IBM Cost of Data Breach Report)
  Ransomware: 24-48 Stunden (schneller geworden!)
  Nation-State-APTs: Monate bis Jahre

Was in dieser Zeit passiert:
  → Angreifer erkundet Netzwerk (BloodHound, Recon)
  → Sammelt Credentials (Mimikatz, Kerberoasting)
  → Etabliert Persistenz (WMI, Scheduled Tasks, Golden Ticket)
  → Datenexfiltration: langsam, unter dem Radar

Warum SIEM/EDR allein nicht ausreicht:
  → APTs nutzen Living-Off-the-Land: keine Malware → keine Signatur
  → Signatur-Evasion: Packer, Encoder, Polymorphismus
  → Zero-Days: kein Patch, keine Signatur
  → Fehlkonfigurationen: keine Signatur möglich
  → False-Positive-Angst: Detection-Threshold zu hoch

Hunting-Ansatz:
  "Was würde ein Angreifer TUN in unserer Umgebung?"
  → Hypothese → Suche → Analysen → Findings oder Neue Hypothese

Hunting-Methodologien

1. Hypothesis-Driven Hunting:

Ausgangspunkt: MITRE ATT&CK
  → Wähle eine Technik: T1059.001 (PowerShell)
  → Hypothese: "Angreifer nutzt PowerShell für Lateral Movement"
  → Hunt: welche PowerShell-Aktivitäten sind in unserem Netzwerk ungewöhnlich?

Beispiel-Hypothese:
  "Angreifer hat Zugangsdaten und nutzt Pass-the-Hash für SMB-Lateral-Movement"
  → Such-Fragen:
    → Welche Workstations verbinden sich zu anderen Workstations via SMB?
    → (Normal: nur File-Server!)
    → Gibt es NTLM-Auth-Events von ungewöhnlichen Quellen?
    → Sind neue Admin-Sessions auf Servern entstanden?

2. Intel-Driven Hunting:

Ausgangspunkt: Threat Intelligence
  → Neue TI: "Lazarus nutzt TTP X in Banking-Sektor"
  → Frage: "Haben wir Spuren von TTP X in unserer Umgebung?"
  → Hunt: spezifisch auf IOCs und TTPs dieser Gruppe

Beispiel:
  → TI-Report: Angreifer nutzt C2 auf Port 8080 mit JA3: abc123
  → Hunt in SSL-Logs: "Gibt es JA3 abc123 in unserer Umgebung?"
  → Hunt in Proxy-Logs: "Port 8080 zu externen IPs?"

3. Situational-Awareness Hunting:

Ausgangspunkt: Baselining
  → Normale Umgebung dokumentieren
  → Hunt: was weicht von der Baseline ab?
  → Besonders nach: Incidents, Penetrationstests, Systemänderungen

Beispiel:
  → Baseline: 5 DNS-Anfragen/Minute pro Workstation
  → Hunt: welche Hosts haben >50 DNS-Anfragen/Minute?
  → Ergebnis: DNS-Tunneling oder übertriebene Beacon-Frequenz?

Tools für Threat Hunting

Velociraptor (Endpoint-Artefakt-Sammlung):

Installation (Server + Client):
  # Server (Linux):
  wget https://github.com/Velocidex/velociraptor/releases/latest/.../velociraptor-linux-amd64
  ./velociraptor config generate -i  # Interactive Setup
  ./velociraptor --config server.config.yaml frontend -v

  # Client deployen (Windows):
  # Velociraptor-GUI → Deployments → Client MSI generieren
  # Stilles Deployment via GPO/SCCM

VQL (Velociraptor Query Language) für Hunting:
  # Alle laufenden Prozesse mit Netzwerkverbindungen:
  SELECT Name, Pid, CommandLine,
    { SELECT LocalAddress, RemoteAddress, Status FROM connections() WHERE Pid = ProcInfo.Pid }
    AS Network
  FROM process_tracker_all()
  WHERE Network

  # PowerShell-Ausführungen der letzten 24h:
  SELECT *
  FROM Artifact.Windows.EventLogs.PowerShell.ISEScriptBlockLogging()
  WHERE Timestamp > now() - 86400

  # Scheduled Tasks mit verdächtigen Befehlen:
  SELECT *
  FROM Artifact.Windows.System.ScheduledTasks()
  WHERE Command =~ "(powershell|cmd|wscript|cscript|mshta)"

  # Registry-Persistenz:
  SELECT *
  FROM Artifact.Windows.Registry.RunKeys()
  WHERE Data =~ "(http|.exe|powershell|cmd)"

KAPE (Kroll Artifact Parser and Extractor):
  # Forensik-Triage ohne Vollimage:
  # Sammelt: Registry Hives, Event Logs, Prefetch, LNK, $MFT
  kape.exe --tsource C: --tdest C:\KAPEOutput \
    --target RegistryHives,EventLogs,Prefetch,LNKFiles

  # Targets (was gesammelt wird):
  # Modules (wie analysiert wird):
  kape.exe --msource C:\KAPEOutput \
    --mdest C:\KAPEParsed \
    --module EvtxECmd,RECmd,LECmd

Sigma-Rules (Detection-as-Code):
  # Sigma: SIEM-agnostische Erkennungsregeln
  # Konvertierung zu SIEM-Query:

  # sigma-cli convert:
  sigma convert -t splunk -p ecs-windows \
    rules/windows/process_creation/proc_creation_win_powershell_download.yml

  # Ausgabe (Splunk):
  source="WinEventLog:Security" EventCode=4688
  (CommandLine="*IEX*" CommandLine="*DownloadString*")

  # Beispiel-Sigma-Rule (YAML):
  title: PowerShell Download Cradle
  id: a7a...
  status: stable
  logsource:
    category: process_creation
    product: windows
  detection:
    selection:
      CommandLine|contains|all:
        - 'IEX'
        - 'DownloadString'
    condition: selection
  falsepositives:
    - Legitimate management scripts
  level: high

Praktische Hunt-Beispiele

Hunt 1: Kerberoasting-Spuren finden:

Hypothese: "Angreifer hat Kerberoasting durchgeführt und SPN-Accounts geknackt"

Datensource: Windows Security Event Log (DC)
Event ID 4769: Kerberos Service Ticket Request

Suche in Splunk:
  index=windows EventCode=4769 TicketOptions="0x40810000"
  ServiceName!="$*"  # Keine Computer-Accounts
  | stats count by Account_Name, ServiceName, Client_Address
  | sort -count
  | where count > 5  # Viele TGS-Anfragen = Kerberoasting!

Auswertung:
  → Normales Verhalten: wenige TGS-Anfragen pro Account
  → Kerberoasting: 100+ TGS-Anfragen für viele SPNs in kurzer Zeit
  → Wenn Account plötzlich viele SPNs abfragt → Alert

Hunt 2: Living-Off-the-Land Detection:

Hypothese: "Angreifer nutzt native Windows-Tools für Post-Exploitation"

LOLBin-Abuse Suche (Sysmon Event ID 1):
  index=sysmon EventCode=1
  (
    (ParentImage="*\\winword.exe" Image="*\\powershell.exe") OR
    (ParentImage="*\\excel.exe" Image="*\\cmd.exe") OR
    (Image="*\\mshta.exe" CommandLine="*http*") OR
    (Image="*\\regsvr32.exe" CommandLine="*/i:http*")
  )
  | table _time, Computer, User, Image, CommandLine, ParentImage

  Rote Flags:
  → Office-App spawnt PowerShell/CMD → Makro-Malware!
  → mshta.exe mit HTTP-Parameter → Phishing
  → regsvr32 mit Internet-URL → Squiblydoo

Hunt 3: Exfiltration Detection:

Hypothese: "Daten werden über DNS exfiltriert"

DNS-Log-Analyse (Zeek):
  # Durchschnittliche Subdomain-Länge pro Domain:
  cat dns.log | zeek-cut query | \
    awk -F'.' '{print NF, length($1), $0}' | \
    sort -rn | head -50
  # Lange erste Labels = verdächtig (Base64-Daten!)

  # Hohe Anfragehäufigkeit zu einer Domain:
  cat dns.log | zeek-cut query | \
    awk -F'.' '{for(i=NF-1;i<=NF;i++) printf "%s.",$i; print ""}' | \
    sort | uniq -c | sort -rn | head -20
  # > 1000 Anfragen zu einer Domain in kurzer Zeit = verdächtig

Hunting-Workflow und Dokumentation

Strukturierter Hunting-Prozess:

TaHiTI (Targeted Hunting integrating Threat Intelligence):
  → Framework für strukturiertes Threat Hunting
  → ENISA-Empfehlung für SOCs

Schritte:
  1. Trigger:       Was initiiert den Hunt? (TI, Alert, Routine)
  2. Hunting Scope: Welche Systeme, welcher Zeitraum?
  3. Hypothese:     Was suchen wir? Warum?
  4. Hunt:          Queries ausführen, Daten analysieren
  5. Findings:      Was wurde gefunden?
  6. Response:      Incident? Neue Detection-Rule?
  7. Documentation: Hunt-Bericht schreiben

Hunt-Bericht Vorlage:
  Hunt ID:          HUNT-2026-042
  Datum:            2026-03-04
  Hunter:           Max Müller
  Trigger:          Routine (monatlicher Hunt)
  Hypothese:        "Kerberoasting in der Domäne durchgeführt"
  TTPs:             MITRE T1558.003
  Datensources:     DC Security Events (4769)
  Zeitraum:         letzten 30 Tage
  Findings:         Keine Anomalien gefunden → Baseline OK
  New Rules:        Sigma-Rule für >10 TGS-Anfragen/min hinzugefügt
  Dauer:            2 Stunden

KPIs für Threat Hunting:
  □ Hunts pro Monat: Ziel ≥ 4 (mind. 1/Woche)
  □ True Positive Rate: % Hunts die echte Threats fanden
  □ MTTD-Reduktion: wie viel früher werden Threats erkannt?
  □ New Detection Rules: wie viele neue Rules aus Hunts entstanden?
  □ Dwell Time: hat sich die durchschnittliche Dwell Time reduziert?