Sysmon Event IDs 19, 20 and 21 all record WMI activity — which one shows persistence is armed?

## What a WMI permanent event subscription is made of Windows Management Instrumentation supports subscriptions that survive reboots and run without a logged-on user, which is why attackers use them for persistence (ATT&CK technique `T1546.003`). Three objects are involved, normally in the `root\subscription` namespace: - an **event filter** (`__EventFilter`) — a WQL query describing the condition, for example a timer firing or a process starting; - an **event consumer** — the action, most commonly `CommandLineEventConsumer` (runs a command) or `ActiveScriptEventConsumer` (runs script text); - a **binding** (`__FilterToConsumerBinding`) — the object that says *when this filter fires, run that consumer*. A filter with no binding never triggers anything. A consumer with no binding is never invoked. **The binding is the moment the persistence becomes live.** ## How Sysmon reports each part Sysmon mirrors that structure across three event IDs: | Sysmon ID | What it records | Useful fields | |---|---|---| | 19 | WmiEventFilter activity | `Operation`, `User`, `EventNamespace`, `Name`, `Query` | | 20 | WmiEventConsumer activity | `Operation`, `User`, `Name`, `Type`, `Destination` | | 21 | WmiEventConsumerToFilter activity | `Operation`, `User`, `Consumer`, `Filter` | `Operation` is `Created` or `Deleted`, so deletions appear too — which matters, because a subscription that is planted, used and removed leaves a trail of 19/20/21 records and no surviving object on disk. ## Why the promoted rule keys on 21 When a hunt turns up hand-found WMI persistence and you are converting it into a maintainable rule, 21 is the highest-signal anchor: - it is the record that means *this thing can now run*, so it has the tightest relationship to the behaviour you care about; - it is comparatively rare in most estates, which matters when a small team is deciding whether it can afford another rule; - filters and consumers are created in bulk by legitimate tooling and, on their own, are not evidence of anything. A rule keyed on 19 alone will fire on every management agent that registers a query and tell you nothing about whether an action is attached. ## What the binding record does not tell you This is where candidates most often over-claim. A 21 record with `Operation: Created` proves that **a binding was registered**. It does not prove: - that the filter's condition has ever been satisfied; - that the consumer's command or script has ever executed; - that the subscription is malicious — approved software creates bindings constantly; - anything about subscriptions that already existed before Sysmon started reporting on that host. Execution, if it happened, shows up elsewhere: a process-creation record whose parent is `WmiPrvSE.exe` is the classic corroboration, since consumer-launched processes are spawned by the WMI provider host rather than by the original creator. ## The join problem the promotion has to solve The binding record identifies its two halves by name, in a form like `CommandLineEventConsumer.Name="HealthCheckConsumer"`. It does not repeat the consumer's `Destination`. So a rule that alerts purely on 21 produces an alert saying *a binding to a consumer called HealthCheckConsumer was created on HOST-1421* — accurate, and almost unusable, because the single most decision-relevant field, what the consumer actually runs, is on the 20 record. That gives you two workable shapes. Either the rule correlates 21 with the matching 20 by consumer name within a short window and carries the `Destination` into the alert, or it alerts on 21 and the triage note tells the analyst to pull the corresponding 20 record as the first pivot. The correlated form is a better alert and a heavier rule to maintain; the simpler form is cheaper and pushes one lookup onto the analyst. On a two-person detection team that trade is worth making consciously rather than by accident. ## Practical reading of a record pair Given a 20 and a 21 seconds apart under the same account, you can state: a subscription named X was fully assembled at time T by account A, and its action is command Y. You cannot state that Y ran, when it will run, or whether A intended harm. Keeping those two lists separate — what the records support and what they do not — is the difference between an escalation that holds up and one that collapses on the first question.