Packed and self-decrypting malware hides its real code from signature scanners until it runs, and emulation lets a scanner run that code in software, one instruction at a time, without ever executing it on the host. MITRE D3FEND names this countermeasure Emulated File Analysis (D3-EFA) and defines it in one line: "Emulating instructions in a file looking for specific patterns." It sits under the Detect tactic as a child of File Analysis (D3-FA) and, like its sibling Dynamic Analysis, analyses Document File and Executable File artefacts. D3FEND's entry is thin: a definition and one academic reference, with no how-it-works text or considerations. This card fills in what that reference and product documentation show about where emulation runs, what it catches, how to check it and where it falls short. It is for detection engineers and endpoint and network security owners.
Key takeaways
- Emulation is not a sandbox. An emulator models a CPU and, in richer engines, an operating system API layer in software; a sandbox (D3-DA) runs the file on a real or virtual system. Emulation is faster and safer, but models fewer behaviours.
- Its strength is unpacking. Microsoft describes the Defender Antivirus emulation engine as dynamically unpacking malware and scanning both behaviour during emulation and memory at the end, which defeats packers and exposes polymorphic code.
- Inferred ATT&CK links only. D3FEND relates D3-EFA to ATT&CK through its artefacts; the eleven techniques that act on Executable File itself include Software Packing (T1027.002) and Deobfuscate/Decode Files or Information (T1140).
- Thresholds are the weak point. Emulators stop after a set number of instructions or on an unsupported instruction or API, so long loops and unmodelled calls let code escape analysis.
- You mostly verify it indirectly. Emulation is usually a built-in engine stage, so verification means confirming the engine is on, current and producing detections on test content.
D3-EFA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-EFA (d3f:EmulatedFileAnalysis) |
| Tactic | Detect |
| Parent technique | File Analysis (D3-FA) |
| Digital artefacts | Document File, Executable File (D3FEND relation: analyzes) |
| D3FEND reference | Polychronakis, Anagnostakis and Markatos, "Network-level polymorphic shellcode detection using emulation", Journal of Computer Virology, 2007 |
| Closest siblings | Dynamic Analysis (D3-DA) under File Analysis; Byte Sequence Emulation (D3-BSE) under Network Traffic Analysis |
| Typical home | Antimalware scan engines, network intrusion detection, analyst emulation frameworks |
| Main limitation | Only what the emulator models is observed; unsupported instructions, APIs and long loops end analysis |
How it works
Emulation runs a file's instructions inside a software model of the processor, memory and, in richer engines, the operating system. Nothing executes on the real host, so the scanner can watch code decode itself and then match patterns against the decoded result.
- Instruction-level emulation: the D3FEND reference describes a network intrusion detection approach that treats each client request as possible machine code. A 32-bit x86 emulator starts an execution chain at every byte offset of a buffer of up to 64 KB, and flags the stream when a chain runs a get-program-counter instruction, reads back the saved instruction pointer and then performs repeated reads from the buffer itself (the paper used a threshold of 19 distinct payload reads). That pattern is the signature of a self-decrypting decoder rather than of any one payload.
- Engine-level emulation in antimalware: Microsoft lists an "Emulation engine" among Defender Antivirus client-side technologies and pairs it with a cloud "Detonation-based ML engine" that detonates files in a sandbox. The emulator handles the fast local case; the sandbox handles what needs a full run.
- Analyst emulation frameworks: Speakeasy, an open source Windows malware emulation framework published under the MIT licence, describes itself as executing binaries, drivers and shellcode "in a modeled Windows runtime instead of a full VM", emulating APIs, processes and threads, file system, registry and network activity, and producing a JSON report.
The paper's distinction between the two network-side techniques is useful: D3FEND files its reference under Byte Sequence Emulation, which applies the same idea to bytes in network traffic, while D3-EFA applies it to files. See D3-BSE Byte Sequence Emulation.
Emulation compared with sandbox detonation
| Aspect | Emulated File Analysis (D3-EFA) | Dynamic Analysis (D3-DA) |
|---|---|---|
| What runs the code | A software model of CPU, memory and selected APIs | A real or virtual operating system |
| Speed and placement | Fast enough for on-access scanning and inline network inspection | Minutes per file; usually asynchronous or held for a verdict |
| Risk to host | Code never runs natively | Contained by the guest and the analysis network |
| Behaviour visibility | Decoding, unpacking, modelled API calls, memory at end of run | Full process, file, registry and network behaviour |
| Typical evasion | Unsupported instructions or APIs, long loops, dependence on real process state | Environment and timing checks, conditional triggers |
| Who operates it | Built into scan engines; frameworks for analysts | Mail, network and EDR services; self-hosted sandboxes |
Most mature stacks use both: emulation to unpack quickly and decide most files locally, detonation for the residue. The sandbox side is covered in D3-DA Dynamic Analysis.
ATT&CK techniques D3FEND relates to D3-EFA
Relationship type: inferred only. D3FEND labels every listed relation "inferred and experimental" (knowledge graph 1.6.0, checked November 2026). Because D3-EFA and D3-DA analyse the same two artefacts, D3FEND lists the same related techniques for both. These eleven act directly on Executable File; each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation | Where emulation helps |
|---|---|---|---|
| T1027.002 | Software Packing | obfuscates Executable File | Emulating the unpacking stub exposes the packed payload for scanning |
| T1140 | Deobfuscate/Decode Files or Information | may-add Executable File | Decoder loops run in the emulator and the decoded output is matched |
| T1027.004 | Compile After Delivery | creates Executable File | Limited: compilation happens on the host, so the compiled output must be scanned when written |
| T1036.003 | Rename Legitimate Utilities | may-create Executable File | Limited: a renamed signed utility emulates as benign |
| T1204.002 | Malicious File | executes Executable File | On-access emulation can stop the file before a user's double-click runs it |
| T1546.002 | Screensaver | creates Executable File | Scanning the dropped screensaver binary |
| T1548.002 | Bypass User Account Control | executes Executable File | Emulated API calls can reveal known bypass patterns, within what the engine models |
| T1565.003 | Runtime Data Manipulation | may-modify Executable File | Limited to code paths reachable in emulation |
| T1574.007, T1574.008, T1574.009 | Path Interception by PATH Environment Variable, by Search Order Hijacking, by Unquoted Path | creates Executable File | Scanning the planted binary when it is written |
D3FEND's list also includes sub-artefact relations for email, Office files, HTML applications and scripts, for example T1566.001 Spearphishing Attachment, T1564.007 VBA Stomping and T1218.005 Mshta, plus Impair Command History Logging under an ID ATT&CK v20 has revoked (successor T1690 Prevent Command History Logging). The "Where emulation helps" column is NHI Mgmt Group's assessment, not D3FEND data. Defensive detail for the strongest fits is in the T1027 Obfuscated Files or Information Defensive Guide and MITRE ATT&CK T1140 Deobfuscate/Decode Files or Information.
Where it is implemented and how to deploy it
- Confirm the engine is in your antimalware stack. Emulation is normally an internal stage of the scan engine, not a separate product. Check vendor documentation for an emulation or unpacking engine and whether it runs on access, on demand or both. For Microsoft Defender Antivirus, the emulation engine is documented as a client-side technology.
- Keep the engine and platform current. Emulator coverage of instructions and APIs improves with engine updates, so track engine and platform versions, not only signature freshness, in your endpoint compliance reporting.
- Keep the cloud and detonation tiers connected. Local emulation is designed to hand off what it cannot decide. Where your product pairs emulation with cloud analysis, as Microsoft's pairs it with detonation-based ML, confirm the cloud connection is allowed through proxies and not disabled by policy.
- Use network emulation where the IDS supports it. Shellcode detection by emulation in network sensors is the D3-BSE pattern; enable it where the sensor offers it and decide which ports to inspect, since the reference paper found long execution chains concentrated on ports 139 and 445.
- Give analysts an emulation framework. For triage of shellcode and Windows binaries, a framework such as Speakeasy produces a structured report of API calls without a full virtual machine. Run it on an isolated analysis host, never on a production workstation.
- Roll back safely. If an engine update causes false positives, use the vendor's supported platform or engine rollback and submit the file for reanalysis rather than excluding the path, which removes all scanning for that location.
How to verify it works
- Engine status: report engine and platform versions per endpoint and alert on devices more than one release behind.
- Test content: scan the EICAR anti-malware test file on demand and on access, and confirm the detection reaches the console and the SIEM. Pair it with an internally built test sample wrapped in a common packer to confirm the engine opens packed files rather than skipping them, where the product logs that.
- Exclusion review: list scan exclusions by path, process and extension each quarter, since an exclusion turns emulation off for exactly the places attackers prefer.
- Escalation check: confirm that files the local engine cannot decide reach cloud analysis, using the product's own reporting of cloud lookups or submissions.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Endpoints on the current engine and platform version | Above 95% within the vendor's release cycle | Old engines model fewer instructions and APIs |
| Scan exclusions with an owner and expiry date | 100% | Unowned exclusions disable emulation silently |
| Detections attributed to unpacking or emulation, per month | Tracked as a trend where the product reports it | Shows the stage is producing value |
| Packed files that later detonate as malicious after a clean local verdict | Each case reviewed | Measures the emulator's escape rate |
Limits, bypasses and failure patterns
- Execution thresholds: the reference paper stops chains at an execution threshold and notes that endless loops placed before a decoder can exhaust it. Engines face the same trade between depth and speed.
- Unmodelled environment: the paper notes that shellcode depending on fixed addresses in the target process can evade emulation, and every emulator ends on instructions or APIs it does not model.
- Encoding layers: the paper's approach does not handle compressed HTTP, Unicode or SSL unless the traffic is decoded first, so network-side emulation depends on decoding and TLS visibility (see M1020 SSL/TLS Inspection).
- Code without a decoder: plain or purely metamorphic code that never decodes itself gives emulation nothing to unpack; behaviour monitoring and detonation must cover it.
- Exclusions and disabled cloud tiers: broad path exclusions for performance, and blocked cloud connectivity, are the common operational failures.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | The control that scan engine emulation implements |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Network sensors applying emulation to traffic |
| NIST CSF 2.0 | DE.CM-09 | Monitoring software and runtime environments for adverse events |
| MITRE ATT&CK mitigation | M1049 Antivirus/Antimalware | The mitigation category where emulation engines sit; see M1049 Antivirus/Antimalware |
| MITRE D3FEND | D3-FA, D3-EFA | Parent and technique |
Practitioner checklist
- Confirm from vendor documentation that your scan engine includes emulation or unpacking.
- Track engine and platform versions, not only signature updates.
- Keep cloud analysis and detonation tiers reachable from every endpoint.
- Review scan exclusions quarterly and give each an owner and expiry.
- Enable shellcode emulation on network sensors where offered, with TLS and decoding in place.
- Provide analysts with an isolated emulation framework for shellcode and binary triage.
- Review every case where a file passed local scanning and was later found malicious.
Standards and references
- MITRE D3FEND: Emulated File Analysis (D3-EFA)
- Polychronakis, Anagnostakis and Markatos: Network-level polymorphic shellcode detection using emulation
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-3 Malicious Code Protection)
- Microsoft Learn: Advanced technologies at the core of Microsoft Defender Antivirus
- Speakeasy: Windows malware emulation framework (GitHub)
- MITRE ATT&CK: T1027.002 Software Packing
Related NHI Mgmt Group resources: Malware Analysis Guide for Defenders · D3-DA Dynamic Analysis · M1049 Antivirus/Antimalware · MITRE D3FEND Guide