Lateral Movement im Lab: SMB, WMI und WinRM mit Detection-Fokus

Lateral Movement ist keine Magie: ein Angreifer wiederverwendet gueltige Credentials innerhalb legitimer Protokolle. In unserem GOAD-Lab mit drei Windows Server 2019 und einem Windows 10 in der Domain sevenkingdoms.local pivotierten wir von einer Workstation zum DC in unter acht Minuten ausschliesslich ueber SMB, WMI und WinRM. Das Ziel ist nicht, Pivot nach Pivot zu drillen, sondern zu zeigen, wo jede Technik in den Logs schreit und wie man die Detection schreibt, bevor der echte Vorfall passiert. Das ist defensive Forschung: jeder Befehl unten lauft gegen eigene Maschinen, und jede Technik endet mit der Telemetrie und der Sigma-Regel, die sie faengt. Wenn deine Umgebung noch nicht steht, fang mit Active Directory Pentest: Kerberoasting Schritt fuer Schritt im GOAD Lab an.

Lab-Setup und der Assumed-Breach-Startpunkt

Wir nehmen einen Breach an: der Operator besitzt bereits ein gueltiges Credential, im Lab gewonnen durch LLMNR/NBT-NS-Poisoning mit Responder und anschliessendem Offline-Crack. Das ist realistisch, denn Lateral Movement startet fast nie bei null; es startet von einem einzigen wiederverwendeten Passwort oder einem erbeuteten Hash. Unsere GOAD-Topologie liefert kingslanding (DC), winterfell und meereen als Member-Server und eine Windows-10-Workstation als Patient Zero. Vor jeder Technik snapshotten wir jede VM, aktivieren Host-only-Networking, damit nichts leckt, und bestatigen, dass das SIEM ingestiert. Detection Engineering funktioniert nur, wenn die Telemetrie zuerst existiert, also wird das Lab telemetrie-zuerst und angriff-danach gebaut, immer in dieser Reihenfolge.

SMB-Execution: psexec und smbexec

Wir starteten mit klassischem SMB ueber impacket-psexec und smbexec. Nach dem Abgreifen eines NTLM-Hashes via Responder fuehrten wir psexec.py sevenkingdoms.local/jaime@10.0.10.10 -hashes :aad3b... aus und landeten als SYSTEM. Der Laerm ist enorm: RemComSvc-Service-Erstellung unter Event ID 7045, Binary-Write auf ADMIN$ loest Event ID 5145 mit ShareName ADMIN$ und einem RelativeTargetName mit zufaelligem .exe-Suffix aus. Die Sigma-Regel bleibt kurz: 7045 filtern, wenn ServiceFileName acht alphanumerische Zeichen plus .exe matcht, faengt 90 Prozent der psexec-Varianten ohne Binary-Signatur ab. smbexec ist leiser bei der Service-Erstellung, aber gespraechiger auf dem Command-Channel, spawnt cmd.exe /Q /c und schreibt Output in eine temporare Datei auf dem Share, was Event ID 5145 ebenfalls faengt.

WMI-Execution: wmiexec und der WmiPrvSE-Parent

WMI verschiebt die Logging-Oberflaeche. Mit impacket wmiexec.py oder direktem Invoke-WmiMethod entsteht der Kindprozess aus WmiPrvSE.exe statt services.exe. In Sysmon erscheint das als Event ID 1 mit ParentImage=C:\Windows\System32\wbem\WmiPrvSE.exe und CommandLine mit cmd.exe /Q /c, dem Standard-Fingerabdruck von wmiexec. Kombiniere das mit Event ID 3 (Netzwerkverbindung) vom Ziel auf Port 445 zum Output-Rueckkanal, und die Konfidenz ist hoch. Da kein Service erstellt wird, feuert die 7045-Regel hier nie, was genau der Grund ist, warum Teams, die nur Service-Installation beobachten, bei WMI blind bleiben. Fuer breiteres LOLBin-Hunting lohnt sich ein Blick in Hunting von Living-off-the-Land-Binaries unter Windows mit KQL.

WinRM-Execution: der Liebling der Operatoren

WinRM ist der Liebling moderner Operatoren, weil es wie legitimer Admin-Traffic aussieht. Wir feuerten Enter-PSSession -ComputerName dc01 -Credential $cred und ein remote Invoke-Command. Indikatoren liegen an drei Stellen: Microsoft-Windows-WinRM/Operational Event ID 91 (Session erstellt), Security Event ID 4624 mit LogonType 3 und AuthenticationPackage Negotiate, sowie Sysmon Event ID 1 mit ParentImage=wsmprovhost.exe. Eine gute Sigma-Regel korreliert wsmprovhost.exe als Parent jedes Prozesses ausser conhost.exe oder csrss.exe in einem Fuenf-Minuten-Fenster und eliminiert so den PowerShell-DSC-Baseline-Laerm. WinRM lauft ueber 5985/5986, also fuegt eine Netzwerkregel auf diesen Ports von einem Host, der nie zuvor WinRM sprach, ein weiteres billiges Signal hinzu.

Ein vierter Vektor: DCOM und Scheduled Tasks

Zwei weitere Vektoren runden jedes ehrliche Lab ab. DCOM-Execution ueber MMC20.Application oder ShellWindows spawnt Kinder aus mmc.exe oder explorer.exe mit unerwartetem Netzwerk-Parent und taucht selten in Junior-Detection-Sets auf; jage es, indem du eine remote 135/DCOM-Verbindung mit einem anomalen Kindprozess korrelierst. Remote Scheduled Tasks via schtasks /create /s oder die ATSVC-Pipe hinterlassen Security Event ID 4698 und einen TaskCache-Registry-Write. Wir fuegen beide dem Lab hinzu, damit die Detection-Bibliothek nicht auf die drei Schlagzeilen-Techniken schielt, denn ein echter Eindringling wechselt den Vektor, sobald einer laut wird, und ein Programm, das nur SMB abdeckt, trainiert Angreifer, WMI zu nutzen.

Die Kette erkennen, nicht die Technik

Der Teil, den niemand erzaehlt: eine isolierte Technik zu erkennen ist leicht, die ganze Kette zu erkennen ist, was zaehlt. Wir bauten ein Elastic-Playbook, das Responder-Hit, dann Hash-Crack, dann erstes Type-3-Logon mit NT-Hash auf einem Host, den der User nie zuvor beruehrt hat, dann wsmprovhost- oder WmiPrvSE-Spawn innerhalb von zehn Minuten verkettet. Diese zeitliche Korrelation senkte False Positives von 40 Alerts pro Tag auf 2 pro Woche in unserem simulierten Lab. Die Lektion: atomare Regeln ertranken Analysten, aber sequenzierte Regeln mit Zeitfenster heben den echten Angriff hervor und unterdrucken den Admin, der WinRM jeden Morgen legitim nutzt. Wenn du frisch mit Sigma und Elastic startest, deckt Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel die ELK-plus-sigmac-Pipeline ab, die wir als Basis nutzen.

Telemetrie-Voraussetzungen: Regeln ohne Logs sind Poesie

Wichtig: all das setzt anstaendige Telemetrie voraus. Ohne Sysmon mit Olaf- oder SwiftOnSecurity-Config, ohne aktiviertes PowerShell Script Block Logging (Event ID 4104) und ohne Sammeln der WinRM- und WMI-Activity-Kanaele werden deine Sigma-Regeln zu Poesie. In GOAD rollten wir eine minimale GPO aus, die diese vier Punkte auf jedem Host umlegt; dieselbe Baseline empfehlen wir in Windows 11 Hardening fuer Hochrisiko Arbeitsplaetze fuer Corporate-Endpoints. Telemetrie zuerst, Regel danach, immer in dieser Reihenfolge, sonst detektierst du den Angreifer am Schweigen von Logs, die nie ankommen. Bestatige die Ingestion mit einem Known-Good-Test, bevor du einer einzigen Regel traust.

Haufige Fallstricke, die Lateral-Movement-Detection blenden

Mehrere Fallstricke wiederholen sich. Erstens, Baselining gegen eine laute Woche: lief wahrend der Baseline ein Massen-Software-Rollout, wird psexec-artige Aktivitaet fuer immer whitelistet. Zweitens, Matching auf Prozessnamen statt Parent-Lineage, was jeder Operator durch Umbenennen des Payloads besiegt. Drittens, LogonType 9 (explizite Credentials) ignorieren, den Pass-the-Hash und runas /netonly erzeugen, ein weit saubereres Signal als die meisten glauben. Viertens, nur auf den ersten Hop alarmieren und verpassen, dass die interessante Bewegung der zweite und dritte ist. Funftens, vergessen, dass legitime Fernadministration fast identisch aussieht, also braucht jede Regel eine Allowlist bekannter Jump-Boxes und Admin-Accounts, sonst wird sie binnen einer Woche totgetunt.

Detection-Checkliste und Validierung mit Atomic Red Team

Bevor du eine Technik als abgedeckt bezeichnest, geh eine Checkliste durch: der Telemetrie-Kanal wird gesammelt, die Sigma-Regel existiert und ist versioniert, die Regel feuert auf den Angriff im Lab, sie feuert nicht auf die legitime Admin-Baseline, und sie ist mit mindestens einem vorangehenden Signal verkettet. Validiere jede Regel mit Atomic Red Team, etwa T1047 fuer WMI, T1021.002 fuer SMB-Admin-Shares und T1021.006 fuer WinRM, und bestatige dann, dass der Alert mit der richtigen Severity im SIEM landet. Eine Regel, die du nie scharf gefeuert hast, ist eine Hypothese, keine Detection, und Hypothesen in Produktion zu schicken ist, wie Programme stille blinde Flecken sammeln.

Vom Lab in die Produktion ausrollen

Eine Lab-Regel in die Produktion zu bringen ist eine eigene Disziplin, und wer diesen Schritt uberspringt, produziert entweder eine Flut von False Positives oder eine Regel, die im echten Netz nie feuert. Rolle jede neue Sigma-Regel zunachst im Audit- oder reinen Alert-Modus aus, mindestens einen vollen Geschaeftszyklus lang, denn die lauteste legitime laterale Bewegung, Patch-Rollouts, Backup-Agents, Remote-Support-Tools und automatisierte Deployment-Pipelines, zeigt sich erst, wenn echte Nutzer und echte Change-Fenster im Spiel sind. Verfolge fuer jede Regel die True-Positive- und False-Positive-Rate in einer einfachen Tabelle, tune die Allowlist bekannter Jump-Boxes und Service-Accounts, und promote sie erst dann zu einer Ticketing- oder Auto-Response-Aktion. Versioniere die Regeln in einem Git-Repository, sodass jede Aenderung reviewt und reversibel ist, tagge jede mit ihrer ATT&CK-Technik-ID und plane einen vierteljaehrlichen Re-Test gegen Atomic Red Team, damit ein Windows-Update, das eine Prozess-Lineage aendert, deine Abdeckung nicht stillschweigend bricht. Ein weiterer haeufig uebersehener Punkt ist die Latenz der Log-Weiterleitung: eine Regel, die technisch korrekt ist, aber auf einem Kanal sitzt, der mit fuenfzehn Minuten Verzoegerung ankommt, gibt dem Angreifer genau das Fenster, das er fuer den naechsten Hop braucht. Miss die Ende-zu-Ende-Latenz von der Aktion auf dem Endpoint bis zum Alert im SIEM und behandle sie als eigene Metrik. Eine Detektionsbibliothek ist eine lebende Codebasis, kein einmaliges Deliverable, und die Teams, die sie so behandeln, sind die, deren SOC tatsaechlich den zweiten und dritten Hop faengt, statt den ersten zu bewundern und den Rest der Kette zu verschlafen.

FAQ

Kann ich Lateral Movement allein mit EDR erkennen und Sysmon sparen? Ein gutes EDR deckt das meiste ab, aber die WMI- und WinRM-Kanaele plus Script Block Logging geben dir Evidenz, die das EDR manchmal wegzusammenfasst, und in einem Breach willst du die Rohevents fuer die Timeline. Fahr beides, wo das Budget es erlaubt. Welche Technik ist am schwersten zu fangen? In unserem Lab ist WMI die am wenigsten erkannte, weil kein Service erstellt wird und WmiPrvSE ein legitimer Alltagsprozess ist, also verpassen Teams, die auf 7045 setzen, sie komplett; genau deshalb empfehlen wir, die Detection-Arbeit dort zu starten statt beim lauten psexec, das ohnehin jeder faengt.

Researcher-OPSEC und ein kurzer praktischer Zyklus

Zum Schluss Researcher-OPSEC: Lateral-Movement-Labs erzeugen Hashes, Kerberos-Tickets und Samples, die nicht auf deine echte Workstation lecken duerfen. Wir arbeiten immer in isolierten Host-only-VMs, mit Snapshots vor jeder Ausfuehrung, und wir wiederverwenden niemals Passwoerter zwischen Lab und persoenlicher Produktion. Fuer einen breiteren Blick auf Isolation von Forschungsumgebungen erklaert OPSEC fuer Security-Researcher: Persoenliches Bedrohungsmodell das Modell, das wir adoptiert haben. Praktischer Takeaway: waehle diese Woche eine Technik (wir empfehlen WMI als die am schwaechsten erkannte), reproduziere sie in GOAD, schreib die Sigma-Regel, validiere mit Atomic Red Team T1047 und erst dann gehe weiter. Kurzer Zyklus, echte Detection, eine Technik voll geschlossen, bevor du die naechste offnest.