---
{
  "title": "Windows Management Instrumentation",
  "summary": "WMI abuse uses Windows management functionality for discovery, execution, or other unauthorized activity.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1047"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1047: Windows Management Instrumentation",
      "url": "https://attack.mitre.org/techniques/T1047"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

WMI abuse uses Windows management functionality for discovery, execution, or other unauthorized activity. WMI's legitimate administrative role makes attribution dependent on context.


## An investigation example

A rarely used administrative identity triggers remote management activity followed by a new process on a workstation.

## Evidence to examine

Correlate management events, source identity, remote connections, process ancestry, and approved administration records.

## A common analytical pitfall

WMI usage alone is not malicious; many management products depend on it.

## Response considerations

Preserve both management and endpoint evidence, verify the initiating identity, and constrain unnecessary remote administrative authority.


## Management capability can serve legitimate and unauthorized work

Windows Management Instrumentation provides structured access to management information and operations. Administrators and monitoring tools use it for inventory and control, while an intruder may misuse available capabilities for discovery or execution. The relevant security question concerns the requesting identity, operation, target, and authorization, not merely the presence of WMI activity.

Local and remote use can have different evidence and access requirements. A management query is distinct from starting a process, and an attempted operation is distinct from success. Other WMI-related mechanisms can support persistence, but that should not be inferred from every query. Describe the operation actually observed.

## A fictional remote-management sequence

An academy's endpoint records show a management-related process associated with unexpected execution on a workstation. Analysts correlate authentication, management logs, process ancestry, source host, and approved support activity. They establish whether the operation came from an expected management server or another source using available authority.

Telemetry configuration affects detail. Some records may identify the provider or operation while others show only a resulting process. Preserve the source and timing of each observation and avoid assuming that one process name explains every action. A later live query can describe current state without reconstructing all earlier management activity.

## Map a management request

Draw a fictional administrator, management service, target workstation, and resulting process. Mark authentication, authorization, request, and execution evidence separately. Then compare an approved inventory query with an unexpected execution request. Use documentation and prepared records rather than issuing remote commands to real devices.

Defensive planning should retain legitimate administration while limiting unnecessary authority and monitoring meaningful deviations. Removing all management capability can disrupt operations, while trusting every request from a familiar tool can hide misuse. Review the actual identity and target boundary and verify the effect of any containment action.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[incident-response]]
- [[remote-services]]
- [[inhibit-system-recovery]]
- [[command-and-scripting-interpreter]]