Threat Hunting: Proaktiv nach Angreifern suchen

Threat Hunting geht davon aus, dass Angreifer bereits im Netz sind - man weiss es nur noch nicht. Die Frage ist nicht "Wurden wir angegriffen?" sondern "Wo versteckt sich der Angreifer gerade?"

Threat Hunting vs. SIEM-Monitoring

Warum reaktives Monitoring nicht genügt

SIEM-Monitoring (reaktiv):

• Wartet auf bekannte Angriffsmuster (Signaturen, Regeln)
• Dwell Time: durchschnittlich 197 Tage bis zur Entdeckung (IBM 2024)
• Erkennt: bekannte Angriffe, laute Angriffe
• Blind für: neue Techniken, langsame/stille Angreifer

Problem: APT-Gruppe nutzt legitime Windows-Tools (Living off the Land) → Keine Signaturen → kein Alert! Angreifer kann Monate im Netz bleiben, Daten exfiltrieren.

Threat Hunting (proaktiv):

• Analyst nimmt Hypothese: "Ich glaube, ein Angreifer verwendet PowerShell für Lateral Movement"
• Sucht systematisch in Telemetrie-Daten nach Beweisen
• Findet: auch dann, wenn kein Alert ausgelöst wurde

Ein erfolgreich abgeschlossener Hunt hat immer einen Wert - unabhängig vom Ergebnis: Ein gefundener Angreifer führt in die Incident Response. Kein gefundener Angreifer führt zur Erstellung einer neuen SIEM-Regel (Hunt → Detection). Identifizierte Blindspots führen zur Verbesserung der Datenerfassung.

Hunt Maturity Model (SQRRL)

Level	Beschreibung
Level 0	Kein Hunting (nur reaktiv, Alert-basiert)
Level 1	Minimal (seltene, ad-hoc Hunts)
Level 2	Prozedural (reproduzierbare Hunt-Prozeduren)
Level 3	Innovative (eigene Techniken, ML-unterstützt)
Level 4	Leading (automatisierte Hunting-Pipelines)

Hypothesen-Entwicklung mit MITRE ATT&CK

MITRE ATT&CK Framework

• 14 Taktiken (Phasen): Reconnaissance, Initial Access, Execution...
• 200+ Techniken pro Taktik
• Sub-Techniken: konkrete Implementierungen
• Gruppen: welche APTs nutzen welche Techniken?

Hypothesen-Quellen

1. MITRE ATT&CK: "Was würden Angreifer tun?"
2. Threat Intelligence: "Was tun APTs in unserer Branche?"
3. Aktuelle Reports: "Was wurde letzte Woche von Incident-Response-Teams gesehen?"
4. Hunt-Ergebnisse: "Was haben wir beim letzten Hunt übersehen?"

Hypothesen-Beispiele

Hypothese 1: Kerberoasting

• ATT&CK: T1558.003
• "Angreifer fordert Kerberos-Service-Tickets für Offline-Cracking an"
• Daten: Windows Security Event 4769 (Kerberos Service Ticket Request)

Hypothese 2: PowerShell-basierte Ausführung

• ATT&CK: T1059.001
• "Malware nutzt PowerShell für Downloader oder Lateral Movement"
• Daten: Process Creation Events (Event 4688), PowerShell-Scriptblock-Logging

Hypothese 3: Living off the Land (LoLBins)

• ATT&CK: T1218 (System Binary Proxy Execution)
• "Angreifer missbraucht legitime Windows-Tools für böswillige Zwecke"
• Verdächtige Prozesse: certutil.exe, regsvr32.exe, mshta.exe, wscript.exe

Hypothese 4: Datenexfiltration via DNS

• ATT&CK: T1048.003
• "Daten werden über DNS-Anfragen nach aussen geschleust"
• Daten: DNS-Logs (sehr lange Subdomains, häufige TXT-Record-Anfragen)

Hypothesen-Qualität

Gut: "Angreifer nutzt certutil.exe um Payload herunterzuladen" - spezifisch, messbar, MITRE-referenziert

Schlecht: "Angreifer macht irgendwas böses" - zu breit, keine Suchanleitung

Datenquellen und Telemetrie

Windows Event Logs - kritische Events

Event-ID	Bedeutung	Hunting-Relevanz
4624	Erfolgreicher Login (Anmeldungstyp beachten!)	Type 3 = Network, Type 10 = Remote Interactive (RDP)
4625	Fehlgeschlagener Login	Brute Force erkennen
4688	Prozess erstellt	Command Line muss geloggt sein!
4689	Prozess beendet	-
4698	Scheduled Task erstellt	häufige Persistenz-Methode
4720	Benutzer erstellt	-
4732	Benutzer zur Gruppe hinzugefügt	Privilegien-Eskalation!
4769	Kerberos Service Ticket Request	Kerberoasting!
7045	Neuer Service installiert	Persistence!

Folgende Einstellungen müssen aktiv sein: Process Command Line Logging (Event 4688 mit vollständiger Kommandozeile), PowerShell Scriptblock Logging (Event 4104), PowerShell Module Logging sowie Sysmon für Prozesserstellung, Netzwerkverbindungen und Registry-Änderungen.

EDR-Telemetrie

• CrowdStrike Falcon, SentinelOne, Microsoft MDE
• Sehr granular: jede Prozess-Erstellung, jede Netzwerkverbindung
• API-Zugriff für Hunt-Queries
• CrowdStrike: Events Data Dictionary (über 50 Event-Typen)

DNS-Logs

• Welche Domains wurden aufgelöst?
• Ungewöhnlich lange Subdomains = DNS-Exfiltration?
• Anfragen an bekannte Malware-C2-Domains
• Interne Systeme die externe DNS-Server nutzen (verdächtig!)

NetFlow / Network Traffic

• Welche IP kommuniziert mit wem?
• Datenvolumen: grosse Uploads nach aussen?
• Beaconing: regelmäßige Verbindungen (C2-Kommunikation)
• Ungewöhnliche Ports oder Protokolle

Proxy-Logs

• HTTP/HTTPS-Anfragen (mit SSL-Inspection)
• User Agent Strings (verdächtige oder unbekannte)
• Anfragen an frisch registrierte Domains (< 30 Tage alt)

Hunt-Techniken

Stack Counting

Die Kernfrage lautet: Welche Werte kommen selten vor? Ausreisser sind verdächtig.

Beispiel: Parent Process von PowerShell. Normale Parent-Prozesse sind explorer.exe, cmd.exe oder powershell.exe selbst. Verdächtig ist word.exe → powershell.exe (typisch für Macro-Ausführung). Kritisch ist svchost.exe → powershell.exe, wofür es keinen legitimen Grund gibt.

// KQL (Kusto Query Language / Microsoft Sentinel):
DeviceProcessEvents
| where FileName =~ "powershell.exe"
| summarize count() by InitiatingProcessFileName
| order by count_ asc
// Kleinste count_ = seltenste Parent = verdächtigste!

Frequency Analysis

Wie oft verbindet sich Host X mit Domain Y? Stabiles Intervall ist ein Zeichen für C2-Beaconing (typisch: alle 60 Sekunden), während normale Verbindungen unregelmäßig sind.

-- DNS-Beaconing-Erkennung:
SELECT timestamp, DNS, count(*) as requests
FROM dns_logs
WHERE timestamp > now() - 24h
GROUP BY DNS
HAVING requests > 100  -- Häufige Anfragen an selbe Domain

Clustering

• Ähnliche Aktivitäten gruppieren
• Anomalien durch Ausreisser erkennen
• ML-basiert: Isolationswald, DBSCAN
• Einsatz: User Behavior Analytics (UEBA)

TTP-based Hunting

Gezielt nach einer bestimmten MITRE-Technik suchen. Beispiel: T1218.011 Rundll32 - "Angreifer nutzt rundll32.exe um DLL auszuführen":

// Sentinel: Verdächtige Rundll32-Ausführungen
DeviceProcessEvents
| where FileName =~ "rundll32.exe"
| where ProcessCommandLine has_any ("javascript:", "vbscript:", "http")
| project Timestamp, DeviceName, ProcessCommandLine

Hunt-Szenarien und Playbooks

Hunt 1: PowerShell Downloader

Hypothese: Angreifer lädt Payload mit PowerShell herunter

DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has_any (
    "DownloadString", "DownloadFile", "IEX", "Invoke-Expression",
    "WebClient", "Net.WebClient", "Start-BitsTransfer",
    "bitsadmin", "certutil", "-enc", "-encoded"
)
| where InitiatingProcessFileName !in~ ("powershell.exe", "pwsh.exe")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine

Triage: PowerShell aus Word ist fast sicher Malware. PowerShell aus einer Skript-Verwaltung ist möglicherweise legitim und muss geprüft werden.

Hunt 2: Kerberoasting Detektion

Hypothese: Angreifer fordert Service Tickets für Offline-Cracking an

// Verdächtige Service Ticket Requests:
// RC4-Verschlüsselung (0x17) ist veraltet und beim Cracking bevorzugt
// Viele Tickets von einem Host kurz hintereinander
SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"  // RC4 = verdächtig!
| where ServiceName !endswith "$"  // Nicht Maschinen-Accounts
| summarize count() by Account, ServiceName, Computer
| where count_ > 5  // Mehrere Tickets = Kerberoasting!

Hunt 3: DNS-Tunneling

Hypothese: Daten werden via DNS-Anfragen exfiltriert. Normale Subdomains sind kurz (www.google.com), DNS-Tunnel enthalten Base64-kodierte Nutzdaten in langen Subdomains (z.B. aGVsbG8gd29ybGQ=.evil.com).

DnsEvents
| where SubType == "LookupQuery"
| extend SubdomainLength = strlen(extract("^([^.]+)", 1, Name))
| where SubdomainLength > 40  // Verdächtig lange Subdomain
| summarize count() by ClientIP, Name
| order by count_ desc

Hunt 4: Lateral Movement via SMB

Hypothese: Angreifer bewegt sich per Pass-the-Hash über SMB

SecurityEvent
| where EventID == 4624
| where LogonType == 3  // Netzwerk-Login
| where AuthenticationPackageName == "NTLM"  // PtH nutzt NTLM!
| where TargetUserName != "ANONYMOUS LOGON"
| summarize count() by IpAddress, TargetUserName
| where count_ > 5  // Ein Quell-IP versucht viele Ziele

Toolchain für Threat Hunter

Velociraptor

Open-Source-Plattform für Endpoint-Sichtbarkeit und Hunting. Ein Agent auf den Endpoints ermöglicht artefaktbasierte Abfragen per VQL (Velociraptor Query Language) sowie Live Response direkt auf Verdachts-Maschinen. Beispiel: alle Autostart-Einträge auf allen Hosts abfragen mit SELECT * FROM Artifact.Windows.Sys.Users().

Microsoft Sentinel (Cloud-SIEM)

KQL als mächtige Query-Sprache, Hunting-Workbooks als strukturierte Hunt-Leitfaden, Jupyter Notebooks für ML-basiertes Hunting sowie Bookmarks zum Speichern und Verfolgen interessanter Findings.

Elastic Security (EQL Stack)

EQL (Event Query Language) ermöglicht sequenzielle Abfragen für Angriffsketten. Das folgende Beispiel erkennt PowerShell-Ausführungen, die direkt aus einer Office-Anwendung gestartet wurden:

sequence by process.parent.entity_id
  [process where process.name == "winword.exe"]
  [process where process.name == "powershell.exe"]

Timelines helfen beim Zusammenführen von Events; community-basierte Hunt Queries stehen öffentlich zur Verfügung.

Jupyter Notebooks

ML-unterstütztes Hunting mit Pandas und Scikit-Learn für Anomalie-Erkennung. Die MSTIC Microsoft Threat Intelligence Notebooks sind auf GitHub verfügbar. Visualisierungen werden mit Matplotlib oder Plotly erstellt.

MITRE Caldera (Adversary Emulation)

Automatisierte Angreifer-Emulation nach ATT&CK zur Hunt-Validierung: "Würden wir diesen Angriff erkennen?" Das Tool eignet sich auch für Red Team Automation.