T1047: Windows Management Instrumentation
Adversaries may abuse Windows Management Instrumentation (WMI) to execute malicious commands and payloads. WMI is designed for programmers and is the infrastructure for management data and operations on Windows systems.CitationWMI 1-3 WMI is an administration feature that provides a uniform environment to access Windows system components.
The WMI service enables both local and remote access, though the latter is facilitated by Remote Services such as Distributed Component Object Model and Windows Remote Management.CitationWMI 1-3 Remote WMI over DCOM operates using port 135, whereas WMI over WinRM operates over port 5985 when using HTTP and 5986 for HTTPS.CitationWMI 1-3 CitationMandiant WMI
An adversary can use WMI to interact with local and remote systems and use it as a means to execute various behaviors, such as gathering information for Discovery as well as Execution of commands and payloads.CitationMandiant WMI For example, `wmic.exe` can be abused by an adversary to delete shadow copies with the command `wmic.exe Shadowcopy Delete` (i.e., Inhibit System Recovery).CitationWMI 6
**Note:** `wmic.exe` is deprecated as of January of 2024, with the WMIC feature being “disabled by default” on Windows 11+. WMIC will be removed from subsequent Windows releases and replaced by PowerShell as the primary WMI interface.CitationWMI 7,8 In addition to PowerShell and tools like `wbemtool.exe`, COM APIs can also be used to programmatically interact with WMI via C++, .NET, VBScript, etc.CitationWMI 7,8
Security context for executives and security teams
Windows Management Instrumentation matters because it is a normal Windows administration capability that can also be used to run commands and payloads locally or remotely. For leaders, the risk is not that WMI exists, but that legitimate management pathways can become an execution path during an intrusion, including ransomware or espionage activity referenced in ATT&CK relationships. Coverage depends on whether the organization can distinguish approved administration from suspicious WMI-driven execution.
Executive priority
Prioritize WMI as a control-validation issue for Windows estates: who is allowed to use remote management, how privileged accounts are governed, and whether SOC/IR teams can reconstruct WMI activity after an incident. Because ATT&CK links this technique to many campaigns and groups, it is a useful test of operational resilience, privileged access governance, and audit evidence for endpoint monitoring and administrative control enforcement.
Technical view
T1047 is an Enterprise ATT&CK execution technique on Windows. WMI can be accessed locally or remotely; remote WMI may be facilitated through DCOM or WinRM, with ATT&CK noting ports 135, 5985, and 5986. Defenders should validate visibility into WMI execution through legacy wmic.exe, PowerShell as the primary WMI interface going forward, wbemtool.exe, and programmatic COM/API use. ATT&CK provides no official detection text for this object, but a related detection strategy, DET0364, is mapped to WMI execution abuse, and mitigations include user account management, privileged account management, execution prevention, and endpoint behavior prevention.
Likely telemetry
- Windows process creation events with command line, parent/child process, user, host, and integrity context
- PowerShell activity involving WMI interactions, where PowerShell logging is enabled
- WMI service, provider, and operational logs sufficient to identify local or remote WMI activity
- Authentication and logon events tied to remote administration or privileged account use
- Network telemetry for remote WMI pathways, including DCOM over port 135 and WinRM over ports 5985 and 5986 as cited by ATT&CK
Detection direction
- Validate whether DET0364 or equivalent behavioral analytics are implemented for WMI execution abuse rather than relying only on detection of wmic.exe, which ATT&CK notes is deprecated and disabled by default on Windows 11+.
- Tune for context: WMI is a legitimate administration mechanism, so detections should account for approved management servers, expected administrators, normal maintenance windows, and known tooling.
- Look beyond legacy WMIC command lines. Confirm visibility into PowerShell-based WMI usage, wbemtool.exe, and programmatic COM/API access where telemetry supports it.
- Correlate WMI execution with remote-service evidence, privileged account activity, unusual source hosts, and downstream child processes.
- Treat destructive or recovery-impacting WMI usage, such as shadow copy deletion described in ATT&CK, as high-priority triage when observed in combination with suspicious execution context.
Mitigation priorities
- Start with user account management: ensure account lifecycle, deactivation, and role assignment reduce unnecessary access to Windows management functions.
- Strengthen privileged account management: restrict administrative rights, apply least privilege, monitor privileged account use, and preserve accountability through logging and auditing.
- Apply execution prevention where appropriate so unauthorized code, scripts, and administrative tooling cannot run freely on managed endpoints.
- Use endpoint behavior prevention to block or alert on suspicious WMI-driven process behavior when it deviates from approved administrative activity.
- Review remote management exposure and permitted administration paths for DCOM and WinRM in line with business need and monitoring capability.
Additional notes and limits
The decision value is in separating normal Windows administration from adversary execution. WMI is common enough that noisy command-name alerts can create false positives, but important enough that lack of visibility creates a material IR blind spot. The supplied relationships show broad use across campaigns and groups, including espionage, ransomware, and disruptive contexts, but those relationships should be treated as historical ATT&CK context rather than proof of current activity in any environment.
MITRE does not provide official detection text for this technique in the supplied object. Local conclusions require environment-specific data: approved admin tooling, Windows versions, PowerShell and WMI logging configuration, privileged account model, remote management architecture, and endpoint telemetry quality. No active exploitation, customer exposure, or guaranteed detection coverage is implied.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Windows Management Instrumentation
Adversaries may abuse Windows Management Instrumentation (WMI) to execute malicious commands and payloads. WMI is designed for programmers and is the infrastructure for management data and operations on Windows systems.CitationWMI 1-3 WMI is an administration feature that provides a uniform environment to access Windows system components.
The WMI service enables both local and remote access, though the latter is facilitated by Remote Services such as Distributed Component Object Model and Windows Remote Management.CitationWMI 1-3 Remote WMI over DCOM operates using port 135, whereas WMI over WinRM operates over port 5985 when using HTTP and 5986 for HTTPS.CitationWMI 1-3 CitationMandiant WMI
An adversary can use WMI to interact with local and remote systems and use it as a means to execute various behaviors, such as gathering information for Discovery as well as Execution of commands and payloads.CitationMandiant WMI For example, `wmic.exe` can be abused by an adversary to delete shadow copies with the command `wmic.exe Shadowcopy Delete` (i.e., Inhibit System Recovery).CitationWMI 6
**Note:** `wmic.exe` is deprecated as of January of 2024, with the WMIC feature being “disabled by default” on Windows 11+. WMIC will be removed from subsequent Windows releases and replaced by PowerShell as the primary WMI interface.CitationWMI 7,8 In addition to PowerShell and tools like `wbemtool.exe`, COM APIs can also be used to programmatically interact with WMI via C++, .NET, VBScript, etc.CitationWMI 7,8
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.