Most malicious code still arrives as a file, and the cheapest point to catch it is before it runs, by reading what is inside it. MITRE D3FEND names this countermeasure File Content Analysis (D3-FCOA) and defines it as "Employing a pattern matching algorithm to statically analyze the content of files." It sits under the Detect tactic as a child of File Analysis (D3-FA), alongside Dynamic Analysis, Emulated File Analysis and File Hashing, and it has one child of its own, File Content Rules (D3-FCR). This card explains what static content analysis covers, which ATT&CK techniques D3FEND relates to it, where it runs in a real estate, how to prove it works and where it stops working. It is written for detection engineers and endpoint security teams; the general background on malware detection is in the Malware Analysis Guide for Defenders.
Key takeaways
- Static means no execution. D3FEND describes the technique as analysing code without running it in a sandbox, virtual machine or simulator; patterns in the file indicate what kind of software it is, including whether it is malware.
- It is the umbrella for signatures. Rule languages such as YARA and ClamAV signatures are the child technique D3-FCR; D3-FCOA also covers parsers, heuristics and machine learning classifiers that read file bytes and structure.
- The ATT&CK mapping is broad and inferred. D3FEND relates D3-FCOA to roughly 80 ATT&CK techniques only because they all touch a File; read the list as "where a file exists to inspect", not as proof of coverage.
- Obfuscation is the main bypass. Packing, encryption and encoding hide content from static inspection, which is why D3-FCOA is paired with unpacking, script-content interfaces such as AMSI, and dynamic analysis.
- Verification is a scheduled test. Safe test files such as the EICAR string, placed in nested archives and on every scan path, show whether each inspection point is actually reading content.
D3-FCOA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FCOA (d3f:FileContentAnalysis) |
| Tactic | Detect (inherited from File Analysis) |
| Parent technique | File Analysis (D3-FA) |
| Sibling techniques | Dynamic Analysis (D3-DA), Emulated File Analysis (D3-EFA), File Hashing (D3-FH) |
| Child technique | File Content Rules (D3-FCR) |
| Digital artefact | File (D3FEND relation: analyzes File, inherited from the parent) |
| D3FEND reference | Patent "Cyber vaccine and predictive-malware-defense methods and systems", which trains machine learning models on features extracted from malware |
| Typical inputs | Executables, libraries, scripts, Office and PDF documents, archives and disk images |
| Main limitation | Cannot read content that is packed, encrypted or only assembled at run time |
How it works
D3FEND's parent definition sets the goal: File Analysis is an analytic process to determine a file's status, such as virus, trojan, benign, malicious, trusted, unauthorised or sensitive. D3-FCOA is the static branch of that process. A scanner opens the file, identifies its real type from its structure rather than its extension, and applies one or more of the following.
- Byte and string patterns: fixed byte sequences, strings and regular expressions known to occur in a malware family or tool. When these are written in a rule language, the work is D3-FCR. See D3-FCR File Content Rules.
- Structural parsing: reading the PE, ELF or Mach-O headers, section table, import table, resources and certificates; or the macro streams in an Office file and the objects in a PDF. Anomalies such as a section with high entropy, an import table with only loader functions, or an Authenticode signature that does not validate are content findings.
- Container unpacking: opening ZIP, ISO, OneNote and similar containers and analysing each member, because delivery often nests the payload. The ISO and Container File Malware Delivery Guide covers why this matters.
- Statistical and learned models: classifiers trained on extracted features, which is the approach D3FEND's cited reference describes. These score files without a specific signature, so they catch new variants but need their own false positive management.
Two siblings answer different questions. D3-FH File Hashing asks whether this exact file is already known; D3-FCOA asks whether its content looks like something known or suspicious, so it survives the one-byte changes that defeat hash matching. D3-DA Dynamic Analysis and D3-EFA Emulated File Analysis execute or emulate the file to see behaviour, which static analysis cannot.
ATT&CK techniques D3FEND relates to D3-FCOA
Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-FCOA. Every row below is inferred because the ATT&CK technique creates, modifies or uses a File and D3-FCOA analyses File. D3FEND labels these relations "inferred, experimental" (D3FEND knowledge graph 1.6.0, checked November 2026). The list is grouped by tactic and each ID was checked against ATT&CK v20.
| ATT&CK tactic (v20) | Techniques D3FEND relates through the File artefact |
|---|---|
| Initial Access | T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1566.003 Spearphishing via Service |
| Execution | T1204.002 Malicious File, T1059 Command and Scripting Interpreter, T1072 Software Deployment Tools, T1127.001 MSBuild |
| Persistence and Privilege Escalation | T1037.001 to T1037.004 logon and RC scripts and Login Hook; T1546.002, .004, .005, .006, .008, .009, .010, .013, .014, .015 event triggered execution (Screensaver, Unix Shell Configuration Modification, Trap, LC_LOAD_DYLIB Addition, Accessibility Features, AppCert DLLs, AppInit DLLs, PowerShell Profile, Emond, COM Hijacking); T1547.001, .006, .007, .008, .009 autostart (Registry Run Keys / Startup Folder, Kernel Modules and Extensions, Re-opened Applications, LSASS Driver, Shortcut Modification); T1543.001, .002, .004 (Launch Agent, Systemd Service, Launch Daemon); T1137.001 Office Template Macros, T1137.003 Outlook Forms; T1505.003 Web Shell; T1548.002 Bypass User Account Control, T1548.003 Sudo and Sudo Caching; T1647 Plist File Modification |
| Stealth | T1055.001, .002, .003, .009, .014 process injection variants; T1218.005 Mshta, T1218.011 Rundll32; T1574.001 DLL, T1574.004 Dylib Hijacking, T1574.006 Dynamic Linker Hijacking, T1574.007 to T1574.009 path interception, T1574.012 COR_PROFILER; T1014 Rootkit; T1036.001 Invalid Code Signature, T1036.003 Rename Legitimate Utilities, T1036.005 Match Legitimate Resource Name or Location, T1036.006 Space after Filename; T1027.001 Binary Padding, T1027.002 Software Packing, T1027.004 Compile After Delivery; T1564.002, .003, .006, .007 hide artefacts; T1220 XSL Script Processing; T1070.004 File Deletion; T1140 Deobfuscate/Decode Files or Information |
| Defense Impairment | T1556.002 Password Filter DLL, T1556.003 Pluggable Authentication Modules; T1685.006 Clear Linux or Mac System Logs; T1690 Prevent Command History Logging |
| Credential Access | T1555.003 Credentials from Web Browsers, T1003.007 Proc Filesystem, T1003.008 /etc/passwd and /etc/shadow, T1552.001 Credentials In Files, T1552.003 Shell History, T1187 Forced Authentication, T1649 Steal or Forge Authentication Certificates |
| Discovery | T1033 System Owner/User Discovery, T1083 File and Directory Discovery, T1018 Remote System Discovery, T1016 System Network Configuration Discovery |
| Collection | T1005 Data from Local System, T1119 Automated Collection, T1074.001 Local Data Staging, T1114.001 Local Email Collection, T1560.001 to T1560.003 Archive Collected Data |
| Lateral Movement | T1534 Internal Spearphishing, T1072 Software Deployment Tools |
| Command and Control, Exfiltration | T1071.001 Web Protocols, T1573.002 Asymmetric Cryptography, T1041 Exfiltration Over C2 Channel, T1048.002 Exfiltration Over Asymmetric Encrypted Non-C2 Protocol |
| Impact | T1486 Data Encrypted for Impact, T1565.001 Stored Data Manipulation, T1565.003 Runtime Data Manipulation |
D3FEND still lists four IDs that ATT&CK v20 has revoked; the table shows the successors: Plist Modification is now T1647 Plist File Modification, DLL Side-Loading is folded into T1574.001 DLL, Clear Linux or Mac System Logs is now T1685.006, and Impair Command History Logging is now T1690 Prevent Command History Logging. D3FEND also lists Launchd, which ATT&CK v20 marks deprecated with no successor, so it is left out.
In practice, static content analysis is strongest against the rows where the adversary writes a recognisable file: phishing attachments, web shells, malicious DLLs dropped for hijacking, Office template macros and persistence scripts. It adds little against discovery and collection techniques, where the files involved are the victim's own. The defensive context for the most relevant rows is in the MITRE ATT&CK T1566 Phishing, T1505 Server Software Component Defensive Guide and T1027 Obfuscated Files or Information Defensive Guide.
Where it is implemented
| Inspection point | What it reads | Strength | Watch for |
|---|---|---|---|
| Endpoint antimalware on access | Files as they are written, opened or executed | Sees the file on the host where it will run | Exclusions for paths, processes and extensions that remove whole directories from inspection |
| Script content interfaces | Script and macro content handed to the antimalware product at run time. On Windows, the Antimalware Scan Interface (AMSI) is integrated with PowerShell, Windows Script Host, JavaScript and VBScript, Office VBA macros and UAC elevation requests | Inspects content after the script engine receives it, including dynamic code evaluation | Script hosts that are not AMSI integrated; older engine versions |
| Email and web gateways | Attachments and downloads before delivery | Stops content before any host sees it | Password-protected archives and links to cloud storage that the gateway cannot open |
| Storage and repository scanning | File shares, object storage, artefact repositories, upload buckets | Finds dormant files and checks uploaded content | Scan schedules that lag behind writes; very large objects skipped |
| Network file extraction | Files carved from traffic (see D3-FC File Carving) | Covers hosts without an agent | Encrypted transport hides the file unless traffic is decrypted |
| Incident response sweeps | Disk images and live systems scanned with rule sets during an investigation | Applies new intelligence across the estate quickly | Scanner performance on production hosts; collection of results |
For the product categories that host this capability, see the Next-Generation Antivirus (NGAV) Guide and the EDR Guide. The open source engines named by D3FEND for the child technique, YARA and ClamAV, are covered in the D3-FCR card.
Implementation steps
- Map the file entry points. List where files enter and come to rest: email, browser downloads, removable media, file shares, collaboration platforms, CI artefact stores, web upload endpoints. Each needs at least one inspection point from the table above.
- Turn on content inspection depth. Confirm archive scanning, nested container depth, script and macro inspection and, on Windows, that the antimalware product is registered as the AMSI provider. Record the maximum file size each engine inspects, because larger files pass unread.
- Review exclusions before tuning. Export every path, extension and process exclusion. Remove any that cover user-writable locations such as Downloads, Temp or a whole profile directory. The EDR Tuning and Exclusions Management Guide gives a process.
- Pilot in detect mode. Where a product supports audit or report-only mode for a new content engine or rule set, run it on a pilot ring for two to four weeks, review detections and false positives, then move to block.
- Route results to the SOC. Detections need file path, hash, file type, rule or model name and the parent process or delivery channel, so analysts can decide between a single file and an outbreak.
- Roll back safely. When a content rule or model update causes false positives, restore the previous rule version or switch that engine to audit mode, release quarantined files by hash after review, and keep a record of the change for the next tuning cycle.
How to verify it works
- Standard test file: the EICAR anti-malware test file is a harmless 68-byte file that products detect as if it were malware. EICAR also publishes it inside a ZIP and inside a ZIP within a ZIP, which tests whether a scanner looks more than one level into archives.
- Every path, not one: deliver the test file by email, browser download, a file share write and an upload endpoint. A detection on one channel says nothing about the others.
- Script content: use the antimalware vendor's documented script test to confirm that script-time inspection, such as AMSI on Windows, is active.
- Telemetry check: confirm each detection reaches the SIEM with file hash, path and engine name, and that the alert opens a case.
- Emulation: include benign, authorised samples that mimic packed or container delivery in purple team exercises and record which inspection point caught them.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| File entry points with an active content inspection point | 100% of listed entry points | Gaps are where malicious files arrive unread |
| Monthly test file detections per channel | Every channel detects, including the nested archive | Proves inspection depth end to end |
| Exclusions covering user-writable paths | Zero | The most common silent bypass |
| Endpoints with current engine and content updates | Above 98% | Stale content misses new families |
| False positive rate per new rule or model update | Tracked per release | Shows whether pilots are catching problems before block mode |
Limits, bypasses and failure patterns
- Packed and encrypted payloads: D3FEND's child technique notes that simple signatures against raw content cannot match encoded, encrypted or sufficiently obfuscated content. Software packing (T1027.002), binary padding (T1027.001) and compile after delivery (T1027.004) all target this gap.
- Fileless and in-memory code: content that never lands as a file is out of scope for file analysis. The Fileless Malware Guide covers the memory and script-time controls that fill it.
- Containers the scanner cannot open: password-protected archives with the password in the email body, and disk images mounted by the user, deliver content past gateways that only see an opaque blob.
- Size and time limits: engines skip files above a configured size or stop after a timeout, and attackers pad files to exceed those limits.
- Broad exclusions: performance-driven exclusions for build directories, developer tools or backup paths leave exactly the locations attackers write to.
- Treating a model score as a verdict: learned classifiers produce probabilities. Without a review process for medium scores, teams either drown in alerts or set thresholds so high that new variants pass.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | The control that requires malicious code detection at entry and exit points and on hosts |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Routing file detections into monitoring and analysis |
| NIST CSF 2.0 | DE.CM-09, DE.AE-02 | Monitoring software and data for adverse events; analysing those events |
| CIS Controls v8.1 | Control 10 Malware Defenses | Anti-malware deployment, updates and scanning of removable media |
| MITRE ATT&CK mitigation | M1049 Antivirus/Antimalware | The closest ATT&CK mitigation (NHI Mgmt Group view); see M1049 Antivirus/Antimalware |
| MITRE D3FEND | D3-FA, D3-FCOA, D3-FCR | Parent, technique and child |
Related countermeasures
- File Content Rules (D3-FCR): the rule-language child of this technique. See D3-FCR File Content Rules.
- File Hashing (D3-FH) and File Hash Reputation Analysis (D3-FHRA): exact-match identification and reputation lookups. See D3-FH File Hashing and D3-FHRA File Hash Reputation Analysis.
- Byte Sequence Emulation (D3-BSE): a network-side sibling that analyses byte sequences to judge whether they are likely malicious shellcode. See D3-BSE Byte Sequence Emulation.
- Dynamic Analysis (D3-DA) and Emulated File Analysis (D3-EFA): the behavioural siblings that cover what static inspection cannot read.
Practitioner checklist
- List every file entry point and the inspection point that covers it.
- Confirm archive, nested container, macro and script inspection are enabled.
- Record the maximum inspected file size and timeout for each engine.
- Remove exclusions that cover user-writable paths.
- Pilot new engines and rule sets in audit mode before blocking.
- Send file hash, path, type and engine name with every detection.
- Test each channel monthly with the EICAR file, including the nested archive.
- Pair static inspection with script-time and dynamic analysis for obfuscated content.
Standards and references
- MITRE D3FEND: File Content Analysis (D3-FCOA)
- MITRE D3FEND: File Content Rules (D3-FCR)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-3 Malicious Code Protection)
- NIST: SP 800-83 Rev. 1 Guide to Malware Incident Prevention and Handling for Desktops and Laptops
- Microsoft Learn: Antimalware Scan Interface (AMSI)
- EICAR: Anti-Malware Test File
- ClamAV Documentation: Signatures
Related NHI Mgmt Group resources: Malware Analysis Guide for Defenders · YARA Rules Guide · Next-Generation Antivirus (NGAV) Guide · CIS Control 10 Malware Defenses Guide · MITRE D3FEND Guide