This blog post will teach you how to detect malware WMI Event Consumers.
- First, we review the WMI and the many ways attackers use it.
- Second, we review WMI Event Consumers and how it’s used for persistence.
- Last, we explore investigation techniques, especially the latest (and most effective) methods.
Let’s get to it.
Jump to…
What Is Windows Management Instrumentation (WMI)?
How Do Threat Actors Abuse WMI?
What Are WMI Event Consumers?
What Are Malware WMI Event Consumers?
Traditional Investigation Methods
Modern Investigation Methods
Keep Learning Investigation Strategies
What Is Windows Management Instrumentation (WMI)?
WMI is a Windows feature that allows admins and apps to search, manage, and monitor system configs and events.
It’s often used for:
- Admin task automation
- Real-time event monitoring
- Remote system management
WMI is part of the Windows OS, accessible via PowerShell, Command Prompt, and various programming interfaces.To get a more detailed understanding of what WMI is and all of its components, check out the WMI Forensics Whitepaper by FireEye or this multi-part series of offensive WMI.
How Do Threat Actors Abuse WMI?
WMI is versatile, so attackers can use it at every step in the attack lifecycle. Below are a few examples of the tactics WMI can be used for.
Some examples:
#1 Execution
WMI can be used to create new processes both locally and remotely using the Win32_process create method. WMIExec.py is an example of a common script that is often abused by threat actors to launch processes remotely via WMI.
WMI can be used to access remote systems through DCOM (used by older systems) or WinRM (newer systems). Any action that can be done via WMI locally can be done remotely as well given the proper firewall rules are in place. We previously saw that you can create processes remotely and the same would apply to persistence such as services.
#3 Discovery
WMI can be used to gather a large array of data from systems such as: AV products (using the AntiVirusProduct class), Patch levels (using the Win32_QuickFixEngineering class), and running processes/services (using the Win32_Process and Win32_Service classes).
WMI can be used directly to disable event logs, clear event logs (using the NTEventLogFile class), and check for virtualization/sandboxing (using Win32_computersystem class).
#5 Impact
WMI can be used to impact systems by inhibiting system recovery by deleting volume shadow copies (using Win32_ShadowCopy class) and forcing system restarts/shutdown (using Win32_OperatingSystem class methods).
#6 Persistence
WMI can be used for persistence by creating services (using Win32_service create method), modifying registry autorun keys (using StdRegProv methods), and using WMI permanent event consumers. WMIPersist.py is a script that automates the process of creating persistence via event consumers.
This post does not cover all malicious uses of WMI.
We focus on:
- How attackers use WMI as a persistence mechanism via event consumers.
- How investigators can detect it.
What Are WMI Event Consumers?
WMI consumers are a way to listen to WMI events and take action on them.
There are two types:
| Temporary Consumers | Permanent Consumers |
|---|---|
| Temporary consumers live only as long as the app that set them up. They are stored in memory. | Permanent consumers live on even after the process that created them has gone away. They are stored inside the WMI database. |
We will focus on permanent consumers as an attacker persistence method because:
- They are more common.
- They are more interesting.
A permanent consumer needs 3 things to exist:
#1 Event Filter
This is an event filter written in WQL that determines what condition will trigger the consumer actions.
| Key Info | Example |
|---|---|
| CreatorSID: User SID that created the filter.
Name: Name of the filter. Query: The WQL query that is used to trigger the “action.” |
|
The consumer is an action that occurs when the filter finds events to trigger on. There are five standard events defined. Of these, CommandLineEventConsumer and ActiveScriptEventConsumer are the most important because they allow a program or script to be executed.
| Key Info | CommandLineEventConsumer Example |
|---|---|
| CreatorSID: User SID that created the consumer.
Name: Name of the consumer. ExecutablePath: Represent the executable to be run. It can be empty, in which case CommandLineTemplate will contain the path and args. CommandLineTemplate: Contains the args and optionally the path. Can be empty, in which case ExecutablePath is required. |
|
| Key Info | ActiveScriptEventConsumer Example |
| CreatorSID: User SID that created the consumer.
Name: Name of the consumer. ScriptFileName: Path to script file to be executed. This must be null if ScriptText is not. ScriptText: Script content to run without writing a file to disk. |
|
The binding is what ties a filter to a consumer. Without this binding nothing will happen. An event consumer and filter can both exist, but no action will be taken until they are mapped together with the binding definition.
| Key Info | Example |
|---|---|
| CreatorSID: User SID that created the binding. This can differ from the user that created the filter
Consumer: Provides the name and type of consumer. Used to get details on what action will occur. Filter: Contains the name of the filter. This is used to find the filter details. Example: What triggers the action?\. |
|
|
Note:
Consumers/filters/bindings are scoped to the namespace they were created in. The above examples created everything in the root\subscription namespace. However, they can also be defined in other namespace like root\default. It’s important to check all namespaces for potential persistence.
|
What Are Malware WMI Event Consumers?
As you’ve gathered by now, WMI Event Consumers are really useful to attackers. As DFIR expert Chris Ray observes: “Malware that use WMI event consumers for persistence can be tricky to catch if you are not looking at WMI, however, once you know what to look for it’s usually easy to spot.”
Advantages for persistence:
| Event-Driven Execution | Fileless Persistence | Stealth and Evasion |
|---|---|---|
| Malware remains dormant until a triggered event like a user login, system startup, or process creation. | This method doesn’t put a file on disk. The malicious script is saved within the WMI database, making it difficult to detect using file-based scanning. | WMI is complex, and it can be difficult to understand all of its components. As a result it’s easy to miss WMI persistence that deviates beyond the standard cases that everyone talks about. |
Example of Stealth and Evasion:
If you only look in root\subscription you can miss persistent if it’s defined elsewhere like root\default or even sub-namespaces like root\subscription\ms_409
If you only focus on looking for consumers of type ActiveScriptEventConsumer or CommandLineEventConsumer you could miss easy persistence that made custom named consumers that are inherited from the above consumers.
An attacker creates a WMI event subscription using the three components we reviewed above:
| #1 Create Event Filter | #2 Create Event Consumer | #3 Create Event Binding |
|---|---|---|
| The attacker picks the event that triggers execution. | The attacker decides the action that executes when the event occurs. | The attacker links the filter to the consumer, ensuring the execution actually happens when the event occurs. |
| Example | Example | Example |
| Monitor process creation (__InstanceCreationEvent) to trigger when cmd.exe runs. | CommandLineEventConsumer to run a PowerShell script. | CommandLineEventConsumer is mapped to event filter so that it can trigger on the desired action. |
Common persistence scenarios:
| Tools That Use WMI Persistence | Threat Actors/Malware that has used WMI Persistence |
|---|---|
| Impacket (WMIPersist.py) | APT 29 |
| CrackMapExec | SolarWinds Compromise |
| MetaSploit wmi_persistence module | Turla |
| SilentTrinity | |
| More examples of scripts that automate the WMI persistence via event consumers can be found here | You can find more examples of threat groups and malware-abusing WMI consumers here and here. |
Traditional Investigation Methods
A classic method of detecting malware WMI Event Consumers is:
- Looking where the evidence is found.
- Looking for suspicious signs in the data.
The evidence is found in 4 places:
- EDRs
- WMI database
- Sysmon event log
- WMI-activity event log
Here is how to access the data:
| EDRs |
|---|
| How to Access the Data:
Most EDR tools like Microsoft Defender for Endpoint, CrowdStrike Falcon, or SentinelOne provide visibility into WMI abuse. To check if your EDR supports WMI logging check out the EDR Telemetry project for a quick comparison. Use built-in hunting queries in Kusto Query Language (KQL) or SIEM solutions like Splunk: DeviceEvents | where ActionType == 'WmiBindEventFilterToConsumer' Example KQL query in Defender to get WMI binding events:
|
| WMI Database | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| How to Access the Data:
The WMI database is located: c:\windows\system32\wbem\repository Windows\system32\wbem\repository\fs (xp) The folder is comprised of the following files:
Depending on what you have available, there are 3 main options for getting data out of the WMI database:
|
| Sysmon Event Log |
|---|
| How to Access the Data:
Requires Sysmon with an appropriate configuration (sysmon.xml). A commonly used sysmon configuration that includes the below events for monitoring can be found here by SwiftOnSecurity. View logs in Event Viewer under: Applications and Services Logs\Microsoft\Windows\Sysmon\Operational Query logs using PowerShell: Get-WinEvent -LogName Microsoft-Windows-Sysmon/Operational |
| WMI-Activity Event Log |
|---|
| How to Access the Data:
Located at: Applications and Services Logs\Microsoft\Windows\WMI-Activity\Operational View using Event Viewer (eventvwr.msc) or PowerShell: Get-WinEvent -LogName Microsoft-Windows-WMI-Activity/Operational Here’s what to look for:
|
Modern Investigation Methods
While we provided a traditional method, it’s not the method we recommend. That’s because this approach focuses on:
- Learning the ins and outs of each particular artifact type.
- Investigating each one by one according to their idiosyncrasies.
This is a waste of time — and risks losing the forest for the trees.
During an investigation, your real question isn’t “Are these WMI Consumer Events suspicious?” Your real question is higher level. You want to know if “Trigger Tasks” (WMI Consumer Events being one type) were used by an attacker. “Triggered Tasks” are higher-level information artifacts representing persistence on a system. Some action will occur based on a trigger.
For WMI persistence:
- “Consumer” is the action.
- “Filter” is the trigger.
This approach is big picture.
| Modern Investigation Method | Traditional Investigation Method |
|---|---|
|
|
Cyber Triage is built around the modern investigation method. Cyber Triage represents WMI persistence of “Triggered Task.”
Cyber Triage directly parses the WMI database using a custom script we wrote that leverages the python-cim library. We enumerate all namespaces and look for any instances of __FilterToConsumerBinding:
From there, we get the associated filter and consumers. Cyber Triage focuses on the consumers that can execute code/programs vs the other less interesting consumers like logging.
Cyber Triage has scoring to flag any persistence using non-standard consumers or non-standard namespaces as bad — one way a threat actor could try to hide their activity.
Example showing Cyber Triage scoring WMI persistence that is located in a non-standard namespace:
If you’d like to see how Cyber Triage works for yourself, you can.
Keep Learning Investigation Strategies
We hope this blog post helped you better understand how to investigate malware WMI event consumers. If you’d like to keep learning our approach to investigations, here are some resources you’ll love:
| Intro to DFIR Series | DIFR Next Steps Series |
|---|---|
