WMI-Persistenz untersuchen: Checkliste für Incident Response

Kurz gesagt. Sichern Sie zuerst das Repository, betrachten Sie dann den Host live und korrelieren Sie anschließend. Die Objekte sagen Ihnen, was ausgeführt wird und wann; Microsoft-Windows-WMI-Activity/Operational (Ereignis-ID 5861) und Sysmon (19–21) sagen Ihnen, wann es registriert wurde; Prefetch, Amcache und Prozesstelemetrie sagen Ihnen, ob es ausgeführt wurde. Bereinigen Sie erst, wenn die Beweise gesichert sind.

1. Repository sichern

Kopieren Sie C:\Windows\System32\wbem\Repository aus einer Schattenkopie, bevor Sie WMI anfassen: WMI-Repository forensisch sichern. Das Entfernen einer Subscription, eine Softwareinstallation oder der Neuaufbau des Repositorys kann gelöschte Datensätze überschreiben, die Sie noch nicht gelesen haben.

2. Host live betrachten

Listen Sie auf, was WMI aktuell ausführt, über die üblichen Namespaces hinweg:

'root/subscription','root/cimv2','root/default' | ForEach-Object {
  $ns = $_
  '__EventFilter','__EventConsumer','__FilterToConsumerBinding' | ForEach-Object {
    Get-CimInstance -Namespace $ns -ClassName $_ -ErrorAction SilentlyContinue
  }
} | Format-List *

Sysinternals Autoruns hat einen Reiter WMI mit derselben Live-Ansicht. Beide zeigen nur aktive Objekte und verlassen sich auf einen WMI-Dienst, den ein Angreifer kontrollieren kann.

3. Gesicherte Dateien parsen

Legen Sie den Ordner Repository in WMI Parser ab. Prüfen Sie in dieser Reihenfolge:

1. Bindings, die keine Windows-Standards sind. Die Subscriptions SCM Event Log und BVT sind zu erwarten — sofern ihr Inhalt übereinstimmt (Details).
2. Die Aktion des Consumers: Befehlszeile, Skripttext oder -datei und Pfade. Kodiertes PowerShell, Binärdateien unter C:\ProgramData, C:\Users\… oder %TEMP% sowie Skript-Consumer verdienen eine genaue Prüfung.
3. Der Auslöser des Filters: Laufzeit (löst nach jedem Start aus), Anmeldung, Timer, Prozessstart oder Geräteereignisse.
4. CreatorSID jedes Objekts: welches Konto es registriert hat.
5. Wiederhergestellte Objekte: gelöschte Bindings, ältere Versionen, ungebundene Consumer. Sie zeigen, was existierte und was bereinigt wurde (so funktioniert die Wiederherstellung).
6. Namespaces außer root\subscription.

4. Mit Ereignisprotokollen korrelieren

Das Repository selbst hat keinen dokumentierten Erstellungszeitpunkt für seine Objekte; über diese Ereignisse datieren Sie sie. Die zwei FILETIMEs, die WMI Parser für jeden Instanz-Header anzeigt, sind Hinweise, die Sie damit abgleichen.

5. Nach Ausführung suchen

Eine Subscription beweist eine Konfiguration, keine Ausführung. Prüfen Sie für die Payload des Consumers Prefetch, Amcache, ShimCache, SRUM und EDR-Telemetrie; für Skripte den Prozessbaum unter scrcons.exe; für Befehlszeilen Prozesse mit dem Elternprozess WmiPrvSE.exe. Gleichen Sie deren Zeitpunkte mit Neustarts (bei Laufzeit-Auslösern) oder Anmeldungen (bei Anmelde-Auslösern) ab.

6. Das Umfeld prüfen

• MOF-Dateien und AutoRecover: Eine mit #pragma autorecover kompilierte .mof wird beim Neuaufbau des Repositorys erneut eingespielt. Prüfen Sie C:\Windows\System32\wbem\AutoRecover und den Wert Autorecover MOFs unter HKLM\SOFTWARE\Microsoft\Wbem\CIMOM.
• Eigene Klassen: Daten oder Code, versteckt in den Eigenschaften einer vom Angreifer definierten Klasse, außerhalb der Subscription-Triade.
• Andere Hosts: Dieselben Filter- und Consumer-Namen auf mehreren Rechnern deuten auf eine Verteilung aus der Ferne hin.

7. Sicher bereinigen

Sind die Beweise gesichert und ist der Umfang bekannt, entfernen Sie die drei Objekte in dem Namespace, in dem sie liegen — das Binding zuerst:

$ns = 'root/subscription'
Get-CimInstance -Namespace $ns -ClassName __FilterToConsumerBinding | Where-Object { $_.Filter.Name -eq 'IntelPerfMonitor' } | Remove-CimInstance
Get-CimInstance -Namespace $ns -ClassName CommandLineEventConsumer -Filter "Name='IntelPerfMonitor'" | Remove-CimInstance
Get-CimInstance -Namespace $ns -ClassName __EventFilter -Filter "Name='IntelPerfMonitor'" | Remove-CimInstance

Ersetzen Sie die Namen durch Ihre eigenen (diese stammen aus dem fiktiven Beispiel). Löschen Sie dann die Payload, auf die der Consumer verwies, und führen Sie die Live-Abfrage zur Bestätigung erneut aus.

FAQ

Welche Ereignis-ID zeigt eine neue WMI-Persistenz?

Ereignis-ID 5861 in Microsoft-Windows-WMI-Activity/Operational wird protokolliert, wenn ein permanenter Event Consumer an einen Filter gebunden wird. Sysmon ergänzt, sofern konfiguriert, die Ereignisse 19, 20 und 21 für Filter, Consumer und Bindings.

Wie entferne ich WMI-Persistenz?

Entfernen Sie nach der Beweissicherung das Binding, dann den Consumer und den Filter mit Get-CimInstance … | Remove-CimInstance in dem Namespace, in dem sie liegen, und löschen Sie die Payload, auf die der Consumer verwies.

Reicht die Live-Abfrage aus?

Nein. Sie zeigt nur aktive Objekte des abgefragten Namespace, niemals gelöschte, und verlässt sich auf den WMI-Dienst eines möglicherweise kompromittierten Hosts. Parsen Sie zusätzlich das gesicherte Repository.

Verwandte Artikel

• WMI-Persistenz über Event Subscriptions erklärt
• Gelöschte WMI-Persistenz wiederherstellen