WMI-Persistenz über Event Subscriptions erklärt

Kurz gesagt. Eine WMI Event Subscription besteht aus drei Objekten: einem __EventFilter (eine WQL-Abfrage, die beschreibt, wann), einem Event Consumer (was zu tun ist) und einem __FilterToConsumerBinding, das beide verbindet. Permanent registriert, übersteht sie Neustarts und läuft als SYSTEM. MITRE führt sie als T1546.003. Die Spuren liegen im CIM-Repository, und Sie können sie offline auslesen — gelöschte Objekte eingeschlossen.

Die drei Bestandteile

WMI ist die Verwaltungsschicht von Windows. Neben der Beantwortung von Abfragen kann sie reagieren: Tritt ein Ereignis ein, das einer Abfrage entspricht, übergibt sie es an einen Consumer. Eine permanente Subscription besteht aus:

Windows liefert fünf Standard-Consumer-Klassen aus:

• CommandLineEventConsumer: CommandLineTemplate, ExecutablePath, WorkingDirectory. Gestartet vom WMI-Provider-Host (WmiPrvSE.exe).
• ActiveScriptEventConsumer: ScriptingEngine (VBScript oder JScript) und entweder ScriptText oder ScriptFilename. Ausgeführt von scrcons.exe.
• LogFileEventConsumer: hängt Text an Filename an.
• NTEventLogEventConsumer: schreibt einen Eintrag ins Ereignisprotokoll.
• SMTPEventConsumer: versendet eine E-Mail.

Nur die ersten beiden führen beliebigen Code aus, weshalb die meiste WMI-Persistenz sie nutzt.

Warum Angreifer sie nutzen

Zum Anlegen einer Subscription sind Administratorrechte nötig, doch einmal eingerichtet, bietet sie viel:

• Sie übersteht Neustarts und benötigt keine Datei in einem Run-Schlüssel, einem Dienst oder einer geplanten Aufgabe.
• Die Aktion läuft als SYSTEM, als Kindprozess ständig laufender WMI-Prozesse.
• Auslöser kann alles sein, was WMI sieht: einige Minuten nach dem Start, eine Benutzeranmeldung, ein Prozessstart, ein eingesteckter USB-Datenträger, eine Tageszeit oder ein WMI-Timer.
• Sie versteckt sich vor aller Augen: Autoruns-ähnliche Prüfungen, die WMI auslassen, übersehen sie, und das Repository ist eine binäre Datenbank, die nur wenige öffnen.

Ein klassisches Beispiel ist ein Filter auf Win32_PerfFormattedData_PerfOS_System, der auslöst, wenn SystemUpTime zwischen 240 und 325 Sekunden liegt, sodass die Payload etwa vier Minuten nach jedem Start anläuft:

SELECT * FROM __InstanceModificationEvent WITHIN 60
WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System'
AND TargetInstance.SystemUpTime >= 240 AND TargetInstance.SystemUpTime < 325

Gebunden an einen CommandLineEventConsumer mit der Vorlage C:\ProgramData\Intel\m64.exe -svc ergibt das einen vollständigen Persistenzmechanismus — genau das enthält das Beispiel von WMI Parser, auf dem fiktiven Host FIN-WKS-07.

Wo die Spuren liegen

Subscriptions sind Objekte im WMI-Repository, C:\Windows\System32\wbem\Repository:

• OBJECTS.DATA enthält die Objekte selbst, in Seiten zu 8 KiB.
• INDEX.BTR ist der Index, der angibt, welches Objekt wo liegt.
• MAPPING1.MAP bis MAPPING3.MAP übersetzen die logischen Seiten des Index in physische.

Normalerweise liegen sie im Namespace root\subscription, aber eine in root\cimv2 oder root\default registrierte Subscription funktioniert ebenfalls. Das Format ist in OBJECTS.DATA: forensische Analyse des WMI-Repositorys beschrieben.

Zwei Eigenschaften sind in einem Fall besonders wichtig:

• CreatorSID hält für jedes Objekt das Konto fest, das es angelegt hat. Eine SID mit der Endung -500, S-1-5-32-544 oder die SID eines bestimmten Benutzers erzählen jeweils eine andere Geschichte.
• Gelöschte Objekte werden nicht überschrieben. Ihre Seiten werden freigegeben und erst überschrieben, wenn WMI den Platz braucht; die Bereinigung eines Angreifers hinterlässt daher oft den Filter, den Consumer oder das Binding. Siehe gelöschte WMI-Persistenz wiederherstellen.

Was das Repository nicht liefert, ist ein dokumentierter Erstellungszeitpunkt. Jeder Instanzdatensatz trägt zwei undokumentierte FILETIMEs, die oft dem Schreibzeitpunkt folgen; behandeln Sie sie als Hinweise. Für die zeitliche Einordnung korrelieren Sie mit Ereignis-ID 5861 in Microsoft-Windows-WMI-Activity/Operational und mit den Sysmon-Ereignissen 19 bis 21, beschrieben in der Checkliste für die Untersuchung.

So finden Sie sie

1. Sichern Sie das Repository aus einer Schattenkopie, mit KAPE (Target WBEM) oder Velociraptor: WMI-Repository forensisch sichern.
2. Parsen Sie es offline. Legen Sie den Ordner in WMI Parser ab: Das Tool listet jedes Binding mit seinem Filter und Consumer auf, stellt gelöschte wieder her und gibt für jedes Objekt an, ob es aus dem Index oder aus dem Carving stammt.
3. Trennen Sie die Standards ab. Windows installiert eine SCM-Event-Log-Subscription, ältere Images zusätzlich eine BVT-Subscription. Sie sind harmlos, wenn ihr Inhalt übereinstimmt: siehe SCM Event Log Consumer und BVTConsumer.
4. Lesen Sie, was übrig bleibt: die auslösende Abfrage, den Befehl oder das Skript, die Pfade und den Ersteller.

Befunde, auf die Sie achten sollten: kodiertes PowerShell, Binärdateien in benutzerbeschreibbaren Ordnern (C:\ProgramData, C:\Users\Public, %TEMP%), Skript-Consumer, Auslöser auf Laufzeit oder Anmeldung sowie Subscriptions außerhalb von root\subscription.

FAQ

Was ist WMI-Persistenz über Event Subscriptions?

Ein Angreifer registriert eine permanente WMI Event Subscription: einen __EventFilter, der ein Ereignis beschreibt, einen Consumer, der eine Aktion beschreibt, und ein __FilterToConsumerBinding, das beide verknüpft. Windows führt die Aktion dann bei jedem Eintreten des Ereignisses als SYSTEM aus, auch nach Neustarts.

Wo werden WMI Event Subscriptions gespeichert?

Im WMI-(CIM-)Repository, C:\Windows\System32\wbem\Repository, hauptsächlich in OBJECTS.DATA mit den zugehörigen INDEX.BTR- und MAPPING-Dateien. Normalerweise liegen sie im Namespace root\subscription.

Welche Consumer sind für Persistenz relevant?

CommandLineEventConsumer (führt eine Befehlszeile aus) und ActiveScriptEventConsumer (führt VBScript oder JScript aus) führen Code aus. LogFileEventConsumer, NTEventLogEventConsumer und SMTPEventConsumer schreiben eine Datei, ein Ereignis oder eine E-Mail.

Verwandte Artikel

• OBJECTS.DATA: forensische Analyse des WMI-Repositorys
• WMI-Repository forensisch sichern
• WMI-Persistenz untersuchen: Checkliste für Incident Response