How T1047 Windows Management Instrumentation shows up in Windows intrusions
A SOC lead looking at Windows telemetry will often see WMI activity that looks routine, and the working question is how to separate abuse from legitimate administration. The answer is rarely a single event. It comes from context: which account started the WMI process, which host it ran against, what the parent process was, and whether the pattern matches how administrators on that estate normally use WMI. Start by baselining the normal WMI administration on your Windows fleet before tuning any alert. Execution (TA0002) is the ATT&CK tactic where adversaries try to run malicious code or instructions on a system. T1047 Windows Management Instrumentation is one way to do that, by using the WMI service to run commands or start processes on a local or remote Windows host. Because WMI is a built-in administration interface that operations teams use every day, the technique blends into normal activity, which is why detection depends on the surrounding process, network and account context rather than on WMI use alone. This page targets Enterprise ATT&CK 20.0. Technique mappings, detection strategy IDs and data component references can change between releases, so confirm them against the version your detection content names before you rely on them. For the mapping work, check the current technique page on MITRE ATT&CK and the ATT&CK updates page for any changes that affect T1047 since 20.0. Record which ATT&CK version each Sigma rule, Wazuh decoder or Security Onion query was written against, so that a later release does not silently break coverage. Ask your detection engineering team to confirm which WMI-related telemetry is already collected from endpoints and domain controllers, since many gaps come from logging that was never enabled rather than from missing rules.
Which Windows telemetry reveals WMI execution and which tool collects it
This table maps each data component used to detect T1047 to the signal it gives, the Windows source that produces it, and an open-source collector that can gather it. Read it as a checklist: confirm each source is enabled and forwarded before relying on the detection, because field availability depends on your logging configuration. The main takeaway is that process and WMI-specific events carry most of the signal, while network events add context.
| Data component | Signal for WMI execution | Windows source and open-source collector |
|---|---|---|
| Process Creation (DC0032) | Records the process started by the WMI provider host, including parent, command line and user context, which shows remote or local WMI-launched processes | Windows Security event 4688 or Sysmon Event ID 1; collect with Wazuh agents or a Sysmon-based pipeline forwarded to Wazuh or Security Onion |
| Network Connection Creation (DC0082) | Shows outbound connections on RPC or DCOM ports from the calling host, useful for spotting remote WMI activity between hosts | Sysmon Event ID 3 or Zeek connection logs; collect with Sysmon-based forwarding, Zeek on Security Onion or Suricata metadata |
| WMI Creation (WMI activity) | Captures creation of WMI event filters, consumers and bindings, which can indicate persistence or remote subscription abuse alongside execution | Sysmon Event IDs 19, 20 and 21, or Windows WMI-Activity operational logs; collect with Wazuh agents or Velociraptor artifacts |
| Command Execution (DC0064, supporting) | Records command-line or script content run through WMI, which helps analysts confirm intent when process records are sparse | Command-line capture within process events or PowerShell script block logging; collect with Wazuh or Velociraptor where enabled |
| Logging configuration (all rows) | Determines whether each signal exists at all, including command-line auditing, Sysmon rule scope and WMI operational log size | Confirm with your Windows audit policy, Sysmon configuration and forwarding setup in your own environment before tuning any detection |
Detection logic for WMI-driven execution that analysts can tune
WMI-driven execution hides inside normal Windows management traffic, so no single event is conclusive. The cards below pair each detection idea with the thresholds analysts should set and the legitimate management tools that will trigger it. Tune each rule against your own estimated baseline before it pages anyone.
Unexpected parent-child relationships under the WMI provider host
Process creation telemetry for the WMI provider host process (WmiPrvSE.exe) is the starting point. Alert when it spawns command interpreters, script hosts or unsigned binaries, because the provider host normally spawns only provider DLLs and a small set of vendor agents. Set the threshold at the first occurrence per host for child processes outside your approved list, then widen only after two weeks of review. Expected false positives come from SCCM and endpoint management agents, which launch scripts through WMI as part of normal inventory and patch jobs. Maintain an allowlist keyed on signed publisher and parent path, not on process name alone.
Remote WMI sessions to management ports
Network connection creation events show which hosts open connections to the remote management ports used by WMI. Flag a workstation that initiates these connections to more than one peer within a short window, since administrators and management servers usually touch many endpoints from a small number of sources. Set the threshold by source host, comparing against the count your management servers normally produce during a patch cycle. Common false positives include monitoring products that poll hardware status, asset discovery scans and remote support tools. Confirm the source list with your infrastructure team before tuning the threshold down.
WMI event consumer and subscription creation
Permanent WMI event subscriptions bind a filter to a consumer, which lets an attacker run code when a system event occurs. Monitor for the creation of event filters, event consumers and their bindings, and alert on any new binding that is not tied to a known product. Because these objects are rare in healthy estates, a single unexpected binding deserves immediate triage rather than a threshold. Expected noise is limited, but endpoint security suites, some backup products and older management agents create bindings during install, so record a golden baseline after each software change window.
Unusual command execution from management tooling
Management tooling such as remote administration consoles and inventory agents should run a predictable set of commands. Compare command execution telemetry for these tools against a per-host profile built over a baseline period, and alert when a tool runs commands it has never run before or runs them outside its scheduled window. Set the threshold as a deviation from the host's own history rather than a fixed count. Expected false positives include scheduled inventory jobs, monthly patch windows and help desk sessions, so align the baseline with your change calendar and document each approved job.
Privileged account use for WMI execution
WMI execution usually runs under an account with local or domain administrative rights. Correlate WMI-related process events with the account performing them, and alert when a standard user account or a service account outside its expected host set triggers them. This check depends on account management controls being in place, so confirm that administrative accounts are separated from daily-use accounts. False positives come from service accounts used by SCCM and monitoring products, which should be documented with their permitted hosts and reviewed when those products are upgraded.
How to confirm the T1047 detection fires before you trust it
This sequence turns a T1047 detection idea into evidence that the alert fires, carries the fields analysts need, and behaves predictably under normal administrative noise. It ends with a documented gap list that drives tuning and the next range exercise.
Agree the emulation scope in writing
Before anything runs, the detection owner, the range operator, the system owners and the authorized testing lead agree in writing which hosts, accounts and time window are in scope, which WMI-related behaviors the team will exercise at a high level, and who can stop the exercise. The scope names the ATT&CK version the detection targets, since ATT&CK v20 is the version these pages use, and the detection strategy and data components it relies on. Done means a signed scope note that the range operator can point to during the run.
Map each planned action to expected telemetry
Each activity in the agreed scope is written as a row in a validation matrix with the expected data components, most likely Process Creation (DC0032), Network Connection Creation (DC0082) and WMI Creation, the host and log sources that should record it, and the rule or analytic expected to fire. Analysts review the matrix so that every planned action has a named signal before the run starts. Done means each row has a source, a field list and an expected alert name, with no row left blank.
Confirm baseline telemetry is flowing
Before the controlled window opens, the platform team checks that the Windows event sources, the Wazuh or Security Onion agents, and any Sysmon or equivalent configuration are reporting from the range hosts, and that clocks are synchronized across the endpoints and the SIEM. Silent sources are fixed now, because a missing log source looks identical to a missed detection later. Done means a dated health check shows every in-scope host reporting to the platform.
Run the activity in a controlled window
The range operator executes the agreed actions inside the defined window, one planned row at a time, while a second person records the start and end time of each action in the validation log. The operator does not improvise outside the matrix, and the stop authority watches for any spread beyond the scope. Done means the log shows each action with timestamps and an operator name, and the stop point was either not used or recorded.
Check each alert for timing and fields
Analysts compare each expected row against what the SIEM recorded, checking whether the alert fired, how long after the action it appeared, and whether the key fields are populated, such as the process image, parent process, command line, user, host and destination where relevant. An alert that fires with empty fields is recorded as a partial pass, because analysts cannot triage it. Done means every row carries a result of fired, partial, or missed, with the measured delay and the list of missing fields.
Measure false positives during the window
Analysts review every alert raised in the window that was not part of the matrix, along with routine administrative activity on the same hosts, to separate expected benign WMI use from alerts that would swamp a queue in production. Each unexplained alert is tagged with its cause and the allowlist or tuning option that would address it, and the owners agree which tuning changes are safe. Done means a false positive table exists with an owner and a decision for each entry.
Record gaps and retest after tuning
The team writes a gap register listing each missed or partial detection, the likely cause (missing data source, rule logic, field mapping, or time delay), the owner and the planned fix, then reruns the affected rows after changes are made. Compliance and audit owners receive the validation log as evidence of testing, not as an assurance statement. Done means the register is closed, or each open gap has a dated owner decision, and the rerun results are attached to the same record.
Why WMI activity is hard to separate from normal administration
Detecting T1047 Windows Management Instrumentation cannot rely on seeing WMI run, because WMI is a built-in Windows management interface that monitoring agents, inventory tools, endpoint products and administrators use every day. The decision that matters is which context turns a WMI event into a finding: the parent process that spawned the WMI activity, the account making the call, the source host, the target host and the time of day. A detection that alerts on any remote WMI execution will flood the queue on a busy Windows estate, so teams should agree on a baseline of expected WMI callers before writing alert logic. Confirm this baseline with the operations and endpoint teams rather than assuming it from a generic template.
The reference for this logic is the MITRE ATT&CK detection content for the technique, which is published as detection strategies with DET IDs and analytics. ATT&CK v18, released October 28, 2025, moved technique pages from a single detections section to these detection strategies and analytics, and it also reworked data components. Before mapping rules, check which ATT&CK version your detection library targets, because later releases such as v19 and v20 can rename or revise content. A practical starting point is to record, for each analytic you adopt, the data component it depends on (for example Process Creation or Network Connection Creation), the fields it reads, and the version it was written against. Your own tuning records should then show which context fields reduced false positives and which removed real signal.
Several decisions follow from this. Name an owner for the WMI caller baseline and review it after major changes to management tooling. Decide whether remote WMI from administrative jump hosts is allowed to go unalerted, and document that exception so it is visible to auditors. Ask your detection engineers to state, in each rule's notes, which ATT&CK version and analytic the rule implements, so that a future ATT&CK release does not silently break coverage. These steps cost staff time rather than tooling, and they are the difference between a WMI rule that analysts trust and one they mute.
Mitigations that reduce WMI abuse: user and privileged account controls
T1047 runs through accounts that are allowed to use remote management. The two ATT&CK mitigations this page targets, User Account Management (M1018) and Privileged Account Management (M1026), shape who holds that access and how it is limited. The cards below describe what to review in each area and what to confirm in your own environment.
Limit who can use remote management
Review which groups and accounts can reach WMI remotely, both locally and across the network. Remote WMI access is often granted broadly for inventory or monitoring tools that no longer need it. Confirm which service accounts still hold remote management rights, document the business reason for each, and remove rights that have no current owner. Check the same list after every change to group membership, since access often returns through nested groups.
Restrict administrative accounts
Identify every account with local administrator rights on Windows endpoints and servers, and confirm that day-to-day users do not hold them. Standing administrative rights make WMI execution with elevated privileges possible from ordinary sessions. Ask your team to confirm how local administrator passwords are unique per system and how changes to admin group membership generate alerts that reach a responder.
Separate administrative tiers
Keep accounts used for workstation work separate from accounts used to manage servers, domain controllers and security tooling. When a workstation account is compromised, a separate tier limits how far WMI execution can reach. Review whether privileged accounts log on to lower-tier systems, and confirm that the tier boundaries are enforced by policy rather than by habit.
Review privileged account use
Confirm that privileged accounts are used only for approved administrative tasks and that their logons to remote hosts are logged and reviewed. Pay attention to WMI sessions started by accounts that normally do not perform remote administration. Your team should confirm how often these accounts are reviewed and who signs off on the review.
Validate controls before relying on them
Effectiveness of these mitigations depends on your directory design, your tooling and your change process, so it must be confirmed in your own environment. Ask whether the controls were tested with a WMI execution scenario in a non-production setting, and whether the results were recorded against the ATT&CK version you target, as described in the detection notes on this page.
Triage steps when a WMI execution alert fires
Start by confirming who ran the activity and from where before anyone treats the alert as an intrusion. Pull the originating host, the account that authenticated, and the parent process that launched the WMI client, then match them against your asset inventory and identity records. Confirm whether the account is a named administrator, a service account or a user without a documented need for remote management. If the source host is a patch management server, a monitoring collector or a known administration workstation, the alert is more likely a sanctioned job, but the account still has to be verified against its owner. Record the timestamps in UTC so they line up across Windows event logs, sensor data and firewall records.
Next, check whether the activity matches an approved management job. Ask the change owner or the team that runs your endpoint and configuration tooling whether a scheduled inventory, software deployment or remote query was planned for that window, and ask for the job identifier or change ticket. Then scope the blast radius: search for similar process creation and network connection events from the same source host to other hosts on the DCE/RPC and WMI ports in the same time range, and list every target that received a connection. A single target that matches an approved job is different from a fan-out across a subnet. Confirm which of your detection sources, including Sysmon or endpoint telemetry, actually recorded each step, because gaps in coverage change how far you can scope with confidence.
Preserve evidence before making changes that could overwrite it. Export the relevant Windows event log channels and sensor records for the source and target hosts, keep copies of the detection rule and alert payload, and note who accessed them. Collect volatile data such as running processes, network connections and logged-on sessions only when the alert suggests active use, and follow your incident response procedure for chain of custody. Decide on containment based on what you have confirmed: if the account or source is unverified and activity is ongoing, isolate the host or disable the account through your identity process and escalate to the incident response lead and the owner of the affected systems. If the job is approved, document the result and tune the rule to the known pattern instead of suppressing it broadly.
Rehearsing T1047 detection in a private cyber range
The range should mirror the parts of the client estate where T1047 activity would matter, without touching production systems or production identities. A private range is isolated from corporate networks, and DeployOpen builds it inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. The design is agreed in writing before work starts, including which Windows versions, domain structure and log sources are in scope.
- Windows endpoints: Include workstations and servers that represent the real build images, with Sysmon or equivalent process and WMI event logging configured the way the client's standard builds configure it.
- Monitored domain: Stand up a directory domain with tiered administrative accounts so that user and privileged account behavior can be observed and tested against the mitigation design.
- Collection stack: Forward Windows event data to Wazuh, or to Security Onion where network telemetry is also required, and confirm which Windows event channels reach the platform.
- Network visibility: Place sensors where Network Connection Creation telemetry can be captured between range hosts so that remote management traffic is visible.
- Version pinning: Record the ATT&CK version the detections target, such as Enterprise ATT&CK 20.0, so results remain comparable after later releases.
Confirm with the client's security team which logging policies on production endpoints the range must match.
An inject is a scripted, controlled action that the exercise team runs to produce telemetry the detection should catch. Injects are mapped to the detection set for T1047 and to the data components the detection depends on, such as Process Creation and Network Connection Creation. The exercise team, not the analysts being tested, controls timing and records each action so that every alert can be traced back to a known event. Scenario scope, including which behaviors are permitted, is agreed in writing with the client before the exercise.
- Scripted sequence: Define a numbered list of injects, each with a stated purpose, expected data source and expected alert, so reviewers can compare outcomes line by line.
- Benign variants: Include administrative activity that looks similar but is legitimate, so the team can measure false positives as well as misses.
- Mitigation checks: Add injects that test whether User Account Management and Privileged Account Management controls block or log the activity as designed.
- Timing record: Log the time of each inject at the source so detection latency can be measured.
- Stop conditions: Document how the exercise is halted and how range hosts are reset between runs.
Ask for the inject catalog and the stop conditions in writing before the first run.
A rehearsal is useful only when its results can be judged against criteria agreed before the run. The criteria cover detection timing, analyst handling and the feedback loop into rules. They should be written so that a CISO, a platform lead and an auditor could each read the same result and reach the same conclusion. DeployOpen prepares the evidence, and independent auditors or certification bodies decide whether it satisfies any control requirement.
- Timely alerts: Alerts for each inject fire within the window the team set in advance, and the window is recorded for each scenario.
- Runbook use: Analysts follow the T1047 runbook, including triage, scoping across hosts and containment steps, and their notes show which steps they followed.
- Accurate scoping: The team identifies the affected hosts and accounts that the inject set touched, with no missed endpoints.
- Rule feedback: Gaps and noisy rules produce tracked changes to Sigma rules or Wazuh rules, each linked to the ATT&CK version used in the run.
- Retest: Changed rules are rerun against the same inject set to confirm the fix, and the results are kept with the exercise record.
Agree the thresholds for timing and scoping with the client before the exercise, not after the results are known.
Questions SOC leads ask about detecting T1047
How do you tell WMI administration apart from WMI abuse?
Start from a baseline of which accounts, hosts and parent processes legitimately use WMI, then alert on deviations rather than on WMI use itself. Administrative use is usually predictable: known management servers, specific service accounts and expected namespaces. Abuse tends to show up as remote execution from workstations, unusual parent-child chains that launch command interpreters, or WMI commands run by accounts that do not normally administer endpoints. Record these patterns for a few weeks in your own environment before you tune alerts. Your Process Creation and Network Connection Creation telemetry will carry most of the signal, and the combination of both is usually more informative than either alone.
How do you tune WMI detections for SCCM noise?
Treat Configuration Manager as a known, named source of legitimate WMI activity and scope exclusions to it precisely. Identify the site servers, distribution points and client agents that generate the traffic, then exclude them by host and account rather than by process name alone, since process names are easy to imitate. Review every exclusion on a schedule and document why it exists. Keep the excluded activity logged so that a compromised management host remains visible. Confirm the exact WMI namespaces and command patterns your Configuration Manager version uses with your platform team before you write exclusions, because these details vary by deployment.
Which data sources must be enabled to detect T1047 on Windows?
At minimum you need process creation events with command line capture, network connection events, and WMI activity logging. ATT&CK's detection content for this technique relies on the Process Creation data component, and the Network Connection Creation component adds context for remote WMI sessions. Without command line logging, you can see that a process started but not what it was asked to do. Enable the WMI Activity operational log and confirm that event volume is retained long enough to support investigations. Check each source on a test host first, because a configured policy does not guarantee that events reach your collector.
How do you test a WMI detection rule in Sigma and Wazuh?
Write the rule in Sigma first so it stays portable, then convert it to your Wazuh rule format and test both versions against the same sample events. Build a labeled test set that contains benign administrative activity and simulated suspicious activity generated in a lab or cyber range. Confirm that each rule fires on the malicious set, stays quiet on the benign set, and produces fields your analysts can pivot on. Record the results and the rule version so you can repeat the test after any change. Use your own lab for these tests, and avoid running technique behavior against production systems.
How often should T1047 detections be re-validated against new ATT&CK versions?
Re-validate whenever MITRE publishes a new Enterprise ATT&CK version that touches Execution techniques, and record the version each detection targets. Recent releases include v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and releases can rename, deprecate or revoke techniques and change detection content. Check the ATT&CK updates pages after each release, compare the detection strategy and data component references for T1047, and rerun your test set. Confirm the exact cadence and scope of this review with your detection engineering owner, since it depends on how your team tracks content.
What should we do when WMI telemetry is missing or incomplete?
Treat missing telemetry as a detection gap, not as evidence that nothing happened. First confirm whether the problem sits on the endpoint, in the forwarding agent, or in the collector. Check that the relevant logging policies are applied, that the WMI Activity log is not full or disabled, and that the agent is shipping those channels. Then test the gap with a controlled event in your cyber range and confirm it arrives in your SIEM. Until the gap closes, document it as a known limitation, add compensating checks such as network-based monitoring, and raise it in your risk register. DeployOpen can help plan and implement the logging and collection changes inside your environment, with the scope agreed in writing first.
Can a team run T1047 detection and response rehearsals without outside help?
A capable detection team can run basic rehearsals in-house if it has a isolated lab, clear rules of engagement and people who can read Windows event logs well. The work usually includes building test hosts, scripting controlled WMI activity, verifying each data source and running response playbooks. Costs come from staff time, lab infrastructure and the effort to keep it current, and most of these recur as ATT&CK content changes. External help is useful when the team lacks lab build experience or needs an independent view of coverage. Ask any provider for a written scope listing the systems, data sources and exercises covered before work starts.
How DeployOpen builds T1047 detections and range exercises
DeployOpen works on T1047 Windows Management Instrumentation as a fixed-scope engagement, and the first deliverable is a written scope that names the Windows estate, the open-source stack that will receive the telemetry, and the data the detections depend on. In practice that means confirming that Process Creation events are collected from the hosts in scope, that WMI Creation events are logged where the client expects them, and that Network Connection Creation records are available from the endpoints or sensors that matter for remote WMI activity. The scope also records who owns each log source, how long events are retained in the client's own environment, and which accounts are allowed to run administrative WMI tasks on servers. Gaps found at this stage are written down as preconditions, so the client knows what must change before detection work starts. Timelines and effort depend on the size of the estate and the state of logging, so the client should ask for them in the written scope rather than assume them.
Once telemetry is confirmed, DeployOpen builds or tunes detections on the client's own open-source stack, typically Wazuh, Security Onion, Zeek, Sigma rules and Velociraptor where those tools are already deployed or agreed. The work focuses on the decisions a SOC analyst will face: whether a WMI process launch from a management server is expected, which parent processes and remote hosts are normal for the client's administrators, and which accounts should trigger review when they run WMI remotely. Each rule is tested against benign administrative activity first, so the false-positive profile is known before handover. Detection logic is mapped to the ATT&CK version the client targets, since ATT&CK v18 and later releases changed how detections are described and which data components they reference. The client's privileged account controls, covering the ATT&CK mitigations User Account Management (M1018) and Privileged Account Management (M1026), are reviewed alongside the rules because they determine who should be generating WMI activity at all.
DeployOpen then rehearses the detections in a private cyber range, where a purple team exercise runs controlled WMI activity against replicas of the client's Windows hosts and the blue team responds using its own runbooks. The exercise checks whether the alert fires, whether it reaches the right queue, and whether the analyst has the context needed to decide quickly. Results, timestamps, rule versions and open gaps are documented as evidence that the client can give to internal audit or to an independent assessor. DeployOpen prepares that evidence but does not issue audit reports or certifications; independent auditors and certification bodies make those determinations. Ongoing testing and tuning can be added as a retainer, and the client should confirm in writing who maintains the rules after handover.
