Malformed files are built to reach parser bugs, and a file that starts with the right signature can still carry internal fields that no legitimate writer would ever produce. MITRE D3FEND defines File Internal Structure Verification (D3-FISV) as "The process of checking specific static values within a file, such as file signatures or magic numbers, to ensure they match the expected values defined by the file format specification." Where a signature check stops at the first bytes, this technique looks at the fixed values the specification requires inside the file's content blocks. This card covers what D3FEND says, worked examples from real format specifications, where the check already runs, how to deploy and test it, and its limits. It is for engineers running document gateways, upload pipelines and endpoint document handling. The family overview is D3-CV Content Validation.
Key takeaways
- It checks the inside, not the label. Fixed fields within a file's structure must hold the values the format specification demands.
- Specifications use MUST, and that is your rule set. The Microsoft Compound File specification says the byte order field "MUST be set to 0xFFFE"; anything else is a malformed file.
- A built-in example already exists. Office File Validation compares legacy binary Office files with a predefined schema and opens failures in Protected View by default.
- Cheap checks first. Forensic validation research runs short header and structure checks to reject most candidates before any full decode.
- Structure is not safety. A well-formed document with a malicious macro passes; pair this with content analysis, CDR and scanning.
D3-FISV at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FISV (d3f:FileInternalStructureVerification) |
| Definition | "The process of checking specific static values within a file, such as file signatures or magic numbers, to ensure they match the expected values defined by the file format specification." |
| Tactic | Isolate (through Content Filtering) |
| Parent technique | File Format Verification (D3-FFV), under Content Validation (D3-CV) |
| Digital artefact | Analyzes File Content Block ("A section within a file that contains the main content or data payload"); inherits filters File and enforces Content Policy |
| D3FEND references | Garfinkel, "Carving Contiguous and Fragmented Files with Fast Object Validation"; van den Bos, "Gathering Evidence: Model-Driven Software Engineering in Automated Digital Forensics" |
Hierarchy and artefacts are taken from the D3FEND 1.6.0 ontology, checked November 2026. The definition text D3FEND gives for D3-FISV is the same as the one it gives for D3-FMVV File Metadata Value Verification. What separates them in the ontology is the artefact: D3-FMVV analyses header and footer blocks, while D3-FISV analyses the File Content Block. This page follows that artefact split (NHI Mgmt Group reading): D3-FISV is about fixed values inside the body of the file's structure.
How it works
D3FEND explains that file format specifications define expected values for specific fields, and that this technique verifies that a file's static values match the declared format's specification. Its own example is the byte order field in the Compound Document Header of Microsoft Office files, which identifies little-endian byte order as 0xFFFE. A validator built on this idea needs three things.
- A machine-readable model of the format. Which fields exist, at which offsets, and which values the specification allows. The van den Bos thesis describes Derric, a declarative language for describing file formats so validators can be generated rather than hand-written.
- A parser that walks the structure. It follows the format from block to block and reads each fixed field it reaches.
- A decision rule. Any required value that does not match makes the file invalid. There is no partial credit for a mostly correct structure.
Worked examples from format specifications
| Format | Fixed internal values a validator can check | Source |
|---|---|---|
| Compound File (legacy .doc, .xls, .ppt) | Byte Order MUST be 0xFFFE; Major Version MUST be 3 or 4; Sector Shift MUST be 0x0009 for version 3 (512-byte sectors) or 0x000C for version 4 (4096-byte sectors); Mini Sector Shift MUST be 0x0006 (64-byte mini sectors) | Microsoft [MS-CFB] Compound File Header |
| PNG | IHDR shall be the first chunk and IEND the last; the case of a chunk type's first letter marks it critical or ancillary, and a decoder meeting an unknown critical chunk must tell the user it cannot safely interpret the image | W3C PNG Third Edition |
| ZIP | Each entry in the central directory starts with 0x02014b50, the end of central directory record with 0x06054b50, and each local file header with 0x04034b50 | PKWARE APPNOTE 6.3.10, sections 4.3.7, 4.3.12, 4.3.16 |
| JPEG | Segments follow the start marker in a valid sequence and the image ends with FF D9 | Garfinkel, fast object validation (JPEG validator) |
Garfinkel's Compound File validator shows the security payoff: it checks the header and allocation tables and rejects the object when sector pointers are negative or point beyond the number of sectors in the file. Out-of-range pointers are exactly the kind of value that sends a careless parser outside its buffer.
ATT&CK techniques D3FEND relates to D3-FISV
Relationship type: inferred only. D3FEND has no direct ATT&CK mapping for D3-FISV. Its technique page lists techniques it infers through a shared artefact, chiefly File: the ATT&CK technique involves a File and D3-FISV, through its Content Filtering ancestor, filters File. D3FEND labels these "inferred, experimental" (D3FEND 1.6.0, checked November 2026), and the same list appears for every sibling under Content Validation. Each ID below 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, 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, .003, .005, .006 masquerading; 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 |
| 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, as are entries the page shows by name without an ID.
Where the check genuinely bites (NHI Mgmt Group view): malicious documents delivered as attachments or downloads (T1566.001, T1204.002) that depend on malformed structures to exploit a reader, and files that hide data in places a valid structure does not allow, which relates to T1027.009 Embedded Payloads and to VBA Stomping (T1564.007), where the stored source and compiled code in an Office file no longer agree. Structure checks find the anomaly; they do not decide intent. See the T1027 Obfuscated Files or Information Defensive Guide.
Where it is implemented
The examples are listed alphabetically and are illustrations, not recommendations.
| Implementation | What it checks | Point to note |
|---|---|---|
| Content disarm and reconstruction (CDR) products | Parse the file to rebuild it; files that cannot be parsed against the format are rejected | See D3-CM Content Modification |
| Forensic carving and validation tools | Format validators that accept or reject candidate byte runs, as in Garfinkel's JPEG, MSOLE and ZIP validators | Built for recovery, but the same validators work as a gate |
| Microsoft Office File Validation | Compares a legacy binary file's structure (.doc, .dot, .xls, .xlt, .ppt, .pps, .pot) to a predefined file schema before Word, Excel or PowerPoint opens it | Failures open in Protected View by default; the Group Policy setting "Set document behavior if file validation fails" can block them instead |
| Upload and import pipelines using full parsers | Decoding an image or parsing a document with a maintained library, and rejecting on parse errors | The parser handles hostile input: isolate it and patch it |
Office File Validation settings
Microsoft's documentation for Office 2016 describes three Group Policy settings, configured per application for Excel, PowerPoint and Word. Office 2016 itself reached end of support on 14 October 2025, so confirm the equivalent settings in the administrative templates for the Office version you run.
- Turn off file validation: leave this not enabled. Microsoft recommends that file validation is not turned off and calls it a key part of the layered defence. Files opened from trusted locations skip validation, so keep trusted locations few.
- Set document behavior if file validation fails: "Open files in Protected View" is the default; "Block files" stops failed files opening at all. Choose Block where users have no business need for old binary formats.
- Turn off error reporting for files that fail file validation: controls whether Office later prompts users to send validation data to Microsoft; set it to match your data sharing policy.
Pair this with the Office Macro Blocking Guide: structure validation and macro controls cover different parts of the same delivery chain.
Deploying it
- Pick the formats that matter. Start with the formats your users open most from outside: PDF, Office documents, images and archives.
- Prefer strict, maintained parsers. Validate with libraries that implement the specification and fail on violations, rather than lenient readers that silently repair files.
- Run the validator in isolation. It parses untrusted data: give it least privilege, memory and time limits, and no network access.
- Log before enforcing. Record failures for a few weeks (an example period, not a standard). Old or unusual writers produce technically invalid files, and you need to know which ones your business relies on.
- Enforce with quarantine or reduced trust. Send failures to D3-CQ Content Quarantine or, on endpoints, to a read-only view such as Protected View.
- Roll back per format. If one format rule blocks critical work, move that rule to log-only and fix the source, rather than turning validation off.
How to verify it works
- Field tamper test: take a harmless legacy .doc test file, change the byte order field from FE FF to another value in a copy, and confirm the gateway or Office rejects it or opens it in Protected View.
- Order test: build a test PNG whose IEND chunk is not last, or whose first chunk is not IHDR, and confirm rejection.
- Truncation test: cut a valid ZIP, PDF and JPEG part way through; each should fail without the validator crashing or hanging.
- Policy test: on a managed endpoint, confirm with a group policy results report that "Turn off file validation" is not enabled for Word, Excel and PowerPoint.
- Alert path: confirm each failure reaches the SOC with format, failing field and source.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| High-risk formats covered by structural validation at gateways | All formats on the allowlist | Uncovered formats are the path of least resistance |
| Managed endpoints with Office File Validation not turned off | 100% | One policy exception reopens the gap |
| Malformed test files rejected per release | 100% | Proves the check runs |
| Structural failures per week by source | Baselined; spikes reviewed | Clusters point to a campaign or a broken partner system |
| Validator crashes or timeouts | Zero; each investigated | A crash on input may be a parser vulnerability |
Limits, bypasses and failure patterns
- Valid but hostile: a document that obeys every structural rule can still carry a macro, script or exploit for a logic bug. Follow with D3-FCOA File Content Analysis and scanning.
- Lenient parsers: a validator that repairs damaged files hides exactly the anomalies you wanted to see.
- Parser mismatch: the gateway's parser and the user's application may read the same file differently, so a file valid to one is dangerous to the other. Re-encoding or CDR narrows the gap.
- Trusted location sprawl: Office skips validation for files opened from trusted locations; broad network shares listed as trusted bypass the check.
- Coverage gaps: Office File Validation covers the legacy binary formats only; validate Office Open XML and PDF elsewhere in the chain.
- Ignoring Protected View fatigue: if many legitimate files fail, users learn to click Enable Editing. Fix the noisy source rather than training the habit.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 Information Input Validation | Checking input syntax and structure |
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | Rejecting malformed files before scanning and use |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Validation at mail, web and import boundaries |
| MITRE ATT&CK mitigations | M1049 Antivirus/Antimalware, M1040 Behavior Prevention on Endpoint | Closest mitigations (NHI Mgmt Group view); see M1040 Behavior Prevention on Endpoint |
| MITRE D3FEND | D3-CV, D3-FFV, D3-FISV | Ancestors and technique |
Practitioner checklist
- List the external formats you accept and the specification each must meet.
- Validate structure with strict, maintained parsers that fail rather than repair.
- Isolate validators with least privilege and resource limits.
- Keep Office File Validation on and decide between Protected View and Block.
- Keep Office trusted locations few and narrow.
- Quarantine failures and log the failing field and source.
- Keep tampered, reordered and truncated test files in release testing.
- Follow structure checks with content analysis, CDR or scanning.
Standards and references
- MITRE D3FEND: File Internal Structure Verification (D3-FISV)
- Microsoft: [MS-CFB] Compound File Header
- W3C: Portable Network Graphics (PNG) Specification, Third Edition
- PKWARE: APPNOTE.TXT, .ZIP File Format Specification
- Microsoft: Prevent file format attacks by using Office file validation
- Garfinkel: Carving Contiguous and Fragmented Files with Fast Object Validation
- van den Bos: Gathering Evidence, Model-Driven Software Engineering in Automated Digital Forensics
- OWASP: File Upload Cheat Sheet
Related NHI Mgmt Group resources: D3-FFV File Format Verification, D3-FMBV File Magic Byte Verification, D3-CV Content Validation, Macro Malware Guide.