Threat Hunting in der Praxis: Erste Schritte für KMU

"Threat Hunting ist nur für große SOCs mit 10+ Analysten" - das stimmt nicht. Die Grundprinzipien des Threat Huntings sind auch für kleinere Teams anwendbar, wenn man pragmatisch vorgeht: nicht jeden Tag, nicht alle TTPs auf einmal, aber systematisch und zielgerichtet. Dieser Guide zeigt wie.

Warum Threat Hunting - auch für kleine Teams?

Das Problem mit rein reaktiver Sicherheit

SIEM-Alarme erkennen was wir erwarten: bekannte Angriffsmuster → Signatur-Alarm. Unbekannte APT-Technik → kein Alarm!

Statistiken:

• Durchschnittliche Verweildauer von Angreifern: 207 Tage (IBM 2024)
• 56% der Angriffe werden durch externe Parteien entdeckt (Kunden, Partner, Strafverfolgung) - nicht durch das interne Team!

Was passiert wenn Angreifer 207 Tage unentdeckt ist:

Zeitraum	Aktivität
Tag 1-14	Reconnaissance, Persistence
Tag 15-60	Lateral Movement, Privilege Escalation
Tag 60-180	Daten exfiltrieren, Hintertüren legen
Tag 180+	Ransomware deployen ODER dauerhaft Daten stehlen

Threat Hunting Ziel: "Assume breach" - davon ausgehen dass Angreifer BEREITS drin sind. Aktiv nach Beweisen suchen, bevor der Schaden eintritt.

Für KMU ohne dedizierten Analysten:

• Nicht täglich, aber regelmäßig: 2-4 Stunden/Woche
• Fokus auf 3-5 High-Value-Hypothesen
• SIEM + EDR als Werkzeuge nutzen
• Ergebnisse: neue SIEM-Regeln erstellen

Die 5 wichtigsten Hunt-Hypothesen für KMU

Hypothese 1: "Angreifer hat Living-off-the-Land-Binaries genutzt"

LotL = Missbrauch von Windows-Bordmitteln (certutil, mshta, regsvr32). Die KQL-Abfrage für Microsoft Sentinel sucht nach Prozessausführungen verdächtiger Binaries, die nicht von bekannten Installer-Prozessen gestartet wurden:

DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName in (
    "certutil.exe", "mshta.exe", "regsvr32.exe",
    "bitsadmin.exe", "installutil.exe", "regasm.exe",
    "wscript.exe", "cscript.exe"
  )
| where InitiatingProcessFileName !in (
    "msiexec.exe", "setup.exe", "installer.exe"
  )
| project TimeGenerated, DeviceName, AccountName,
          FileName, ProcessCommandLine
| order by TimeGenerated desc

Was zu suchen ist:

• certutil.exe -decode/-urlcache/-split → Download/Decode
• mshta.exe http:// → Remote HTA-Ausführung
• regsvr32.exe /s /u /i:http:// → COM-Scriptlet

Hypothese 2: "Kerberoasting - Service-Accounts werden angegriffen"

Kerberoasting ist erkennbar über Event 4769 (Kerberos Service Ticket Request). Verdächtig ist eine hohe Frequenz von Requests mit EncryptionType 0x17 (RC4) für denselben Account - RC4 ist schwach und wird von Angreifern bevorzugt. In Microsoft Sentinel filtert man auf TicketEncryptionType == "0x17" und schließt Computer-Accounts sowie das krbtgt-Konto aus. Mehr als fünf solcher Requests von einer Workstation sind ein klares Alarmsignal, besonders außerhalb der Bürozeiten.

Hypothese 3: "Neue Persistenz-Mechanismen eingerichtet"

Drei Bereiche sind besonders relevant: Registry Run Keys (Event ID 13, Schlüsselpfad enthält CurrentVersion\Run), neu erstellte Scheduled Tasks (Event ID 4698) und WMI-Subscriptions (WmiBindingCreated in DeviceEvents). Für alle drei lassen sich in Sentinel KQL-Abfragen formulieren, die neue Einträge mit dem erstellenden User und dem jeweiligen Inhalt ausgeben. Bekannte Software-Installationen sollten vorab als Whitelist hinterlegt werden.

Hypothese 4: "Credential Dumping versucht"

Angreifer versucht LSASS-Speicher zu lesen. Der direkteste Indikator ist ein OpenProcessApiCall auf lsass.exe von einem Prozess der nicht zu Windows Defender (MsMpEng.exe), csrss.exe oder werfault.exe gehört:

DeviceEvents
| where ActionType == "OpenProcessApiCall"
| where FileName =~ "lsass.exe"
| where InitiatingProcessFileName !in (
    "MsMpEng.exe",
    "csrss.exe",
    "werfault.exe"
  )
| project TimeGenerated, DeviceName, AccountName,
          InitiatingProcessFileName, InitiatingProcessCommandLine

Microsoft Defender meldet Credential-Dumping-Versuche zusätzlich über DeviceAlertEvents mit AlertName contains "Credential".

Hypothese 5: "DNS-Exfiltration oder Beaconing"

Zwei Muster sind charakteristisch: eine ungewöhnlich hohe DNS-Query-Frequenz von einem einzelnen Gerät (mehr als 1.000 Queries in 24 Stunden) und auffällig lange Subdomain-Namen. Subdomains mit mehr als 40 Zeichen deuten auf base64-kodierte Nutzdaten hin - ein klassisches Merkmal von DNS-Tunneling-Werkzeugen wie dnscat2 oder iodine.

Hunt-Prozess: Schritt für Schritt

Vor jeder Hunt-Session

1. Hypothese wählen (15 Minuten):

• Aktuelle BSI-Warnmeldungen prüfen
• MITRE ATT&CK: welche Technik noch nicht gejagt?
• Aus Threat-Intelligence: welche Gruppen sind aktiv?
• Aus letztem Pentest: was wurde genutzt?

2. Datenverfügbarkeit prüfen:

• Welche Logs sind im SIEM verfügbar?
• Lückenhaft? → Hunt wird unzuverlässig!
• Fehlende Log-Quellen dokumentieren

3. Baseline verstehen (wichtig!):

• Was ist "normal" in dieser Umgebung?
• Gibt es legitimen Grund für certutil-Aufrufe? (Softwareinstallation?)
• Scheduled Tasks: welche sind bekannt/erwartet?

Während der Hunt-Session

4. Abfrage ausführen und iterieren:

• Erste Abfrage zeigt 500 Ergebnisse → eingrenzen
• Zeitraum einschränken (letzte 7 Tage)
• Known-Good ausschließen (Whitelist)
• Interessante Ergebnisse tiefer analysieren

5. Pivoting (weiterführende Analyse):

• Verdächtiger Fund? → Was hat dieses Gerät sonst noch gemacht?
• Verdächtiger User? → Welche anderen Systeme hat er kontaktiert?
• Verdächtige IP? → Welche anderen Geräte haben sie kontaktiert?

Nach der Hunt-Session

6. Ergebnis dokumentieren:

• Bedrohung gefunden: → Incident Response!
• Kein Fund: → Dokumentieren "Hunt auf TTP X - keine Anomalie gefunden"
• Learnings: was war schwieriger als erwartet?

7. SIEM-Regel erstellen:

• Hunt-Abfrage → als geplante SIEM-Regel einrichten
• Nächste Mal automatisch Alarm statt manueller Hunt
• Hunt-Ergebnisse verbessern SIEM-Coverage!

Hunt-Kalender für kleine Teams

Wöchentlich (2-3 Stunden)

• Living-off-the-Land Binaries (LotL) - schnell, hoher Wert
• Neue Scheduled Tasks und Registry Run Keys
• DNS-Anomalien

Monatlich (4-6 Stunden)

• Kerberoasting und Pass-the-Hash Indicators
• Lateral Movement: ungewöhnliche Authentifizierungen
• Exfiltration: große ausgehende Datenmengen

Quartalsweise (8-16 Stunden)

• Vollständiger MITRE ATT&CK Coverage Review
• Neue TTPs aus aktuellen Threat Intelligence Reports
• Detection Engineering: alle neuen Regeln aus Hunts testen

Nach Incidents / Pentests

• Immediate Hunt: wurden ähnliche TTPs schon früher genutzt?
• Zeitraum: letzte 3 Monate rückwirkend
• Andere Systeme: hat sich Angreifer weiter ausgebreitet?

Tools für kleinere Teams

Tool	Beschreibung
Microsoft Sentinel	KQL-Abfragen, guter Einstieg
Elastic SIEM	EQL für Event-Sequences
Hayabusa	Schnelle Windows-Eventlog-Analyse (kostenlos!)
Chainsaw	Windows-Forensik-Tool (kostenlos)
Sigma Rules	Community-basierte Erkennungsregeln

Von Threat Hunting zu Detection Engineering

Jede Hunt sollte SIEM-Regeln produzieren

Angenommen, eine Hunt auf mshta.exe mit Remote-URLs liefert in 30 Tagen keinen Fund. Die Hunt-Abfrage trotzdem als geplante SIEM-Regel speichern:

• Name: "LotL: mshta.exe mit Remote-URL"
• Frequenz: Alle 15 Minuten
• Alert-Schwellwert: 1 Treffer = Alarm
• Schweregrad: High
• MITRE ATT&CK: T1218.005 (Mshta)

Beim nächsten Angreifer der mshta nutzt: sofortiger Alert statt manuelle Suche. Die Hunt ist zu Detection geworden.

Detection-Debt

Welche ATT&CK-Techniken haben wir NOCH KEINE Regel für?

• ATT&CK Navigator: Coverage-Matrix erstellen
• Priorität: häufig genutzte TTPs zuerst decken
• Quartalsweise: neue TTPs aus Threat Intel hinzufügen

Sigma Rules (community-basiert)

• github.com/SigmaHQ/sigma: Tausende vorgefertigte Regeln
• Konvertierung für alle SIEMs: sigmahq-convert
• Nicht alle Regeln passen: Anpassen an eigene Umgebung!
• Guter Ausgangspunkt für Detection Engineering

---

Threat Hunting ist eine Investition in proaktive Sicherheit. AWARE7 führt professionelle Threat-Hunting-Sessions für Unternehmen durch und hilft beim Aufbau eigener Hunt-Kapazitäten im SOC.

Threat Hunting anfragen | Penetrationstest