DC0008: WMI Creation
Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or providers.
Analyst context for executives and security teams
WMI Creation is a data component for observing the initial creation of Windows Management Instrumentation objects such as filters, consumers, subscriptions, bindings, or providers. Its business value is that these objects can become durable system state: if defenders do not know when they are created, investigations may miss important changes that affect persistence, automation, or system management visibility.
Executive priority
Treat this as a coverage-validation item rather than a standalone threat claim. Security leaders should ask whether the SOC and incident response teams can prove when WMI objects are created, who or what created them, and whether that evidence is retained long enough to support investigations, audit requests, and recovery decisions. Because the ATT&CK object provides no platform, tactic, mitigation, or detection guidance, prioritization should be driven by local exposure to WMI-based administration and the organization’s need for endpoint state-change evidence.
Technical view
Validate whether telemetry can capture the initial construction of WMI filters, consumers, subscriptions, bindings, and providers. Detection engineering should focus on evidence of new WMI object creation and correlate it with the creating account, host, process context, time, and any related management activity available in local logging. Incident responders should confirm they can distinguish expected administrative or software-management creation from unusual or unexplained creation events. No ATT&CK relationship context was supplied, so this should not be mapped to a specific technique or tactic without additional evidence.
Likely telemetry
- Endpoint or host logs that record WMI object creation
- WMI repository or namespace change evidence
- Process and command execution context associated with WMI changes, if locally collected
- Account, host, timestamp, and administrative tooling context tied to creation activity
- Change-management or endpoint-management records for expected WMI object deployment
Detection direction
- Confirm that WMI creation events are collected at all; the official ATT&CK object does not provide detection guidance.
- Baseline known administrative, monitoring, and software-management activity that legitimately creates WMI objects to reduce false positives.
- Alert or review on newly created WMI filters, consumers, subscriptions, bindings, or providers that lack an approved change record or expected owner.
- Correlate creation activity with identity, host role, and process context before escalating; WMI can be used for legitimate management.
- Identify blind spots where endpoint logging, retention, or normalization does not preserve enough detail to reconstruct who created the WMI object and when.
Mitigation priorities
- Establish an inventory or baseline of expected WMI objects where operationally feasible.
- Restrict and review administrative permissions that can create or modify WMI objects, using local access-control practices.
- Require change-management evidence for approved WMI object creation by management tools or administrators.
- Ensure incident response playbooks include review of WMI filters, consumers, subscriptions, bindings, and providers during endpoint state analysis.
- Set retention and collection requirements so WMI creation evidence is available during investigations and compliance reviews.
Analyst notes and limits
This take is intentionally framed around defensive validation because the supplied ATT&CK object is a data component, not a technique. The only official behavioral detail provided is the creation of WMI objects such as filters, consumers, subscriptions, bindings, or providers. No relationships, tactics, platforms, or official detection text were supplied.
ATT&CK provides no official detection text, no platform list, no tactics, and no relationship context for this supplied object. Local logging configuration, endpoint architecture, administrative tooling, and retention policy are required to determine practical coverage and detection value.
WMI Creation
Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or providers.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 01aedc7d9f3e… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0008Open source URL
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.