Static checks miss a file whose malicious behaviour only appears when it runs, and Dynamic Analysis closes that gap by opening the file somewhere it can do no harm and watching what it does. MITRE D3FEND names this countermeasure Dynamic Analysis (D3-DA) and defines it as "Executing or opening a file in a synthetic "sandbox" environment to determine if the file is a malicious program or if the file exploits another program such as a document reader." D3FEND lists the synonyms Malware Sandbox and Malware Detonation, places it under the Detect tactic as a child of File Analysis (D3-FA), and says it analyses Document File and Executable File artefacts. This card covers what D3-DA catches, which ATT&CK techniques D3FEND relates it to, where it is implemented, how to prove it works and how malware gets past it. It is for detection engineers, email and endpoint security owners and SOC leads; the general sandbox background is in the Malware Sandbox Guide.
Key takeaways
- Behaviour, not signatures. D3-DA observes what code does in a sandbox, virtual machine or simulator, which exposes behaviour without disassembling the sample.
- All ATT&CK links are inferred. D3FEND relates D3-DA to ATT&CK only through shared artefacts; eleven techniques act on Executable File itself, such as Software Packing (T1027.002) and Malicious File (T1204.002).
- Evasion is the main limit. D3FEND's own considerations warn that malware detects fake environments and debuggers and may only act on a date, a delay or a command, which ATT&CK tracks as Virtualization/Sandbox Evasion (T1497).
- Placement decides value. A sandbox only helps if files actually reach it: mail attachments, web downloads and files carved from network traffic are the common feeds.
- Verify with benign test files. Submit known harmless test samples on a schedule and confirm a verdict, a block and an alert arrive within the expected time.
D3-DA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DA (d3f:DynamicAnalysis) |
| Tactic | Detect |
| Parent technique | File Analysis (D3-FA) |
| Synonyms | Malware Sandbox, Malware Detonation |
| Digital artefacts | Document File, Executable File (D3FEND relation: analyzes) |
| Implementation named by D3FEND | Cuckoo Sandbox |
| D3FEND references | Palo Alto Networks patent US20150319136A1 (Malware analysis system); Sophos patent US20180032727A1 (application controller opening files in a virtual machine or quarantined environment based on reputation) |
| Sibling techniques under File Analysis | Emulated File Analysis (D3-EFA), File Content Analysis (D3-FCOA), File Hashing (D3-FH) and others |
| Main limitation | Samples that recognise the sandbox or wait out the analysis window |
How it works
D3FEND describes D3-DA as analysing the interaction of a piece of code with a system while the code runs in a controlled environment. A working deployment has four stages.
- Intake: a file arrives from a feed: an email gateway, a web proxy, an endpoint agent, a file carved from network traffic (see D3-FC File Carving) or an analyst upload. Most products pre-filter with cheaper checks such as hash reputation first, so only unknown files are detonated.
- Detonation: the file is opened or executed in a fresh, disposable guest. Documents are opened in the matching reader, so a document that exploits the reader is caught as well as a plain executable.
- Observation: the sandbox records process creation, API calls, file and registry changes, network connections and memory. The open source CAPE sandbox, derived from Cuckoo v1, documents API hooking, capture of files created, modified or deleted, PCAP capture, behavioural and network signatures, screenshots and full memory dumps.
- Verdict and action: the behaviour is scored, and the result drives an action: block or quarantine, an alert, or a new signature. The Palo Alto Networks patent D3FEND cites describes exactly this loop: a firewall sends an unknown sample to a virtual machine and a signature is generated automatically when it is judged malicious.
ATT&CK techniques D3FEND relates to D3-DA
Relationship type: inferred only. D3FEND labels these relations "inferred, experimental" (D3FEND knowledge graph 1.6.0, checked November 2026). They come from shared digital artefacts: D3-DA analyses Executable File and Document File, so ATT&CK techniques that create, modify or execute those artefacts, or one of their sub-artefacts, are related. Every ID below was checked against ATT&CK v20.
Same artefact: Executable File
| ATT&CK ID | Technique | D3FEND relation | What detonation can show |
|---|---|---|---|
| T1027.002 | Software Packing | obfuscates Executable File | Unpacking at run time and the real payload behaviour behind the packer |
| T1027.004 | Compile After Delivery | creates Executable File | A compiler invoked by the sample and the new binary it produces |
| T1036.003 | Rename Legitimate Utilities | may-create Executable File | A copied system utility under a new name being launched |
| T1140 | Deobfuscate/Decode Files or Information | may-add Executable File | Decoded executables written to disk during the run |
| T1204.002 | Malicious File | executes Executable File | The behaviour a user would trigger by opening the attachment or download |
| T1546.002 | Screensaver | creates Executable File | A screensaver binary dropped and registered for persistence |
| T1548.002 | Bypass User Account Control | executes Executable File | Elevated child processes started without a consent prompt |
| T1565.003 | Runtime Data Manipulation | may-modify Executable File | Changes to other executables during the run |
| T1574.007 | Path Interception by PATH Environment Variable | creates Executable File | A binary planted in a directory earlier in the PATH |
| T1574.008 | Path Interception by Search Order Hijacking | creates Executable File | A binary planted where the search order finds it first |
| T1574.009 | Path Interception by Unquoted Path | creates Executable File | A binary written to exploit an unquoted service or shortcut path |
Sub-artefacts (grouped)
| Sub-artefact | Related ATT&CK IDs (inferred) |
|---|---|
| Email, Email Attachment | T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1534 Internal Spearphishing, T1114.001 Local Email Collection |
| Office Application File, Microsoft HTML Application | T1137.003 Outlook Forms, T1564.007 VBA Stomping, T1218.005 Mshta |
| Executable Binary | T1027.001 Binary Padding, T1036.001 Invalid Code Signature, T1055.003 Thread Execution Hijacking, T1546.006 LC_LOAD_DYLIB Addition, T1546.008 Accessibility Features, T1546.015 Component Object Model Hijacking |
| Executable Script and init or startup scripts | T1059 Command and Scripting Interpreter, T1220 XSL Script Processing, T1016 System Network Configuration Discovery, T1137.001 Office Template Macros, T1505.003 Web Shell, T1546.005 Trap, T1546.013 PowerShell Profile, T1547.001 Registry Run Keys / Startup Folder, T1547.009 Shortcut Modification, T1037.001 to T1037.004 Boot or Logon Initialization Scripts |
D3FEND also lists Impair Command History Logging under an ID that ATT&CK v20 has revoked; its successor is T1690 Prevent Command History Logging. Treat the tables as a guide to what a sandbox report can surface, not as a coverage claim: a technique is only detected when the sample performs it inside the analysis window and the sandbox records it. Deeper defensive detail is in T1027 Obfuscated Files or Information Defensive Guide, T1204 User Execution and T1574 Hijack Execution Flow Defensive Guide.
Where it is implemented
Product and project names are examples of each class, listed alphabetically within a row, not recommendations.
| Implementation class | Typical feed | Example | Fits when |
|---|---|---|---|
| Email gateway or cloud mail detonation | Inbound attachments | Microsoft Defender for Office 365 Safe Attachments detonates attachments in a virtual environment; its unknown malware response options are Off, Monitor, Block and Dynamic Delivery | Attachments are your main malware entry point |
| Network or firewall sandbox | Files in web downloads and transfers | The firewall-to-VM model in the Palo Alto Networks patent D3FEND cites | You inspect web and file transfer traffic at the edge |
| Endpoint or EDR cloud detonation | Unknown files seen on hosts | EDR products that submit unknown files for cloud analysis | Files arrive by USB, chat or sync tools that bypass mail and proxy |
| Self-hosted malware sandbox | Analyst and SOAR submissions | CAPE (open source, derived from Cuckoo v1); the original Cuckoo repository was archived in April 2021 and its README calls Cuckoo 2.x unmaintained | A malware analysis team needs full control of guest images and data |
| Disposable desktop for manual checks | Single files an analyst opens | Windows Sandbox: hardware-isolated, discarded on close, available on Pro, Enterprise and Education editions | Quick manual triage, not automated verdicts |
Data handling matters: a commercial service sends samples to the vendor's analysis environment. Microsoft states that Safe Attachments scanning runs in the region where the organisation's Microsoft 365 data resides; check the equivalent statement for any service before you send documents that may contain personal or confidential data. Policy design for the related mitigation is in M1048 Application Isolation and Sandboxing; D3FEND's own comment on M1048 notes that "sandboxing" often describes a detection environment such as D3-DA, while many forms of isolation are static.
Implementation steps
- Map the file entry points. List how files reach users and servers: mail, web, collaboration tools, removable media, file transfer services, CI artefacts. Decide which feed each sandbox covers and record the gaps.
- Choose the action per feed. For mail, decide between holding messages until a verdict and delivering with placeholders. In Safe Attachments, Block quarantines detected messages and is the default in the Standard and Strict presets; Dynamic Delivery delivers the body at once with placeholders and works only for Exchange Online mailboxes.
- Build realistic guests. D3FEND advises that the simulated and real environments be as similar as possible. Match the OS build, office suite, reader versions, language, installed applications and a believable user profile. For a self-hosted CAPE deployment, its documentation recommends Windows 10 or Windows 11 23H2 guests on a Linux host.
- Isolate the analysis network. Decide what samples may reach. CAPE offers per-analysis routing such as drop (blocks non-CAPE traffic), inetsim (fake services) and internet (a dedicated "dirty line"); its documentation warns that internet routing lets every sample connect through the same uplink. Keep sandbox hosts off production networks and restrict host ports.
- Pilot in monitor mode. Run one feed in a non-blocking mode (Safe Attachments Monitor, for example) for two to four weeks, review verdicts, and measure added delivery delay. Microsoft states attachment scanning typically completes within 15 minutes.
- Enforce and integrate. Switch to blocking, send verdicts and reports to the SIEM, and feed new indicators to endpoint and network controls so one detonation protects every host.
- Plan rollback. Keep the previous policy exported. If delays or false positives hurt the business, revert the feed to monitor mode rather than off, so analysis and evidence continue.
How to verify it works
- Synthetic submissions: on a schedule, send benign test files (for example the EICAR anti-malware test file, and harmless documents your own team builds to perform an observable action such as launching a child process) through each feed. Confirm the verdict, the block or quarantine, and the SIEM alert.
- Feed health: track submissions per day per feed; a sudden drop to zero usually means a broken connector, not a quiet week.
- Coverage of encrypted files: test a password-protected archive. Safe Attachments, for example, has a separate setting, "Block messages containing encrypted attachments that could not be scanned", for files it cannot detonate.
- Emulation exercises: include sandbox-aware samples in authorised adversary emulation (see MITRE CALDERA Adversary Emulation Guide) and record whether the sandbox, the endpoint control or neither caught them.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Scheduled test files detected per feed | 100% | Proves the pipeline works end to end |
| Median time to verdict | Within the vendor's stated typical time | Delays push users to bypass controls |
| Share of unknown files detonated, by feed | Rising, with gaps documented | Shows which entry points are blind |
| Files that timed out or could not be analysed | Tracked and reviewed weekly | Encrypted and oversized files are an evasion path |
| Malware later found on endpoints that passed the sandbox | Each case reviewed | Measures evasion in your own estate |
Limits, bypasses and failure patterns
- Environment checks: D3FEND notes malware may spot a virtualisation vendor or a sped-up clock. ATT&CK tracks this as T1497 with sub-techniques T1497.001 System Checks, T1497.002 User Activity Based Checks and T1497.003 Time Based Checks. See MITRE ATT&CK T1497 Virtualization/Sandbox Evasion.
- Conditional triggers: behaviour that waits for a date, a long delay or a command from a server will not show in a short run. Pair detonation with endpoint behaviour monitoring, covered in M1040 Behavior Prevention on Endpoint.
- Files that never reach the sandbox: encrypted archives, files above a size limit, files in encrypted traffic that is not inspected, and files fetched after delivery through a link.
- Unrealistic guests: a guest without the right office suite or reader cannot detonate an exploit aimed at that reader, so the document looks clean.
- Network leaks from the lab: a self-hosted sandbox with open internet routing can let samples reach real infrastructure or alert the operator that analysis is happening.
- Verdicts nobody acts on: a monitor-mode policy that was never moved to blocking, or reports that never reach the SIEM, leaves detection without response.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-44 Detonation Chambers | The control for opening attachments and running suspicious applications in an isolated environment |
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection, SI-4 System Monitoring | Malware detection and the monitoring that consumes verdicts |
| NIST CSF 2.0 | DE.CM-09, DE.AE-02 | Monitoring software and runtime environments; analysing adverse events |
| MITRE ATT&CK mitigations | M1048 Application Isolation and Sandboxing, M1049 Antivirus/Antimalware | D3FEND relates M1048 to D3-DA; M1049 covers the signature layer before and after detonation |
| MITRE D3FEND | D3-FA, D3-DA | Parent and technique |
Related countermeasures
- Emulated File Analysis (D3-EFA): emulates instructions instead of running the full file. See D3-EFA Emulated File Analysis.
- File Hash Reputation Analysis (D3-FHRA): the cheap pre-filter that keeps known files out of the sandbox queue. See D3-FHRA File Hash Reputation Analysis.
- File Carving (D3-FC): extracts files from network traffic to feed detonation.
- Process Spawn Analysis (D3-PSA) and System Call Analysis (D3-SCA): the same behaviour signals watched on real endpoints. See D3-PSA Process Spawn Analysis. The parent File Analysis implementation guide covers the family as a whole.
Practitioner checklist
- List every file entry point and record which sandbox feed covers it.
- Build guests that match your real OS, office suite, readers and language.
- Isolate the analysis network and choose a routing mode per analysis deliberately.
- Pre-filter with hash reputation so the sandbox sees unknown files only.
- Decide how encrypted and oversized files are handled, and alert on them.
- Run in monitor mode first, measure delay, then enforce.
- Send verdicts to the SIEM and push new indicators to endpoint and network controls.
- Submit benign test files through every feed on a schedule and record the result.
- Review every case where malware passed the sandbox and adjust guests or feeds.
Standards and references
- MITRE D3FEND: Dynamic Analysis (D3-DA)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-44 Detonation Chambers)
- MITRE ATT&CK: T1497 Virtualization/Sandbox Evasion
- Microsoft Learn: Safe Attachments in Microsoft Defender for Office 365
- Microsoft Learn: Windows Sandbox overview
- CAPE Sandbox documentation: What is CAPE?
- CAPE Sandbox documentation: Per-analysis network routing
- Cuckoo Sandbox: GitHub repository
Related NHI Mgmt Group resources: Malware Sandbox Guide · Malware Analysis Guide for Defenders · Microsoft Defender for Office 365 Configuration Guide · MITRE D3FEND Guide