Windows Management Instrumentation

Officially an execution technique, Windows Management Instrumentation (WMI) is leveraged for lateral movement and discovery as well. Our many hundreds of WMI detections arise from a wide array of disparate threats.


Why do adversaries use WMI?

Like many of the threats highlighted in this report, WMI is a native Windows utility that administrators use regularly to automate tasks and remotely manage systems in their environments. Adversaries generally use WMI for the same reasons that administrators use it: to execute processes on remote systems. Since it’s installed by default and routinely used for benign purposes, it blends in with normal operating system activity.

Security analysts and other network defenders occasionally struggle with WMI process ancestry. For example, malicious activity traced back to the WMI Provider Host, WMIPrvSE.exe, leads to a dead end in the process tree. On a local host, this may mean a WMI Event Consumer was used for persistence.

In the case of lateral movement, the WMIPrvSE.exe execution on one host should correlate to a WMI Command Line (wmic.exe) execution on the originating host. Attackers may also leverage WMI to avoid detection based on process ancestry, such as using an Office macro to set a WMI event consumer to launch a malicious PowerShell command—thereby avoiding defenders who monitor PowerShell activity spawned by Office.

Specific to the environments we monitor (and contrary to its classification as an execution technique), we’ve observed a substantial number of adversaries using WMI to enumerate user accounts or other system information for reconnaissance. Some of our analytics also trigger on adversaries using WMI for lateral movement.

How do adversaries use WMI?

Some of the common ways we see adversaries leveraging WMI include:

  • Executing processes with wmic.exe
  • Discovering system information
  • Scheduling persistence with WMI structures
  • Launching WMI from Office documents to execute commands in phishing campaigns
  • Bypassing application whitelisting controls

Emerging tactics

Some less common—but no less interesting—uses of WMI include:

  • Deletion of shadow copies, likely to avoid using vssadmin.exe
  • WMI copying commands to the clipboard in fileless infections
  • Execution of stylesheets with wmic.exe

As its prevalence suggests, many threats and threat actors use WMI in their attacks and campaigns. Some noteworthy examples include:

  • Emotet
  • Metasploit
  • Cobalt Strike
  • WannaCry
  • NotPetya
  • OilRig
  • Olympic Destroyer
  • Empire
  • Lazarus Group

Sighted with

Adversaries commonly leverage WMI in concert with PowerShell (T1086), Windows Management Instrumentation Event Subscription (T1084), and XSL Script Processing (T1220). We frequently detect WMI with PowerShell largely because of the Get-WMICObject cmdlet, which adversaries use to locally or remotely query the Windows operating system to enumerate information or execute new processes.

As we noted above, adversaries are known to execute stylesheets with wmic.exe, which explains why we see threats leveraging WMI and XSL Script Processing together. This might be a direct result of the “Squiblytwo” attack technique discussed in the Detection section below. WMI is commonly used to install event filters and consumers, which is why our detections are sometimes tagged with both WMI and the WMI Event Subscription technique.



MITRE’s data sources

  • Authentication logs
  • Netflow/Enclave netflow
  • Process monitoring
  • Process command-line parameters

Collection requirements

In addition to those data sources listed by MITRE, Windows WMI logging and Sysmon WMI event codes (e.g., 19: WmiEventFilter activity detected, 20: WmiEventConsumer activity detected, and 21: WmiEventConsumerToFilter activity detected) are also good sources to collect from if you want to detect malicious uses of WMI.

Process monitoring and command-line parameters

Telemetry drawn from process monitoring and command-line parameters can be useful for detecting adversarial uses of WMI, and you can collect it via EDR tools, Sysmon, or native command-line logging in Windows 7 and newer versions.

Process monitoring enables detection strategies that look for malicious use of wmic.exe for process creation, Lateral Movement, and reconnaissance.


Compared to other data sources—WMI Activity logging, for example—enabling additional Sysmon logging will generate a lot of noise. However, the data format is easier to manipulate and ingest into a SIEM, making it easier to build detection strategies around.

Windows EventIDs

EventID 5861 logs generate a permanent record of WMI event subscriptions.

Detection suggestions

In general, only trusted binaries and known administrative tools and processes will initiate WMI activity. As such, it makes sense to look for known bad or unusual processes launching WMI.

New WMI event consumers will execute the WMI Provider Host (`WMIPrvSE.exe`) process. Monitoring WMIPrvSE.exe for abnormal child processes, such asPowerShell or cmd.exe, is a reliable way to detect malice. Emotet, for example, uses this technique to obscure the normal parent-child relationship and execute encoded PowerShell commands via WMIPrvSE.exe to download second-stage executables.

Permanent WMI event consumers offer adversaries a stealthy method of persistence. However, permanent event consumer subscriptions are logged by WMI logging and Sysmon. Legitimate software will leverage these, but they occur infrequently and are easy to monitor for malicious use.

Looking for unusual parent-child relationships and with unique command-line parameters is another solid indicator of malice. It should be rare for something like the IIS worker process (w3wp.exe) to spawn wmic.exe. When this occurs, it warrants investigation. This can be a sign that an adversary is leveraging a web shell for process creation, reconnaissance, or for remote access after initially accessing an environment. It is also rare for browsers (IE, Edge, Chrome, Firefox, etc.) to spawn wmic.exe, and, when it does happen, it’s usually bad.

In cases where wmic.exe is being used for credential theft, defenders might consider looking for wmic.exe executions with unusual module loads, including:

  • samlib.dll
  • vaultcli.dll
  • Cross process injection into the Local Security Authority Subsystem Service (lsass.exe)

That last point requires elevated permissions but can be a reliable signal of credential theft and post-exploitation tools such as Mimikatz.

As noted earlier, adversaries frequently abuse wmic.exe to bypass application whitelisting controls and download and execute malicious VBScript or JScript stylesheets from remote network resources. This technique is known colloquially as “Squiblytwo,” and security teams can detect it by looking for instances of wmic.exe with URLs in the command lines and that include the “format” option. This will typically be accompanied by a module load of jscript.dll and vbscript.dll into wmic.exe.

Some malware families will use wmic.exe to create local antivirus exclusions to prevent antivirus-based detection. Because of this, it makes sense to look out for unusual binaries that are unsigned and included in antivirus exclusion rules.

Further, it’s almost always malicious when wmic.exe spawns as a child process of Microsoft Word, PowerPoint, MSPublisher, Visio, Access, Outlook, Onenote, WordPad, or Excel. As such, it makes sense to examine the chain of execution and follow-on activity when this occurs.

Wmic can also leverage the WMI subsystem to execute commands or files remotely. Cobalt Strike, Koadic, and many other red team and post-exploitation frameworks will spawn unique and unsigned binaries or commands remotely using the well known process call create command. Monitoring what is being executed in this context can reliably turn up malice. It also makes sense to look out for wmic.exe making remote connections.

Some other considerations:

  • Adversaries can use wmic.exe to interact with remote systems, conduct reconnaissance, and move laterally.
  • Since there are more common tools that are easier to use, Win32_Process create is rarely used for legitimate reasons and should be regarded with suspicion.
  • Reconnaissance is harder to detect because it looks very similar to normal admin behavior.
  • Surrounding context is important in identifying if queries are malicious or benign.

If you want to detect ransomware using WMI to delete shadow copies, consider looking for wmic.exe execution with command lines including shadowcopy delete.

In rare instances, adversaries running fileless attacks will redirect WMI outputs to the clipboard, which can be detected by looking for command lines that include output and clipboard.

WMI can be stealthily used in almost every phase of an attack. When adversaries leverage it to enumerate local user accounts and profile devices, security teams can detect it by looking for things such as wmic.exe profiling user accounts, domain information, or even PowerShell querying the operating system or executing new processes, either locally or remotely. Cmdlets such as 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 into standard DCOM/PSRemoting traffic and could generate high volumes of false negatives. This is yet another reason—along with minimal logging and defender knowledge of WMI—why attackers love WMI.


Getting Started With Atomic Red Team

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:
wmic /node:"" process call create “calc.exe”
Useful telemetry will include:
Data sourceTelemetry
Data source:

Process monitoring


child processes of wmiprivse.exe

Data source:

Process command line


“process”, “create”

Review and repeat

Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:

  • Were any of your actions detected?
  • Were any of your actions blocked or prevented
  • Were your actions visible in logs or other defensive telemetry?

Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.

Jesse Brown
Detection Engineer
The detection strategies in this section were brought to you by Jesse Brown! As a Detection Engineer for Red Canary's Cyber Incident Response Team, Jesse works alongside a talented team dedicated to quickly identifying and remediating threats in customer environments. He enjoys dissecting malware and adversary techniques to help improve the Red Canary detection engine. Jesse holds a Master's of Professional Studies in Cybersecurity and Information Assurance from The Pennsylvania State University.
The detection strategies in this section were brought to you by Jesse Brown! As a Detection Engineer for Red Canary's Cyber Incident Response Team, Jesse works alongside a talented team dedicated to quickly identifying and remediating threats in customer environments. He enjoys dissecting malware and adversary techniques to help improve the Red Canary detection engine. Jesse holds a Master's of Professional Studies in Cybersecurity and Information Assurance from The Pennsylvania State University.