Windows Management Instrumentation, or WMI, is ATT&CK T1047. It belongs to the Execution tactic and applies to Windows. WMI is a legitimate administration feature, which is the reason attackers like it: a lot of normal software uses it, so abuse can hide in the noise.
How attackers use it
MITRE describes WMI as the infrastructure for management data and operations on Windows, designed for programmers, giving a uniform way to access system components. The service allows both local and remote access. Remote access depends on other remote services such as Distributed Component Object Model and Windows Remote Management. Remote WMI over DCOM uses port 135, and WMI over WinRM uses port 5985 for HTTP and 5986 for HTTPS.
An adversary can use WMI to interact with local and remote systems. That covers discovery, such as gathering information, and execution of commands and payloads. MITRE gives one example: wmic.exe can be used to delete shadow copies, which is a way to inhibit system recovery.
MITRE adds a note that matters for planning. The wmic.exe tool has been deprecated since January 2024 and the WMIC feature is disabled by default on Windows 11 and later. It will be removed from later Windows releases and replaced by PowerShell as the main WMI interface. COM APIs, and tools such as wbemtool.exe, can also reach WMI from C++, .NET, VBScript and other languages. Blocking only wmic.exe is therefore not a complete answer.
The procedure examples span a wide range. WMI was used in scripts for remote execution and system surveys, to gather information about installed antivirus products, to execute PowerShell, to deploy tools on remote machines, and to steal credentials and run backdoors at a later time.
How to detect it
The MITRE analytic describes a multi-event chain: process creation, command execution, and, if the activity is remote, a matching network connection. It covers WMIC, PowerShell and COM API use.
Specific data to collect:
- Process creation with command line. On Windows, event 4688 with command line auditing turned on, or Sysmon event 1. Look for wmic.exe, and for PowerShell using WMI or CIM commands.
- Parent process. Processes launched by WmiPrvSE.exe, the WMI provider host, are a classic place to look for remote WMI execution.
- Network. Connections to port 135 and to the high ports that follow it, and to ports 5985 and 5986, between hosts that do not normally manage each other.
- WMI activity logs. The Microsoft-Windows-WMI-Activity operational log records WMI operations. Sysmon also has events 19, 20 and 21 for WMI event filter, consumer and binding activity.
Baselines help here. Your management tools will use WMI all day. The signal is a workstation using WMI against another workstation, or an unusual account doing it.
How to reduce the risk
MITRE lists four mitigations:
- Privileged account management. Prevent credential overlap across systems for administrator and privileged accounts, so one stolen credential does not unlock WMI everywhere.
- Behavior prevention on endpoint. On Windows 10 and later, enable Attack Surface Reduction rules that block processes created by WMI commands. MITRE warns that many legitimate tools use WMI for command execution, so test before you enforce.
- User account management. By default only administrators can connect remotely using WMI. Restrict who is allowed, or disallow remote WMI for all users where it is not needed.
- Execution prevention. Use application control to block wmic.exe where it is not required. MITRE gives Windows Defender Application Control policy rules as an example for Windows 10 and Windows Server 2016 and above.
Also restrict inbound access to the WMI and WinRM ports with host firewalls, so that workstations cannot reach each other on them. That follows from the port information on the MITRE page.
Check your own environment
Windows PowerShell, list WMI event subscriptions in the root subscription namespace. This is read-only. On most machines this returns little or nothing, and every entry needs an explanation:
Get-CimInstance -Namespace root\subscription -ClassName __EventFilter
Get-CimInstance -Namespace root\subscription -ClassName __EventConsumer
Get-CimInstance -Namespace root\subscription -ClassName __FilterToConsumerBinding
Windows PowerShell, check whether wmic.exe is present on this machine:
Get-Command wmic.exe -ErrorAction SilentlyContinue
Windows PowerShell, see which accounts are in the local group that can reach WMI remotely by default:
Get-LocalGroupMember -Group "Administrators"
Then a short review:
- Is command line auditing turned on for process creation?
- Do you forward WMI Activity logs to a central place?
- Which hosts should be allowed to use remote WMI against which others?
- Is wmic.exe still needed on any system? If not, block it.
Quick check
Which ports does remote WMI use?
Port 135 for WMI over DCOM, and ports 5985 (HTTP) and 5986 (HTTPS) for WMI over WinRM.
Why is blocking wmic.exe alone not enough?
WMI can also be reached through PowerShell, wbemtool.exe and COM APIs from languages such as C++, .NET and VBScript. MITRE notes WMIC is being replaced by PowerShell as the main interface.
