Log Dejargonizer

Sysmon · Event 19

Sysmon Event 19: A WMI event filter was registered

Something registered a WMI event filter — a rule that watches for a system condition. On its own that is harmless. Combined with events 20 and 21 it forms WMI persistence, which survives reboots, touches no startup folder, and leaves no file on disk.

Also written as Sysmon 19Sysmon Event ID 19WmiEventFilter activity detectedWMI persistence detection

What it means for you

On a personal computer

Only present if you installed Sysmon. WMI is a Windows management system that ordinary users never interact with directly.

For an analyst

WMI persistence is a three-part construction: a filter that defines when to trigger (19), a consumer that defines what to run (20), and a binding that links them (21). All three are needed for it to work. Because it lives in the WMI repository rather than in the registry or the file system, it survives reboots and is invisible to autorun tools that only check the usual locations. The volume is low enough that alerting on all three is practical.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
WmiEventFilter activity detected:
  RuleName: T1546.003
  EventType: WmiFilterEvent
  UtcTime: 2026-08-28 09:18:02.441
  Operation: Created
  User: CORP\jbrooks
  EventNamespace: "root\\cimv2"
  Name: "WindowsUpdateFilter"
  Query: "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System'"

The fields that decide it

Everything else in the log line is context.

Operation
Whether the filter was created or removed. Creation is the interesting one.
Name
The filter's name. Names imitating Microsoft's own are a common disguise.
Query
The WQL query defining the trigger condition. This is the useful field.
  • A query on Win32_LocalTime or __InstanceModificationEventTime-based triggering — the filter fires on a schedule.
  • A query watching for process creationTriggers when a particular program starts.
  • A query watching logon or startup conditionsTriggers at boot or sign-in, which is classic persistence.
EventNamespace
The WMI namespace, normally root\cimv2.
User
The account that registered the filter.

Ordinary reasons this happens

Most of the time it is one of these.

  • Monitoring and management software that legitimately uses WMI subscriptions.
  • Some enterprise inventory and asset tools.
  • Hardware vendor management agents.
  • In-house scripts using WMI subscriptions for automation, which is uncommon but does happen.

When it is not ordinary

Fileless persistence through a WMI subscription.

What gives it awayA filter registered alongside a consumer and a binding, triggering on a time or startup condition. Nothing is written to disk and no registry autorun key is touched.

ATT&CK T1546.003

Persistence that survives ordinary cleanup.

What gives it awayWMI subscriptions created during an intrusion, which remain after files are deleted and registry keys removed because they live in the WMI repository.

ATT&CK T1546.003

Triggering on a specific application launching.

What gives it awayA filter watching for process creation of a particular program, so the payload runs when someone opens it.

ATT&CK T1546.003

What to do next

  1. Look for matching Events 20 and 21. A filter alone does nothing — all three parts are needed.
  2. Read the WQL query to understand what triggers it.
  3. If a consumer exists, read what it actually runs. That is the payload.
  4. Check whether the name imitates a Microsoft component.
  5. Check whether the same subscription exists on other machines. Management software will be consistent.
  6. Enumerate existing subscriptions directly, because anything created before you started collecting will not appear in these events.

Queries to run

kql All three parts together. Low enough volume in most environments to read every one. 
Event | where Source == 'Microsoft-Windows-Sysmon' and EventID in (19, 20, 21) | project TimeGenerated, Computer, EventID, RenderedDescription | order by TimeGenerated desc
powershell Current subscriptions on a machine. Essential, because it finds persistence created before Sysmon was collecting. 
Get-WmiObject -Namespace root\subscription -Class __EventFilter; Get-WmiObject -Namespace root\subscription -Class __EventConsumer; Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding
sigma There is a good argument for alerting on all three unfiltered, then excluding your management tooling by name. 
detection:
  selection:
    EventID:
      - 19
      - 20
      - 21
  condition: selection

Common questions

What is WMI persistence?

A three-part construction: an event filter defining when to trigger, an event consumer defining what to run, and a binding linking the two. Once registered, the payload runs whenever the condition is met, across reboots. It lives in the WMI repository rather than on disk or in registry autorun keys, which is what makes it hard to find.

Why is WMI persistence hard to detect?

Because it leaves no file and no registry run key, so tools that check the usual autorun locations miss it entirely. Sysmon events 19, 20, and 21 catch the registration itself, and querying the root\subscription namespace directly finds what already exists. Without one of those, it is genuinely easy to overlook.

How do I remove a malicious WMI subscription?

Delete all three parts from the root\subscription namespace — the filter, the consumer, and the binding. Removing only one leaves fragments behind. Enumerate them first with Get-WmiObject against __EventFilter, __EventConsumer, and __FilterToConsumerBinding so you know exactly what you are removing.

Should I alert on Sysmon events 19, 20, and 21?

In most environments, yes, unfiltered to begin with. The volume is genuinely low, and the technique is specific enough that a legitimate subscription is memorable. Establish which of your management tools create subscriptions, exclude those by name, and alert on everything else.

Read next

Vendor documentation

Last reviewed 28 August 2026