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)

// Hunt-Abfrage (Microsoft Sentinel KQL):
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"  // Bekannte Installer
  )
| 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”

SecurityEvent
| where EventID == 4769           // Kerberos Service Ticket
| where TicketEncryptionType == "0x17"  // RC4 (schwach, preferred by attackers)
| where ServiceName !endswith "$"  // Kein Computer-Account
| where ServiceName != "krbtgt"   // Kein TGT
| summarize count() by TargetUserName, IpAddress, ServiceName
| where count_ > 5                // Mehrere Requests = verdächtig

Auffälligkeiten:

• Viele Service-Ticket-Requests von einer Workstation
• Requests für RC4-verschlüsselte Tickets (sollte AES sein!)
• Requests außerhalb Bürozeiten

Hypothese 3: “Neue Persistenz-Mechanismen eingerichtet”

Registry Run Keys:

SecurityEvent
| where EventID == 13  // Registry Set Value
| where RegistryKey contains "CurrentVersion\\Run"
| where RegistryKey !contains "Uninstall"
| project TimeGenerated, DeviceName, AccountName, RegistryKey, RegistryValueData
| order by TimeGenerated desc

Scheduled Tasks:

SecurityEvent
| where EventID == 4698  // Scheduled Task Created
| project TimeGenerated, Computer, SubjectUserName, TaskName, TaskContent
| extend Alert = "New scheduled task created: " + TaskName

WMI Persistence:

DeviceEvents
| where ActionType == "WmiBindingCreated"
| project TimeGenerated, DeviceName, AccountName, AdditionalFields

Hypothese 4: “Credential Dumping versucht”

Angreifer versucht LSASS-Speicher zu lesen.

DeviceAlertEvents  // Microsoft Defender
| where AlertName contains "Credential"
| where TimeGenerated > ago(30d)

// Oder: LSASS Access prüfen:
DeviceEvents
| where ActionType == "OpenProcessApiCall"
| where FileName =~ "lsass.exe"
| where InitiatingProcessFileName !in (
    "MsMpEng.exe",         // Windows Defender
    "csrss.exe",
    "werfault.exe"
  )
| project TimeGenerated, DeviceName, AccountName,
          InitiatingProcessFileName, InitiatingProcessCommandLine

Hypothese 5: “DNS-Exfiltration oder Beaconing”

Hohe DNS-Query-Frequenz:

DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where Protocol == "DNS"
| summarize DNSCount = count() by DeviceName, RemoteIP
| where DNSCount > 1000  // Mehr als 1000 DNS-Queries von einem Gerät am Tag?
| order by DNSCount desc

Lange Subdomain-Namen (DNS-Tunneling):

DeviceNetworkEvents
| where Protocol == "DNS"
| extend DomainParts = split(RemoteUrl, ".")
| extend Subdomain = tostring(DomainParts[0])
| where strlen(Subdomain) > 40  // Lange Subdomains → base64-kodierte Daten?
| project TimeGenerated, DeviceName, RemoteUrl, Subdomain

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

Beispiel: Aus Hunt zu Regel (LotL mshta)

// Hunt-Abfrage (manuell):
DeviceProcessEvents
| where FileName == "mshta.exe"
| where ProcessCommandLine contains "http"
| project TimeGenerated, DeviceName, AccountName, ProcessCommandLine

→ KEIN Fund in 30 Tagen

Trotzdem: Abfrage als SIEM-Regel speichern!

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

→ Nächstes Mal wenn Angreifer mshta nutzt: sofortiger Alert! → 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