Parsers trust that a file is what it claims to be, and attackers exploit that trust with files whose extension, header and content disagree or whose structure breaks the specification. MITRE D3FEND names the countermeasure File Format Verification (D3-FFV) and defines it as "Verifying that a file conforms to its expected format specifications". It sits under the Isolate tactic as a child of Content Validation (D3-CV), and it heads five narrower checks (four direct children, with magic bytes under metadata values): magic bytes, internal structure, metadata values, metadata consistency and decompression. This card explains how the five checks fit together, which ATT&CK techniques D3FEND relates to the family, where format verification runs, how to test it and where it stops. It is written for application security engineers and teams running mail, upload and file transfer gateways; the policy layer above it is covered in D3-CV Content Validation.
Key takeaways
- Format verification is a stack of checks. D3FEND splits it into four child checks plus D3-FMBV, which sits under D3-FMVV, running from a cheap magic byte test to full decoding; a real control chains several, cheapest first.
- Agreement is the core test. D3FEND's only reference, an OPSWAT patent, treats a file type as trustworthy when the header description, the leading bytes and the actual content are consistent with one another.
- The extension and Content-Type are claims, not evidence. OWASP's File Upload Cheat Sheet warns the Content-Type header "can be spoofed" and that a signature check "should not be used on its own".
- Conforming does not mean safe. A perfectly valid PDF or Office file can carry malicious content, so verification is followed by scanning, conversion or disarm.
- Verification failures are signals. The NCSC import pattern says verification errors should be raised as alerts for an operator, because they suggest a malfunctioning or compromised upstream component.
D3-FFV at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FFV (d3f:FileFormatVerification) |
| Tactic | Isolate |
| Parent technique | Content Validation (D3-CV), under Content Filtering (D3-CF) |
| Digital artefact | File Section, "one of the portions of a file in which the file is regarded as divided" (D3FEND relation: analyzes); children add File Content Block Data, File Metadata and File Magic Bytes |
| Children | D3-FISV, D3-FMVV (with its child D3-FMBV), D3-FMCV, D3-FCDC |
| D3FEND reference | OPSWAT, "File Security Using File Format Validation", US20200104494A1 (patent) |
| Main limitation | Detects malformed and mislabelled files, not malicious but well-formed ones |
How it works: the child checks
D3FEND does not publish a how-it-works article for D3-FFV itself; its children carry the detail. D3-FMBV is a child of D3-FMVV rather than of D3-FFV directly. Read them as stages of one pipeline.
| Child | D3FEND definition (abridged) | Catches | Cost |
|---|---|---|---|
| D3-FMBV File Magic Byte Verification | "Utilizing the magic number to verify the file" | An executable renamed to .pdf or .jpg | Very low |
| D3-FISV File Internal Structure Verification | Checking specific static values within a file against the values the format specification defines | Files with a valid header but broken required structures | Low to medium |
| D3-FMVV File Metadata Value Verification | Checking static values in the file against the specification (D3FEND currently gives it the same definition text as D3-FISV) | Metadata fields with values outside what the format allows | Low |
| D3-FMCV File Metadata Consistency Validation | Validating that declared lengths, pointers and checksums "accurately describe the file's content" | Length and offset fields that point outside the file, bad checksums | Medium |
| D3-FCDC File Content Decompression Checking | "Checking if compressed or encoded data sections can be successfully decompressed or decoded" | Corrupt or crafted compressed streams, archive bombs | High |
The "Catches" and "Cost" columns are NHI Mgmt Group's reading of the definitions. The OPSWAT patent abstract describes the combined logic: parse the header block's description of the content, the content's leading bytes and the actual content, compare each pair, and treat the file type as validated "when the data from the description, the data from the leading bytes and the data from the actual content are consistent with one another". In NCSC terms this is syntactic verification, confirming "the structure and syntax of the object are correct", before any semantic check of whether the content makes sense for the business operation.
ATT&CK techniques D3FEND relates to D3-FFV
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-FFV. Its page shows an "inferred, experimental" list derived through the File artefact family it shares with its parent (checked November 2026). The list matches the one on the D3-CV Content Validation card, which shows it in full; the summary below groups it. Each ID was checked against ATT&CK v20.
| ATT&CK tactic (v20) | Examples from the D3FEND list |
|---|---|
| Initial Access and Execution | T1566.001 Spearphishing Attachment, T1566.002, T1566.003; T1204.002 Malicious File; T1127.001 MSBuild |
| Persistence and Privilege Escalation | T1546 and T1547 sub-techniques, T1037.001 to T1037.004, T1543.001, .002, .004, T1137.001, T1137.003, T1505.003 Web Shell, T1548.002, T1548.003 |
| Stealth | T1036.001 Invalid Code Signature, T1036.003, T1036.005 Match Legitimate Resource Name or Location, T1036.006 Space after Filename; T1027.001, T1027.002, T1027.004; T1564.002, .003, .006, .007, .009; T1055 and T1574 sub-techniques; T1218.005, T1218.011; T1070.004 |
| Defense Impairment | T1556.002, T1556.003; T1647 Plist File Modification; T1685.006 Clear Linux or Mac System Logs; T1690 Prevent Command History Logging |
| Credential Access, Collection, C2, Exfiltration, Impact | T1003.007, T1003.008, T1552.001, T1552.003, T1555.003; T1074.001, T1114.001, T1560.001 to T1560.003; T1071.001, T1573.002; T1048.002; T1565.001, T1565.003 |
D3FEND still lists some IDs that ATT&CK v20 has revoked; the table shows the successors: Plist Modification is now T1647, DLL Side-Loading is folded into T1574.001, Clear Linux or Mac System Logs is now T1685.006, and Impair Command History Logging is now T1690. D3FEND also lists Launchd, which ATT&CK v20 marks deprecated with no successor, so it is left out.
Where format verification genuinely bites (NHI Mgmt Group view): masquerading and delivery. Files whose type is disguised by name or location (T1036.005, T1036.006) fail when content and claimed type are compared, and web shells uploaded through a form that expects images (T1505.003) fail a strict format check. See the T1036 Masquerading Defensive Guide.
Where it is implemented
| Placement | Typical checks | Reference |
|---|---|---|
| Web application upload handlers | Extension allowlist, magic bytes, image re-encoding, specialised validation libraries, applied also to files inside archives | OWASP ASVS 5.0 V5.2.2 (all accepted files at L2 and above); the Secure File Upload Handling Guide |
| Mail, web and file transfer gateways | True file type detection regardless of extension, per-type policies, nested content checks | NCSC Safely Importing Data pattern |
| Cross-domain and import solutions | Transform to a simple format, then strict verification as the final step | NCSC pattern: verification is "the key security enforcing component" |
| Malware scanning engines | Heuristics for files that break their format | For example, ClamAV's AlertBrokenExecutables (PE and ELF) and AlertBrokenMedia (JPEG, TIFF, PNG, GIF), both off by default |
| Content disarm and reconstruction | Parses to the specification and rebuilds only conforming parts | Content Disarm and Reconstruction |
Implementation steps
- Define the accepted types per entry point. For each upload form, mailbox rule or transfer path, list the business-required file types and nothing more (ASVS V5.1.1 asks for permitted types, extensions and maximum size to be documented).
- Chain the checks, cheapest first. Extension against the allowlist, magic bytes against the claimed type, structure and metadata against the specification, then decoding of compressed sections.
- Use maintained parsers. Prefer well-maintained format libraries over hand-written checks, and keep them patched; the parser is itself attack surface.
- Recurse into containers. Apply the same rules to every file inside archives and compound documents, with depth limits.
- Fail closed and alert. Reject or quarantine non-conforming files and send verification failures to the SOC, as the NCSC pattern advises.
- Pilot in log-only mode. Measure how many legitimate files fail (old document versions, files from scanners and line-of-business tools) and handle them by adding tested types, not by disabling checks.
- Follow with content controls. Send conforming files on to malware scanning, D3-CFC Content Format Conversion or disarm.
How to verify it works
- Mismatch tests: a harmless executable renamed to an allowed extension, a text file renamed to an image, and a file with a correct header but truncated body must all be rejected.
- Nested tests: the same files inside an allowed archive must be rejected at the same rate as when uploaded directly.
- Header spoof test: a request with a forged Content-Type must make no difference to the decision.
- Alert path: each rejection should produce a log record with the entry point, claimed type, detected type and reason, and repeated failures from one source should alert.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Entry points with a documented type allowlist | 100% | Undocumented paths accept anything |
| Mismatch test files rejected, direct and nested | 100% on every release | Proves the chain runs at every layer |
| Legitimate files rejected after pilot | Low and falling | Shows the allowlist matches business need |
| Verification failures investigated | All repeated-source failures | Failures can indicate probing or a compromised upstream system |
Limits, bypasses and failure patterns
- Magic bytes only: a file can start with valid magic bytes and still be something else further in. OWASP warns signature checks should not be used alone.
- Polyglot files: a file can be valid in two formats at once and pass verification for the allowed one. Re-encoding or conversion removes this ambiguity better than verification alone.
- Lenient parsers: a verifier that tolerates errors the specification forbids, while the downstream application interprets them differently, leaves a gap between what was checked and what runs.
- Outer layer only: checking the archive but not its members, or the document but not embedded objects, is the most common gap.
- Valid but malicious: macros, scripts and exploits in well-formed files pass. Format verification must be followed by scanning or disarm.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 Information Input Validation | Checking that file inputs match their expected format |
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | The scanning that follows verification |
| OWASP ASVS 5.0 | V5.1.1, V5.2.2 | Documented permitted types; extension and content type agreement |
| MITRE D3FEND | D3-CV, D3-FFV and its child checks | Parent, technique and child checks |
Practitioner checklist
- Document permitted file types, extensions and size for each entry point.
- Never base a decision on the extension or Content-Type alone.
- Chain magic byte, structure, metadata and decompression checks.
- Apply every check to files inside archives and compound documents.
- Use maintained parsing libraries and patch them.
- Reject or quarantine non-conforming files and alert on repeated failures.
- Run mismatch and nested test files on every release.
- Send conforming files on to scanning, conversion or disarm.
Standards and references
- MITRE D3FEND: File Format Verification (D3-FFV)
- OPSWAT: File Security Using File Format Validation, US20200104494A1
- OWASP: Application Security Verification Standard 5.0 (V5 File Handling)
- OWASP: File Upload Cheat Sheet
- NCSC: Pattern: Safely Importing Data
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-10)
- ClamAV: clamd.conf.sample heuristic alerts
Related NHI Mgmt Group resources: D3-CV Content Validation · D3-FCDC File Content Decompression Checking · D3-FMBV File Magic Byte Verification · Secure File Upload Handling Guide · MITRE D3FEND Guide