WMI Event Subscription erkennen: dateilose Persistenz über WMI

Nach den Registry-Run-Keys folgt die unauffälligste Form der Persistenz unter Windows: die WMI-Event-Subscription. Windows Management Instrumentation kann so eingerichtet werden, dass bei einem bestimmten Ereignis - etwa einer Uhrzeit, dem Systemstart oder dem Start eines Prozesses - automatisch ein Befehl ausgeführt wird. Das Abonnement liegt tief in der WMI-Datenbank, nicht als Datei im Dateisystem, und läuft im Kontext von SYSTEM. Deshalb gilt die Technik als dateilos und wird von einfachen Dateiscans nicht gesehen. Berühmt wurde sie durch Stuxnet und APT29. Der Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.

Was der Angreifer tut

Eine WMI-Event-Subscription besteht aus drei Bausteinen. Auf der Ebene des Prinzips, nicht als Anleitung:

• Der Event-Filter (Auslöser). Ein __EventFilter mit einer WQL-Abfrage legt fest, wann es losgeht - zum Beispiel wenige Sekunden nach dem Systemstart oder zu einer festen Uhrzeit.
• Der Event-Consumer (Aktion). Ein CommandLineEventConsumer führt einen Befehl aus, ein ActiveScriptEventConsumer ein Skript. Hier steht die eigentliche Nutzlast, oft eine PowerShell.
• Die Bindung. Ein __FilterToConsumerBinding verknüpft Auslöser und Aktion - erst damit wird das Abonnement scharf.
• Ablegen und bleiben. Alles landet im WMI-Repository im Namespace root\subscription und übersteht den Neustart. Angelegt wird es per PowerShell, wmic oder mofcomp.

Für die Erkennung ist entscheidend: Das Anlegen dieser Objekte ist nativ protokolliert, und ein Consumer, der eine Shell startet, ist ein lautes, spezifisches Signal.

Welche Logquellen die Technik zeigt

• Native WMI-Events. Sysmon Event 19 (Filter), 20 (Consumer) und 21 (Bindung) sind genau für diese Technik gebaut und protokollieren jedes Anlegen samt Namen und Ziel - die wichtigste Quelle.
• Prozess-Telemetrie der Anlage. Event 4688 und Sysmon Event 1 zeigen die Kommandozeile von powershell, wmic oder mofcomp, mit der das Abonnement angelegt wird.
• Die Ausführung des Consumers. Feuert ein ActiveScriptEventConsumer, startet scrcons.exe; ein CommandLineEventConsumer startet seinen Befehl als Kind von WmiPrvSE.exe. Beides erscheint in der Prozess-Telemetrie.
• Die nachgelagerte Aktion. Startet der Consumer eine PowerShell oder ein LOLBin, greifen die LOLBins-Erkennung und die Endpunkt-Telemetrie, siehe Sysmon einrichten.

Das Muster im Log

Das klarste Signal ist das Anlegen eines Event-Consumers über Sysmon Event 20, besonders wenn sein Ziel auf eine PowerShell mit codiertem Befehl, ein Skript oder eine URL zeigt. Ein ActiveScriptEventConsumer ist für sich schon selten und verdient einen Blick. Dazu kommt die Anlage über die Kommandozeile: Tauchen __EventFilter, CommandLineEventConsumer oder root\subscription in einer PowerShell- oder wmic-Zeile auf, ist das Absicht und kein Zufall. Das dritte Signal ist scrcons.exe oder ein von WmiPrvSE.exe gestarteter Befehl, der auf einen feuernden Consumer hindeutet. Legitime WMI-Abonnements stammen von wenigen bekannten Verwaltungs- und Monitoring-Werkzeugen. Wie immer trennt der Blick auf Name, Ziel und anlegenden Prozess den Alltag vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft. Die erste und zweite nutzen die nativen Sysmon-WMI-Events, die dritte die Anlage über die Kommandozeile. Ein Hinweis zur Abdeckung: Die ersten beiden Regeln lassen sich sauber nach Splunk und Elastic übersetzen; für die KQL-Backends (Microsoft Sentinel und Defender) gibt es für die Sysmon-WMI-Events keine passende Tabelle, deshalb greift dort nur die dritte, prozessbasierte Regel. Das ist eine Grenze des Schemas, kein Regelfehler.

1. WMI-Event-Consumer oder -Filter angelegt (T1546.003). Das Anlegen eines Filters, Consumers oder einer Bindung über Sysmon 19/20/21 - das breite Signal. Die Regel steht auf level: medium.

title: WMI-Event-Consumer oder -Filter angelegt
id: 5c1a7e38-4b26-4d19-9f02-7a3c6e2b84d1
status: experimental
description: |
  Erkennt das Anlegen eines WMI-Event-Consumers, -Filters oder einer Bindung ueber die nativen
  Sysmon-WMI-Events (19 Filter, 20 Consumer, 21 Bindung). Eine dauerhafte WMI-Event-Subscription
  ueberlebt den Neustart und startet den hinterlegten Befehl beim passenden Ereignis - ein
  beliebter, unauffaelliger Weg zur Persistenz. Legitime Software legt solche Abonnements selten an.
references:
  - https://attack.mitre.org/techniques/T1546/003/
author: blue-team.net
tags:
  - attack.persistence
  - attack.privilege-escalation
  - attack.t1546.003
logsource:
  product: windows
  category: wmi_event
detection:
  selection:
    Operation|startswith: 'Created'
  condition: selection
falsepositives:
  - Einzelne Verwaltungs- und Monitoring-Software legt WMI-Abonnements an; bekannte Faelle als Baseline ausnehmen
level: medium

2. Verdächtiger WMI-Event-Consumer (T1546.003). Ein Consumer, dessen Ziel auf Skript-Host, codierten Befehl, URL oder scrcons zeigt - das spezifische Signal. Auf level: high.

title: Verdaechtiger WMI-Event-Consumer
id: 9b3d6f21-5a47-4c28-8e71-2b6a4c1d95e3
status: experimental
description: |
  Erkennt einen WMI-Event-Consumer, dessen Ziel auf einen Skript-Host, einen codierten Befehl, eine
  URL oder scrcons zeigt. Ein ActiveScriptEventConsumer oder CommandLineEventConsumer, der
  PowerShell oder cmd startet, ist das spezifische Zeichen einer WMI-Persistenz. Legitime Consumer
  rufen selten eine Shell mit codiertem Befehl auf.
references:
  - https://attack.mitre.org/techniques/T1546/003/
author: blue-team.net
tags:
  - attack.persistence
  - attack.privilege-escalation
  - attack.t1546.003
logsource:
  product: windows
  category: wmi_event
detection:
  selection:
    Destination|contains:
      - 'powershell'
      - 'pwsh'
      - 'cmd.exe'
      - 'mshta'
      - 'wscript'
      - 'cscript'
      - 'scrcons'
      - '-enc'
      - 'FromBase64String'
      - 'http://'
      - 'https://'
  condition: selection
falsepositives:
  - Sehr selten; einzelne Verwaltungs-Consumer rufen Skripte auf - bekannte Faelle ausnehmen
level: high

3. Anlegen über die Kommandozeile (T1546.003). Die WMI-Persistenz-Marker in einer PowerShell-, wmic- oder mofcomp-Zeile - greift auch ohne die nativen WMI-Events und läuft auf allen Backends. Ebenfalls level: high.

title: Anlegen einer WMI-Persistenz ueber die Kommandozeile
id: 2e7c9a14-6b35-4d26-b803-5f1a8c3e47d6
status: experimental
description: |
  Erkennt das Anlegen einer WMI-Event-Subscription ueber die Kommandozeile - etwa mit
  PowerShell (Register-WmiEvent, __EventFilter, CommandLineEventConsumer,
  ActiveScriptEventConsumer), wmic oder mofcomp im Namespace root\subscription. Das greift auch
  dort, wo die nativen Sysmon-WMI-Events nicht erfasst werden, und zeigt den Anlagevorgang direkt.
references:
  - https://attack.mitre.org/techniques/T1546/003/
author: blue-team.net
tags:
  - attack.persistence
  - attack.privilege-escalation
  - attack.t1546.003
logsource:
  product: windows
  category: process_creation
detection:
  sel_sub:
    CommandLine|contains:
      - '__EventFilter'
      - 'CommandLineEventConsumer'
      - 'ActiveScriptEventConsumer'
      - '__FilterToConsumerBinding'
      - 'root\subscription'
      - 'Register-WmiEvent'
  condition: sel_sub
falsepositives:
  - Einzelne Verwaltungsskripte legen legitim WMI-Abonnements an; bekannte Skripte und Konten ausnehmen
level: high

Härtung: der Angriff, der ins Leere läuft

• WMI-Abonnements inventarisieren. Den Namespace root\subscription regelmäßig gegen eine bekannte Baseline prüfen; Werkzeuge wie Autoruns und das WMI-Explorer-Cmdlet machen die Einträge sichtbar.
• Sysmon-WMI-Protokollierung aktivieren. Die Events 19, 20 und 21 in der Sysmon-Konfiguration einschalten - ohne sie bleibt die Technik weitgehend unsichtbar.
• Rechte für WMI begrenzen. Das Anlegen von Abonnements erfordert hohe Rechte; lokale Admin-Rechte vereinzeln und privilegierte Konten trennen nimmt der Technik die Grundlage.
• Verhaltensregel scharf schalten. Ein Consumer, der eine Shell mit codiertem Befehl startet, sollte immer alarmieren - das ist die zuverlässigste Einzelregel.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf isolierten Systemen mit aktivem Sysmon und eingeschalteten WMI-Events:

• Für Regel 1 und 3 mit PowerShell ein harmloses Abonnement anlegen, dessen Consumer nur eine Textdatei schreibt. Sysmon Event 20 und die Kommandozeile müssen erscheinen; danach wieder entfernen.
• Für Regel 2 als Ziel des Consumers testweise eine powershell mit einem kurzen, ungefährlichen Befehl setzen. Die Regel muss greifen.
• Breiter wird der Test mit den Fällen zu T1546.003 aus Atomic Red Team.

Fehlalarme und Tuning

• Verwaltungs- und Monitoring-Software. Einige Werkzeuge nutzen WMI-Abonnements legitim (etwa SCCM). Für Regel 1 die bekannten Consumer-Namen und Konten als Baseline ausnehmen.
• Legitime Skripte. Administratoren legen vereinzelt Abonnements per PowerShell an. Für Regel 3 die bekannten Skripte und Konten dokumentieren und filtern.
• Name und Ziel auswerten. Reichere die Treffer mit dem Consumer-Namen und seinem Ziel an; ein zufällig wirkender Name mit einer codierten PowerShell wiegt schwerer als ein benannter Consumer eines bekannten Produkts.
• Korrelation schlägt Einzelregel. Wer das Anlegen, den anlegenden Prozess und die spätere Ausführung über scrcons oder WmiPrvSE als Kette betrachtet, trennt Verwaltung und echten Angriff zuverlässiger als jede Einzelregel.

Fazit

Die WMI-Event-Subscription ist die unauffälligste Persistenz unter Windows: dateilos, als SYSTEM und über jeden Neustart hinweg. Die verlässlichen Signale sind das Anlegen von Filter, Consumer und Bindung über die nativen Sysmon-WMI-Events, ein Consumer mit verdächtigem Ziel und die Anlage-Marker in der Kommandozeile. Die wirksamste Härtung schaltet die WMI-Protokollierung ein, inventarisiert den Namespace root\subscription gegen eine Baseline und vereinzelt die Rechte. Als Nächstes in der Persistenz-Reihe folgt das neue Konto als Hintertür. Verwandt sind die Registry-Run-Keys und die WMI-Ausführung. Weitere Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Persistence.