D3FEND File Analysis (D3-FA) Implementation Guide

Most estates run several file scanners at once, at the mail gateway, the web proxy, the endpoint and the file server, yet few teams can say which kind of analysis each one performs or which files pass through none of them. MITRE D3FEND groups these controls under File Analysis (D3-FA), a technique in the Detect tactic that D3FEND defines as "an analytic process to determine a file's status. For example: virus, trojan, benign, malicious, trusted, unauthorized, sensitive, etc." This guide treats D3-FA as a programme: what each of its child techniques contributes, how to choose and layer them, where each one belongs in the file path, how to measure the whole and where the family as a whole fails. It does not repeat the individual technique cards, which are linked from the table below. It is written for detection engineers, endpoint and email security owners and security architects. For D3FEND itself see the MITRE D3FEND Guide; for the analyst's side of malware work see the Malware Analysis Guide for Defenders.

Key takeaways

File Analysis is a family of five techniques, not one control. D3FEND places File Hashing, File Content Analysis (with its child File Content Rules), Emulated File Analysis and Dynamic Analysis under D3-FA.
The techniques trade speed for depth. Hashing is near instant and exact, content rules are fast and tunable, emulation exposes packed code, and sandbox detonation is slow but sees behaviour. A sound design uses each where its cost fits.
Placement matters as much as technique. The same engine catches far more at the mail gateway and on file write than in a weekly scheduled scan.
D3FEND's ATT&CK links for D3-FA are inferred. They come from the shared File artefact and the site labels them "inferred, experimental", so use them to plan tests, not to claim coverage.
The family has shared blind spots. Fileless execution, living-off-the-land tools and encrypted archives sit outside what any file scanner inspects, so pair D3-FA with process and script analysis.

What D3FEND means by File Analysis

In the D3FEND ontology (knowledge graph 1.6.0, checked November 2026) D3-FA is a defensive technique that analyses the File artefact and enables the Detect tactic. Its knowledge base article describes four approaches: comparing file signatures or metadata against historical collections of malware, checking files against a source of ground truth such as cryptographic signatures, pattern matching on file contents or behaviour, and disassembling binary code to look for predictive behaviour such as API call signatures. It notes that analysis may happen in a protected environment such as a sandbox or on a live system.

The definition is wider than malware. "Trusted", "unauthorized" and "sensitive" are also statuses, so the same family covers deciding whether a binary is signed by an approved publisher and whether a document holds regulated data. In practice most deployments start with malware detection and extend to trust and sensitivity decisions later. D3FEND also lists D3-FA among the D3FEND techniques related to the ATT&CK mitigation M1021 Restrict Web-Based Content.

The child techniques at a glance

The table lists every child technique in the D3FEND ontology under D3-FA. Definitions are D3FEND's own; the "best at" column is NHI Mgmt Group's summary of the linked cards.

D3FEND technique	D3FEND definition	Best at	Main weakness
D3-FH File Hashing	Employing file hash comparisons to detect known malware	Exact, cheap matching of known files and estate-wide sweeps during an incident	Any change of one byte produces a new hash
D3-FCOA File Content Analysis	Employing a pattern matching algorithm to statically analyze the content of files	Catching recognisable files before they run: attachments, web shells, dropped DLLs, macros	Packing and encryption hide the content
D3-FCR File Content Rules (child of D3-FCOA)	Employing a pattern matching rule language to analyze the content of files	Fast, in-house detections written from intelligence, using YARA or ClamAV signatures	Rule quality: weak rules either miss variants or flood the SOC
D3-EFA Emulated File Analysis	Emulating instructions in a file looking for specific patterns	Exposing packed and self-decrypting code without running it on the host	Limited to what the emulator models; evasive code can detect it
D3-DA Dynamic Analysis	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	Behaviour that only appears at run time, including document exploits	Slow, costly and evaded by sandbox-aware or delayed payloads

D3FEND does not model a separate child for file reputation or allowlisting by publisher; those decisions fall under the parent's "ground truth such as cryptographic signatures" wording and are usually delivered by application control. See the Next-Generation Antivirus (NGAV) Guide for how commercial engines combine several of these techniques in one product.

How to choose and combine the techniques

Each child answers a different question about a file. Layer them so that cheap checks remove the bulk of traffic and expensive checks see only what is left.

Question about the file	Technique that answers it	Typical cost per file	Use it when
Have we seen exactly this file before?	D3-FH	Very low	Always, first; and for retro-hunts with new indicators
Does its content match a known family or pattern?	D3-FCOA, D3-FCR	Low	On every write, download and attachment
What does the code do once unpacked?	D3-EFA	Medium	Executables and scripts that static analysis cannot read
What does it do when opened or run?	D3-DA	High (seconds to minutes)	Unknown files from outside, at the mail and web edge, or on analyst request

A sequencing pattern

Hash first. Compute a SHA-256 hash at every inspection point and check it against known-bad and known-good lists. A known-good match can skip later stages; a known-bad match blocks.
Static content next. Run vendor signatures and your own D3-FCR rules on everything not already decided. This is where in-house YARA rules from incident intelligence earn their keep. See the YARA Rules Guide.
Emulate what static analysis cannot read. Packed executables and obfuscated scripts go to the emulator built into most endpoint and gateway engines.
Detonate the unknown remainder. Send unknown executables, macro documents, archives and installers from external sources to a sandbox, ideally before delivery. Accept that this adds delay at the mail gateway and decide in advance whether to hold or release on timeout.
Feed results back. Every malicious verdict from D3-DA or D3-EFA should produce a hash and, where possible, a content rule, so the next copy is caught at stage one or two.

Small and large organisations

Small organisations: rely on the combined engine in a managed endpoint product and the sandbox included with a cloud email service. The decisions that remain are coverage (are all endpoints and file stores in scope) and response (who acts on a verdict).
Large or targeted organisations: add an in-house D3-FCR rule lifecycle, a sandbox you control for analyst submissions, and scheduled hash and rule sweeps across servers, file shares and cloud storage after each significant incident.

Where each technique belongs in the file path

Files enter and move through an estate along a few routes. Map each route to the techniques applied there and look for routes with none.

Inspection point	Techniques usually present	Gap to check
Email gateway	D3-FH, D3-FCOA, D3-DA	Password-protected archives and links to files hosted elsewhere
Web proxy or secure web gateway	D3-FH, D3-FCOA, sometimes D3-DA	TLS traffic not decrypted, so files are never seen
Endpoint, on access and on execution	D3-FH, D3-FCOA, D3-EFA	Exclusions that remove whole folders or file types from scanning
File servers and cloud storage	D3-FH, D3-FCOA, often scheduled only	Files written by sync clients and service accounts that are never rescanned
Build and software supply chain	D3-FH against expected digests, signature checks	Artefacts pulled from public registries without verification
Analyst submission	D3-DA, D3-EFA, D3-FCR	No agreed route, so analysts upload samples to public services

The endpoint exclusion list is the most common silent gap. See the EDR Tuning and Exclusions Management Guide.

ATT&CK techniques D3FEND relates to File Analysis

D3-FA analyses File, so D3FEND relates it to every ATT&CK technique that creates, modifies or uses a file. The D3FEND site labels all of these relations "inferred, experimental" (checked November 2026). The table groups a selection by ATT&CK v20 tactic; the child cards carry the full list. Every ID was checked against ATT&CK v20.

ATT&CK tactic (v20)	Examples D3FEND relates through the File artefact	Practical reading
Initial Access	T1566.001 Spearphishing Attachment	Strong: the attachment is a file every child technique can inspect
Execution	T1204.002 Malicious File	Strong if analysis happens before the user opens the file
Persistence	T1505.003 Web Shell, T1547.001 Registry Run Keys / Startup Folder	Good for dropped files; the registry change itself needs other telemetry
Stealth	T1027.002 Software Packing, T1036.005 Match Legitimate Resource Name or Location, T1055.001 Dynamic-link Library Injection	Packing is where D3-EFA and D3-DA add most over static rules
Credential Access	T1552.001 Credentials In Files	Here the file is the victim's own; content analysis finds the exposed secret, not malware
Command and Control	T1071.001 Web Protocols	Weak: only the file carried over the channel can be analysed
Impact	T1486 Data Encrypted for Impact	Catches the ransomware binary if it lands as a file; the encryption itself needs behaviour detection

D3FEND still lists some IDs that ATT&CK v20 has revoked. Their successors are: T1647 Plist File Modification for Plist Modification, T1574.001 DLL for DLL Side-Loading, T1685.006 Clear Linux or Mac System Logs for the older log clearing ID, and T1690 Prevent Command History Logging for Impair Command History Logging. D3FEND also lists Launchd, which ATT&CK v20 marks deprecated. See the MITRE ATT&CK T1566 Phishing and T1027 Obfuscated Files or Information Defensive Guide pages for the defensive context.

Where identity fits

Credentials In Files (T1552.001) is the row where File Analysis helps identity teams directly. Content rules that match API key, token and private key formats, run across file shares, repositories and build outputs, find non-human identity secrets before an attacker does. Treat a match as a credential exposure: rotate the secret, then remove the file. Service accounts that write files to shared storage are also an inspection path: a compromised workload can plant files that no user ever downloads, so make sure files written by service identities are scanned on write. See the Secrets Rotation Runbook Template.

Detection and measurement

File Analysis produces verdicts. Send every verdict, with file hash, inspection point, technique and action taken, to the SIEM so that one malicious file seen at the gateway can be hunted on endpoints. Useful detections include a file blocked at one point but allowed at another, a sandbox verdict arriving after delivery (which should trigger retraction), and a known-bad hash appearing on a server.

Metrics we suggest at NHI Mgmt Group (example measures, not standards):

Route coverage: percentage of file entry routes with at least hash and content analysis.
Exclusion debt: number of endpoint scan exclusions without an owner and review date.
Detonation share: percentage of unknown external executables and macro documents sent to D3-DA before delivery.
Verdict to protection time: time from a malicious sandbox verdict to the hash or rule being active at every inspection point.
Test pass rate: percentage of benign test files (such as the EICAR test file) and safe emulation samples detected at each point.
Late verdicts: files delivered before a malicious verdict, and time to retract them.

Framework mapping

Framework	Reference	Link to D3-FA
NIST SP 800-53 Rev. 5	SI-3 Malicious Code Protection, SC-44 Detonation Chambers	Signature and behaviour scanning; sandbox detonation (D3-DA)
NIST SP 800-53 Rev. 5	SI-4 System Monitoring, SI-7 Software, Firmware, and Information Integrity	Verdicts as monitoring input; hash and signature integrity checks
NIST CSF 2.0	DE.CM-09, DE.AE-02	Software and data monitored; adverse events analysed
CIS Controls v8.1	Control 10 Malware Defenses	Anti-malware deployment, updates, removable media scanning, behaviour-based detection
ISO/IEC 27001:2022	Annex A 8.7 Protection against malware	Organisational control that D3-FA delivers technically

See the CIS Control 10 Malware Defenses Guide.

Common failure patterns

One engine counted several times. The gateway, proxy and endpoint run the same vendor engine with the same signatures, so layering adds coverage of routes but not of techniques.
Scheduled scans only on file stores. Files written between scans by sync clients and service accounts sit unanalysed for days.
Sandbox fail-open by default. On timeout the gateway releases the file, and nobody reviews late malicious verdicts.
No feedback loop. Sandbox and analyst verdicts never become hashes or rules, so the same campaign is analysed again from scratch.
Treating File Analysis as complete malware defence. Fileless techniques and scripts run in memory never present a file; see the D3-SEA Script Execution Analysis card for a complementary technique.

Practitioner checklist

List every file entry route and record which D3-FA child techniques run at each.
Hash every file at inspection and log the hash with the verdict.
Run an in-house D3-FCR rule lifecycle fed by incident and threat intelligence.
Send unknown external executables and macro documents to D3-DA before delivery, with a defined timeout policy.
Review endpoint scan exclusions quarterly, each with an owner and expiry.
Scan files written by service accounts and sync clients on write, not only on schedule.
Turn every malicious verdict into a hash and, where possible, a rule at every inspection point.
Test each inspection point with benign test files and track the pass rate.

MITRE D3FEND File Analysis Implementation Guide: Choosing, Combining and Measuring File Analysis Techniques