DET0366: Detection Strategy for Double File Extension Masquerading
This detection strategy is intended to help identify double file extension masquerading, where a filename can look benign to a user while the true executab...
Analyst context for executives and security teams
This detection strategy is intended to help identify double file extension masquerading, where a filename can look benign to a user while the true executable or opening behavior is determined by a later extension. For leaders, the decision value is not the filename trick itself; it is whether the organization can see and investigate deceptive file naming before it contributes to user-driven execution, malware staging, or incident confusion.
Executive priority
Prioritize this as a practical control-validation item for Windows user endpoints and SOC readiness. Executives should ask whether file visibility, endpoint logging, alert triage, and user-facing controls can distinguish a harmless-looking document from a file whose actual extension indicates a different risk. This supports resilience, audit evidence, and incident response quality because misleading filenames can slow containment decisions and weaken user trust in visual inspection alone.
Technical view
The supplied ATT&CK object has no official description or detection logic, but it is related to ATT&CK technique T1036.007, Double File Extension, under stealth, with Windows listed for the related technique. SOC and detection teams should validate whether endpoint and file telemetry preserve full filenames, extensions, paths, and execution context rather than relying on how a file is rendered in a file browser. Detection engineering should focus on suspicious filename patterns with multiple extensions, especially where the final extension implies executable or script handling, and should correlate with file creation, download, email attachment, user execution, and process start evidence where available.
Likely telemetry
- Endpoint file creation and modification events including full filename and path
- Process execution telemetry including image name, command line, parent process, and user context
- Email or web download metadata where files enter the environment
- Endpoint protection or file reputation events that record original filename and extension
- File inventory or content inspection data that can compare displayed name, final extension, and file type
Detection direction
- Confirm that telemetry records the complete filename, not a truncated or user-interface-rendered view.
- Tune for filenames containing multiple extensions where the final extension changes handling risk, while accounting for legitimate business files that may contain versioning or compound names.
- Correlate double-extension observations with execution, user interaction, download source, or email attachment context to reduce false positives.
- Validate coverage specifically in Windows environments because the related ATT&CK technique lists Windows, while the detection strategy object itself does not specify platforms.
- Use this relationship to T1036.007 as context for stealth-oriented masquerading detections, not as evidence of a specific campaign or guaranteed detection outcome.
Mitigation priorities
- Ensure endpoint and SOC tooling retain and display full filenames and extensions during triage.
- Review user-facing operating system and file-browser settings that may hide known extensions, where administratively appropriate.
- Strengthen controls around files delivered by email, web download, and removable or shared locations before execution.
- Use application control, attachment handling, and endpoint protection policies to reduce execution risk from misleading file types where feasible.
- Document detection assumptions and test results as compliance and incident-readiness evidence rather than relying on filename appearance alone.
Analyst notes and limits
ATT&CK provides this as a detection strategy object, DET0366, for Double File Extension Masquerading, and the supplied relationship states that it detects T1036.007 Double File Extension. Because no official detection text is provided, this take frames validation priorities around the related technique description and common defensive evidence classes without asserting a specific analytic rule.
The detection strategy object has no official description, no official detection content, no tactics, and no platforms specified. Windows relevance comes from the related technique, not from the strategy object itself. Local logging, endpoint configuration, file handling policies, and business naming conventions are required to determine practical coverage and false-positive rates.
Detection Strategy for Double File Extension Masquerading
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1036.007 | Double File Extension Sub-technique | This object detects Double File Extension. |
All related ATT&CK context
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 | de15078caa5c… |
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 DET0366Open 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.