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

AN0919: Analytic 0919

Identifies self-modifying executables that exhibit changes in binary hash, entropy, or memory sections during or between executions—often tied to dynamic unpacking or decryption behaviors.

EnterpriseAN0919AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Analytic AN0919 is about spotting Windows executables that change themselves across runtime or between runs, such as changes in file hash, entropy, or memory sections. For leaders, the value is not that every changing binary is malicious, but that this behavior can expose software that is unpacking, decrypting, or altering code in ways normal file-based allowlists and one-time malware scans may miss.

Executive priority

Prioritize this as a validation question for endpoint visibility and incident readiness: can the organization compare executable state over time and during execution, not just at download or install time? This matters for resilience because self-modifying behavior can undermine static hash-based controls, complicate forensic scoping, and create audit questions about how suspicious runtime behavior is monitored on Windows systems.

Technical view

For SOC and detection engineering teams, validate whether Windows endpoint telemetry can observe executable hash changes, entropy shifts, and memory-section changes during or between executions. Because the ATT&CK object provides no tactic, technique relationship, or official detection logic, this should be treated as a behavior-focused analytic requiring local baselining. Focus tuning on distinguishing expected self-updating, packed, protected, or dynamically generated software from unusual executables showing material binary or memory changes.

Likely telemetry

  • Windows endpoint process execution telemetry
  • File metadata and cryptographic hash observations over time
  • Executable write or modification events
  • Memory inspection or EDR telemetry describing loaded sections
  • Binary entropy or packed-file analysis outputs

Detection direction

  • Confirm whether telemetry captures both on-disk executable changes and runtime memory-section changes; many environments collect process starts but not enough binary or memory detail for this analytic.
  • Baseline known software that legitimately updates, unpacks, protects, or modifies executable content to reduce false positives.
  • Correlate hash or entropy changes with process execution timing, parent process, file path, signer status if locally available, and repeated execution behavior.
  • Avoid treating hash change alone as conclusive; use the analytic as a triage signal for suspicious self-modification rather than a standalone incident declaration.
  • Because no ATT&CK relationships or tactic mapping were supplied, map detections to local use cases and response playbooks based on observed context.

Mitigation priorities

  • Ensure endpoint security tooling on Windows can retain process, file, and executable metadata long enough for between-execution comparison.
  • Reduce reliance on static hashes alone; combine file reputation or allowlisting decisions with runtime behavior review where feasible.
  • Define investigation procedures for self-modifying executables, including collection of original and modified binaries, process lineage, and affected host context.
  • Maintain approved-software baselines so expected updaters, packers, or protected applications can be separated from anomalous activity.
  • Use findings to inform incident response readiness and audit evidence around endpoint monitoring depth, especially where static controls are known to be insufficient.
Analyst notes and limits

This Glexia take is based only on the supplied ATT&CK analytic description for AN0919. The object is Windows-specific and describes detection of self-modifying executables through hash, entropy, or memory-section changes. No tactic, technique relationship, adversary relationship, or official detection logic was provided, so the practical value is framed around telemetry validation, baselining, and triage design rather than a precise ATT&CK procedure.

ATT&CK supplied no official detection implementation, no relationship context, and no tactic mapping for this object. Local endpoint tooling, retention, memory visibility, software inventory, and baseline quality will determine whether this analytic is feasible and actionable. This summary does not claim active exploitation, attribution, impact, or guaranteed detection coverage.

Official MITRE ATT&CK definition

Analytic 0919

Identifies self-modifying executables that exhibit changes in binary hash, entropy, or memory sections during or between executions—often tied to dynamic unpacking or decryption behaviors.

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
3538547791c1fda2...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 3538547791c1…
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 AN0919
    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.