Hunting von Living-off-the-Land-Binaries unter Windows mit KQL

Ein faehiger Angreifer muss keine eigene Binary auf die Festplatte des Opfers werfen: er nutzt, was schon da ist. Rundll32, mshta, certutil, bitsadmin und regsvr32 sind legitime, von Microsoft signierte Werkzeuge, weshalb viele EDR-Loesungen ihre Ausfuehrungen als Rauschen behandeln. Diese Technik heisst Living off the Land, die Binaries selbst LOLBins, katalogisiert im offentlichen LOLBAS-Projekt. Das Basilisk-Team hat in den letzten sechs Monaten 47 Vorfaelle ausgewertet und in 31 davon stand mindestens ein LOLBin in der Kill Chain. Dieser Beitrag liefert die KQL-Abfragen, die wir in Microsoft Defender for Endpoint und Sentinel einsetzen, um solche Ausfuehrungen in handlungsfaehige Detektionen zu verwandeln, ohne das SOC mit False Positives zu fluten.

Was LOLBins sind und warum sie durchrutschen#

Ein LOLBin ist ein vorinstalliertes, signiertes Programm, das eine unbeabsichtigte, angreifernutzliche Nebenfunktion besitzt: Download, Codeausfuehrung, Persistenz oder das Umgehen von Application Control. Weil die Signatur von Microsoft stammt, greifen naive Allowlists nicht, und ein reiner Prozessname als Indikator ist wertlos. Die Detektion verschiebt sich damit von welche Binary auf welche Kommandozeile, welcher Elternprozess, welches Zielverhalten. Genau deshalb ist die Prozess-Kommandozeile (ProcessCommandLine) das wichtigste Feld in jeder Hunting-Abfrage, gefolgt von InitiatingProcessFileName und den nachgelagerten Netzwerkverbindungen desselben Prozesses. Merke dir die Faustregel: ein LOLBin ist erst dann verdachtig, wenn mindestens zwei unabhaengige Signale zusammenfallen, etwa ein seltener Elternprozess und eine externe URL. Ein einzelnes Signal ist fast immer legitime Automatisierung, und wer darauf allein alarmiert, verbrennt das Vertrauen des SOC in wenigen Tagen.

Zuerst die Baseline verstehen#

Bevor eine Regel geschrieben wird, muss die Baseline der Umgebung verstanden sein. Wir starten einen breiten Hunt auf DeviceProcessEvents, gruppieren nach FileName und zaehlen Ausfuehrungen ueber 30 Tage pro Host, um das Normalbild der Flotte zu erfassen. Bei einem Kunden mit 8.200 Endpoints tauchte mshta.exe nur auf 0,4% der Maschinen auf, alle im Marketing fuer einen Legacy-Report. Jede mshta-Ausfuehrung ausserhalb dieser Gruppe verdient damit einen P2-Alert. Dieser Ansatz statistischer Seltenheit ist das Fundament modernen Huntings und passt zu Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel, wo wir vom rohen Indikator zur Git-versionierten Sigma-Regel gehen.

Rundll32 mit verdaechtiger Kommandozeile#

Die empfohlene Basisabfrage fuer rundll32 lautet: DeviceProcessEvents | where FileName =~ 'rundll32.exe' | where ProcessCommandLine has_any ('javascript:', 'shell32.dll,Control_RunDLL', 'mshtml,RunHTMLApplication', '.cpl,', 'url.dll,OpenURL') | where InitiatingProcessFileName !in~ ('explorer.exe', 'svchost.exe') | project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName. Gegen MITRE ATT&CK T1218.011 getestet, fing sie 9 von 10 Cobalt-Strike-Beacon-Ausfuehrungen im SMB-Pivot-Modus. Die Feinabstimmung erfolgt durch Ausschluss legitimer Elternprozesse je Abteilung, was wir in Adversary Emulation mit Caldera und MITRE ATT&CK im Unternehmenslab dokumentieren. Achte besonders auf rundll32 ohne DLL-Argument, ein starkes Signal fur Prozess-Hollowing.

Certutil: das Schweizer Taschenmesser#

Certutil verdient ein eigenes Kapitel. Es laedt Dateien (-urlcache), dekodiert Base64 (-decode) und berechnet Hashes. Unsere Hunting-Abfrage: DeviceProcessEvents | where FileName =~ 'certutil.exe' | where ProcessCommandLine has_any ('-urlcache', '-decode', '-decodehex', '-ping', 'http://', 'https://') | where ProcessCommandLine !contains 'CertificateServices' | extend Stage = case(ProcessCommandLine has '-decode', 'staging', ProcessCommandLine has 'http', 'download', 'recon'). 2025 sahen wir certutil als zweite Stage in Kampagnen, die mit Makro-Phishing begannen, ein Ablauf, den wir aus offensiver Sicht in Initial Access Simuliert: Makros, LNK und ISO im Isolierten Windows-11-Lab beschreiben und den Blue Teams mit AD-Event 4688 korrelieren muessen.

Mshta und regsvr32: Remote-Scriptlets#

Bei mshta und regsvr32 (T1218.010) aendert sich die Logik. Mshta, das eine URL ausfuehrt, ist ausserhalb von Hilfesystemen fast immer boesartig: DeviceProcessEvents | where FileName =~ 'mshta.exe' | where ProcessCommandLine has_any ('http://','https://','.hta','javascript:','vbscript:') liefert in den meisten Flotten eine False-Positive-Rate unter 2%. Regsvr32 mit /i: und einer URL (die Squiblydoo-Technik) faengst du analog uber ProcessCommandLine has_any ('/i:http','scrobj.dll'). Beide profitieren stark von der Korrelation mit der Netzwerkschicht, weil ein lokal harmloser Aufruf durch eine ausgehende Verbindung zum wahren Alarm wird.

Multi-Table-Korrelation mit dem Netzwerk#

Kombiniere den Prozessfund mit DeviceNetworkEvents im gleichen 60-Sekunden-Fenster ueber einen Join auf DeviceId und die Prozess-ID, um zu bestaetigen, dass die Verbindung tatsaechlich vom verdaechtigen Prozess kam: DeviceProcessEvents | where FileName =~ 'mshta.exe' | join kind=inner (DeviceNetworkEvents) on DeviceId, InitiatingProcessId | where NetworkTimestamp between (Timestamp .. Timestamp + 60s). Diese Multi-Table-Korrelation trennt Hunting von reinem Log-Mining und schliesst an Lateral Movement im Lab: SMB, WMI und WinRM mit Detection-Fokus an, wo Angreifer LOLBins via Remote-WMI verketten und die Netzwerksicht den entscheidenden Kontext liefert.

Das Trio Bitsadmin, msiexec und wmic#

Bitsadmin, msiexec /i http und Remote-wmic bilden das Trio, das Standardregeln am haeufigsten unterlaeuft. Fuer msiexec nutzt unsere Lieblingsheuristik ProcessVersionInfoOriginalFileName, um umbenannte Binaries zu erkennen, was Tools wie Sliver standardmaessig tun: where FileName =~ 'msiexec.exe' and ProcessVersionInfoOriginalFileName !~ 'msiexec.exe'. Siehe die Operatorperspektive in C2-Infra mit Sliver im Isolierten Lab fur Defensive Forschung Aufbauen. Bitsadmin faengst du ueber ProcessCommandLine has_any ('/transfer','/create','/addfile'), wmic ueber process call create und /node: fuer Remote-Ausfuehrung.

PowerShell und kodierte Befehle als Nachbarn#

LOLBins treten selten allein auf; meist sitzt eine PowerShell-Stufe daneben. Jage kodierte Befehle mit DeviceProcessEvents | where FileName in~ ('powershell.exe','pwsh.exe') | where ProcessCommandLine has_any ('-enc','-EncodedCommand','-e ','FromBase64String','IEX','Invoke-Expression','-w hidden','-nop'). Die eigentliche Goldquelle ist jedoch das Modul-Logging: aktiviere DeviceEvents-Telemetrie fuer ScriptBlock (Event 4104) und suche dort nach Klartext-Payload, den -enc auf der Kommandozeile verbirgt. Ein rundll32 oder mshta, dessen Elternprozess eine kodierte PowerShell ist, ist ein nahezu sicherer Beacon-Loader und verdient sofort einen hohen Schweregrad statt einer stillen Ablage.

Payload-Drop ueber DeviceFileEvents korrelieren#

Ein certutil-Download ohne die anschliessend geschriebene Datei ist nur die halbe Geschichte. Verbinde die Ausfuehrung mit DeviceFileEvents, um die tatsaechlich abgelegte Payload zu sehen: joine ueber DeviceId und InitiatingProcessId und filtere auf frische FileCreated-Ereignisse in %TEMP%, %APPDATA% oder C:\Users\Public. Reichere den Treffer mit dem SHA256 der Datei an und schlage ihn gegen deine Threat-Intel-Quellen nach; eine unsignierte, gerade geschriebene ausfuehrbare Datei aus einem LOLBin heraus ist ein Befund, der Isolation des Hosts rechtfertigt. Genau diese Kette aus Prozess, Netzwerk und Datei macht aus einem schwachen Indikator eine belastbare Story fuer den Incident-Report.

Operationalisierung in Sentinel und Sigma#

In Sentinel materialisieren wir diese Hunts als Analytics Rules mit Entity Mapping auf Account und Host, 5-Minuten-Frequenz und 1-Stunde-Suppression pro Entitaet, was das Rauschen beherrschbar haelt. Jede Regel bekommt ein MITRE-Tactic/Technique-Tag, damit die Abdeckung messbar wird. Wir exportieren die Logik immer nach Sigma fuer SIEM-Portabilitaet, dieselbe Philosophie wie in Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus. So laeuft dieselbe Detektion, ob der Kunde Defender, Elastic oder Splunk fahrt, und das Red Team validiert sie direkt gegen emulierte Angriffe.

False Positives zaehmen und Fallstricke#

Der haeufigste Fehler ist, LOLBins eliminieren zu wollen; sie sind Teil des OS und werden legitim genutzt. SCCM ruft regelmaessig msiexec, Softwareverteilung nutzt bitsadmin, Backup-Jobs starten certutil fuer Hashing. Tune deshalb nach Elternprozess und Kontext, nie nach Binary allein. Ein weiterer Fallstrick: has versus contains in KQL; has arbeitet tokenbasiert und ist schneller, matcht aber keine Teilstrings, was bei verketteten Kommandozeilen zu Luecken fuehrt. Miss die False-Positive-Rate jeder Regel vor dem Scharfschalten und dokumentiere jede Ausnahme mit Begruendung.

Checkliste#

Vor dem Ausrollen jeder LOLBin-Regel: (1) Baseline ueber mindestens 30 Tage erhoben; (2) Filter auf ProcessCommandLine, nicht nur FileName; (3) Elternprozess-Ausschluesse je Abteilung dokumentiert; (4) Netzwerk-Korrelation wo sinnvoll; (5) umbenannte Binaries ueber OriginalFileName abgedeckt; (6) MITRE-Tag gesetzt; (7) Suppression pro Entitaet konfiguriert; (8) nach Sigma exportiert; (9) gegen einen emulierten Angriff validiert; (10) False-Positive-Rate gemessen und unter Schwelle; (11) jede Ausnahme mit Begruendung und Ablaufdatum im Ticket hinterlegt; (12) die Regel einem konkreten Alarm-Playbook mit Triage-Schritten zugeordnet.

FAQ#

Reicht das Blockieren der LOLBins per WDAC? Selten, weil viele geschaeftskritisch sind; besser ist gezieltes Blocken der gefaehrlichen Aufrufe (etwa certutil -urlcache) plus Detektion. Warum nicht einfach jeden certutil-Download alarmieren? In grossen Umgebungen erzeugt das Hunderte tagliche Treffer aus legitimer Automatisierung; erst die Kombination aus seltenem Elternprozess, externer URL und fehlender Signatur der Zieldatei macht den Alarm belastbar. Brauche ich P1 fuer diese Tabellen? DeviceProcessEvents und DeviceNetworkEvents gehoeren zu Defender for Endpoint P2, in Sentinel via Data Connector.

Wie gehe ich mit Persistenz-LOLBins um? schtasks.exe und sc.exe sind selbst LOLBins, wenn sie neue Tasks oder Dienste anlegen, die auf ein Skript oder einen ungewohnten Pfad zeigen. Jage sie mit DeviceProcessEvents | where FileName in~ ('schtasks.exe','sc.exe') | where ProcessCommandLine has_any ('/create','create','binPath=') | where ProcessCommandLine has_any ('powershell','cmd /c','\Users\','\Temp\','http'). Was, wenn der Angreifer die Binary umbenennt? Deshalb filterst du nie allein auf FileName; die Kombination aus ProcessVersionInfoOriginalFileName, der Kommandozeilen-Signatur und dem Elternprozess ueberlebt das Umbenennen, waehrend ein reiner Namensfilter blind wird.

Zum Abschluss konkret: Fuehren Sie heute in Ihrem Tenant aus: DeviceProcessEvents | where Timestamp > ago(30d) | where FileName in~ ('rundll32.exe','mshta.exe','certutil.exe','regsvr32.exe','bitsadmin.exe','msiexec.exe') | summarize Total=count(), Hosts=dcount(DeviceName) by FileName, bin(Timestamp, 1d) | order by Timestamp desc. Das Ergebnis ist Ihre Baseline-Karte. Alles, was um 3 Standardabweichungen abweicht, wird Regelkandidat. Ein LOLBin wird nicht eliminiert, sondern diszipliniert beobachtet, und Teams, die die Baseline als lebendes Produkt pflegen, erkennen Intrusionen in Stunden statt in Monaten. Plane die Neuberechnung der Baseline als wiederkehrenden Job ein, denn Softwareverteilung, neue Abteilungen und Migrationen verschieben das Normalbild staendig; eine sechs Monate alte Baseline erzeugt genauso viele False Positives wie gar keine. Versioniere jede Regel im Git neben ihrer Sigma-Fassung, verlinke sie mit der emulierten ATT&CK-Technik und lass das Red Team sie in jedem Zyklus erneut ausloesen, damit stille Regressionen sofort auffallen.