Definition
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.
How it works
Analyzing the interaction of a piece of code with a system while the code is being executed in a controlled environment such as a sandbox, virtual machine, or simulator. This exposes the natural behavior of the piece of code without requiring the code to be disassembled.
Considerations
- Malware often detects a fake environment, then changes its behavior accordingly. For example, it could detect that the system clock is being sped up in an effort to get it to execute commands that it would normally only execute at a later time, or that the hardware manufacturer of the machine is a virtualization provider.
- Malware can attempt to determine if it is being debugged, and change its behavior accordingly.
- For maximum fidelity, the simulated and real environments should be as similar as possible because the malware could perform differently in different environments.
- Sometimes the malware behavior is triggered only under certain conditions (on a specific system date, after a certain time, or after it is sent a specific command) and can't be detected through a short execution in a virtual environment.
Implementations
- Cuckoo Sandbox
Implementation perspective
Dynamic Analysis should be treated as a technical defensive capability rather than a product checkbox. In practice, teams should define the protected scope, the conditions under which the technique acts, and the observable evidence that demonstrates the intended behavior. For this technique, likely engineering context includes Document File, Executable File.
Use the technique to identify suspicious, unauthorized, or abnormal activity through observable evidence and repeatable analysis.
Questions to ask
- Which events, states, or artifacts must be observed for the analysis to work?
- What analytic logic, threshold, comparison, or signature turns observations into a finding?
- How are expected false positives, blind spots, and environmental variations documented?
- Who receives the result, and what action is expected when the technique produces a finding?
Evidence and validation
- Telemetry and data-source configuration records
- Analytic logic, thresholds, signatures, and version history
- Test cases demonstrating expected positive and negative results
- Alert, triage, escalation, and tuning records
Common failure patterns
- Required telemetry is missing, delayed, or transformed in a way that invalidates the analysis.
- The technique produces alerts without an accountable triage and response process.
- Detection coverage is claimed from product deployment without testing the relevant analytic behavior.
This implementation perspective is original Bare Metal Cyber educational content. It does not replace the official D3FEND definition or establish that a specific product implements the technique.
Technique hierarchy
Top-level family
Parent techniques
Direct child techniques
None listed at this level.
Artifacts and ontology entities
These relationships describe how D3FEND connects a defensive technique to artifacts or other ontology entities. They describe graph semantics, not a product certification.
Explicit technique relationships
Show inferred artifact relationship paths (2)
NIST SP 800-53 relationships
The relation label is preserved from the D3FEND ontology. It is not converted into a claim that the control automatically implements or validates this technique.
ATT&CK Enterprise mitigation relationships
These links come from the D3FEND ontology’s ATT&CK mitigation mapping. They help users navigate between the knowledge bases and do not guarantee mitigation effectiveness.
D3FEND note: "Sandboxing" is often used to describe a detection environment which includes some forms of analysis (see D3-DA.)" Many forms of isolation (e.g., quarantining) are more static in nature and simply limit software's access to system resources.
Offensive-technique relationships
These relationships are generated from D3FEND graph paths and are explicitly experimental. They should be treated as hypotheses for defensive analysis—not as proof that the technique prevents, detects, or removes an offensive behavior.
ATT&CK Enterprise (38)
ATT&CK for ICS (5)
Authoritative sources
- Open this technique on the official D3FEND website ↗
- Open the official ontology resources ↗
- Malware analysis system ↗Palo Alto Networks Inc · Huagang Xie; Xinran Wang; Jiangxia Liu · PatentReference
- Use of an application controller to monitor and control software file and application environments ↗Sophos Ltd · Andrew J. Thomas · PatentReference
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by The MITRE Corporation. MITRE D3FEND™ and the D3FEND logo are trademarks of The MITRE Corporation. MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Use of D3FEND source material is subject to the official Terms of Use.