A file called invoice.pdf that is really a script, or a "PDF" whose header, structure and contents disagree, is the oldest trick in content delivery, and checking the extension alone never catches it. MITRE D3FEND defines Content Validation (D3-CV) as "Verify and validate contents complies with policy." It sits under the Isolate tactic as a child of Content Filtering (D3-CF), next to Content Modification and Content Quarantine, and D3FEND's reference is an OPSWAT patent on file format validation. This card covers what D3FEND says, the child techniques that make validation concrete, the ATT&CK techniques D3FEND relates, how to deploy validation in upload, mail and import pipelines, and how to test it. Application-side upload practice is in the File Upload Security Guide; this page stays on the countermeasure.
Key takeaways
- Validation is a gate, not a scanner. It checks that content matches what policy allows (type, structure, size, metadata) rather than looking for known malware.
- Consistency is the core test. The D3FEND reference validates a file only when its header description, leading bytes and actual content agree with one another.
- Never one signal alone. OWASP warns that the client-supplied Content-Type is easily spoofed and that a file signature check should not be relied on alone.
- Validate after transformation too. The NCSC import pattern puts strict verification after transformation; a failure there signals a broken or compromised transformer.
- Decide what happens on failure. Rejected content should be quarantined or refused with a log entry and alert, not silently dropped or passed through.
D3-CV at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-CV (d3f:ContentValidation) |
| Definition | "Verify and validate contents complies with policy" |
| Tactic | Isolate (through the parent Content Filtering) |
| Parent technique | Content Filtering (D3-CF) |
| Child techniques (D3FEND 1.6.0) | File Content Decompression Checking (D3-FCDC), File Format Verification (D3-FFV), File Internal Structure Verification (D3-FISV), File Magic Byte Verification (D3-FMBV), File Metadata Consistency Validation (D3-FMCV), File Metadata Value Verification (D3-FMVV) |
| Digital artefacts | Filters File and enforces Content Policy (inherited); children analyse File Magic Bytes, File Section, File Content Block data and File Metadata |
| D3FEND reference | OPSWAT patent application US20200104494A1, "File Security Using File Format Validation" |
How it works
D3FEND's description: to ensure content is safe, its composition must be validated according to its content policy. The cited patent describes the method behind format validation. A file has a header block describing the content, leading bytes in the content block, and the actual content. The validator parses all three and compares the header description with the leading bytes, the leading bytes with the content, and the description with the content. The file format type is treated as valid and trustable only when all three agree.
The UK NCSC's Safely Importing Data pattern adds a second dimension: syntactic verification checks structure and syntax (for example that content is valid XML or JSON conforming to a schema), and semantic verification checks that the meaning is valid for the business process. The NCSC asks for verification that is simple and strict, handles one known format, and confirms that all potentially active content has been removed.
What each check catches
| Check | D3FEND child | Catches | Cannot catch |
|---|---|---|---|
| Magic bytes match the declared type | D3-FMBV | Executables or scripts renamed to a document extension | Polyglot files that are valid in two formats |
| Format conforms to its specification | D3-FFV | Malformed files built to trip parsers | Valid files carrying a malicious macro |
| Internal structure is consistent | D3-FISV | Hidden or unreferenced sections, appended data | Malicious content in referenced sections |
| Metadata values within policy | D3-FMVV | Disallowed authoring tools, out-of-range sizes or dimensions | Forged but plausible metadata |
| Metadata consistent with content | D3-FMCV | Header claims that do not match the content | Consistent but hostile files |
| Decompression stays within bounds | D3-FCDC | Archive and compression bombs | Small archives with malicious members |
The column mapping checks to child techniques is NHI Mgmt Group's reading of the D3FEND definitions. D3-FCOA File Content Analysis covers the detection side that looks for malicious content rather than policy conformance.
ATT&CK techniques D3FEND relates to D3-CV
Relationship type: inferred only. D3FEND derives these rows from shared artefacts, chiefly File: the ATT&CK technique involves a File and D3-CV filters File. It labels them "inferred, experimental" (D3FEND 1.6.0, checked November 2026); the same list appears for its siblings under Content Filtering. 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, T1072 Software Deployment Tools, T1127.001 MSBuild |
| Persistence and Privilege Escalation | T1037.001 to T1037.004 logon, network logon and RC scripts and Login Hook; T1546.002, .004, .005, .006, .008, .009, .010, .013, .014, .015 event triggered execution; T1547.001, .006, .007, .008, .009 autostart execution; 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 |
| Stealth | T1055.001, .002, .003, .009, .014 process injection; T1218.005 Mshta, T1218.011 Rundll32; T1574.001, .004, .006, .007, .008, .009, .012 hijack execution flow; 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; T1070.004 File Deletion |
| Defense Impairment | T1556.002 Password Filter DLL, T1556.003 Pluggable Authentication Modules; T1647 Plist File Modification; 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 |
| Discovery and Collection | T1083 File and Directory Discovery, 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 |
| Command and Control, Exfiltration | T1071.001 Web Protocols, T1573.002 Asymmetric Cryptography, T1048.002 Exfiltration Over Asymmetric Encrypted Non-C2 Protocol |
| Impact | T1565.001 Stored Data Manipulation, T1565.003 Runtime Data Manipulation |
D3FEND still lists some 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.
Where validation genuinely bites (NHI Mgmt Group view): masquerading and delivery. Files renamed to look harmless (T1036.005, T1036.006, and in ATT&CK v20 also T1036.008 Masquerade File Type, which D3FEND does not list for this technique) fail a magic byte or consistency check. Attachments and uploads (T1566.001, T1204.002) and web shells uploaded through a vulnerable form (T1505.003) are stopped when the upload path accepts only validated types. See the T1036 Masquerading Defensive Guide.
Where it is implemented
| Placement | Typical validation | Note |
|---|---|---|
| Web application upload handlers | Extension allowlist, signature check, size limits, image decoding | See the Secure File Upload Handling Guide |
| Email security gateways | True file type detection, blocked types, archive inspection | Type rules based on content, not on the attachment name |
| API and message ingestion | Schema validation of JSON and XML, field ranges and business rules | See the Input Validation and Output Encoding Guide |
| Cross domain and import gateways | Strict verifier for one simple format after transformation | NCSC pattern: verification on the trusted side, after the protocol break |
| CDR and modification pipelines | Output checked against the expected format | Pairs with D3-CM Content Modification |
Building a validation policy (from the OWASP File Upload Cheat Sheet)
- Allowlist extensions: only business-critical types, checked after decoding the filename, with care for double extensions, null bytes and case tricks.
- Treat Content-Type as a hint: it is client-supplied and easy to spoof.
- Check the signature: confirm the file signature matches the expected type, but never as the only check.
- Bound sizes: cap upload size and measure the extracted size of archives to stop decompression bombs.
- Rename on storage: generate names such as UUIDs and store outside the web root.
- Follow with scanning: validated files still go to antivirus or a sandbox before use.
Rolling it out
- Write the content policy per entry point. Allowed types, size limits, schemas and the action on failure.
- Use maintained parsers. Validate with well-tested libraries rather than hand-written byte checks; the NCSC asks for robustly engineered components that handle external content.
- Log before enforcing. Run validation in a logging mode on live traffic for a period to find legitimate files that would fail.
- Enforce with quarantine. Failed content goes to D3-CQ Content Quarantine with the reason recorded.
- Add validation after any transformation. Alert on every post-transformation failure.
- Roll back a single over-strict rule by switching it to logging mode, not by disabling validation for the entry point.
How to verify it works
- Mismatch tests: upload safe test files with a wrong extension, a renamed text file posing as an image, a double extension and a trailing space in the name. Each should be refused and logged.
- Malformed files: submit truncated and structurally invalid samples of each allowed type and confirm they are rejected without crashing the service.
- Size and nesting: submit an archive whose extracted size exceeds the limit and a deeply nested archive; confirm both are refused.
- Schema tests: for APIs, send records with extra fields, wrong types and out-of-range values.
- Alert path: confirm a failure reaches the SOC with entry point, file type claimed, type detected and reason.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Entry points with a written content policy and validation | 100% of external file and data entry points | Unvalidated entry points are the bypass |
| Mismatch test cases rejected | 100% in each release test | Proves the checks run |
| Post-transformation validation failures | Zero expected; each investigated | The NCSC treats these as a sign of malfunction or compromise |
| Legitimate files rejected per week | Tracked and falling | Over-strict rules drive workarounds |
| Parser library version lag | Within your patch window | Validators parse hostile input |
Limits, bypasses and failure patterns
- Extension-only checks: the most common gap; an extension says nothing about content.
- Polyglots: a file can be valid in two formats at once and pass a single-format check. Combine validation with re-encoding or conversion where the format allows.
- Valid but hostile: a well-formed document with a macro passes format validation. Validation must be paired with modification or content analysis.
- Client-side validation only: checks in the browser are a usability feature; the server must repeat them.
- Parser vulnerabilities: the validator parses untrusted input; run it with least privilege, resource limits and in isolation where possible.
- Silent failure handling: rejected files dropped without logging leave the SOC blind to probing. See the T1027 Obfuscated Files or Information Defensive Guide for the evasion side.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 Information Input Validation | Checking the validity of information inputs |
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | Validation as a filter ahead of scanning |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Validation at mail, web and import boundaries |
| NIST CSF 2.0 | PR.PS-05 | Preventing disguised executables from running |
| MITRE ATT&CK mitigations | M1049 Antivirus/Antimalware, M1038 Execution Prevention | Closest mitigations (NHI Mgmt Group view); see M1049 Antivirus/Antimalware and M1038 Execution Prevention |
| MITRE D3FEND | D3-CF, D3-CV and its six children | Parent, technique and children |
Practitioner checklist
- Write a content policy for every external file and data entry point.
- Validate type by content (signature and structure), never by extension or Content-Type alone.
- Bound file sizes, extracted sizes and nesting depth.
- Validate on the server, with maintained parsers, in isolation.
- Validate again after any transformation and alert on failures.
- Quarantine failed content with the reason recorded.
- Keep a regression suite of mismatch, malformed and oversized test files.
- Follow validation with malware scanning; validation alone does not detect payloads.
Standards and references
- MITRE D3FEND: Content Validation (D3-CV)
- OPSWAT: File Security Using File Format Validation (US20200104494A1)
- NCSC: Pattern, Safely Importing Data
- NCSC: Content-based attack protection
- OWASP: File Upload Cheat Sheet
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
- MITRE ATT&CK: T1036.008 Masquerade File Type
Related NHI Mgmt Group resources: D3-CM Content Modification, D3-CQ Content Quarantine, File Upload Security Guide, D3-FCOA File Content Analysis.