D3-CFC Content Format Conversion: Flattening Risky Files Into Safer Formats and Verifying the Result

Complex file formats carry far more capability than the reader needs, and converting a file into a simpler format throws that capability away, including whatever an attacker hid in it. MITRE D3FEND names this countermeasure Content Format Conversion (D3-CFC) and defines it as "mechanical transformation from one format to another which may be normalization or specifically flattening." It sits under the Isolate tactic as a child of Content Modification (D3-CM), next to Content Excision, Content Rebuild and Content Substitution. Where excision removes chosen parts and keeps the format, conversion changes the format itself: a word processing file becomes a PDF, a PDF becomes a set of page images, an image is decoded and re-encoded, rich text becomes plain text. This card covers when to normalise and when to flatten, how D3FEND relates the technique to ATT&CK, how to deploy and verify it, and what it costs users. It is written for security architects, email and web security engineers, and teams building file intake for applications or segmented networks.

Key takeaways

• Two strengths of conversion. Normalisation re-encodes into a clean instance of the same or a stricter format; flattening reduces a document to static content such as page images, which removes nearly all active capability and most usability.
• Simpler output, simpler verification. The NCSC safe import pattern converts complex formats into simple ones because a strict verifier for one simple format is feasible, where verifying the complex original is not.
• D3FEND links it to 15 ATT&CK techniques through the File artefact. These are the same inferred relations as its siblings, including Spearphishing via Service (T1566.003) and XSL Script Processing (T1220); none is a direct mapping.
• The converter is exposed. It parses hostile input by design, so it must run sandboxed, patched and without network access.
• Conversion is lossy on purpose. Forms, formulas, macros, links, signatures and sometimes searchable text are lost, so pick the target format per use case and keep a release path for originals.

D3-CFC at a glance

Normalisation versus flattening

D3FEND's definition names two forms of conversion. In practice they sit on a scale from light to heavy.

The deciding question is what the recipient needs to do with the file. If they only need to read it, flatten or convert to a simple format. If they need to edit it, normalise or use excision instead. If the content is structured data feeding a system, convert to a simple schema-defined format and validate it; that is the case the NCSC pattern is built around.

The NCSC safe import pattern

The NCSC's guidance on safely importing data into a more trusted system lists transforming complex file formats into simple ones as a control, because building a verification engine for complex formats is unlikely to be feasible. Its design points are directly usable for D3-CFC:

• Transform on the low side: conversion happens in the less trusted zone, and the design assumes the transformation engine could be compromised.
• Verify after transform: syntactic and semantic verification of the simple output comes last, after the protocol break and flow control, and because only one simple format is involved the verifier can be strict.
• Alert on verification failure: if the conversion worked, verification should never fail, so every failure is raised as an alert.
• Keep the steps in series: so no path can skip conversion or verification.
• Handle nesting: unpack nested content, convert where needed, verify, and limit nesting depth.
• Rebuild only if needed: once verified, the object may be rebuilt into the format the destination needs.

ATT&CK techniques D3FEND relates to D3-CFC

Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-CFC; every row below is inferred through the File artefact that D3-CFC modifies (D3FEND 1.6.0, checked November 2026).

D3-CFC shares its artefacts with the other Content Modification children, so D3FEND infers the same 15 same-artefact techniques for it; the full table with D3FEND's relation for each is on the D3-CNE Content Excision page and is not repeated here. The grouping below is NHI Mgmt Group's view of how much conversion actually helps. All IDs were checked against ATT&CK v20.

D3FEND's page for D3-CFC also shows a long list inferred through sub-artefacts of File. Two are the core of the practical case: Malicious File (T1204.002), which acts on Executable File, and VBA Stomping (T1564.007), which acts on Office Application File. A flattened document cannot carry either. Phishing attachments are related in D3FEND through the Email artefact rather than File; see MITRE ATT&CK T1566 Phishing.

Where it is implemented

Upload-specific controls are in the File Upload Security Guide; product category selection is in the Content Disarm and Reconstruction buyer's guide.

Implementation steps

1. Map flows to needs. For each channel (email, web, uploads, transfers into segmented networks) record which file types arrive and whether the recipient reads, edits or machine-processes them.
2. Choose a target per type and need. Read-only documents: PDF or flattened PDF. Images: re-encode to an allowed type. Structured data: a schema-defined simple format. Editable documents: normalise or use excision rather than flattening.
3. Isolate the converter. Run conversion in a sandbox or disposable container with no network access, limited CPU, memory and time, and least-privilege service identity. Patch the rendering libraries on a defined schedule, since they parse hostile input.
4. Add strict verification. Check that the output conforms to the target format (structure and allowed features), contains no active content, and opens. Alert on every failure.
5. Pilot with a release path. Convert for one group, keep originals in quarantine for a defined period, and record release requests by file type to find where conversion is too aggressive.
6. Decide on OCR and accessibility. If flattened PDFs will be searched or read by screen readers, add OCR text and test the result, or offer a normalised alternative.
7. Roll back. Keep the ability to switch a channel to pass-through with scanning, or to excision, and to release originals, so a broken process can be restored quickly.

How to verify it works

• Benign capability corpus: maintain harmless test files that each carry one capability the conversion should remove (a message-box macro, a PDF script alert, an embedded file, an external image link, appended data after an image end marker). Run them monthly through each channel and confirm the outputs lack them.
• Format conformance check: validate outputs against the target format with an independent validator, not the converter's own success code.
• Sandbox containment test: confirm the conversion environment cannot reach the network or persistent storage outside its job, for example by checking egress logs during test runs.
• Fidelity spot checks: compare a sample of outputs with originals for legibility and completeness so users trust the converted copy.

Limits, bypasses and failure patterns

• A vulnerable converter: the NCSC pattern states that the transformation engine processes the complex format and could itself be attacked, and that patching does not cover vulnerabilities not yet public. Isolation and least privilege, not the conversion, protect you here.
• Fail-open on errors: timeouts, unsupported types and encrypted files passed through unchanged undo the control. Make the failure mode explicit and prefer block or quarantine for high-risk channels.
• Trusting rewriting too much: OWASP notes that rewriting an image does not guarantee all malicious content is removed. Verify the output and keep malware scanning alongside conversion.
• Content-level attacks survive: conversion removes active capability, not meaning. A flattened invoice with fraudulent bank details or a phishing link printed as text still works on a human reader.
• Flattening for everyone: applying pixel flattening to every document drives users to other channels. Match conversion strength to risk and need.
• Losing evidence: converting without keeping the original removes what incident responders need. Hold originals securely for a defined period.

Framework mapping

Related countermeasures

• Content Excision (D3-CNE): removes selected parts and keeps the original format, the better fit when users must edit. See D3-CNE Content Excision.
• Content Modification (D3-CM): the parent technique. See D3-CM Content Modification.
• Content Validation (D3-CV): the verification step after conversion. See D3-CV Content Validation.
• Content Quarantine (D3-CQ): holds originals and files that cannot be converted. See D3-CQ Content Quarantine.
• Content Rebuild (D3-CNR): rebuilds a file to its own specification rather than converting it to another format.

Practitioner checklist

• Map each channel's file types to what recipients need to do with them.
• Choose normalisation, conversion or flattening per type and need, not one setting for all.
• Run converters sandboxed, without network access, with resource and time limits.
• Patch rendering and conversion libraries within your critical patch window.
• Verify every output with an independent, strict validator and alert on failures.
• Define fail-closed handling for unsupported, encrypted, oversized and timed-out files.
• Keep originals in quarantine with an audited release path.
• Add OCR or offer normalised copies where search and accessibility matter.
• Test each channel monthly with a benign capability corpus.

Standards and references

• MITRE D3FEND: Content Format Conversion (D3-CFC)
• NCSC: Pattern: safely importing data
• OWASP: File Upload Cheat Sheet
• OPSWAT Inc.: Method For Content Disarm and Reconstruction, US20190268352A1
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-3, SC-18, SI-10)
• MITRE ATT&CK: T1204.002 Malicious File

Related NHI Mgmt Group resources: Content Disarm and Reconstruction · File Upload Security Guide · Macro Malware Guide · MITRE D3FEND Guide