Windows-Persistenz: 10 Dokumentierte Techniken und ihre Gegenmassnahmen

Persistenz ist nicht der glamourose Teil eines Engagements, aber sie unterscheidet einen Angreifer, der beim ersten Reboot den Zugang verliert, von dem, der drei Wochen spater zuruckkommt, wenn das Team den Alarm langst vergessen hat. Bei Basilisk OffSec fuhren wir Ubungen bei Kunden durch, bei denen mehr als 70% der Detections, die zu echten Fallen wurden, mit trivialen Mechanismen begannen: Run-Keys, Scheduled Tasks mit niedlichen Namen, Services mit unquotierten Pfaden. Das Ziel dieses Katalogs ist nicht, das Verstecken von Implants zu lehren. Es geht darum, zehn reale Techniken zu dokumentieren, die wir jede Woche sehen, und KQL-Queries zu liefern, die Ihr Defender XDR oder Sentinel morgen frueh ausfuhren kann.

Die erste Familie, die abzudecken ist, sind die Autorun-Registry-Keys. HKCU\Software\Microsoft\Windows\CurrentVersion\Run bleibt das am meisten ausgenutzte T1547.001 in Commodity-Kampagnen, nicht weil Angreifer faul sind, sondern weil es in jedem Profil ohne Privilegien funktioniert. Eine simple Query wie DeviceRegistryEvents | where RegistryKey has "CurrentVersion\\Run" and InitiatingProcessFileName !in ("explorer.exe","msiexec.exe") fangt 80% der Falle, sobald Sie eine Hostname-Baseline haben. Um den offensiven Kontext dieser Pfade zu verstehen, lohnt sich ein Blick auf Initial Access Simuliert: Makros, LNK und ISO im Isolierten Windows-11-Lab, denn die meisten Makros, die wir im Lab sehen, schreiben am Ende genau in diese Keys.

Scheduled Tasks (T1053.005) sind die zweithaufigst missbrauchte Technik und die am wenigsten gemeldete. Die Herausforderung ist nicht die Erkennung der Task-Erstellung, sondern das Filtern des Rauschens: ein Corporate Windows 11 erstellt im Schnitt 40 legitime Tasks wahrend Update-Zyklen. Die Query, die uns am besten dient, ist DeviceProcessEvents | where FileName == "schtasks.exe" and ProcessCommandLine has_any ("/create","/change") | where InitiatingProcessParentFileName !in (~"msiexec.exe",~"trustedinstaller.exe") kombiniert mit Get-ScheduledTask-Anreicherung, die leeren Author oder unsignierten Author filtert. Parallel dazu fangen das Monitoring von Security-Event 4698 und das Durchgehen von TaskCache\Tree in der Registry versteckte Tasks, die schtasks /query nicht zeigt.

Windows-Services (T1543.003) bleiben der bevorzugte Vektor, sobald der Angreifer bereits SYSTEM hat. Der Blue-Team-Fokus sollte auf drei Signalen liegen: Service-Erstellung auf unsignierte Binary, ImagePath in world-writable Verzeichnissen wie ProgramData oder Public, und der klassische unquoted service path. Eine gute Jagd startet mit DeviceEvents | where ActionType == "ServiceInstalled" | where FolderPath !startswith "C:\\Windows\\" and FolderPath !startswith "C:\\Program Files". Um nicht mit legitimen Installationen zu verwechseln, joinen Sie mit der Zertifikat-Tabelle und verwerfen alles mit bekanntem Corporate-Signer. Dieses Muster spiegelt die baseline-getriebene Detection wider, die wir in Hunting von Living-off-the-Land-Binaries unter Windows mit KQL behandelt haben.

WMI Event Subscription (T1546.003) ist, wo es ernst wird. Es ist leise, uberlebt Reboots und taucht selten in Junior-Playbooks auf. Das Rezept: __EventFilter, __EventConsumer und __FilterToConsumerBinding in der Klasse root\subscription monitoren. In Defender funktioniert DeviceEvents | where ActionType == "WmiBindEventFilterToConsumer", aber in Umgebungen ohne MDE brauchen Sie Sysmon mit aktivierten Events 19, 20 und 21. Kombinieren Sie mit Get-WmiObject -Namespace root\subscription -Class __EventConsumer als wochentlichem Compliance-Check. Lateral-Movement-Techniken, die in WMI-Persistenz enden, sind gut in Lateral Movement im Lab: SMB, WMI und WinRM mit Detection-Fokus illustriert.

COM Hijacking (T1546.015) missbraucht den Vorrang von HKCU vor HKLM bei CLSIDs. Der Angreifer registriert einen InProcServer32 unter HKCU, der auf eine kontrollierte DLL zeigt, und jeder Prozess, der diese CLSID in User-Session ladt, fuhrt den Code aus. Zum Jagen fokussieren Sie sich auf unerwartete Schreibvorgange in HKCU\Software\Classes\CLSID\*\InProcServer32, wo der Default-Wert nicht auf eine Microsoft-signierte DLL auflost. AppInit_DLLs (T1546.010) und Image File Execution Options (T1546.012) gehoren zur gleichen Kategorie von Registry-basiertem Execution-Flow-Missbrauch und verdienen eigene Queries. Wer wissen will, warum moderne Evasion immer noch hier durchgeht, sollte EDR-Umgehung fur Forschung: Direct Syscalls Erklart ohne Romantik lesen.

Startup-Folder, Logon Scripts (T1037), BITS Jobs (T1197) und Print Processors (T1547.012) schliessen die praktische Liste ab. BITS verdient besondere Aufmerksamkeit, weil es Logoff uberlebt und Payloads uber vertrauenswurdigen Prozess ziehen kann: bitsadmin /list /allusers /verbose als wochentlicher Check fangt schon 95% der Falle. Print Processors sind nach PrintNightmare wieder auf der Karte, und das Monitoring von HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments ist gunstig. Um das mit dem vollen offensiven Zyklus zu korrelieren, zeigen Adversary Emulation mit Caldera und MITRE ATT&CK im Unternehmenslab und Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus, wie diese Detections in fortlaufende Ubungen mit dem Red Team umgewandelt werden.

Praktischer Takeaway: Stapeln Sie die zehn obigen Queries in einer einzigen Sentinel-Watchlist, konfigurieren Sie eine 14-Tage-Baseline pro Host bevor Sie alarmieren, und reviewen Sie Hits in einem wochentlichen Threat-Hunting-Fenster. Persistenz wird nicht mit einer brillanten Regel erkannt, sie wird mit Review-Disziplin erkannt. Starten Sie morgen, indem Sie die ersten zwei Queries (Run-Keys und schtasks) im Produktionsumfeld im Read-Only-Modus laufen lassen, zahlen Sie die Hits, und Sie werden legitime Persistenz entdecken, die niemand dokumentiert hat. Das ist der echte Startpunkt des Programms.