D3-CNE Content Excision: Stripping Macros, Scripts and Embedded Objects From Files Safely

Most malicious documents need one hidden part to do harm, a macro, a script, an embedded object or a launch action, and removing that part while keeping the rest usable stops the attack without blocking the business. MITRE D3FEND names this countermeasure Content Excision (D3-CNE) and defines it as "Removing specific, potentially malicious, parts of content". It sits under the Isolate tactic as a child of Content Modification (D3-CM), which itself sits under Content Filtering (D3-CF), alongside Content Format Conversion, Content Rebuild and Content Substitution. This card covers what excision removes in common file formats, how D3FEND relates it to ATT&CK, where it is deployed, how to prove it works, and where it breaks. It is written for email and web security engineers, application teams that accept file uploads, and security architects designing content disarm and reconstruction (CDR) pipelines.

Key takeaways

• Excision is surgical. It removes only the parts that break policy and keeps the file in its original format, which makes it more acceptable to users than blocking or flattening.
• Decide per item, not per file. D3FEND's reference, an OPSWAT CDR patent application, judges each item on risk, visibility to the user and whether the file structure needs it, then keeps, removes or modifies it.
• D3FEND links it to 15 ATT&CK techniques through the File artefact. These include Data from Local System (T1005), File Deletion (T1070.004) and Spearphishing via Service (T1566.003); all are inferred relations, not proof of coverage.
• Removing is harder than it looks. Formats such as PDF keep old content after an edit unless the file is rewritten, so excision must rebuild the output rather than patch it.
• Verify the output, not the engine. Run a strict check after excision that confirms no active content remains, and alert on any failure, as the NCSC's safe import pattern recommends.

D3-CNE at a glance

How it works

Excision has four stages: parse the file into its parts, classify each part against a content policy, remove the parts that fail, and write a new, valid file from what remains. The D3FEND reference patent describes this for compound (OLE structured storage) files: the engine breaks the file into storages and streams, assesses each item in each stream, processes it, and reassembles a file with the same format as the input.

The patent's decision logic is a useful model for any excision policy. Each item is judged on three criteria:

• Acceptability of unwanted behaviour: unacceptable, acceptable or unknown risk.
• Visibility: whether the user perceives the item. Images are visible, macros are hidden, fonts are partly visible.
• Necessity: whether the file structure depends on it. A header is mandatory; a hyperlink is not.

Hidden, non-mandatory items with unacceptable or unknown risk are removed. Unacceptable items that are visible or mandatory are modified instead (for example stripping metadata or embedded objects, or re-saving an image), which is where excision hands over to its sibling techniques. Low-risk visible items are kept.

What is typically excised

Where identity fits

Metadata excision is also a data protection control. Document properties, tracked changes, comments and embedded file paths can expose user names, internal host names and sometimes connection strings or tokens left in embedded objects. Excising them from outbound documents reduces what an attacker can learn for credential and service account targeting; leaked secrets in files map to Credentials In Files (T1552.001), one of the techniques D3FEND relates to this countermeasure.

ATT&CK techniques D3FEND relates to D3-CNE

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

D3FEND derives these rows because each ATT&CK technique acts on a File (accesses, creates, adds, modifies, deletes, encrypts or produces one). D3FEND's page for the technique also shows a much longer list inferred through sub-artefacts of File, such as Office Application File (VBA Stomping, T1564.007) and Executable File (Malicious File, T1204.002); those two are the most practically relevant to excision and are shown at the end. All IDs were checked against ATT&CK v20. The relevance column is NHI Mgmt Group's view.

Most of the 15 same-artefact rows are weak for this countermeasure because D3FEND infers them from any action on a file. Phishing attachments, the main use case in practice, are related in D3FEND through the Email artefact rather than File; see the MITRE ATT&CK T1566 Phishing and T1204 User Execution pages.

Where it is implemented

Product category selection is covered in the Content Disarm and Reconstruction buyer's guide and upload handling in the Secure File Upload Handling Guide.

Implementation steps

1. Write the content policy first. For each file type you accept, list which parts are allowed, removed or cause a block. Typical first policy: remove macros, ActiveX, embedded executables, PDF JavaScript and launch actions; keep text, images and tables; block password-protected archives you cannot inspect.
2. Identify legitimate exceptions. Finance models with macros, signed PDF forms and engineering files with embedded objects will break. Agree a release path (sender allowlist, signed macros, a request workflow) before enforcement.
3. Run in monitor mode. Log what would be removed for two to four weeks without changing files. Review the counts per item type and per sender to find business processes the policy would break.
4. Enforce for a pilot group. Turn on excision for one department, keep the original files in a quarantine store for a defined period, and give users a clear notice in the file or the message that content was removed.
5. Add output verification. After excision, re-scan the output with a strict validator that confirms no active parts remain and that the file opens. Alert on any verification failure, since it means the engine missed something.
6. Widen enforcement. Extend to all users and channels (email, web, uploads, file transfer) in stages, measuring helpdesk tickets and release requests at each stage.
7. Roll back. Keep the ability to switch a channel back to monitor mode and to release originals from quarantine, so a broken business process can be restored within hours.

How to verify it works

• Benign test corpus: keep a set of harmless files that contain each item your policy removes (a macro that only shows a message box, a PDF with a JavaScript alert, an embedded OLE object, metadata with a test author). Send them through each channel monthly and confirm the output no longer contains them.
• Structure inspection: open outputs with a format inspection tool and confirm the removed parts are absent from the file structure, not just hidden. For PDF, confirm there are no earlier revisions carrying the removed objects.
• Usability check: confirm outputs open in the applications users have, with layout intact.
• Bypass attempts: include renamed extensions, nested archives and unusual encodings in authorised tests to confirm the engine identifies true types and enforces depth limits.

Limits, bypasses and failure patterns

• Patching instead of rewriting: deleting an object reference but leaving the object bytes in the file, or appending a PDF revision, leaves the content recoverable. ExifTool's documentation notes, for example, that its PDF edits are reversible because original data is never removed from the file. Excision output must be a fresh, rewritten file.
• Unsupported and encrypted files passed through: engines that cannot parse a type often pass it unchanged by default. Decide explicitly whether unsupported means block.
• The parser as an attack surface: the excision engine parses hostile files. The NCSC safe import pattern assumes the transformation engine could be compromised; run it isolated, patched and with resource limits.
• Removing too little: a policy that strips macros but keeps external template links or remote images still lets a document call out to an attacker's server.
• Removing too much without a release path: users who lose working spreadsheets will move files through personal email or cloud storage, which removes the control entirely.
• Treating excision as malware detection: excision does not tell you a file was malicious. Keep scanning and reputation checks alongside it; see D3-FHRA File Hash Reputation Analysis.

Framework mapping

Related countermeasures

• Content Modification (D3-CM): the parent technique. See D3-CM Content Modification.
• Content Format Conversion (D3-CFC): converts the whole file to a safer format instead of removing parts. See D3-CFC Content Format Conversion.
• Content Rebuild (D3-CNR) and Content Substitution (D3-CNS): rebuild the file to its specification, or replace parts with safe alternatives instead of deleting them.
• Content Validation (D3-CV) and Content Quarantine (D3-CQ): check that content conforms before or after excision, and hold what cannot be made safe. See D3-CV Content Validation and D3-CQ Content Quarantine.

Practitioner checklist

• Write a per-file-type content policy: allowed, removed, blocked.
• Agree release paths for legitimate macros and embedded content before enforcing.
• Run monitor mode first and review removal counts by item type and sender.
• Require rewritten output files, never in-place edits or appended revisions.
• Decide explicitly how unsupported, encrypted and oversized files are handled.
• Verify every output with a strict validator and alert on failures.
• Run the excision engine isolated, patched and with resource and nesting limits.
• Keep originals in quarantine for a defined period with an audited release process.
• Test each channel monthly with a benign corpus and record the result.

Standards and references

• MITRE D3FEND: Content Excision (D3-CNE)
• OPSWAT Inc.: Method For Content Disarm and Reconstruction, US20190268352A1
• NCSC: Pattern: safely importing data
• OWASP: File Upload Cheat Sheet
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-3, SC-18)
• MITRE ATT&CK: T1564.007 VBA Stomping
• ExifTool: application documentation

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