Threat Hunting: Einstieg mit Hypothesen statt Alarmen

Threat Hunting ist die Suche nach Angreifern, für die es noch keinen Alarm gibt. Während das SOC auf Regeln wartet, die anschlagen, stellt der Threat Hunter eine Frage an die eigenen Daten: Wenn jemand bei uns wäre und Technik X benutzen würde, welche Spuren müssten wir sehen? Dann sucht er genau danach. In diesem Beitrag erfährst du, was Threat Hunting von Alarmbearbeitung und IOC-Abgleich unterscheidet, wie ein Hunt abläuft, wie du eine brauchbare Hypothese formulierst, welche Techniken und Daten du brauchst und woran der Einstieg in den meisten Organisationen scheitert.

Was Threat Hunting ist und was nicht

Drei Merkmale machen Threat Hunting aus: Es ist proaktiv, also nicht durch einen Alarm ausgelöst. Es ist hypothesengetrieben, also mit einer konkreten Annahme, was gesucht wird. Und es wird von Menschen geführt, die Werkzeuge nutzen, nicht von Werkzeugen, die Menschen benachrichtigen. Das Ziel ist die Verkürzung der Zeit zwischen Einbruch und Entdeckung, und das Ergebnis eines Hunts sind zwei Dinge: entweder ein Fund, der an den Incident-Response-Prozess übergeben wird, oder die Erkenntnis, dass die Technik nicht gefunden wurde, samt einer neuen Erkennungsregel, damit beim nächsten Mal ein Alarm entsteht statt eines Hunts.

Was oft als Threat Hunting bezeichnet wird, aber keines ist: Alarme aus dem SIEM abarbeiten, das ist Triage. Eine IOC-Liste gegen die Logs laufen lassen, das ist Abgleich mit Threat Intelligence und lässt sich automatisieren. Schwachstellen scannen, das ist Schwachstellenmanagement. Hunting beginnt dort, wo es keinen Indikator gibt, nur eine Annahme über Verhalten.

Drei Arten von Hunts

• Intelligence-getrieben. Ein Bericht beschreibt, wie eine Gruppe deine Branche angreift. Die Hypothese folgt aus dem Bericht: Diese Gruppe nutzt geplante Aufgaben zur Persistenz, also suchen wir nach geplanten Aufgaben, die Skripte aus Benutzerverzeichnissen starten.
• Technik-getrieben. Die Hypothese kommt aus MITRE ATT&CK: Wir nehmen eine Technik, die für unsere Umgebung relevant ist und für die wir keine Erkennung haben, und prüfen, ob sie in den letzten 90 Tagen vorgekommen ist.
• Daten-getrieben. Keine konkrete Technik, sondern die Frage: Was ist in diesen Daten ungewöhnlich? Seltene Prozess-Eltern-Kind-Paare, Dienste, die nur auf einem System existieren, Konten, die sich nachts anmelden. Anspruchsvoller, weil die Definition von „ungewöhnlich“ eine Vorstellung von „normal“ voraussetzt.

Der Ablauf eines Hunts

Der niederländische Finanzsektor hat mit TaHiTI (Targeted Hunting integrating Threat Intelligence) eine der wenigen frei veröffentlichten Methodiken vorgelegt, an der sich das Vorgehen gut erklären lässt. Sie kennt drei Phasen:

1. Initiieren. Hypothesen entstehen aus Threat Intelligence, aus ATT&CK, aus Vorfällen und aus dem Bauchgefühl erfahrener Analysten. Sie landen in einem Backlog und werden nach Risiko priorisiert: Wie wahrscheinlich ist die Technik bei uns, wie groß wäre der Schaden, wie gut ist sie bereits durch Regeln abgedeckt?
2. Jagen. Die Hypothese wird präzisiert, die nötigen Daten werden bestimmt, die Suche wird ausgeführt und verfeinert. Ein Fund führt zur Eskalation; oft führt ein Zwischenergebnis zu einer neuen Hypothese, das nennt TaHiTI Pivoting.
3. Abschließen. Dokumentation: Hypothese, Daten, Abfragen, Ergebnis. Übergabe an Incident Response, wenn etwas gefunden wurde. Übergabe an Detection Engineering, damit aus der Abfrage eine Regel wird. Aktualisierung des Backlogs.

Andere Rahmenwerke, etwa PEAK mit den Phasen Prepare, Execute und Act with Knowledge, beschreiben denselben Kreis mit anderen Worten. Entscheidend ist der dritte Schritt: Ein Hunt ohne Dokumentation und ohne neue Regel war ein Nachmittag mit dem SIEM.

So formulierst du eine Hypothese

Eine brauchbare Hypothese hat vier Teile: den Angreifer mit seinem Ziel, die Technik, die Datenquelle und das erwartete Muster. „Angreifer im Netz finden“ ist keine Hypothese. „Ein Angreifer mit Zugriff auf ein Benutzerkonto würde Kerberoasting nutzen, um Dienstkonten-Passwörter offline zu knacken; das würde auf den Domain Controllern als Häufung von Event 4769 mit Verschlüsselungstyp RC4 für viele verschiedene Dienstkonten innerhalb weniger Sekunden sichtbar sein“ ist eine. Drei weitere Beispiele, die sich mit den üblichen Windows-Ereignissen prüfen lassen:

• Ein Angreifer, der Werkzeuge nachladen will, ohne Schadsoftware mitzubringen, würde Bordmittel wie certutil, bitsadmin oder PowerShell mit einer URL aufrufen. Datenquelle: Event 4688 mit Befehlszeile. Muster: diese Programme mit http in den Argumenten.
• Ein Angreifer, der sich seitlich bewegt, würde RDP von Arbeitsplatz zu Arbeitsplatz nutzen. Datenquelle: Event 4624 mit Anmeldetyp 10. Muster: Quell- und Zielsystem sind beide Clients, keine Admin-Systeme.
• Ein Angreifer, der Daten über DNS ausschleust, würde sehr viele, sehr lange Anfragen an eine einzelne Domain stellen. Datenquelle: Sysmon Event 22 oder DNS-Server-Logs. Muster: Anfragen mit über 50 Zeichen Subdomain, tausendfach, an eine Domain, die sonst niemand auflöst.

Techniken: Stacking, Baselining, Ausreißer

Die meisten Hunts laufen auf eine von drei analytischen Techniken hinaus. Stacking zählt, wie oft etwas vorkommt, und schaut sich das Seltene an: Welche Eltern-Kind-Prozesskombination gibt es in 90 Tagen nur dreimal? Welcher Dienst existiert nur auf einem einzigen Server? Angreifer sind selten, ihre Spuren auch. Baselining legt fest, was normal ist, um Abweichungen zu erkennen: Wie viele Dienstinstallationen pro Woche sind üblich, welche Konten melden sich nie außerhalb der Arbeitszeit an? Gruppierung fasst zusammen, was zusammengehört: Alle Systeme, auf denen dasselbe unbekannte Binary liegt, sind wahrscheinlich Teil desselben Vorfalls.

Keine dieser Techniken braucht maschinelles Lernen. Eine Abfrage mit Gruppierung und Zählung im SIEM oder der EDR-Konsole reicht für den Anfang, und sie liefert in der Regel mehr als jedes Anomalie-Dashboard, weil der Hunter weiß, warum er fragt.

Was du dafür brauchst

• Daten mit Tiefe. Prozessstarts mit Befehlszeile, Anmeldungen, Netzwerkverbindungen pro Prozess, DNS. Ohne Endpunkt-Telemetrie bleibt das Hunting an der Oberfläche.
• Ein Werkzeug, das Fragen beantwortet. Die Suche im SIEM oder in der EDR-Konsole, mit Gruppierung, Zählung und Zeiträumen von mindestens 90 Tagen.
• Feste Zeit. Hunting „zwischen den Alarmen“ findet nicht statt. Ein fester Block pro Woche, in dem die Warteschlange jemand anders bearbeitet.
• Eine Abdeckungskarte. Damit du nicht jagst, was die Regeln ohnehin melden. Die ATT&CK-Karte aus dem Detection Engineering ist zugleich die Landkarte für das Hunting: Wo keine Erkennung ist, wird gejagt.
• Ein Backlog. Eine Liste offener Hypothesen mit Priorität, damit die Frage „was jagen wir heute“ nie neu entsteht.

Drei Hunts zum Nachmachen

Die Abfragen sind in Kusto-Syntax geschrieben, wie sie Microsoft Sentinel und Defender verwenden, weil sie sich gut lesen lässt; die Logik überträgt sich eins zu eins auf Splunk, Elastic oder die Visualisierungen in Wazuh, weil jede der drei nur zählt, gruppiert und filtert.

Hunt 1: Kerberoasting in den letzten 30 Tagen

Hypothese: Ein Angreifer mit einem beliebigen Domänenkonto hat Diensttickets für viele Dienstkonten angefordert, um deren Passwörter offline zu knacken. Daten: Event 4769 der Domain Controller. Muster: ein Konto fordert innerhalb weniger Minuten Tickets mit RC4-Verschlüsselung für mehrere verschiedene Dienste an.

SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4769 and TicketEncryptionType == "0x17"
| where ServiceName !endswith "$" and ServiceName != "krbtgt"
| summarize Dienste = dcount(ServiceName), Erste = min(TimeGenerated), Letzte = max(TimeGenerated)
    by TargetUserName, IpAddress, bin(TimeGenerated, 5m)
| where Dienste >= 5
| order by Dienste desc

Bewertung: Treffer mit alten Anwendungen, die tatsächlich RC4 brauchen, sind bekannt und wandern in eine Ausnahmeliste; alles andere ist ein Vorfall. Ergebnis: ob Fund oder nicht, die Abfrage wird als Regel mit Schwelle fünf und Zeitfenster fünf Minuten dauerhaft aktiviert, und die Dienstkonten mit RC4 kommen auf die Liste für die Umstellung auf AES.

Hunt 2: seltene Eltern-Kind-Prozesse

Hypothese: Ein Angreifer hat aus einer Office-Anwendung, einem Browser oder einem Systemdienst heraus etwas gestartet, was diese Programme sonst nie starten. Daten: Prozessstarts mit Elternprozess, also Sysmon Event 1, Event 4688 oder die EDR-Telemetrie. Muster: Kombinationen aus Elternprozess und Kindprozess, die in 30 Tagen auf der gesamten Flotte weniger als fünfmal vorkommen.

DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "outlook.exe", "msedge.exe", "chrome.exe", "wmiprvse.exe", "w3wp.exe")
| summarize Anzahl = count(), Hosts = dcount(DeviceName), Beispiel = any(ProcessCommandLine)
    by InitiatingProcessFileName, FileName
| where Anzahl <= 5
| order by Anzahl asc

Bewertung: Das ist Stacking in Reinform. Die Liste ist kurz, und jede Zeile bekommt eine Antwort: Softwareverteilung, Makro eines Fachbereichs, oder ein Angreifer. Word startet cmd, Outlook startet PowerShell, der Webserver-Prozess startet irgendetwas: das sind die Zeilen, die zuerst angeschaut werden. Ergebnis: Die harmlosen Kombinationen wandern in eine Baseline, die verdächtigen in eine Regel, die beim nächsten Auftreten sofort alarmiert.

Hunt 3: Beaconing im Netzwerkverkehr

Hypothese: Ein kompromittiertes System meldet sich in regelmäßigen Abständen bei einem Command-and-Control-Server. Daten: das conn.log von Zeek oder die Firewall-Logs. Muster: viele kleine Verbindungen von einem internen System zu derselben externen Adresse über viele Stunden, mit gleichmäßigen Abständen.

ZeekConn
| where TimeGenerated > ago(24h)
| where not(ipv4_is_private(id_resp_h))
| order by id_orig_h, id_resp_h, TimeGenerated asc
| extend Abstand = datetime_diff("second", TimeGenerated, prev(TimeGenerated))
| summarize Verbindungen = count(), Bytes = sum(orig_bytes), Mittel = avg(Abstand), Streuung = stdev(Abstand)
    by id_orig_h, id_resp_h, id_resp_p
| where Verbindungen >= 48 and Bytes < 1000000 and Streuung < Mittel * 0.2
| order by Streuung asc

Bewertung: Update-Dienste, Telemetrie und Monitoring-Agenten sehen genauso aus und stehen auf der Erlaubnisliste, die dieser Hunt beim ersten Durchlauf erst erzeugt. Was danach übrig bleibt, wird über Threat Intelligence, Zertifikat und Domainalter geprüft. Ergebnis: Die Erlaubnisliste und die Schwellen werden zur Regel; der Hunt selbst läuft danach wöchentlich mit den neuen Zielen als einzigem Blick.

Vorlage: so wird ein Hunt dokumentiert

Ein Hunt ohne Dokumentation wird in drei Monaten wiederholt, ohne dass jemand es merkt. Die Vorlage passt in ein Ticket oder eine Seite im Wiki und hat zehn Felder:

Das Feld „Datenquellen und Zeitraum“ mit dem Zusatz, was gefehlt hat, ist das wichtigste für die Zukunft: Jeder Hunt, der an fehlender Telemetrie scheitert, ist ein Argument für die nächste Logquelle im SIEM.

Wo deine Organisation steht

David Bianco, von dem auch die Pyramid of Pain stammt, hat ein Reifegradmodell für Threat Hunting beschrieben, das fünf Stufen kennt. Stufe 0 verlässt sich vollständig auf automatische Alarme. Stufe 1 nutzt Threat Intelligence, um nach Indikatoren zu suchen. Stufe 2 folgt veröffentlichten Hunting-Verfahren anderer. Stufe 3 entwickelt eigene Verfahren für die eigene Umgebung. Stufe 4 automatisiert erfolgreiche Hunts zu dauerhaften Erkennungen und nutzt die freie Zeit für neue Hypothesen. Die meisten Organisationen stehen zwischen 0 und 1 und glauben, sie stünden bei 2. Das realistische Ziel für ein SOC mittlerer Größe ist Stufe 2 mit Ausflügen nach 3: fremde Verfahren übernehmen, an die eigene Umgebung anpassen, dokumentieren, in Regeln überführen.

Woran der Einstieg scheitert

• Zu breite Hypothesen. „Suche nach seitlicher Bewegung“ ist ein Thema, keine Hypothese. Eine Technik, eine Datenquelle, ein Muster.
• Kein Ergebnis außer dem Fund. Wer nichts findet, hat nicht umsonst gejagt, wenn daraus eine Regel entsteht. Wer nichts dokumentiert, jagt in drei Monaten dasselbe noch einmal.
• Jagen, was schon alarmiert. Ohne Abdeckungskarte wird Zeit auf Techniken verwendet, für die es längst eine Regel gibt.
• IOC-Abgleich als Hunting. Der Abgleich bekannter Indikatoren ist nützlich, aber automatisierbar. Wer ihn als Hunting bucht, hat kein Hunting.
• Keine Zeit. Der häufigste Grund. Hunting ist die erste Tätigkeit, die gestrichen wird, wenn die Alarme zunehmen, und genau dann wäre sie am nötigsten.

Fazit

Threat Hunting ist die Antwort auf eine unbequeme Wahrheit: Regeln erkennen, was jemand vorher beschrieben hat, und Angreifer wissen das. Wer regelmäßig mit einer konkreten Hypothese in die eigenen Daten geht, findet entweder den Angreifer, der durch die Regeln gerutscht ist, oder die Lücke, durch die er rutschen würde. Beides ist ein Gewinn. Für den Einstieg reicht eine Hypothese pro Woche, eine Abfrage, ein dokumentiertes Ergebnis und eine neue Regel. Das Blue Team, das das ein Jahr durchhält, hat fünfzig Techniken geprüft, die vorher niemand angeschaut hat.