Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel

Threat Hunting scheitert, wenn es ein Bauchgefuehl bleibt. Ein Analyst grept nach einem boesen Hash, findet nichts und erklaert die Umgebung fuer sauber, was nur beweist, dass ein Artefakt fehlt. Das Basilisk-Team betreibt Hunting als Engineering-Pipeline: eine Hypothese als portable Sigma-Regel formuliert, zu einer Elastic-Query kompiliert, gegen echte Telemetrie validiert, getunt und dann zu einer stehenden Detektion befoerdert. Dieser Text geht den ganzen Weg vom Indikator zur Detektion mit konkreten Regeln, Queries und Tuning-Schritten, die du heute Abend im Lab reproduzieren kannst, und ist so gebaut, dass er mit einer Emulationsquelle paart, damit du etwas Echtes jagst statt in einen leeren Index zu starren.

Vom Indikator zur Detektion: die Pyramid of Pain

David Biancos Pyramid of Pain ist das Denkmodell, das Hunting den Aufwand wert macht. Hashes und IPs sitzen unten: trivial fuer einen Angreifer zu aendern, also verfaellt eine darauf gebaute Jagd in Stunden. Domains und Netzartefakte sind etwas haerter. Oben sitzen Tools und TTPs, die Taktiken, Techniken und Prozeduren, die ein Gegner neu bauen muesste, um auszuweichen, was fuer ihn teuer und fuer dich dauerhaft ist. Gutes Hunting zielt auf Verhalten, nicht auf Indikatoren: nicht 'finde Hash X', sondern 'finde jeden Prozess, der aus einem Office-Dokument einen Skript-Interpreter startet und dann eine ausgehende Verbindung aufbaut'. Sigma existiert genau dafuer, diese Verhaltenslogik einmal auszudruecken und ueber jedes Backend laufen zu lassen, damit deine geistige Arbeit nicht an eine einzige Query-Sprache gebunden ist.

Anatomie einer Sigma-Regel

Eine Sigma-Regel ist ein kleines YAML-Dokument mit festem Skelett. Der logsource-Block deklariert die noetige Telemetrie, etwa product: windows und category: process_creation, was auf Sysmon Event ID 1 oder Windows 4688 abbildet. Der detection-Block haelt eine oder mehrere benannte Selektionen und eine condition, die sie mit boolescher Logik verbindet. Eine minimale LOLBin-Regel definiert selection als Image|endswith: '\\certutil.exe' zusammen mit CommandLine|contains: '-urlcache' und setzt dann condition: selection. Ergaenze eine falsepositives-Liste und ein level, damit die Triage einen Treffer gewichten kann, und tagge sie mit der ATT&CK-Technik, die sie abdeckt. Die entscheidende Disziplin: eine Regel drueckt ein testbares Verhalten aus, mit Feldnamen aus einem Schema, das du wirklich ausfuehrst, nicht aus einem Blog-Screenshot.

Den Elastic-Stack aufsetzen

Du brauchst Telemetrie, bevor du Regeln brauchst. Stelle Elasticsearch und Kibana bereit, roll dann Endpunkte mit dem ueber Fleet verwalteten Elastic Agent aus und schicke die System- und Windows-Integrationen, sodass Prozesserstellung, Netzwerk- und Authentifizierungsereignisse in Indizes landen, die auf das Elastic Common Schema (ECS) normalisiert sind. ECS ist der Dreh- und Angelpunkt: es benennt Vendor-Felder in stabile Namen wie process.command_line, process.parent.name und destination.ip um, sodass eine einmal geschriebene Query weiter funktioniert, waehrend Quellen sich aendern. Unter Windows deploye Sysmon mit einer kuratierten Konfiguration (eine gepflegte Community-Config ist der vernuenftige Standard), denn das native Audit-Log ist fuer Verhaltens-Hunting zu grob. Pruefe die Aufnahme, indem du bestaetigst, dass ein Test-certutil in Discover mit gefuelltem process.command_line auftaucht, bevor du irgendeiner Regel traust.

Sigma auf ein Elastic-Backend kompilieren

Sigma ist portabel, weil ein Compiler es in den Dialekt jedes Backends uebersetzt. Die moderne Toolchain ist sigma-cli, das pySigma mit einem Plugin pro Ziel treibt. Installiere das Elasticsearch-Plugin und fuehre dann sigma convert -t elasticsearch -p ecs_windows rules/certutil_urlcache.yml aus, um eine Elasticsearch-Query zu erzeugen, oder ziele mit -t eql auf die Event Query Language fuer Korrelation ueber Ereignisse. Eine Pipeline wie ecs_windows ist das, was die generischen Feldnamen der Regel auf deine ECS-Felder remappt, und sie wegzulassen ist der haeufigste Grund, warum eine konvertierte Regel trotz echtem Treffer null Ergebnisse liefert. Fuer Sequenzlogik drueckt Elastics EQL 'Prozess A, dann Netzwerk B durch denselben Prozess in N Sekunden' aus, waehrend das neuere ES|QL exzellent fuer explorative Aggregation waehrend der Jagd selbst ist.

Eine konkrete Jagd: Living-off-the-Land-Binaries

Angreifer vermeiden es, Malware abzulegen, indem sie signierte System-Binaries missbrauchen: certutil zum Download, mshta und rundll32 zur Ausfuehrung, regsvr32 fuer die Squiblydoo-Technik, bitsadmin fuer Transfer. Beginne breit in ES|QL: FROM logs-* | WHERE process.name IN ("certutil.exe","mshta.exe","regsvr32.exe") | STATS count = COUNT(*) BY process.command_line, host.name | SORT count ASC, lies dann die seltenen Kommandozeilen, denn normale Admin-Nutzung ist hochvolumig und repetitiv, waehrend der Aufruf des Angreifers ein einsamer Ausreisser ist. Pivotiere bei jedem Treffer auf den Elternprozess und die nachfolgende Netzverbindung, um die Absicht zu bestaetigen: ein certutil, dessen Elternprozess winword.exe ist und das unmittelbar danach zu einer externen IP verbindet, ist praktisch nie legitim. Die tieferen KQL-Muster je Binary, mit den gutartigen Baselines zum Abziehen, sind in Hunting von Living-off-the-Land-Binaries unter Windows mit KQL katalogisiert.

Hypothesengetriebenes Hunting, auf ATT&CK abgebildet

Jage nicht zufaellig; jage eine Hypothese, die an eine Technik gebunden ist. Formuliere sie als Satz: 'Wenn ein Gegner Kerberoasting (T1558.003) durchfuehrte, saehe ich einen Anstieg von TGS-Anfragen mit RC4-Verschluesselung von einem einzigen Konto.' Druecke das dann als Regel aus und teste es gegen emulierte Aktivitaet, denn eine Jagd, die du nicht auf Kommando ausloesen kannst, ist eine Jagd, der du nicht trauen kannst. Erzeuge das Verhalten sicher im Lab: fahre die Kerberoasting-Kette aus Active Directory Pentest: Kerberoasting Schritt fuer Schritt im GOAD Lab oder automatisiere eine ganze ATT&CK-Matrix mit Adversary Emulation mit Caldera und MITRE ATT&CK im Unternehmenslab. Fuer Ost-West-Bewegung stehen Telemetrie und Detektionen in Lateral Movement im Lab: SMB, WMI und WinRM mit Detection-Fokus.

Tuning und False Positives

Eine Regel, die bei jedem Backup-Job feuert, ist Rauschen, das Analysten darauf trainiert, Alarme zu ignorieren, was schlimmer ist als keine Regel. Tune mit Daten, nicht mit Raten: fahre den Kandidaten ueber 30 Tage Historie, lies jeden Treffer und charakterisiere die gutartigen Cluster, ein bestimmtes Service-Konto, ein Patch-Management-Tool, einen Monitoring-Agent. Kodiere diese als explizite Ausschluesse in der filter-Selektion der Regel, statt den Match zu verbreitern, sodass du bekanntes Gutes abziehst, ohne dich fuer die boesartige Variante zu blenden. Verfolge Precision als Zahl und verlange, dass eine Regel eine Schwelle nimmt, bevor sie befoerdert wird. Achte auch auf das Gegenteil: eine ueberoptimierte Regel mit so vielen Ausschluessen, dass der Angreifer einfach ein ausgeschlossenes Konto wiederverwendet. Tuning ist Subtraktion des Erklaerten, nie Subtraktion des Unbequemen.

Von der Jagd zur stehenden Detektion

Eine erfolgreiche Jagd ist eine Hypothese, die etwas fand oder eine Luecke bewies; so oder so soll sie nicht verdunsten. Befoerdere die validierte Sigma-Regel in dein Detection-as-Code-Repository, versioniere sie in Git mit ihren ATT&CK-Tags und False-Positive-Notizen und deploye sie als geplante Elastic-Detection-Regel, die einen Alarm mit dem Kontext ausloest, den ein Analyst braucht, um in einem Bildschirm zu triagieren. Schliesse den Kreis mit dem Red Team, sodass jede emulierte Technik entweder eine Detektion oder einen dokumentierten blinden Fleck liefert; dieser Feedback-Zyklus ist der ganze Sinn von Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus. Wenn eine Detektion im Ernstfall feuert, braucht der Responder Host-Level-Triage, wo DFIR unter Linux: Live-Triage mit UAC und Velociraptor uebernimmt.

Fallstricke und Checkliste

Die wiederkehrenden Fehler: eine Regel ohne die ECS-Pipeline konvertieren und dem Null-Ergebnis trauen; auf einer Datenquelle jagen, die du nie aufgenommen hast, sodass Abwesenheit nichts bedeutet; auf Hashes und IPs bauen, die verfallen; eine Regel schreiben, die du nicht auf Kommando ausloesen kannst; und eine laute Regel ausrollen, die das Vertrauen in die ganze Pipeline erodiert. Die Checkliste vor jeder Jagd: (1) Hypothese als Satz formuliert, an eine ATT&CK-Technik gebunden; (2) noetige Logquelle als vorhanden und in ECS gefuellt bestaetigt; (3) Sigma-Regel drueckt ein Verhalten aus, mit gelisteten False Positives; (4) mit der richtigen Pipeline kompiliert und die Query manuell plausibilisiert; (5) gegen emulierte Aktivitaet ausgeloest, um das Feuern zu beweisen; (6) ueber historische Daten getunt, Precision gemessen; (7) zu versioniertem Detection-as-Code befoerdert; (8) an das Purple-Team-Backlog zurueckverlinkt.

FAQ

Warum Sigma statt direkt Elastic-Queries zu schreiben? Portabilitaet und Review. Eine Sigma-Regel ist vendorneutral, sodass dieselbe Verhaltenslogik heute zu Elastic und morgen zu einem anderen SIEM kompiliert, und sie reviewt sich als kleines deklaratives Dokument statt einer wuchernden Query. Du fuehrst weiterhin natives ES|QL fuer interaktive Exploration; Sigma ist fuer die dauerhaften, teilbaren Detektionen, die jede einzelne Plattform ueberleben. Beide sind komplementaer, keine Konkurrenten. In der Praxis prototypst du eine Idee interaktiv in ES|QL, und sobald sie sich bewaehrt, giesst du sie in eine versionierte Sigma-Regel, damit das Wissen das Team ueberdauert und nicht in der Suchhistorie eines Einzelnen verschwindet.

Wie unterscheidet sich Hunting von Alerting? Alerting fuehrt bekannte Bad-Detektionen kontinuierlich aus; Hunting testet proaktiv Hypothesen ueber Aktivitaet, die noch keine Regel faengt, und sein Ergebnis ist oft eine neue Regel. Ein reifes Programm speist Hunting-Resultate ins Alerting, sodass die manuelle Jagd von heute die automatisierte Detektion von morgen wird. Produziert eine Jagd nie ein dauerhaftes Artefakt, eine Regel oder eine dokumentierte Luecke, war sie Unterhaltung, kein Engineering.

Fazit

Behandle Hunting als Pipeline, nicht als Ahnung. Ziele auf Verhalten hoch in der Pyramid of Pain, druecke jede Hypothese als einzelne Sigma-Regel aus, kompiliere sie mit der richtigen ECS-Pipeline zu Elastic und beweise, dass sie gegen emulierte Aktivitaet feuert, bevor du einem sauberen Ergebnis glaubst. Tune mit echten Daten, miss Precision und befoerdere Ueberlebende in versionierte Detektionen, die an einen Purple-Team-Zyklus zurueckverdrahtet sind. So gemacht, ist ein leeres Ergebnis aussagekraeftiger Beweis statt falscher Beruhigung, und jede Jagd hinterlaesst die Umgebung mit einer dauerhaften Detektion mehr oder einem ehrlich dokumentierten blinden Fleck. Diese Anhaeufung, nicht eine einzelne clevere Query, bewegt den Gegner tatsaechlich die Pyramide hinauf und aus deiner Reichweite.