MITRE’s data sources
- Authentication logs
- Netflow/Enclave netflow
- Process monitoring
- Process command-line parameters
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.
EventID 5861 logs generate a permanent record of WMI event subscriptions.
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:
- 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
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
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.