T1047
Windows Management Instrumentation
What it is
Windows Management Instrumentation (WMI) is the built-in interface for managing a Windows machine: querying its configuration, reading its state and carrying out actions on it, either locally or from another host over the network. Administrators and management tools rely on it constantly, and it is present and enabled on every supported version of Windows.
One of the actions WMI exposes is starting a process. That makes it an execution mechanism in its own right: WMI can run a command on a host without opening a remote shell or installing anything, using only components Windows already ships.
How adversaries use it
Locally, an attacker can ask WMI to start a program instead of launching it directly. That changes what the process tree records: the new process is started by WMI's own machinery rather than by the attacker's shell, so the link back to the command that caused it is less obvious.
Remotely, WMI is a long-established way to run a command on another machine with valid administrative credentials. The built-in command-line client, the CIM and WMI cmdlets, and widely used remote-execution tools all reach the same interface, and nothing has to be copied to the target first.
WMI also serves discovery, to enumerate processes, installed software, security products and accounts, and can keep code running through event subscriptions. That case is tracked separately in ATT&CK, under event-triggered execution.
Detect it in Elastic
Data source: Endpoint process-creation telemetry on the host where the WMI request ran, with authentication records for the calling account and WMI event-subscription records
Key fields
Two signals cover most WMI use. For commands run through WMI, Sysmon Event ID 1 (event.code: "1") records the resulting process, and process.parent.name is the field to read first: a process started through WMI has a different parent from one started in a shell or an interactive session, and process.command_line on that process shows what was run. When the request came from another machine, the receiving host also records an authentication for the calling account just before the process starts, which ties the execution back to its origin. For persistence, Sysmon Event IDs 19, 20 and 21 record a WMI event subscription's filter, consumer and binding; the consumer's command or script is what runs when the filter fires.
Example event
{
"host": {
"name": "WKSTN07"
},
"event": {
"code": "20",
"action": "WmiEventConsumer activity detected"
},
"winlog": {
"event_data": {
"Name": "ExampleConsumer",
"Type": "Command Line",
"Operation": "Created",
"Destination": "C:\\Example\\job.bat"
}
}
}Prebuilt Elastic rule: Persistence via WMI Event Subscription
Hunt guidance
Start from what WMI starts. On most hosts, the programs WMI launches form a small, stable set. Establish that set for each host from the host's own earlier activity, and treat a program or command line that WMI has not started on that host before as the lead, rather than reviewing every process WMI starts.
For remote execution, pair the target with the source. On the target, the new process appears shortly after a remote sign-in from another machine. On the source, look for the client that made the call: the WMI command-line utility, the CIM or WMI cmdlets, or a remote-execution tool. A remote sign-in followed within seconds by a new process that WMI started ties the two together.
Where it is collected, the WMI-Activity operational log records the operations themselves, including the method call that created a process. That helps when the process-creation record alone is ambiguous.
Ruling out legitimate activity
WMI is busy on every managed Windows estate. Endpoint management suites, monitoring agents, inventory tools, security products and administrators' own scripts query it constantly, and many of them start processes through it as part of normal operation.
The useful discriminators are the same as for any execution mechanism: what was run, from where, by which account, and whether that host has done it before. A management agent starting its own signed helper, as it does every day, is routine. A command interpreter, an encoded command line, or a binary in a user-writable location that WMI started, particularly by an interactive account or from another workstation, is not. A per-host picture of what WMI normally starts is what makes the unusual case stand out from the volume.
Telemetry needed
References
Practice it
1 scenario in this catalog covers T1047. We don't name it, because identifying the technique is part of what a scenario grades. Explore the Range →