A file that claims to be a PDF, a PNG or a Word document but carries the wrong fixed values in its header or footer is either corrupt or lying, and either way it should not reach a parser unchecked. MITRE D3FEND names this countermeasure File Metadata Value Verification (D3-FMVV) and defines it 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." It is a child of File Format Verification (D3-FFV), which sits under Content Validation and Content Filtering in the Isolate tactic, and it is itself the parent of File Magic Byte Verification (D3-FMBV). This card covers what the check does, which format values are worth checking, where the control is implemented, how to test it and why it is never enough on its own. It is written for engineers who build upload pipelines, mail and web gateways, and endpoint content controls.
Key takeaways
- It checks declared constants, not behaviour. D3-FMVV compares fixed values that a format specification requires, such as a signature at offset 0, a version field or a byte order marker, against what the file actually contains.
- Header and footer both count. D3FEND's ontology says the technique analyses File Header Block and File Footer Block, so trailing structures such as a ZIP end of central directory record are in scope as well as leading magic bytes.
- The ATT&CK relations are inherited. D3FEND lists no direct ATT&CK mapping; its long inferred list comes from the parent relation "filters File", so it describes where files are involved, not proof that this check stops each technique.
- Cheap, fast and easy to bypass alone. OWASP's File Upload Cheat Sheet warns that signature validation should not be used on its own because bypassing it is common and easy. A polyglot or a valid header on hostile content passes.
- Its real value is as an early gate. Rejecting mismatched files before deeper parsing, scanning or content disarm reduces the attack surface of the expensive stages behind it.
D3-FMVV at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FMVV (d3f:FileMetadataValueVerification) |
| Tactic | Isolate (via Content Filtering) |
| Parent technique | File Format Verification (D3-FFV), under Content Validation (D3-CV) |
| Child technique | File Magic Byte Verification (D3-FMBV) |
| Siblings under D3-FFV | File Content Decompression Checking (D3-FCDC), File Internal Structure Verification (D3-FISV), File Metadata Consistency Validation (D3-FMCV) |
| Digital artefacts | Analyses File Header Block and File Footer Block |
| D3FEND references | Garfinkel, "Carving Contiguous and Fragmented Files with Fast Object Validation"; Lin, "Introductory Computer Forensics" |
| Typical placement | File upload handlers, mail and web gateways, file transfer services, sandboxes and endpoint content inspection |
| Main limitation | Confirms that a file looks like its declared type, not that it is safe |
How it works
Many file formats define fields whose values never vary. D3FEND's description gives two examples: file signatures (magic numbers) used to identify a format, and the byte order field in the Microsoft compound document header, where the 29th and 30th bytes must hold 0xFFFE. The control reads the declared type of a file (from its extension, a MIME type or the context of the upload), looks up the fixed values that type requires, and rejects or quarantines the file when they do not match.
The difference between D3-FMVV and its child D3-FMBV is scope. Magic byte verification checks only the identifying signature. Metadata value verification checks every static value the specification fixes, which can include version numbers, reserved fields that must be zero and trailing records. The neighbouring D3-FMCV goes further and checks that variable metadata (declared lengths, offsets, checksums) is consistent with the content, which is a different and more expensive test.
Example fixed values by format
The table shows values taken from the published specifications. It is a sample for building rules, not a complete catalogue.
| Format | Location | Fixed value | Source |
|---|---|---|---|
| Microsoft Compound File (legacy .doc, .xls, .msg) | Offset 0, 8 bytes | Header signature D0 CF 11 E0 A1 B1 1A E1 | MS-CFB |
| Microsoft Compound File | Offset 8, 16 bytes | Header CLSID must be all zeroes | MS-CFB |
| Microsoft Compound File | Offset 26 and 28 | Major version 0x0003 or 0x0004; byte order 0xFFFE | MS-CFB |
| Microsoft Compound File | Offset 30 and 32 | Sector shift 0x0009 (v3) or 0x000C (v4); mini sector shift 0x0006 | MS-CFB |
| Microsoft Compound File | Offset 56 | Mini stream cutoff size 0x00001000 | MS-CFB |
| PNG | First 8 bytes | 89 50 4E 47 0D 0A 1A 0A | W3C PNG Third Edition |
| PNG | Chunk order | IHDR first, IEND last | W3C PNG Third Edition |
| ZIP (and ZIP-based formats such as .docx, .xlsx, .jar) | Start of each entry | Local file header signature 0x04034b50 | PKWARE APPNOTE 6.3.10 |
| ZIP | End of file, before an optional comment of up to 65,535 bytes | End of central directory signature 0x06054b50 | PKWARE APPNOTE 6.3.10 |
The ZIP row shows why the footer matters. A ZIP reader locates the archive from its end, and the trailing comment means the end record is not at a fixed offset, so a verifier has to search the last 65,557 bytes (22-byte record plus the maximum comment) rather than assume a position. Content placed before a valid ZIP structure is a classic way to build a file that two parsers read differently.
ATT&CK techniques D3FEND relates to D3-FMVV
Relationship type: inferred only. D3FEND has no direct ATT&CK mapping for D3-FMVV. The D3FEND 1.6.0 page (checked November 2026) shows a long list of inferred and experimental relations, roughly 80 technique IDs across ten tactics. They arise because D3-FMVV inherits the relation "filters File" from Content Filtering, so every ATT&CK technique that D3FEND links to a File artefact appears. That list tells you where files sit in an attack, not where a header check would stop it. The rows below are the subset where verifying a file's declared format genuinely helps. D3FEND's list also includes two IDs that ATT&CK v20 has revoked; they are left out here. Each ID shown was checked against ATT&CK v20.
| Tactic (ATT&CK v20) | ATT&CK ID and name | Where D3-FMVV helps (NHI Mgmt Group view) |
|---|---|---|
| Initial Access | T1566.001 Spearphishing Attachment; T1566.003 Spearphishing via Service | Attachments whose content does not match their declared type are quarantined at the gateway |
| Execution | T1204.002 Malicious File | An executable renamed as a document fails the document signature check before a user opens it |
| Persistence | T1505.003 Web Shell; T1137.001 Office Template Macros | An upload declared as an image but carrying script content fails the image signature check |
| Stealth | T1036.005 Match Legitimate Resource Name or Location; T1027.001 Binary Padding; T1027.002 Software Packing | Files named like trusted resources but with foreign headers are flagged; padding and packing are mostly out of reach |
| Collection | T1560.001 Archive via Utility | Archives leaving through upload or transfer channels are identified by real signature, not by extension |
ATT&CK v20 also has T1036.008 Masquerade File Type, which describes exactly the deception this control targets. D3FEND does not list it against D3-FMVV, so it is named here as our own observation, not a D3FEND mapping. See the T1027 Obfuscated Files or Information Defensive Guide for the evasion side.
Where it is implemented
| Implementation class | What it checks | Fits when |
|---|---|---|
| Application upload handlers | Signature and key header fields of each upload against an allowlist of permitted types | You own the code that accepts files from users or partners |
| File identification libraries and tools | Magic tests at fixed offsets, for example the libmagic database used by the Unix file command, which runs filesystem, magic and language tests in that order | You need a maintained signature database rather than hand-written rules |
| Mail and web security gateways | "True file type" detection that compares the real type with the extension and MIME type | Most hostile files arrive by email or download |
| Content disarm and reconstruction services | Format verification as the first stage before parsing and rebuilding | You already rebuild documents and want early rejection of malformed ones |
| Endpoint and file server content inspection | Type verification on write or on open | Files move between hosts and shares without passing a gateway |
The file manual page describes its --mime-type option for machine-readable output and -k (--keep-going) for reporting every match rather than the first, which is useful when testing whether a sample matches more than one format. Deeper upload handling, including storage and naming, is covered in the Secure File Upload Handling Guide.
Implementation steps
- Start from an allowlist of types. For each channel (web upload, mail, file transfer) list the formats the business needs. The Risky File Types page helps decide what to exclude.
- Write the fixed values per type. Take signatures and fixed fields from the format specification (MS-CFB, the W3C PNG specification, PKWARE APPNOTE) rather than from community lists, and record the source in the rule.
- Verify both ends where the format has a footer. Check trailing records such as the ZIP end of central directory, and decide what to do with data before the signature or after the expected end.
- Bind the check to the declared type. Reject when extension, declared MIME type and verified type disagree. OWASP's File Upload Cheat Sheet notes that the Content-Type header is supplied by the client and can be spoofed.
- Run in log-only mode first. Record mismatches for two to four weeks (an example period, not a standard) to find legitimate files that break the rules, such as older format versions.
- Enforce and route. Move to block or quarantine. Send rejected files to analysis rather than discarding them, so the security team can see what was attempted.
- Keep later stages. Pass accepted files on to scanning, sandboxing or content disarm. Rolling back the check means returning a rule to log-only, not removing the pipeline stage.
How to verify it works
- Renamed file test: submit a harmless executable renamed with a document or image extension. It must be rejected or quarantined, and the log must name the mismatch.
- Header tamper test: take a valid sample and change one fixed field (for example the compound file byte order, or one PNG signature byte). It must fail.
- Footer test: submit an archive with appended data after the end record and one with a truncated end record, and confirm the behaviour matches your policy.
- Known-good regression set: keep a corpus of legitimate files of every allowed type and version and run it after every rule change, so tightening a rule does not block real business files.
- Bypass path check: confirm every channel that accepts files goes through the check, including APIs, partner transfer services and service accounts that write directly to storage.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| File intake channels covered by the check | 100% of listed channels | Unchecked channels are the bypass |
| Mismatch rejections per week, by channel and type | Tracked and trended | Spikes show campaigns or broken integrations |
| False rejections of legitimate files | Close to zero after tuning | Keeps the business from demanding exceptions |
| Regression corpus pass rate after rule changes | 100% | Proves rules match real formats |
Limits, bypasses and failure patterns
- Valid header, hostile body: a correct signature says nothing about macros, scripts or exploit data later in the file. That is why D3FEND places this beside internal structure and consistency checks, and why scanning and disarm still follow.
- Polyglot files: a file can satisfy the fixed values of two formats at once, for example an image that is also a valid archive read from the end. Checking only the leading bytes misses this.
- Trusting the client's label: using the extension or Content-Type as the declared type without cross-checking lets the attacker choose the rule they will be tested against.
- Signature-only allowlists: OWASP warns that signature checks on their own are commonly bypassed. Treat a pass as "eligible for the next stage", not "safe".
- Silent channels: direct writes to object storage by integrations, or service accounts with upload rights, skip the check. Inventory these identities and route their writes through the same pipeline.
- Stale rules for evolving formats: new versions add fields or change defaults. Rules built from an old specification reject legitimate files and push teams to disable the check.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 Information Input Validation | Validating that file input matches its expected format |
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | Format verification as an early stage of malicious file handling |
| NIST SP 800-53 Rev 5 | CM-7 Least Functionality | Allowing only the file types the business needs |
| MITRE ATT&CK mitigations | M1049 Antivirus/Antimalware; M1021 Restrict Web-Based Content | The mitigation families in which file type checks are usually delivered |
| MITRE D3FEND | D3-FFV, D3-FMVV, D3-FMBV | Parent, technique and child |
See M1049 Antivirus/Antimalware and M1021 Restrict Web-Based Content for those mitigations.
Related countermeasures
- File Format Verification (D3-FFV): the parent. See D3-FFV File Format Verification.
- File Magic Byte Verification (D3-FMBV): the child, limited to the identifying signature. See D3-FMBV File Magic Byte Verification.
- File Metadata Consistency Validation (D3-FMCV): checks lengths, pointers and checksums against content. See D3-FMCV File Metadata Consistency Validation.
- File Internal Structure Verification (D3-FISV) and File Content Decompression Checking (D3-FCDC): the deeper sibling checks. See D3-FISV File Internal Structure Verification and D3-FCDC File Content Decompression Checking.
Practitioner checklist
- Keep an allowlist of permitted file types per intake channel.
- Build fixed-value rules from the format specifications and record the source.
- Check footers and trailing records, not only leading magic bytes.
- Reject when extension, declared MIME type and verified type disagree.
- Pilot in log-only mode with a regression corpus of legitimate files.
- Quarantine rejected files for analysis rather than deleting them.
- Route every channel, including service account and API writes, through the check.
- Keep scanning, sandboxing or content disarm after the check; never treat a pass as safe.
Standards and references
- MITRE D3FEND: File Metadata Value Verification (D3-FMVV)
- Microsoft: [MS-CFB] Compound File Header
- W3C: Portable Network Graphics (PNG) Specification, Third Edition
- PKWARE: APPNOTE.TXT .ZIP File Format Specification 6.3.10
- OWASP: File Upload Cheat Sheet
- Linux man-pages: file(1)
- MITRE ATT&CK: Masquerade File Type (T1036.008)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: File Upload Security Guide · Secure File Upload Handling Guide · Content Disarm and Reconstruction · D3-FFV File Format Verification · MITRE D3FEND Guide