WMI-Ausführung erkennen: Code über Windows Management Instrumentation

Nach den geplanten Aufgaben folgt der zweite große Ausführungsweg der Welle: WMI, Windows Management Instrumentation. Es ist die Schnittstelle, über die sich Windows abfragen und steuern lässt - und genau diese Mächtigkeit macht sie für Angreifer attraktiv. Mit WMI lässt sich Code starten, ohne eine Datei abzulegen, lokal wie aus der Ferne, und alles läuft unter einem legitimen Systemprozess. Deshalb ist WMI zugleich ein Ausführungs- und ein beliebter Lateral-Movement-Mechanismus. Dieser Beitrag nimmt die Ausführung in den Blick und bleibt auf der Verteidigerseite.

Was der Angreifer tut

Die Ausführung über WMI läuft auf der Ebene des Prinzips, nicht als Anleitung, in wenigen Schritten ab:

• WMI ansprechen. Über wmic, die PowerShell-WMI-Cmdlets oder direkt die WMI-Schnittstelle ruft der Angreifer die Methode Create der Klasse Win32_Process auf.
• Den Befehl starten. WMI startet den gewünschten Prozess - der läuft als Kind des Anbieterhosts WmiPrvSE.exe, nicht unter dem aufrufenden Werkzeug.
• Aus der Ferne arbeiten. Mit einem Host- oder ComputerName-Parameter geschieht das auf einem entfernten System, ohne Datei und ohne neuen Dienst dort.
• Unauffällig bleiben. Weil WMI ein legitimes Verwaltungswerkzeug ist, geht der Missbrauch leicht in der normalen Aktivität unter.

Für die Erkennung ist entscheidend: So flexibel WMI ist, das Ergebnis ist immer dasselbe - ein Prozess unter WmiPrvSE.exe -, und die direkten Befehle tragen ein klares Muster.

Welche Logquellen die Technik zeigt

• Prozess-Telemetrie. Event 4688 und Sysmon Event 1 zeigen den unter WmiPrvSE.exe gestarteten Prozess - das werkzeugunabhängige Kernsignal - sowie die Aufrufe von wmic und PowerShell samt Kommandozeile.
• Die nachgelagerte Aktion. Startet WMI eine PowerShell oder ein LOLBin, greifen die PowerShell-Protokollierung und die LOLBins-Erkennung.
• WMI-Aktivitätslogs. Das Operational-Log der WMI-Aktivität dokumentiert Abfragen und Methodenaufrufe - nützlich im Hunting, wenn die Prozessspur allein nicht reicht.
• Endpunkt-Telemetrie. Für die saubere Erfassung der Eltern-Kind-Beziehungen siehe Sysmon einrichten.

Das Muster im Log

Der verlässlichste Befund ist ein Prozess unter WmiPrvSE.exe: Dieser Anbieterhost startet im Normalbetrieb kaum je eine Kommandozeile, PowerShell oder ein LOLBin - tut er es doch, steckt fast immer WMI-Ausführung dahinter, egal mit welchem Werkzeug sie ausgelöst wurde. Ergänzt wird das durch die direkten Befehle: wmic mit process call create und die PowerShell-Cmdlets Invoke-WmiMethod oder Invoke-CimMethod mit Win32_Process. Kommt ein Host- oder ComputerName-Parameter hinzu, geht es um Fernausführung. Wie überall gilt: Die Herkunft und das Konto trennen die legitime Verwaltung vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und über alle Backends sauber übersetzbar. Die erste nutzt den Anbieterhost als Elternprozess, die zweite den wmic-Befehl, die dritte die PowerShell-WMI-Cmdlets. Die erste ist die tragende, weil sie werkzeugunabhängig greift.

1. WmiPrvSE startet eine Shell oder ein LOLBin (T1047). Ein Kindprozess unter dem WMI-Anbieterhost. Die Regel steht auf level: high.

title: WmiPrvSE startet eine Shell oder ein LOLBin
id: 4b2e8c17-6a39-4d50-9c21-3e7a1b9d64f2
status: experimental
description: |
  Erkennt einen Prozess, dessen Elternprozess WmiPrvSE.exe ist. Wird Code ueber WMI
  ausgefuehrt - lokal oder aus der Ferne -, startet der Zielbefehl als Kind des WMI-
  Anbieterhosts. Eine Kommandozeile, PowerShell oder ein LOLBin unter WmiPrvSE.exe ist das
  universelle Signal fuer WMI-basierte Ausfuehrung, unabhaengig vom genutzten Werkzeug.
references:
  - https://attack.mitre.org/techniques/T1047/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1047
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith: '\WmiPrvSE.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
  condition: selection
falsepositives:
  - Einzelne Verwaltungs- und Monitoringloesungen, die ueber WMI Prozesse starten; bekannte Faelle ausnehmen
level: high

2. wmic process call create (T1047). Der klassische WMI-Ausführungsbefehl, lokal oder per /node aus der Ferne. Ebenfalls level: high.

title: wmic process call create
id: 2d7a4b91-5c38-4e06-8f12-6a3e9c2d71b5
status: experimental
description: |
  Erkennt den klassischen WMI-Ausfuehrungsbefehl ueber wmic: process call create startet
  einen beliebigen Prozess, mit dem Schalter /node sogar auf einem entfernten Host. Das ist
  einer der direktesten Wege zur lokalen wie entfernten Codeausfuehrung ueber WMI.
references:
  - https://attack.mitre.org/techniques/T1047/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1047
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\wmic.exe'
  sel_process:
    CommandLine|contains: 'process'
  sel_call:
    CommandLine|contains: 'call'
  sel_create:
    CommandLine|contains: 'create'
  condition: sel_img and sel_process and sel_call and sel_create
falsepositives:
  - Sehr selten; dokumentierte Verwaltungsskripte; bekannte Faelle nach Konto und Ziel ausnehmen
level: high

3. WMI-Prozessstart über PowerShell (T1047). Invoke-WmiMethod oder Invoke-CimMethod mit Win32_Process. level: medium, weil diese Cmdlets auch legitim vorkommen.

title: WMI-Prozessstart ueber PowerShell
id: 9c1e6b40-7a28-4d35-b0f2-5e3a2c7d94b8
status: experimental
description: |
  Erkennt die Ausfuehrung ueber WMI aus PowerShell heraus. Invoke-WmiMethod oder
  Invoke-CimMethod zusammen mit der Klasse Win32_Process und der Methode Create starten
  einen Prozess - mit dem Parameter ComputerName auch aus der Ferne. Diese Kombination ist
  ein gaengiger, skriptbarer WMI-Ausfuehrungsweg.
references:
  - https://attack.mitre.org/techniques/T1047/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1047
logsource:
  product: windows
  category: process_creation
detection:
  sel_cmdlet:
    CommandLine|contains:
      - 'Invoke-WmiMethod'
      - 'Invoke-CimMethod'
  sel_class:
    CommandLine|contains: 'Win32_Process'
  condition: sel_cmdlet and sel_class
falsepositives:
  - Legitime Verwaltungsautomatisierung ueber WMI; bekannte Konten und Skripte ausnehmen
level: medium

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

• WMI aus der Ferne eindämmen. Den entfernten WMI-Zugriff per Firewall und Konfiguration auf Verwaltungsquellen begrenzen - das nimmt der Fernausführung die Fläche.
• Rechte beschränken. Die WMI-Namespace-Rechte auf das Nötige reduzieren, damit nicht jedes Konto Methoden wie Win32_Process Create aufrufen kann.
• Anwendungssteuerung. Mit WDAC oder AppLocker eingrenzen, was WmiPrvSE.exe als Kind starten darf - eine Shell gehört dort nicht hin.
• WMI-Telemetrie aktivieren. Das WMI-Aktivitätslog einschalten und die Eltern-Kind-Regel scharf schalten, damit WMI-Ausführung sichtbar wird.

Der Test

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

• Für Regel 2 lokal wmic process call create mit einem harmlosen Programm aufrufen. Event 4688 muss den wmic-Befehl zeigen.
• Für Regel 1 denselben Aufruf beobachten: Das gestartete Programm muss als Kind von WmiPrvSE.exe erscheinen.
• Für Regel 3 per Invoke-CimMethod mit Win32_Process einen Testbefehl starten. Die Kommandozeile muss die Cmdlet-Nutzung zeigen. Breiter wird der Test mit den Fällen zu T1047 aus Atomic Red Team.

Fehlalarme und Tuning

• Verwaltung und Monitoring. Inventar- und Monitoringlösungen nutzen WMI intensiv. Für Regel 1 die bekannten Verwaltungskonten und -quellen als Baseline ausnehmen.
• Admin-Skripte. wmic und die WMI-Cmdlets kommen in Verwaltungsskripten vor. Für Regel 2 und 3 die bekannten, signierten Skripte filtern.
• Softwareverteilung. Manche Verteilsysteme starten Prozesse über WMI. Nach Host und Konto baselinen, statt die Regel zu entschärfen.
• Korrelation schlägt Einzelregel. Wer den WmiPrvSE-Kindprozess mit der Quelle und der nachgelagerten Aktion verknüpft, trennt Verwaltung und echten Angriff zuverlässiger als jede Einzelregel.

Fazit

WMI ist so mächtig für die Verwaltung wie für den Angreifer - Ausführung ohne Datei, lokal wie aus der Ferne, getarnt als legitimer Systemprozess. Der verlässliche Anker ist der Kindprozess unter WmiPrvSE.exe; die direkten Befehle wmic process call create und die WMI-Cmdlets ergänzen ihn. Die wirksamste Härtung begrenzt den entfernten WMI-Zugriff, reduziert die Namespace-Rechte und schränkt ein, was der Anbieterhost starten darf. Als Nächstes folgt die Dienst-Erstellung als weiterer Ausführungsweg. Verwandt sind die geplanten Aufgaben, die Impacket-Werkzeuge, deren wmiexec genau hier ansetzt, und WinRM als zweite Fernverwaltungs-Schnittstelle. Weitere Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Execution.