Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN0973: Analytic 0973

Detects abuse of fileless storage mechanisms such as Registry keys, WMI classes, and Event Logs used to stage payloads, scripts, or encoded content outside traditional files.

EnterpriseAN0973AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

This analytic matters because it focuses on payloads or script content hidden in Windows storage locations that are not ordinary files, such as Registry keys, WMI classes, and Event Logs. For leaders, the practical issue is coverage confidence: file-focused controls and investigations may miss activity staged in these locations unless Windows telemetry and SOC procedures explicitly account for it.

Executive priority

Prioritize this as a validation item for Windows monitoring and incident response readiness, especially where business-critical systems depend on endpoint evidence for containment decisions, audit support, or recovery scoping. The key leadership question is whether the organization can prove it collects and reviews the Windows data sources needed to find suspicious use of Registry, WMI, and Event Log storage mechanisms, rather than relying only on file-based malware detection.

Technical view

AN0973 is a Windows detection analytic for abuse of fileless storage mechanisms, specifically Registry keys, WMI classes, and Event Logs used to stage payloads, scripts, or encoded content outside traditional files. MITRE does not provide detection logic for this analytic, and no tactic or relationship context was supplied, so SOC and detection teams should treat it as a coverage validation objective rather than a ready-to-run rule. Validate whether endpoint and Windows logging sources expose creation, modification, and unusual content patterns in these storage locations, then tune detections against known administrative and software-management behavior.

Likely telemetry

  • Windows Registry key and value creation or modification events
  • WMI repository, class, namespace, or persistence-related activity logs where available
  • Windows Event Log write, clear, or unusual content patterns relevant to staged data
  • Endpoint detection and response telemetry for process activity interacting with Registry, WMI, or Event Logs
  • PowerShell or script execution telemetry when scripts interact with these storage mechanisms

Detection direction

  • Confirm that Windows endpoints actually generate and retain telemetry for Registry, WMI, and Event Log activity; absence of these sources is the primary coverage gap implied by the analytic.
  • Build or review analytics that identify unusual storage of scripts, encoded content, or payload-like data in non-file locations, while avoiding assumptions that all Registry, WMI, or Event Log changes are malicious.
  • Tune for administrative baselines, software deployment tools, monitoring agents, and legitimate Windows management activity to reduce false positives.
  • Because no official detection logic is provided, require local testing and validation before using this analytic for alerting, compliance evidence, or incident response decisions.
  • Document which Windows asset classes are covered, retention periods, and whether responders can retrieve the underlying Registry, WMI, or Event Log evidence during an investigation.

Mitigation priorities

  • Start with telemetry assurance: ensure Windows logging and endpoint visibility cover Registry, WMI, and Event Log activity on systems where this risk is material.
  • Harden and monitor administrative access paths that can modify these storage mechanisms, using least privilege and change accountability where applicable.
  • Include fileless storage checks in incident response playbooks so investigations do not stop at file-system artifacts.
  • Use detection engineering reviews to compare file-centric malware controls against non-file Windows storage abuse scenarios.
  • Maintain evidence of monitoring scope, retention, and response procedures for audit and readiness discussions.
Analyst notes and limits

The supplied object is a detection analytic, not a technique description. Its value is in prompting coverage validation for Windows fileless storage locations. Since tactics, relationships, and detection logic are not supplied, recommendations should remain environment-specific and should be validated against local administrative behavior.

Official detection content is not provided, tactics are not specified, and no ATT&CK relationship context was supplied. This take cannot infer adversary usage, prevalence, impact, or guaranteed detectability. Local telemetry, baselines, and endpoint configuration determine practical coverage.

Official MITRE ATT&CK definition

Analytic 0973

Detects abuse of fileless storage mechanisms such as Registry keys, WMI classes, and Event Logs used to stage payloads, scripts, or encoded content outside traditional files.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
cc13febf88c3ceef...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle cc13febf88c3…
Raw source

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 references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN0973
    Open source URL
Source and licensing

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.