How do you detect WMI event subscription persistence?

Collect Sysmon Events 19, 20 and 21, which record the filter, consumer and binding respectively, and the WMI-Activity Operational log, where Event 5861 records a permanent binding. Alert on new CommandLineEventConsumer and ActiveScriptEventConsumer objects, and on scrcons.exe or WmiPrvSE.exe spawning shells or script hosts. Because subscriptions created before logging began will not appear in telemetry, enumerate the root\subscription namespace with Get-CimInstance across the fleet and diff against a known-good list. Expect a few legitimate subscriptions from management software and allowlist them by consumer name.

Detecting WMI Event Subscription Persistence: Filters, Consumers and Bindings

WMI permanent event subscriptions persist through three linked objects in the root\subscription namespace: an event filter that defines the trigger, an event consumer that defines the action, and a binding that joins them. Nothing is written to a startup location, so file and Run-key detections miss it entirely. Sysmon Events 19, 20 and 21 and the WMI-Activity Operational log both record the creation, and the repository can be enumerated at any time.

Signals at a Glance

Signal	Where	ATT&CK
__EventFilter created (WmiEventFilter activity)	Sysmon 19	T1546.003
CommandLineEventConsumer or ActiveScriptEventConsumer created	Sysmon 20	T1546.003
FilterToConsumerBinding created	Sysmon 21	T1546.003
Permanent subscription registered (binding event)	WMI-Activity/Operational Event 5861	T1546.003
scrcons.exe or WmiPrvSE.exe spawning cmd, powershell or script hosts	Sysmon 1	T1047
New classes or instances written to root\subscription	WMI repository enumeration	T1546.003

Sysmon, Event 5861 and Process Lineage

Sysmon 19, 20 and 21 give a clean, field-level view of each object. The consumer is the most useful because it names the command or script that will run. Here is a Splunk search over Sysmon that surfaces new consumers and what they execute:

index=sysmon (EventCode=19 OR EventCode=20 OR EventCode=21)
| eval detail=case(
    EventCode=19, "FILTER name=".Name." query=".Query,
    EventCode=20, "CONSUMER name=".Name." type=".Type." dest=".Destination,
    EventCode=21, "BINDING consumer=".Consumer." filter=".Filter)
| table _time host User EventCode Operation detail
| sort - _time
`comment("tune/validate: expect a few vendor subscriptions (SCCM, hardware monitoring); allowlist by consumer name after review")`

At execution time the lineage is distinctive. A CommandLineEventConsumer launches its command from WmiPrvSE.exe, and ActiveScriptEventConsumer scripts run inside scrcons.exe. Neither process should normally spawn a shell on a workstation:

Alert on scrcons.exe starting at all outside of known management software, and on WmiPrvSE.exe parenting cmd.exe, powershell.exe, mshta.exe or rundll32.exe.
Ingest Microsoft-Windows-WMI-Activity/Operational and alert on Event 5861 so you still have coverage on hosts without Sysmon.
Pay attention to filters keyed on boot time or logon, such as queries against Win32_PerfFormattedData_PerfOS_System uptime or __InstanceModificationEvent on a timer. Those are the usual persistence triggers.

Enumerating the Repository

Real-time telemetry can miss subscriptions created before logging began, so enumerate the namespace directly. All three object types live in root\subscription, and anything beyond a short, known list is worth a review:

# PowerShell: list permanent WMI subscriptions on the local host
$ns = 'root\subscription'
Get-CimInstance -Namespace $ns -ClassName __EventFilter |
  Select-Object Name, EventNamespace, QueryLanguage, Query
Get-CimInstance -Namespace $ns -ClassName CommandLineEventConsumer |
  Select-Object Name, CommandLineTemplate, ExecutablePath, WorkingDirectory
Get-CimInstance -Namespace $ns -ClassName ActiveScriptEventConsumer |
  Select-Object Name, ScriptingEngine, ScriptFileName, ScriptText
Get-CimInstance -Namespace $ns -ClassName __FilterToConsumerBinding |
  Select-Object Filter, Consumer
# tune/validate: collect over WinRM/EDR live response and diff against a known-good reference.

Vetted sources

Use the SigmaHQ WMI event subscription rules (Sysmon 19, 20 and 21), Elastic’s WMI persistence detections, Splunk ESCU WMI content, MITRE CAR analytics and Atomic Red Team T1546.003 tests. Sysmon community configs include the WmiEvent rules. Autoruns lists WMI entries, and baseline your own environment since SCCM and monitoring agents may register legitimate subscriptions.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Sysmon, Event 5861 and Process Lineage

Enumerating the Repository

Build Detections That Fire

Persistence Detection

Detection Hub

COM Hijacking Detection