Operator On The Wire
Waitlist
← Back to Knowledge Base
OOTW / Chapter II - Local / 04. Windows / 03. Persistence / WMI

WMI

WMI permanent event subscriptions execute a consumer when a WMI event query matches.

The persistence chain has three parts:

  • An event filter that defines the trigger
  • An event consumer that defines the action
  • A binding that connects the filter to the consumer

Permanent WMI subscriptions are stored in the WMI repository and survive reboot. They commonly execute through the WMI service context, so creation usually requires local administrator rights unless namespace permissions are misconfigured.

When enumerating WMI persistence opportunities, try to identify:

  • Existing objects in root\subscription
  • __EventFilter objects with suspicious WQL
  • CommandLineEventConsumer objects executing shells or payloads
  • ActiveScriptEventConsumer objects with embedded script
  • Filter-to-consumer bindings
  • Recent creation through PowerShell, WMIC, CIM or mofcomp.exe

Enumeration

List event filters:

Get-WmiObject -Namespace root\subscription -Class __EventFilter

List command-line consumers:

Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer

List script consumers:

Get-WmiObject -Namespace root\subscription -Class ActiveScriptEventConsumer

List bindings:

Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding

CIM alternatives:

Get-CimInstance -Namespace root/subscription -ClassName __EventFilter
Get-CimInstance -Namespace root/subscription -ClassName CommandLineEventConsumer
Get-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding

Legacy WMIC inspection:

wmic /namespace:\\root\subscription PATH __EventFilter get Name,Query
wmic /namespace:\\root\subscription PATH CommandLineEventConsumer get Name,CommandLineTemplate

Interesting findings include:

  • Unknown event filters
  • WQL queries using short polling intervals such as WITHIN 5
  • Consumers launching cmd.exe, powershell.exe, rundll32.exe, regsvr32.exe or payloads from writable paths
  • Bindings that connect unknown filters to unknown consumers
  • WMI subscriptions created near logon, service creation or payload staging
  • mofcomp.exe, wmic.exe or PowerShell used before persistence appears

Once WMI subscription creation is available, a trigger and command consumer can be registered.

Remediation

Patch the weakness:

  • Remove unauthorized __FilterToConsumerBinding objects first.
  • Remove the related CommandLineEventConsumer or ActiveScriptEventConsumer.
  • Remove the related __EventFilter.
  • Remove payload files referenced by consumers.
  • Review WMI namespace permissions if non-admin users were able to create permanent subscriptions.

Remove the example subscription:

Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding |
Where-Object { $_.Filter -like "*Windows Update Filter*" -or $_.Consumer -like "*Windows Update Consumer*" } |
Remove-WmiObject
Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer -Filter "Name='Windows Update Consumer'" | Remove-WmiObject
Get-WmiObject -Namespace root\subscription -Class __EventFilter -Filter "Name='Windows Update Filter'" | Remove-WmiObject

Detect abuse:

  • Review Sysmon Event IDs 19, 20 and 21 for WMI filter, consumer and binding creation.
  • Review PowerShell Event IDs 4103 and 4104 for Set-WmiInstance, Register-WmiEvent and CIM creation.
  • Review WMI-Activity Operational logs for suspicious WMI operations.
  • Hunt for wmic.exe, mofcomp.exe and PowerShell writing to root\subscription.
  • Alert on consumers launching script interpreters, LOLBins or payloads from writable paths.