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, jede auf ihre MITRE-ATT&CK-ID zu mappen und KQL-Queries zu liefern, die Ihr Defender XDR oder Sentinel morgen frueh ausfuhren kann, samt der Gegenmassnahme, die jede Tur schliesst.

1. Autorun-Registry-Keys (T1547.001)

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. Die Gegenmassnahme ist eine User-Baseline plus AppLocker oder WDAC, das Execution aus user-schreibbaren Pfaden blockt, sodass selbst ein geschriebener Run-Wert nicht starten kann. 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.

2. Scheduled Tasks (T1053.005)

Scheduled Tasks 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 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. Die Gegenmassnahme ist das Alarmieren bei Task-Erstellung ausserhalb von Change-Fenstern und das Verbot der Task-Registrierung fuer Nicht-Admins per GPO.

3. Windows-Services (T1543.003)

Windows-Services 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. Die Gegenmassnahme ist das Quotieren jedes Service-Pfads, das Einschranken von SeCreateServicePrivilege und Code-Signing-Enforcement. Dieses Muster spiegelt die baseline-getriebene Detection wider, die wir in Hunting von Living-off-the-Land-Binaries unter Windows mit KQL behandelt haben.

4. WMI Event Subscription (T1546.003)

WMI Event Subscription 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; ein CommandLineEventConsumer oder ActiveScriptEventConsumer auf einem Endpoint ist fast nie legitim. Lateral-Movement-Techniken, die in WMI-Persistenz enden, sind gut in Lateral Movement im Lab: SMB, WMI und WinRM mit Detection-Fokus illustriert.

5. COM Hijacking (T1546.015)

COM Hijacking 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. Die Gegenmassnahme ist das Baselining, welche CLSIDs jeder Host in HKCU legitim uberschreibt (meist keine), und das Alarmieren bei jedem neuen Eintrag, da ein sauberes Corporate-Image diesen Key kaum je fullt.

6. AppInit_DLLs und Image File Execution Options (T1546.010 / T1546.012)

AppInit_DLLs und Image File Execution Options gehoren zur gleichen Kategorie von Registry-basiertem Execution-Flow-Missbrauch und verdienen eigene Queries. AppInit_DLLs ladt eine DLL in jeden Prozess, der user32.dll linkt, und modernes Windows deaktiviert es unter Secure Boot, sodass allein seine Aktivierung ein Alarm ist: alarmieren Sie bei jedem Write auf HKLM\...\Windows\AppInit_DLLs. IFEO-Missbrauch setzt einen Debugger-Wert unter dem Key einer Ziel-Executable, sodass der Start von etwa sethc.exe stattdessen die Angreifer-Binary ausfuhrt; jagen Sie Writes auf Debugger- und GlobalFlag-Werte und korrelieren Sie mit unerwarteten Kindprozessen. Wer wissen will, warum moderne Evasion immer noch hier durchgeht, sollte EDR-Umgehung fur Forschung: Direct Syscalls Erklart ohne Romantik lesen.

7. Startup-Folder und Logon Scripts (T1037)

Der Startup-Folder und Logon Scripts schliessen das klassische User-Land-Trio. Ein Shortcut im per-user oder all-users Startup-Folder lauft beim Logon ohne Elevation, und der UserInitMprLogonScript-Registry-Wert unter HKCU\Environment fuhrt bei jedem Logon ein Skript aus, wahrend er unter den meisten Default-Regelsatzen durchfliegt. Jagen Sie File-Creation-Events in den beiden Startup-Pfaden, wo der schreibende Prozess kein bekannter Installer ist, und alarmieren Sie bei jedem Wert in UserInitMprLogonScript, der auf einem sauberen Host leer ist. Die Gegenmassnahme ist eine gesperrte Startup-Folder-ACL und GPO-Auditing der Logon-Script-Registry-Werte.

8. BITS Jobs (T1197)

BITS verdient besondere Aufmerksamkeit, weil es Logoff uberlebt und Payloads uber einen vertrauenswurdigen Prozess ziehen kann: bitsadmin /list /allusers /verbose als wochentlicher Check fangt schon 95% der Falle, und das Microsoft-Windows-Bits-Client/Operational-Log verzeichnet Job-Erstellung und Notify-Kommandos. Die gefahrliche Variante setzt eine SetNotifyCmdLine, sodass BITS selbst den Payload startet, wenn der Transfer fertig ist, was fur einen unachtsamen Analysten wie svchost-Aktivitat aussieht. Die Gegenmassnahme ist das Monitoring des BITS-Operational-Kanals auf Jobs mit Notify-Kommandozeile und das Deckeln der Job-Lebensdauer per Policy, damit ein haengender Transfer nicht wochenlang lauert.

9. Print Processors und weitere Autostart-Extensions (T1547.012)

Print Processors sind nach PrintNightmare wieder auf der Karte, und das Monitoring von HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments ist gunstig: eine neue Print-Processor-DLL, von spoolsv.exe aus einem nicht-standard Pfad geladen, ist ein hochkonfidentes Signal. Dieselbe Boot-and-Logon-Autostart-Familie (T1547) umfasst Winlogon-Shell- und Userinit-Manipulation, LSA Security Support Providers und Netsh-Helper-DLLs; jeder ist ein einzelner Registry-Wert, der sich auf einem verwalteten Host nie andern sollte, sodass eine Compliance-Query, die aktuelle Werte gegen ein Golden Image vergleicht, alle auf einmal faengt. Die Gegenmassnahme ist uberall dieselbe: den guten Wert kennen, bei Abweichung alarmieren.

10. Detections in ein Programm verwandeln

Die zehnte Technik ist die, die die anderen neun zusammenbindet: Detection als wiederholbares Programm operationalisieren statt als Haufen von Regeln. 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. 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, sodass jede Regel im Takt geubt, getunt und re-validiert wird statt zu verrotten.

Die zehn nach Praevalenz und Kosten priorisieren

Nicht alle zehn Techniken verdienen am ersten Tag denselben Aufwand, und ein Programm, das versucht, den Ozean auszukochen, bleibt stehen, bevor es irgendetwas ausliefert. Ordne sie nach Praevalenz gegen Detektionskosten: Run-Keys und Scheduled Tasks sind hochpraevalent und guenstig, also kommen sie zuerst; Windows-Services und BITS sind mittelpraevalent und billig abzufragen, also kommen sie als Zweites; WMI Event Subscription, COM Hijacking und die IFEO- oder AppInit-Familie sind seltener, aber deutlich hoeher im Impact, wenn sie auftauchen, weil sie einen faehigeren Operator signalisieren, also kommen sie als Drittes, duerfen aber nicht ausgelassen werden. Print Processors und die Winlogon- oder Userinit-Autostart-Werte sind selten, aber als Golden-Image-Vergleich trivial billig, also falte sie in denselben woechentlichen Compliance-Sweep. Mappe jede Technik darauf, ob Praevention, Detektion oder beides auf deiner Flotte realistisch ist, denn manche, wie unquotierte Service-Pfade, werden besser einmal behoben als ewig beobachtet, waehrend andere, wie WMI-Subscriptions, nur detektiert und reviewt werden koennen. Ein weiterer entscheidender Faktor ist der Ort der Persistenz: dieselbe Technik auf einem Kiosk-Rechner ist ein niedrigpriorisierter Hinweis, auf einem Domain Controller oder einem Code-Signing-Host ist sie ein Alarm hoechster Stufe, also gewichte jede Detektion mit der Kritikalitaet des Assets, auf dem sie feuert. Diese Prioritaetsordnung als einseitige Matrix zu veroeffentlichen haelt das Programm ehrlich und gibt der Leitung einen verteidigbaren Grund dafuer, wohin die naechste Stunde Engineering fliesst, statt dass jeder Analyst seine Lieblingstechnik zuerst jagt und der Rest der Liste jahrelang unbearbeitet bleibt.

FAQ

Welche Technik sollte ein kleines Team zuerst erkennen? Run-Keys und Scheduled Tasks, in dieser Reihenfolge, weil sie den Grossteil der Commodity-Persistenz abdecken und die Queries billig sind; machen Sie diese zwei sauber, bevor Sie WMI-Subscriptions anfassen. Brauche ich Sysmon, wenn ich schon Defender for Endpoint fahre? Fur die meisten reicht MDE, aber WMI Event Subscription (Events 19-21) und manche Registry-Write-Sichtbarkeit sind mit Sysmon starker, also fahren Sie Sysmon auf Ihren Kronjuwel- und Hochrisiko-Hosts, selbst wenn die Flotte allein auf MDE setzt. Abdeckung ist ein Spektrum, und Sysmon setzen Sie dort ein, wo der Blast-Radius am grossten ist.

Checkliste und Fazit

Praktischer Takeaway: Persistenz wird nicht mit einer brillanten Regel erkannt, sie wird mit Review-Disziplin erkannt. Gehen Sie die Checkliste fur jede der zehn durch: Telemetrie-Kanal gesammelt, KQL-Query geschrieben und versioniert, Per-Host-Baseline etabliert, Gegenmassnahme ausgerollt, und die Regel mit Atomic Red Team validiert, sodass Sie sie haben feuern sehen. 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, und alles danach ist disziplinierte Iteration.