AN1033: Analytic 1033
Detects adversary behavior where a file with a benign-looking first extension (e.g., .txt, .jpg) ends with a dangerous second extension (e.g., .exe, .scr), and is subsequently executed. The behavior chain includes file creation with misleading naming and user or system-initiated process execution from the disguised file.
Analyst context for executives and security teams
This analytic matters because disguised filenames can turn a routine user action into execution of a dangerous file on Windows. For leaders, the decision value is whether the organization can see both parts of the behavior: creation of a file with a misleading double extension and later process execution from that file.
Executive priority
Prioritize this as a practical endpoint and SOC readiness question: are Windows logging, endpoint controls, and analyst workflows able to distinguish benign document-like filenames from executable content that is actually run? This supports incident triage, user-risk reduction, and audit evidence that endpoint execution monitoring is not limited to obvious executable names.
Technical view
Validate coverage for Windows events that show file creation where the filename has a benign-looking first extension such as .txt or .jpg followed by a dangerous executable extension such as .exe or .scr, then correlate that file to subsequent process execution. Because no official detection logic or ATT&CK relationships are supplied, teams should implement and tune locally against endpoint telemetry and known administrative or software-delivery patterns that may produce unusual filenames.
Likely telemetry
- Windows file creation events or endpoint file-write telemetry
- Process creation events including image path, command line, parent process, and user context
- Endpoint detection and response alerts or metadata showing file path and execution lineage
- File metadata such as full filename, extension sequence, directory, signer status, and hash where available
Detection direction
- Confirm that telemetry preserves the full filename, not only the final extension or normalized file type.
- Correlate misleading double-extension file creation with later execution from the same path or hash.
- Tune for false positives from legitimate installers, test files, or administrative packaging workflows that may use unusual filenames.
- Review blind spots where endpoint logging excludes user download folders, temporary directories, removable media paths, or short-lived files.
- Because ATT&CK provides no official detection implementation here, validate detection performance with local Windows endpoint data before treating it as production coverage.
Mitigation priorities
- Ensure Windows endpoints collect file creation and process execution telemetry needed for correlation.
- Use endpoint controls and policy to reduce execution from user-writable or high-risk locations where appropriate.
- Educate users and help desk staff that a document-looking name can still end in an executable extension.
- Include double-extension execution checks in incident response triage and endpoint hunting playbooks.
- Maintain evidence of telemetry coverage and alert review for compliance or control validation purposes.
Analyst notes and limits
This object is a detection analytic, AN1033, for Windows. The supplied ATT&CK content describes the behavior chain but does not provide tactics, relationships, or official detection logic, so the take focuses on validation direction rather than claiming specific coverage.
Assessment is limited to the supplied STIX fields and the MITRE external reference. No adversary attribution, active exploitation, related techniques, or guaranteed detection outcome is supported by the provided data.
Analytic 1033
Detects adversary behavior where a file with a benign-looking first extension (e.g., .txt, .jpg) ends with a dangerous second extension (e.g., .exe, .scr), and is subsequently executed. The behavior chain includes file creation with misleading naming and user or system-initiated process execution from the disguised file.
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 | 4fab8873aeae… |
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 AN1033Open 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.