Threat Hunting mit Hypothesen: drei Hunts von der Idee zum Ergebnis

Threat Hunting mit Hypothesen ist die Vertiefung des Threat-Hunting-Einstiegs: Dort geht es um das Prinzip, hier um die Praxis. Der Unterschied zwischen Hunting und dem Bearbeiten von Alarmen ist die Richtung. Ein Alarm kommt zu dir; ein Hunt geht vom Analysten aus, der eine Annahme formuliert und gezielt nach ihren Spuren sucht, ohne dass ein Alarm ihn dazu auffordert. Der Motor ist die Hypothese: eine konkrete, prüfbare Aussage der Form „Wenn ein Angreifer X täte, dann wäre Y in den Daten sichtbar.“ Dieser Beitrag zeigt das an drei vollständig durchgespielten Hunts, jeder mit Hypothese, Datenquelle, Abfrage in Pseudocode, dem erwarteten Rauschen und der Entscheidung am Ende. Wer die drei nachvollzieht, hat das Muster, nach dem sich beliebig viele weitere bauen lassen.

Der Aufbau eines Hunts

Jeder Hunt folgt demselben Gerüst. Erstens die Hypothese, abgeleitet aus einer Technik nach ATT&CK, einem Vorfall oder einem Threat-Intelligence-Bericht. Zweitens die Datenquelle: Welches Log zeigt die Spur, und ist es überhaupt angebunden? Drittens die Abfrage, die das erwartete Muster aus den Daten filtert. Viertens die Analyse: Das Ergebnis ist fast nie ein fertiger Treffer, sondern eine Liste, die noch Rauschen enthält und die man auf das Verdächtige eingrenzt. Fünftens die Entscheidung: ein echter Fund, der in den Incident-Response-Prozess übergeht; eine neue Erkennungsregel, wenn das Muster tragfähig ist; oder ein sauberes Ergebnis, das die Hypothese für diesmal entkräftet und dokumentiert wird, damit der Hunt wiederholbar bleibt. Wichtig ist die Dokumentation: Ein Hunt ohne festgehaltene Hypothese, Abfrage und Ergebnis ist eine einmalige Suche; ein dokumentierter Hunt ist ein wiederholbarer Baustein.

Hunt 1: Verdächtige geplante Aufgaben

Hypothese: Ein Angreifer, der Persistenz eingerichtet hat, nutzt eine geplante Aufgabe, die ein Skript oder Bordmittel aus einem Benutzer- oder Temp-Verzeichnis startet. Wenn das so ist, gibt es Event 4698 mit einer Aktion, die auf powershell, cmd oder einen solchen Pfad zeigt, angelegt von einem Konto, das normalerweise keine Aufgaben anlegt.

Datenquelle: Event 4698 aus dem Security-Log der Endpunkte, wie im Beitrag Persistenz erkennen beschrieben.

Ereignis 4698 der letzten 30 Tage
filtere: TaskContent enthält powershell, cmd.exe, mshta,
         rundll32, -enc, http, \Users\ oder \Temp\
gruppiere nach: anlegendem Konto, Zielsystem
sortiere nach: Häufigkeit aufsteigend (das Seltene zuerst)

Analyse: Die Softwareverteilung und die Administration legen laufend Aufgaben an; diese kommen von bekannten Konten und in großer Zahl und werden ausgeblendet. Übrig bleiben die seltenen Fälle: eine Aufgabe, die ein einzelnes Benutzerkonto auf einem Arbeitsplatz angelegt hat, mit einem Skript aus dem Temp-Verzeichnis. Genau die schaut man sich einzeln an.

Entscheidung: Findet sich eine solche Aufgabe mit bösartigem Inhalt, ist es ein Fund und der Incident-Response-Prozess beginnt. Findet sich ein wiederkehrendes, aber legitimes Muster, etwa ein bestimmtes Verwaltungsskript, wird es als Ausnahme dokumentiert und aus dem Hunt ausgeblendet. Ist das Muster tragfähig genug, wird aus dem Hunt eine dauerhafte Sigma-Regel, und der Hunt hat seine beste Wirkung erzielt: Er hat eine Erkennung geboren.

Hunt 2: Ungewöhnliche übergeordnete Prozesse

Hypothese: Nach einem erfolgreichen Phishing startet der bösartige Code aus der Office-Anwendung oder dem Mail-Programm heraus. Wenn das so ist, gibt es einen Prozess wie powershell, cmd oder wscript, dessen übergeordneter Prozess winword, excel, outlook oder ein Browser ist, eine Kombination, die im Normalbetrieb fast nie vorkommt.

Datenquelle: Sysmon Event 1 oder Event 4688 mit übergeordnetem Prozess und Befehlszeile.

Sysmon 1 der letzten 14 Tage
filtere: ParentImage endet auf winword.exe, excel.exe,
         outlook.exe, msedge.exe, chrome.exe
und:     Image endet auf powershell.exe, cmd.exe, wscript.exe,
         mshta.exe, rundll32.exe
gruppiere nach: Zielsystem, Benutzer, Befehlszeile
sortiere nach: Häufigkeit aufsteigend

Analyse: Diese Kombination ist so selten, dass die Ergebnisliste meist kurz ist. Ein paar legitime Fälle gibt es: manche Office-Add-ins und Unternehmensmakros starten Skripte. Die kommen wiederkehrend von vielen Systemen und mit derselben Befehlszeile und werden ausgeblendet. Übrig bleibt das Einmalige: eine kodierte PowerShell, gestartet aus Word auf einem einzelnen Rechner. Das ist mit hoher Wahrscheinlichkeit der Moment nach dem Klick, den der Beitrag zum Phishing-Vorfall beschreibt.

Entscheidung: Ein solcher Fund ist fast immer echt und geht sofort in die Reaktion, oft mit Isolierung des Endpunkts. Weil die Trefferquote hoch und das Rauschen niedrig ist, eignet sich dieser Hunt besonders gut, um zu einer dauerhaften Alarmregel zu werden. Er ist ein Musterbeispiel dafür, wie aus einer Hunting-Hypothese eine der wertvollsten Erkennungsregeln wird.

Hunt 3: Seltene ausgehende Verbindungen

Hypothese: Ein Command-and-Control-Kanal spricht mit einem Server, mit dem sonst niemand im Unternehmen spricht. Wenn das so ist, gibt es ausgehende Verbindungen zu einer Zieladresse oder Domain, die in der gesamten Umgebung nur von einem oder sehr wenigen Systemen kontaktiert wird, oft in regelmäßigen Abständen.

Datenquelle: Die Verbindungsprotokolle aus Zeek (conn.log und dns.log) oder die Firewall-Logs.

Ausgehende Verbindungen der letzten 7 Tage
zähle pro Zieldomain: Anzahl verschiedener interner Quellsysteme
behalte: Domains mit nur 1 bis 2 Quellsystemen
schließe aus: bekannte gute Domains (Allowlist)
für die verbleibenden: prüfe Regelmäßigkeit der Abstände
              und Alter der Domain

Analyse: Dieser Hunt ist der rauschigste der drei, weil es viele legitime Gründe für seltene Verbindungen gibt: die Software eines einzelnen Nutzers, ein Nischendienst, eine neue Anwendung. Deshalb ist die Anreicherung entscheidend: Eine frisch registrierte Domain, ein regelmäßiger Takt (das typische Beaconing) und eine Zieladresse in einem Hosting-Netz erhöhen den Verdacht. Die Threat Intelligence hilft, die Kandidaten zu bewerten. Was übrig bleibt, wird auf dem Quellsystem gegengeprüft: Welcher Prozess baut die Verbindung auf?

Entscheidung: Bestätigt sich ein C2-Kanal, ist es ein Fund. Oft aber endet dieser Hunt mit einem sauberen Ergebnis: Die seltenen Verbindungen erweisen sich als legitim, und die Hypothese ist für diesmal entkräftet. Das ist kein Misserfolg. Ein Hunt, der nichts findet, hat einen Bereich der Umgebung als sauber bestätigt und die Allowlist verbessert, und beim nächsten Durchlauf ist er schneller. Genau deshalb gehört auch das negative Ergebnis dokumentiert.

Woher die Hypothesen kommen

Die drei Hunts zeigen das Muster; die Kunst ist, laufend gute Hypothesen zu haben. Die ergiebigsten Quellen: die Techniken aus ATT&CK, sortiert nach den Gruppen, die für die eigene Branche relevant sind; die Lücken in der eigenen Abdeckungskarte, also Techniken ohne Erkennungsregel; frische Threat-Intelligence-Berichte, die ein neues Verhalten beschreiben; und die eigenen Vorfälle, aus denen sich fragen lässt, ob dasselbe woanders unbemerkt passiert ist. Ein gutes Hunting-Programm führt eine Liste offener Hypothesen und arbeitet sie ab, statt auf Eingebung zu warten. Und weil jeder tragfähige Hunt in eine Regel münden sollte, ist Hunting eng mit dem Detection Engineering verzahnt: Der Hunt findet das Muster, das Detection Engineering macht daraus eine dauerhafte Erkennung.

Fazit

Threat Hunting ist keine Magie, sondern ein handwerkliches Gerüst: eine prüfbare Hypothese, die richtige Datenquelle, eine Abfrage, die Analyse des Rauschens und eine Entscheidung am Ende. Die drei durchgespielten Hunts, verdächtige geplante Aufgaben, ungewöhnliche übergeordnete Prozesse und seltene ausgehende Verbindungen, sind Vorlagen, nach denen sich beliebig viele weitere bauen lassen. Der größte Wert entsteht, wenn ein Hunt in eine dauerhafte Regel mündet, denn dann findet die Erkennung künftig automatisch, was der Analyst einmal von Hand gesucht hat. Für ein Blue Team ist Hunting die Tätigkeit, die den Blick vom eingehenden Alarm zur aktiven Suche wendet, und die aus Analysten der ersten Linie die Detection Engineers von morgen macht.