D3-CNR Content Rebuild: Rebuilding Untrusted Files Safely and Proving It Works

Scanning can only block what it recognises, so a file built to evade detection still reaches the user unless something rebuilds it into a known safe form first. MITRE D3FEND names that countermeasure Content Rebuild (D3-CNR), synonym Content Reconstruction, and defines it as "Rebuild the file according to the spec so any unreferenced components or objects are removed." It sits under the Isolate tactic as a child of Content Modification (D3-CM), which in turn sits under Content Filtering (D3-CF). This card covers what D3-CNR does to a file, which ATT&CK techniques D3FEND relates to it, where it is deployed, how to test that rebuilt files are actually clean and still usable, and where the technique stops. It is written for email, web and application security engineers who already know the purchasing side from the Content Disarm and Reconstruction buyer's guide.

Key takeaways

• Rebuild, not repair. D3-CNR parses a file into components and assembles a new file from the parts that conform to the format specification, so anything the specification does not reference is left behind.
• It is the reconstruction half of CDR. D3FEND's only reference for the whole Content Modification family is an OPSWAT patent on content disarm and reconstruction, which disassembles structured storage, processes each item and reassembles an output file in the same format.
• The ATT&CK links are broad and inferred. D3FEND relates D3-CNR to a long list of techniques because it modifies the File artefact; the techniques where rebuilding genuinely changes the outcome are malicious attachments, macros, file padding and hidden content.
• Verification is part of the control. The UK NCSC safe import pattern places a separate verification step after transformation and says every verification failure should raise an alert, because in a working design it should never fail.
• It is not a guarantee. The parser that rebuilds the file processes hostile input, and the NCSC states the import pattern "is not a guarantee of safety"; keep scanning, sandboxing and macro controls alongside it.

D3-CNR at a glance

D3FEND version 1.6.0, checked November 2026. The parent, sibling and artefact relations above are taken from the D3FEND ontology; D3-CNR declares no artefact relations of its own and inherits them from D3-CM.

How it works

D3FEND's description is brief: if content is divided into components for scrutiny, "the components may be combined back afterwards in a safer state." The OPSWAT patent that D3FEND cites gives the mechanism in more detail. The engine receives a file with structured storage, disassembles it into stream subfiles, identifies each item, judges the item on three questions (is its behaviour acceptable, is it visible to the user, is it necessary) and then assembles the processed subfiles into an output file of the same format as the input.

• Parse against the specification: the engine reads the file using the format's own structure (for example the parts inside an Office Open XML package, or the object tree of a PDF), not by searching for known bad patterns.
• Keep what is referenced and needed: text, layout, images and other content that the document actually uses are carried into the new file.
• Drop what is unreferenced or unwanted: orphan objects, data appended after the logical end of the file, hidden streams and active elements the content policy forbids are not carried over. Deciding what to do with a forbidden element is where the siblings come in: remove it (Content Excision), replace it with a placeholder (D3-CNS Content Substitution) or convert the file to a simpler format (Content Format Conversion).
• Write a new file: the output is generated, not edited in place, which is why padding, appended payloads and malformed structures that rely on parser leniency do not survive.

The UK NCSC safe import pattern puts the same idea in an architecture: transform complex content into a simpler form on the untrusted side, pass it through a protocol break and one-way flow control, then verify it on the trusted side, where "verification components should ensure all potentially active content has been removed." The pattern also notes that after verification "you may need to re-build an object in its original format" so the recipient can use it. Rebuilding is therefore both a transformation step and, in some designs, the final step before delivery.

ATT&CK techniques D3FEND relates to D3-CNR

Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-CNR. Its site derives related techniques through shared digital artefacts and labels them "inferred, experimental" (D3FEND 1.6.0, checked November 2026). Because D3-CNR modifies the File artefact, the inferred list is long: more than a hundred technique names across persistence, privilege escalation, stealth, credential access, collection, execution, command and control, exfiltration, initial access, lateral movement and impact, most of them simply because the technique reads, writes or executes a file.

The table below is a selection, made by NHI Mgmt Group, of the inferred techniques where rebuilding a file in transit genuinely changes the outcome. Each ID was checked against ATT&CK v20. D3FEND's list also includes Impair Defenses entries that ATT&CK v20 has revoked; the v20 successors include T1685 Disable or Modify Tools, which content rebuild does not affect.

Read the last two rows as a warning about inferred mappings: D3FEND relates them through the File artefact, but rebuilding inbound files does not stop an attacker already on a host from collecting or staging local data. For the defensive detail on those techniques, see MITRE ATT&CK T1005 Data from Local System and T1074 Data Staged. The initial access path is covered in MITRE ATT&CK T1566 Phishing and T1204 User Execution.

Where it is implemented

Deployment steps

1. Map entry points and file mix. List every way untrusted files arrive and sample a month of traffic per channel: file types, sizes, archive nesting depth and the share of encrypted or password-protected files. This sample becomes the test corpus.
2. Write the content policy per channel. For each file type decide what may survive: macros, embedded objects, external links, form actions, hidden text, comments, metadata. D3FEND's Content Policy artefact is this decision, written down.
3. Define outcomes for files that cannot be rebuilt. Encrypted archives, signed documents, malformed files and unsupported types need a fixed outcome: block, quarantine (Content Quarantine, D3-CQ, is the D3FEND technique), release on request, or deliver with a warning.
4. Run in report-only mode first. Where the product allows, log what would be removed without changing delivery. Review the log with the business owners of affected workflows, such as finance workbooks with macros or signed contracts.
5. Pilot with one channel and one group. Turn on rebuilding for inbound email to a pilot group, measure fidelity complaints and release requests for two to four weeks, then widen.
6. Add verification after rebuild. Check that the output is well formed and contains no forbidden element. In high-assurance designs this is a separate component; in commercial deployments it is often a second scan of the rebuilt file.
7. Plan rollback. Keep originals in a protected store for a defined period so a broken rebuild can be reversed by releasing the original after review, and keep a per-channel switch to fall back to scan-and-block if the engine fails.

How to verify it works

A rebuild engine that silently passes files through looks the same as one that rebuilds them. Testing needs harmless samples with known structure.

• Known-structure test files: build a corpus of benign files that each contain one feature policy should remove: a document with a harmless macro, a PDF with a JavaScript action that only shows a message, a document with an external template reference, a file with data appended after its end marker, an image with location metadata. Send each through every channel and inspect the output structure.
• Byte-level difference: the hash of every rebuilt file should differ from the original. Identical hashes on supported types mean the file was passed through, not rebuilt.
• Fidelity checks: open the rebuilt files in the applications users rely on and confirm text, tables, formulas and images are intact. Poor fidelity drives users to personal email and file sharing, which bypasses the control.
• Bypass checks: send the same samples inside an archive, inside a password-protected archive and as an embedded object inside another document, and confirm the nested content is handled or the policy outcome applies. The NCSC content-based attack protection principle asks for nested content to be expanded, transformed and verified the same way as the outer file.
• Verification alerts: confirm a deliberately malformed file produces an alert rather than a silent drop.

Limits, bypasses and failure patterns

• The rebuild engine is an attack surface. It parses hostile input by design. The NCSC pattern says the transformation engine "could itself be vulnerable to attack" and places it on the untrusted side; patch the engine promptly and run it with least privilege and resource limits.
• Encrypted content passes untouched. A password-protected archive cannot be rebuilt without the password, and attackers often put the password in the email body. Decide the outcome explicitly; the default should not be silent delivery.
• Unsupported formats fall through. A product that rebuilds Office and PDF but not disk images, scripts, CAD files or less common archive formats leaves those paths open. Pair rebuild with file type allowlisting and D3-FFV File Format Verification.
• Links are content, not structure. A rebuilt document can still carry a perfectly valid hyperlink to a credential phishing page unless the policy rewrites or removes links. That is a substitution decision, not a rebuild one.
• Release workflows reopen the gap. If users can release originals without review, the control becomes advisory. Restrict release rights and log every release.
• Coverage stops at the channels you instrument. Files that arrive by personal webmail, unmanaged cloud storage or USB do not pass the rebuild point. The Office Macro Blocking Guide covers the endpoint control that still applies.

Framework mapping

Related countermeasures

• Content Substitution (D3-CNS): replaces a non-compliant element with a safe alternative instead of dropping it; see D3-CNS Content Substitution.
• Content Excision (D3-CNE) and Content Format Conversion (D3-CFC): the other two Content Modification children, for removing parts or flattening to a simpler format.
• Content Quarantine (D3-CQ) and Content Validation (D3-CV): Content Filtering siblings for files that fail policy or need checking before release.
• Analysis techniques: D3-FCOA File Content Analysis and D3-DA Dynamic Analysis detect what rebuilding may miss. The wider model is in the MITRE D3FEND Guide.

Practitioner checklist

• Inventory every inbound file channel and its real file mix before choosing where to rebuild.
• Write a per-channel content policy covering macros, embedded objects, links, hidden content and metadata.
• Set a fixed outcome for encrypted, signed, malformed and unsupported files.
• Start in report-only mode, then pilot one channel and one group.
• Verify rebuilt output separately and alert on every verification failure.
• Run a monthly corpus of harmless known-structure files through every channel and check hashes changed.
• Test nested and password-protected content, not only top-level files.
• Restrict and log release of originals.
• Patch the rebuild engine promptly and run it with least privilege and resource limits.

Standards and references

• MITRE D3FEND: Content Rebuild (D3-CNR)
• OPSWAT, Inc.: Method For Content Disarm and Reconstruction (US20190268352A1)
• NCSC: Pattern for safely importing data
• NCSC: Cross domain solutions, content based attack protection
• OWASP: File Upload Cheat Sheet
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• MITRE ATT&CK: T1566.001 Spearphishing Attachment

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