You detect double extension files by looking for filenames that disguise an executable as a document, such as a file ending in a trusted-looking extension followed by a hidden script or program extension. Review endpoint telemetry, email attachments, and downloads for unusual naming patterns, and ensure file extension display is not hidden from users.
What makes a double-extension phish look legitimate on Windows?
A double-extension lure works because Windows and common email clients can make a file look like a harmless document when the true executable extension is hidden or visually de-emphasised. The attacker relies on user trust in the visible suffix, such as invoice.pdf.exe, or on an environment where file extensions are not clearly shown.
That means detection starts with naming behaviour, not just payload analysis. Look for attachment and download filenames where the last visible extension is a document type but the full filename contains an executable, script, archive, or shortcut extension that changes how the file will run.
File naming alone is not enough, so the better test is whether the apparent document type matches the file’s actual type and behaviour. A file that claims to be a PDF, Word document, or image but is parsed as a program, script, or compressed container deserves closer inspection before any user opens it.
Where to find double-extension indicators in telemetry
Endpoint telemetry is often the most reliable place to confirm the trick, because it exposes the real on-disk filename and the process behaviour that follows. Watch for attachment writes, browser downloads, and email client saves where the filename, hash, file type, and launch chain do not align with the visible name.
Email security logs can also surface the lure before execution. Attachments with unusual compound names, especially when they are paired with spoofed brands, urgent payment themes, or archive wrappers, should be correlated with sender reputation, message header anomalies, and later endpoint execution.
Windows telemetry is especially useful when the visible name hides a secondary extension that users miss. If the file opens through a shell, script host, archive utility, or a renamed system binary rather than the document viewer a user would expect, that is a strong sign the filename was used to conceal execution intent.
For broader phishing context and lure patterns, Phishing Guide gives the surrounding techniques that often accompany malicious attachments and deceptive filenames.
When compound names are used to stage execution or persistence after the click, Persistence Techniques Guide helps you recognise what happens after the initial lure succeeds.
How to reduce user exposure and catch the pattern earlier
The simplest defensive control is to make the real extension visible and train users not to trust the displayed icon or leading part of the filename. If extensions are hidden, a lure can disguise executable content as a normal document with very little effort from the attacker.
Mail, web, and endpoint controls should inspect compound filenames before delivery and execution. That includes blocking executable forms in attachment paths, quarantining archives that contain disguised payloads, and comparing the claimed file type with the detected MIME type, magic bytes, and downstream process launch.
If you need a practitioner baseline for message-layer detection and bait recognition, Top 10 Phishing Techniques is the most natural companion because double-extension files are usually only one step in a larger phishing chain.
Windows hardening also matters when the lure is delivered as a file the user can save locally. Review default application associations, alerting around script and binary execution from user-writable locations, and download monitoring so that a disguised payload is not treated as routine user content.
Risk and Threat Considerations
Double-extension phishing is dangerous because it exploits a gap between what users think they received and what Windows will actually execute. The attacker does not need a novel exploit if the naming trick is enough to get a user to launch a script, binary, or shortcut masquerading as a document.
Failure mechanism: The defence fails when the visible extension is trusted more than the full filename, or when extensions are hidden, so a malicious file is opened as if it were a safe document and the payload runs under the user’s context.
Impact: The usual outcome is initial foothold, credential theft, or follow-on malware execution, and in some cases the file becomes the launch point for additional phishing, persistence, or lateral movement on the endpoint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | Double-extension lures are a phishing delivery technique. |
| Recommendation — Map suspicious compound filenames to phishing activity and correlate them with delivery telemetry. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and systems are monitored to detect potential cybersecurity events | File downloads and attachment launches need continuous monitoring for deceptive payloads. |
| Recommendation — Monitor attachment and download events for filename and execution mismatches. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Endpoint and email telemetry are needed to detect disguised files before execution. |
| Recommendation — Log and review file creation, download, and process-launch events for suspicious compound names. | ||
| OWASP ASVS | V13 — Configuration | Showing real file extensions is a configuration issue that affects user deception risk. |
| Recommendation — Enable visible extensions and safe file-handling defaults on user-facing systems. | ||
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | Email and browser controls are where double-extension lures commonly enter the environment. |
| Recommendation — Block or quarantine deceptive attachments and downloads at the email and web edge. | ||
Practitioner Guidance
What to verify: Confirm whether the file’s full name, detected type, and execution behaviour agree. If the visible suffix says “document” but the system sees an executable or script container, treat it as malicious until proven otherwise.
Decision rule: If the file arrived through email, browser download, or chat and the filename contains a second hidden extension, prioritise quarantine and user notification over manual trust review. If the file also launched a child process, escalate to endpoint triage immediately.
What practitioners underestimate: Users often notice the icon and the first extension, not the true terminal extension. That makes extension visibility settings, attachment inspection, and download telemetry more valuable than simple filename allowlists.
Practitioner takeaway: Detection is strongest when you combine filename inspection with file-type validation and execution telemetry, because the phishing trick is not the name alone, it is the mismatch between the name and the payload.
Related resources from NHI Mgmt Group
- How do you detect attackers searching for credentials in files and the registry on Windows?
- How do you detect Rclone being used for data exfiltration on Windows?
- Why do secrets stay dangerous even when they are no longer actively used?
- How should security teams detect malicious Windows shortcut files when email filtering and signature-based scanning are already in place?