An extension and a Content-Type header are labels the sender chooses, so a file that arrives as report.pdf tells you nothing about what it really is until someone reads its first bytes. MITRE D3FEND defines File Magic Byte Verification (D3-FMBV) as "Utilizing the magic number to verify the file". It is the cheapest check in the Content Validation family: compare the signature at the start of the file with the signature its declared format requires. This card covers what D3FEND says, the signatures that matter in practice, where the check already runs in common tooling, how to deploy and test it, and why it must never stand alone. It is written for engineers who own upload handlers, mail gateways and file import pipelines. The parent picture is in D3-CV Content Validation; this page goes deeper on the first byte check only.
Key takeaways
- It answers one question. Do the leading bytes match the format the file claims to be? It does not say whether the content is safe.
- Extensions and Content-Type are claims. OWASP calls the client-supplied Content-Type "trivial to spoof"; magic bytes are the first content-based check against that claim.
- OWASP warns against relying on it alone. Its File Upload Cheat Sheet says signature validation "should not be used on its own, as bypassing it is pretty common and easy."
- Use maintained signature databases. libmagic and Apache Tika already encode thousands of signatures; hand-written byte comparisons drift and miss variants.
- Treat it as a fast reject filter. In forensic file validation research, header checks are used to discard candidates cheaply before deeper structural checks.
D3-FMBV at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FMBV (d3f:FileMagicByteVerification) |
| Definition | "Utilizing the magic number to verify the file" |
| Tactic | Isolate (through Content Filtering) |
| Parent technique | File Metadata Value Verification (D3-FMVV), under File Format Verification (D3-FFV) and Content Validation (D3-CV) |
| Digital artefact | Analyzes File Magic Bytes ("A specific type of header signature located at the beginning of a file, used to identify the file format"); 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. In D3FEND's model File Magic Bytes is a kind of File Header Block Signature, which is itself a kind of File Metadata, so this technique is the narrowest member of the metadata value checks described in D3-FMVV File Metadata Value Verification.
How it works
D3FEND's explanation is short: many file formats use magic numbers to identify a format or protocol, and checking that the magic number matches the expected value for the declared format is a simple way of verifying the file format. In practice that means three steps.
- Establish the claim. Take the declared type from the extension, the Content-Type header or the business context (an "invoice upload" field expects PDF).
- Read the evidence. Read the first bytes of the stored file, on the server, from the bytes actually written, not from a client-side preview.
- Compare and decide. If the signature belongs to an allowed type and agrees with the claim, pass the file to the next check; if not, reject or quarantine it and log both values.
Signatures practitioners meet most
| Format | Leading bytes (hex) | Source |
|---|---|---|
| PNG | 89 50 4E 47 0D 0A 1A 0A | W3C PNG Third Edition, section 5.2; WHATWG MIME Sniffing |
| JPEG | FF D8 FF | WHATWG MIME Sniffing image patterns |
| GIF | 47 49 46 38 37 61 (GIF87a) or 47 49 46 38 39 61 (GIF89a) | WHATWG MIME Sniffing image patterns |
| ZIP (and ZIP-based formats such as DOCX, XLSX, JAR, APK) | 50 4B 03 04 (local file header signature 0x04034b50) | PKWARE APPNOTE 6.3.10, section 4.3.7; WHATWG archive patterns |
| gzip | 1F 8B 08 | WHATWG archive patterns |
| RAR 4.x | 52 61 72 21 1A 07 00 | WHATWG archive patterns |
| Compound File (legacy .doc, .xls, .ppt, .msg) | D0 CF 11 E0 A1 B1 1A E1 | Microsoft [MS-CFB] Compound File Header |
The table shows why a signature is a weak identity on its own: every Office Open XML document, Java archive and Android package starts with the same ZIP signature, and every legacy Office format shares one Compound File signature. A magic byte check can tell you "this is a ZIP container"; it takes container inspection or structural checks to tell a DOCX from a ZIP full of scripts.
ATT&CK techniques D3FEND relates to D3-FMBV
Relationship type: inferred only. D3FEND has no direct ATT&CK mapping for D3-FMBV. Its technique page lists techniques it infers through a shared artefact, chiefly File: the ATT&CK technique involves a File and D3-FMBV, 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): most rows above are reached only through the broad File artefact. The practical value is narrower: renamed executables and scripts sent as attachments or uploads (T1566.001, T1204.002), web shells pushed through an upload form that expects images (T1505.003), and file masquerading. ATT&CK v20 also has T1036.008 Masquerade File Type, which describes changing a file's extension or header to disguise it and which D3FEND does not list here; a magic byte check catches the extension variant but not a file whose header has been forged too. See the T1036 Masquerading Defensive Guide.
Where it is implemented
Few teams need to write a signature check from scratch. The examples below are listed alphabetically and are illustrations, not recommendations.
| Implementation | How it uses magic bytes | Point to note |
|---|---|---|
| Apache Tika (content detection library) | MagicDetector matches byte patterns near the start of the file, then the default detector refines the result with the file name | Container-aware detectors open ZIP and OLE2 containers to find the real type, but need the whole file and a TikaInputStream; with a plain stream only magic detection runs |
| Browsers (WHATWG MIME Sniffing) | Byte pattern tables for images, audio, video, fonts and archives | When the no-sniff flag is set (the X-Content-Type-Options: nosniff response header), the supplied MIME type is used instead of sniffing, so servers must send correct types |
| file command and libmagic (Unix-like systems) | Runs filesystem tests, then magic tests for an invariant identifier at a small fixed offset, then language tests on text | --mime-type prints the MIME type; -k keeps matching after the first hit, which helps spot files that match more than one format |
| Email and web security gateways | "True file type" rules that classify attachments by content rather than by name | Check that rules apply to archive members, not only to the outer file |
For web applications the server-side handling is covered in the Secure File Upload Handling Guide. On endpoints, the related control for scripts and executables arriving disguised as documents is M1038 Execution Prevention.
Deploying it
- Write an allowlist per entry point. For each upload field, mailbox rule or import job, list the formats the business needs and the signatures they must carry. Everything else is refused.
- Check on the server after storage. Read the bytes the server actually holds, after any decoding of transfer encodings, never a client-supplied value.
- Use a maintained detector. Pin and patch libmagic, Tika or your gateway's engine. Signature databases change as formats evolve.
- Require agreement, not just a known type. Signature, extension and declared Content-Type must all map to the same allowed format; a disagreement is a rejection reason in its own right.
- Run in log-only mode first. Record what would have been rejected for two to four weeks (an example period, not a standard) to find legitimate files with unusual signatures, such as old scanner output.
- Enforce with quarantine. Move failures to D3-CQ Content Quarantine with the claimed type, detected type and entry point recorded.
- Chain the deeper checks. Passing files continue to structure, metadata and decompression checks, then to malware scanning.
- Roll back narrowly. If a rule blocks legitimate work, switch that one format rule to log-only rather than disabling the check for the entry point.
How to verify it works
- Renamed file test: rename a harmless text file to .png and upload it. It should be rejected with "signature mismatch" in the log.
- Wrong but allowed type: upload a genuine PNG named .pdf to a PDF-only field. Both are allowed formats somewhere in your estate, but the claim and evidence disagree, so it should fail.
- Container test: upload a ZIP archive renamed to .docx. A pure magic byte check passes it (both start with 50 4B 03 04); confirm a later container or structure check rejects it.
- Client bypass: send the request directly to the API without the browser form, with a false Content-Type, and confirm the server still decides on bytes.
- Logging and alerting: confirm each rejection reaches the SOC with entry point, claimed type, detected type and file hash.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| External file entry points with server-side signature checks | 100% | An unchecked entry point is the bypass |
| Signature mismatch test cases rejected in release testing | 100% | Proves the check runs after code changes |
| Mismatches per entry point per week | Baselined; spikes investigated | A sudden rise suggests probing |
| Legitimate files wrongly rejected | Tracked and falling | Over-strict rules push users to workarounds |
| Detector library version lag | Within your patch window | Detectors parse hostile input |
Limits, bypasses and failure patterns
- Forged headers: an attacker who knows the check simply writes the expected bytes at the start. OWASP's warning that bypass is "pretty common and easy" is the reason this check is only the first gate.
- Polyglot files: a file can be valid in two formats at once, carrying a correct image signature while also being interpreted as script or archive by another parser. Re-encoding images, as OWASP recommends, removes much of this.
- Shared container signatures: ZIP and Compound File signatures cover many formats, including executable packages. Pair with container inspection, see D3-FISV File Internal Structure Verification.
- Formats without a signature: CSV, plain text, many scripts and some legacy formats have no fixed magic number; file falls back to its least reliable language tests. Use schema or parser validation instead.
- Checking the wrong bytes: validating the first upload chunk, a thumbnail or a base64 string instead of the decoded stored file lets a different payload through.
- Silent rejections: dropping failed files without a log hides reconnaissance; attackers try many variants before one works.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 Information Input Validation | Checking inputs against expected formats |
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | Type checks as a filter ahead of scanning |
| NIST CSF 2.0 | PR.PS-05 | Stopping disguised executables from running |
| MITRE ATT&CK mitigations | M1049 Antivirus/Antimalware, M1038 Execution Prevention | Closest mitigations (NHI Mgmt Group view); see M1049 Antivirus/Antimalware |
| MITRE D3FEND | D3-CV, D3-FFV, D3-FMVV, D3-FMBV | Ancestors and technique |
Practitioner checklist
- List every external file entry point and the formats each one accepts.
- Check signatures on the server, on the stored and decoded bytes.
- Require signature, extension and declared type to agree.
- Use a maintained detection library and keep it patched.
- Follow the signature check with container, structure and metadata checks.
- Re-encode images and run CDR on documents where the format allows.
- Quarantine and log every mismatch with claimed and detected types.
- Keep renamed, container and polyglot test files in your release tests.
Standards and references
- MITRE D3FEND: File Magic Byte Verification (D3-FMBV)
- W3C: Portable Network Graphics (PNG) Specification, Third Edition
- WHATWG: MIME Sniffing Standard
- PKWARE: APPNOTE.TXT, .ZIP File Format Specification
- Microsoft: [MS-CFB] Compound File Header
- OWASP: File Upload Cheat Sheet
- file project: file(1) manual page
- Apache Tika: Content Detection
Related NHI Mgmt Group resources: D3-CV Content Validation, D3-FMVV File Metadata Value Verification, File Upload Security Guide, T1036 Masquerading Defensive Guide.