T1047 Windows Management Instrumentation Defensive Guide: Detecting WMI Execution and Persistence

Windows Management Instrumentation (WMI) gives anyone with administrative credentials a built-in, signed and remotely reachable way to run commands on Windows hosts, which is why intruders use it as readily as administrators do. MITRE ATT&CK tracks this as T1047 under the Execution tactic, and the closely related WMI event subscription persistence as T1546.003. This guide explains how WMI abuse works at the level a defender needs, where it appears in intrusions, which logs actually record it, and how to restrict it without breaking the management tools that depend on it. It is written for detection engineers, Windows platform owners and incident responders.

Key takeaways

• WMI abuse is a credential problem first. Remote WMI needs administrative rights by default, so shared local administrator passwords and over-privileged service accounts decide how far an attacker can travel with it.
• Two techniques, two detection paths. T1047 execution shows up as child processes of WmiPrvSE.exe and remote connections on port 135 or 5985/5986; T1546.003 persistence shows up as new event filters, consumers and bindings.
• Default logging is not enough. You need command-line process logging, Sysmon event IDs 1, 19, 20 and 21 (or an EDR equivalent) and the WMI-Activity Operational channel to see either technique reliably.
• Attack surface reduction rules help but collide with management agents. Both WMI rules conflict with Configuration Manager, so pilot in audit mode and scope by device role.
• WMIC removal does not remove WMI. Microsoft has removed wmic.exe from Windows 11 24H2 and later, but PowerShell CIM cmdlets and COM APIs reach the same WMI service, so detections must not key only on wmic.exe.

How the attack works

WMI is the Windows management infrastructure that exposes system data and operations through classes in namespaces such as root\cimv2. ATT&CK describes T1047 as abuse of WMI to execute commands and payloads, locally or remotely. Remote WMI travels over DCOM, which starts on TCP port 135 and then moves to a dynamic RPC port, or over Windows Remote Management (WinRM) on 5985 for HTTP and 5986 for HTTPS. The remote transports are tracked separately as T1021.003 Distributed Component Object Model and T1021.006 Windows Remote Management.

Execution (T1047)

• Process creation: the attacker calls a method such as the Win32_Process create method through wmic.exe, PowerShell (Invoke-CimMethod, Invoke-WmiMethod) or a COM client. The new process is started by the WMI Provider Host, so its parent is WmiPrvSE.exe, not the attacker's shell.
• Discovery: WMI queries return installed software, running processes, logged-on users, antivirus products and domain details without dropping tools, overlapping with Discovery techniques such as T1082 System Information Discovery and T1087 Account Discovery.
• Destruction: ATT&CK notes that wmic.exe has been used to delete Volume Shadow Copies before ransomware runs, which maps to T1490 Inhibit System Recovery.

Persistence (T1546.003)

A permanent WMI event subscription has three parts: an event filter (a WMI query that defines the trigger, such as a time interval, user logon or uptime threshold), an event consumer (the action, typically a CommandLineEventConsumer or ActiveScriptEventConsumer) and a filter-to-consumer binding that links them. When the trigger fires, WmiPrvSE.exe runs the consumer, often as SYSTEM. ATT&CK also notes subscriptions can be created by compiling MOF files with mofcomp.exe. Nothing needs to exist on disk beyond the WMI repository, which is why the technique features in the Fileless Malware Guide.

Where it shows up

ATT&CK v20 lists 55 groups and campaigns using T1047 and 12 using T1546.003. A few procedure examples show the range:

The common thread is valid administrative credentials. WMI rarely provides the initial access; it is what an intruder uses after harvesting a domain or local administrator credential, a deployment service account or a remote management tool's account. See the T1078 Valid Accounts Guide and the ATT&CK Execution Tactic Guide.

Impact

• Lateral movement at scale: one credential with local administrator rights on many hosts turns WMI into a remote shell across the estate, without installing a service as PsExec-style tools do.
• Durable persistence: event subscriptions run as SYSTEM on a schedule or trigger and survive reboots. Password resets do not remove them.
• Recovery sabotage: shadow copy deletion and service changes executed over WMI remove local recovery options shortly before encryption.
• Evasion through blending: management platforms, inventory agents and monitoring tools use WMI constantly, so unfiltered alerts drown analysts and attackers know it.

Detection

ATT&CK's analytic for T1047 chains process creation, command execution and, for remote use, the matching network connection. Its analytic for T1546.003 looks for creation of filter, consumer and binding objects, mofcomp.exe use, Register-WmiEvent in PowerShell and unusual children of WmiPrvSE.exe. The table lists the telemetry that supports both.

Detection logic that works

• Unusual WmiPrvSE.exe children: alert when WmiPrvSE.exe spawns cmd.exe, powershell.exe, rundll32.exe, mshta.exe or binaries from user-writable paths, and allow-list the specific management agents that do this legitimately. This is D3FEND's Process Spawn Analysis (D3-PSA) applied to WMI.
• Remote WMI from unexpected sources: on servers and workstations, inbound DCOM or WinRM sessions should come from a small set of management hosts. Anything else, especially workstation to workstation, is a lead.
• Any new permanent subscription: Sysmon 19-21 or WMI-Activity 5861 outside a change window. Known vendor subscriptions (the Sigma rule notes hardware health agents) form a short allow-list.
• Interface-agnostic matching: because wmic.exe is gone from current Windows 11 builds, match on the parent process and WMI events rather than only on wmic.exe command lines, and cover PowerShell CIM cmdlets through script block logging. See the PowerShell Security Guide.
• Hunting existing subscriptions: enumerate __EventFilter, __EventConsumer and __FilterToConsumerBinding instances in the root\subscription namespace across the fleet (for example with Get-CimInstance) and compare against a known-good list. Persistence created before your logging existed will not raise an event.

Metrics

• Percentage of Windows endpoints and servers sending Sysmon 1 and 19-21 (or equivalent EDR telemetry) to the SIEM.
• Number of hosts with unexplained permanent WMI subscriptions at the last fleet sweep (target: zero).
• Number of distinct source hosts making remote WMI connections, trended against the approved management host list.
• ASR WMI rule coverage: percentage of eligible devices in block mode, and audit events per week during pilot.
• Mean time from a WmiPrvSE.exe anomalous child alert to analyst triage.

Prevention and hardening

Rollout

1. Inventory WMI dependencies: list management agents, monitoring, backup and inventory tools that use WMI or create subscriptions, and which hosts they run from.
2. Turn on telemetry: command-line process auditing, Sysmon with WMI events or EDR equivalents, and forwarding of WMI-Activity Operational. See the Sysmon Guide and the Windows Event Log Guide.
3. Sweep for existing subscriptions: baseline every host, investigate anything unknown and record approved ones.
4. Pilot ASR rules in audit: start with a ring of Intune-managed workstations, review audit events for two to four weeks, add narrow exclusions for named tools.
5. Enforce in rings: move to block for workstations first, then servers that are not Configuration Manager clients. Roll back by switching the rule to audit or disabled through the same policy channel.
6. Constrain remote WMI by network: host firewall rules so only management hosts reach DCOM and WinRM; monitor denied attempts as a detection source.

Small organisations without Configuration Manager can usually enforce both ASR rules quickly and rely on LAPS plus host firewall rules. Large estates with Configuration Manager should prioritise detection and credential hygiene, scope ASR enforcement to device groups without the agent, and treat permanent subscription monitoring as the main persistence control.

Where identity fits

WMI does exactly what the authenticated caller is allowed to do, so the real control point is the credential. Deployment service accounts, backup agents and remote monitoring tools often hold local administrator rights on every host and rarely have interactive-logon restrictions or rotation. Treat them as privileged non-human identities: inventory them, restrict where they can authenticate from, rotate their secrets and alert when they connect from anywhere other than their home servers. See the Windows Services and Service Account Security Guide and the Windows Remote Management and WinRM/PowerShell Remoting Security Guide.

Lessons from incidents

ATT&CK records that during the SolarWinds Compromise (C0024), APT29 used WMI for remote execution during lateral movement and a WMI event filter that triggered a command-line consumer at boot to launch a backdoor. The SolarWinds supply chain compromise is mostly remembered for forged SAML tokens and hijacked application identities, but the on-premises stage relied on administrative access to move and persist, and WMI was one of the tools. The lesson is that persistence hunting has to include the WMI repository, not just services, scheduled tasks and Run keys.

• Allow-listing whole parent processes: excluding WmiPrvSE.exe children entirely because management tools are noisy blinds the detection that matters most.
• Keying only on wmic.exe: detections built on the wmic.exe command line miss PowerShell CIM, COM clients and remote tooling.
• Never sweeping the repository: subscriptions planted before logging was enabled stay invisible until someone enumerates them.
• Shared local administrator passwords: one dumped hash gives WMI execution on every machine built from the same image.
• Enabling ASR rules blind: enforcing the PsExec/WMI rule on Configuration Manager clients breaks management, and the rollback is often permanent disablement.

Framework mapping

Practitioner checklist

• Deploy Windows LAPS and remove shared local administrator passwords.
• Enable command-line process auditing and collect Sysmon 1, 3 (scoped), 19, 20 and 21 or EDR equivalents.
• Forward Microsoft-Windows-WMI-Activity/Operational and alert on new permanent subscriptions.
• Sweep root\subscription across the fleet and record every approved filter, consumer and binding.
• Alert on unusual WmiPrvSE.exe child processes with a tight, named allow-list.
• Pilot both WMI ASR rules in audit mode, then enforce in rings on devices without Configuration Manager.
• Restrict inbound DCOM and WinRM to approved management hosts.
• Inventory and constrain service accounts with local administrator rights.
• Update detections that rely on wmic.exe to cover PowerShell CIM and COM access.

Standards and references

• MITRE ATT&CK: Windows Management Instrumentation (T1047)
• MITRE ATT&CK: Windows Management Instrumentation Event Subscription (T1546.003)
• Microsoft Learn: Attack surface reduction rules reference
• Microsoft Sysinternals: Sysmon
• Microsoft Learn: Securing a Remote WMI Connection
• Microsoft Learn: Deprecated features for Windows client
• MITRE D3FEND: Process Spawn Analysis
• SigmaHQ: WMI Persistence detection rule

Related NHI Mgmt Group resources: Fileless Malware Guide · ATT&CK Execution Tactic Guide · Persistence Techniques Guide · T1059 Command and Scripting Interpreter Defensive Guide · MITRE ATT&CK Guide for Defenders