AN1213: Analytic 1213
Detects suspicious custom compression/encryption routines through anomalous script or binary execution that produces high-entropy files without standard archiving utilities. Correlates script execution, memory API usage (bitwise ops, CryptoAPI calls), and creation of archive-like files with uncommon headers.
Analyst context for executives and security teams
This analytic matters because custom compression or encryption can be used to stage data in a form that does not look like a normal ZIP, RAR, or other standard archive. For leaders, the practical question is whether Windows monitoring can distinguish normal business scripting and file creation from unusual execution that creates high-entropy, archive-like files with uncommon headers.
Executive priority
Prioritize this as a validation item for Windows endpoint visibility and incident readiness rather than as a standalone risk claim. It helps test whether the SOC can see suspicious preparation of files that may precede data movement, concealment, or other follow-on activity. The business decision value is in confirming telemetry coverage, tuning around legitimate encryption/compression workflows, and documenting evidence for audit or incident response that non-standard file preparation is monitored.
Technical view
On Windows, validate whether endpoint and script telemetry can correlate three behaviors described by the ATT&CK analytic: anomalous script or binary execution, memory/API indicators associated with bitwise operations or CryptoAPI usage, and creation of high-entropy archive-like files with uncommon headers when standard archiving utilities are not involved. Because no official detection logic, tactic, or relationships are supplied, teams should treat AN1213 as a detection design pattern and test it against local baselines for administrative scripts, developer tools, backup agents, encryption products, and line-of-business applications.
Likely telemetry
- Windows process execution telemetry for scripts and binaries
- Script execution logs where available
- File creation telemetry, including file path, extension, header or magic-byte observations where collected
- File entropy or content-characteristic metadata if available from endpoint, EDR, or file-scanning pipelines
- API or memory-behavior telemetry related to CryptoAPI calls or bitwise-heavy routines where available
Detection direction
- Confirm that Windows endpoint monitoring can connect process/script execution to subsequent creation of high-entropy files.
- Tune detections around the absence of standard archiving utilities, while recognizing that legitimate custom packers, encryption tools, developer workflows, backup software, and security tools may create similar signals.
- Prioritize correlation over single indicators: entropy alone or uncommon file headers alone are likely to create false positives.
- Validate whether the SOC actually receives API or memory-behavior signals; many environments collect process and file events but not detailed CryptoAPI or bitwise-operation evidence.
- Use local baselines to identify uncommon producers of archive-like files rather than assuming all uncommon headers are malicious.
Mitigation priorities
- Start with visibility: ensure Windows process, script, and file creation telemetry is collected and retained for investigation.
- Inventory legitimate compression, encryption, backup, and software packaging workflows so detections can be tuned without suppressing important anomalies.
- Apply least-privilege and script execution governance where appropriate to reduce unnecessary custom scripting paths that can produce opaque files.
- Ensure incident response playbooks include triage steps for high-entropy files, including identifying the producing process and whether standard archiving tools were involved.
- Use the analytic as compliance evidence only after confirming the telemetry and correlation logic operate in the local environment.
Analyst notes and limits
AN1213 is a MITRE detection analytic, not a technique description. The supplied object provides a clear behavioral concept for Windows but no official detection query, no tactic, and no relationship context. Its value is strongest as a coverage-validation and tuning prompt for managed detection, SOC engineering, and incident response readiness.
The supplied ATT&CK fields do not identify associated techniques, adversaries, campaigns, active exploitation, impacts, or non-Windows platforms. Detection feasibility depends heavily on local telemetry depth, especially whether file entropy, file headers, script execution, and API or memory-behavior data are available.
Analytic 1213
Detects suspicious custom compression/encryption routines through anomalous script or binary execution that produces high-entropy files without standard archiving utilities. Correlates script execution, memory API usage (bitwise ops, CryptoAPI calls), and creation of archive-like files with uncommon headers.
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 | 1fd91e47be48… |
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 AN1213Open 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.