AN0024: Analytic 0024
Correlates unexpected modifications to WMI event filters, scheduled task triggers, or registry autorun keys with subsequent execution of non-standard binaries by SYSTEM-level processes.
Analyst context for executives and security teams
This analytic matters because it focuses on a common persistence and execution pattern on Windows: changes to automatic execution mechanisms followed by SYSTEM-level process activity running binaries that are not expected or standard for the environment. For leaders, the decision value is whether the organization can connect configuration changes to later execution, rather than only alerting on one event in isolation.
Executive priority
Prioritize this as a Windows resilience and incident-readiness validation item. Security leaders should ask whether SOC tooling can correlate autorun-related changes with subsequent SYSTEM-level execution, whether baselines exist for approved scheduled tasks, WMI event filters, registry autoruns, and standard binaries, and whether incident responders can quickly determine whether a change was authorized. This supports control assurance, audit evidence, and faster triage during suspected persistence activity.
Technical view
For Windows environments, validate correlation across unexpected modifications to WMI event filters, scheduled task triggers, and registry autorun keys, followed by execution of non-standard binaries by SYSTEM-level processes. Because no official ATT&CK detection text or relationships were supplied, implementation should be environment-specific: define what is expected, what is non-standard, and which SYSTEM-launched binaries are approved for each endpoint class.
Likely telemetry
- Windows registry modification events for autorun locations
- Scheduled task creation or trigger modification events
- WMI event filter modification telemetry
- Process creation events including parent process, user context, image path, command line, and integrity/account context
- Endpoint inventory or software allowlist data to distinguish standard from non-standard binaries
Detection direction
- Correlate persistence mechanism changes with later SYSTEM-level process execution rather than alerting only on isolated registry, WMI, or scheduled task events.
- Tune around known administrative software, endpoint management agents, installers, and approved maintenance activity to reduce false positives.
- Establish baselines for expected autorun keys, scheduled task triggers, WMI event filters, and SYSTEM-executed binaries by host role.
- Investigate binaries executing from unusual or user-writable paths when launched in SYSTEM context, if that detail is available in local telemetry.
- Validate collection gaps: missing command-line logging, weak registry auditing, or lack of WMI/scheduled task telemetry will materially reduce analytic value.
Mitigation priorities
- Harden and monitor administrative pathways that can modify WMI filters, scheduled tasks, and registry autorun locations.
- Limit privileges for users and services that can create or alter automatic execution mechanisms.
- Maintain approved baselines for Windows autorun mechanisms and SYSTEM-level binaries.
- Use change control to distinguish authorized software deployment from unexpected persistence-related modifications.
- Ensure incident response playbooks include rapid review of WMI persistence, scheduled task triggers, registry autoruns, and recent SYSTEM-level process execution.
Analyst notes and limits
This is a detection analytic object, not a technique object, and no tactics or relationship context were supplied. Treat it as guidance for validating correlation logic in Windows monitoring rather than as evidence of a specific actor, campaign, or active exploitation pattern.
The official detection field is not provided, and no related ATT&CK techniques, data sources, mitigations, or procedures were supplied. Local baselines, endpoint telemetry quality, and administrative change records are required to turn this into reliable detection coverage.
Analytic 0024
Correlates unexpected modifications to WMI event filters, scheduled task triggers, or registry autorun keys with subsequent execution of non-standard binaries by SYSTEM-level processes.
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 | 1.0 | Current bundle | 5659a4bbc184… |
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 AN0024Open 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.