Blocking every file that fails a content check stops work; letting it through unchanged lets the payload through too, and Content Modification is the middle path. MITRE D3FEND defines Content Modification (D3-CM) as "Modify content that does not comply with policy." It sits under the Isolate tactic as a child of Content Filtering (D3-CF), and it is itself the parent of four narrower techniques: Content Excision, Content Format Conversion, Content Rebuild and Content Substitution. In practice this is the family that content disarm and reconstruction (CDR) products, image re-encoding in upload pipelines and document flattening belong to. This card covers what D3FEND says, which ATT&CK techniques it relates, where modification is deployed, how to prove it works and where it fails. Buying criteria are in the Content Disarm and Reconstruction buyer's guide; this page stays on the countermeasure.
Key takeaways
- Modification assumes detection is incomplete. Instead of deciding whether a file is malicious, it rewrites the file into a form the content policy allows, so unknown payloads in removed parts go with them.
- It is a family, not one action. D3FEND splits it into removing parts (excision), converting format, rebuilding to the specification and substituting parts; most real pipelines chain several.
- The policy decides the outcome. D3FEND ties the technique to a Content Policy artefact: what counts as non-compliant (macros, scripts, embedded files, metadata) is a business decision you must write down.
- The rewriting engine is attack surface. It parses hostile content by design, so it needs patching, isolation and monitoring like any exposed service.
- Keep the original, but out of reach. Users will need the unmodified file sometimes; a controlled release path, not a bypass, is what keeps the control in place.
D3-CM at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-CM (d3f:ContentModification) |
| Definition | "Modify content that does not comply with policy." |
| Tactic | Isolate (through the parent Content Filtering) |
| Parent technique | Content Filtering (D3-CF) |
| Child techniques | Content Excision (D3-CNE), Content Format Conversion (D3-CFC), Content Rebuild (D3-CNR, synonym Content Reconstruction), Content Substitution (D3-CNS) |
| Digital artefacts | Modifies File; filters Digital Media, File Content Block and File Metadata; enforces Content Policy (inherited) |
| D3FEND reference | OPSWAT patent application US20190268352A1, "Method For Content Disarm and Reconstruction" |
| Siblings under Content Filtering | Content Quarantine (D3-CQ), Content Validation (D3-CV) |
How it works
D3FEND's description is short: when content is found not to comply with its content policy, it may be transformed to a safer state by modifying it. The cited patent describes the mechanism behind most CDR engines. The engine takes a file with a structured storage format, disassembles it into stream subfiles, identifies each item, judges whether the item shows unwanted behaviour, whether it is visible to the user and whether it is needed, processes the item on that basis, and reassembles an output file in the same format as the input.
The UK NCSC's Safely Importing Data pattern describes the same idea at architecture level: transformation turns complex formats, such as office documents with thousands of interrelated objects, into simpler ones, can remove active content such as macros and scripts, and the result can be rebuilt into the original or a different format for the recipient. The NCSC treats the transformation engine as likely to be compromised because it handles untrusted content, and puts a separate, strict verification step after it.
The four child techniques
| Technique | D3FEND definition (summarised) | Typical implementation |
|---|---|---|
| Content Excision (D3-CNE) | Removing specific, potentially malicious, parts of content | Strip macros, JavaScript in PDFs, embedded OLE objects, external links and hidden data |
| Content Format Conversion (D3-CFC) | Mechanical transformation from one format to another, which may be normalisation or flattening | Office document to PDF, PDF to image, macro-enabled to macro-free format, rich text to plain text |
| Content Rebuild (D3-CNR) | Rebuild the file according to the specification so unreferenced components or objects are removed | Parse and re-emit the file from known-good objects only, dropping anything the structure does not reference |
| Content Substitution (D3-CNS) | Replacing specific content with something else | Replace a hyperlink with a rewritten safe link, an embedded object with a placeholder, a macro with a notice |
Detail on the first two is in D3-CNE Content Excision and D3-CFC Content Format Conversion.
ATT&CK techniques D3FEND relates to D3-CM
Relationship type: inferred only. D3FEND derives these rows from shared digital artefacts, chiefly File: the ATT&CK technique involves a File and D3-CM modifies or filters File content. D3FEND labels these relations "inferred, experimental" (D3FEND 1.6.0, checked November 2026), and the same list appears for its siblings under Content Filtering. A row does not mean modification stops the technique. Each ID 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, T1072 Software Deployment Tools, 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 Invalid Code Signature, T1036.003 Rename Legitimate Utilities, T1036.005 Match Legitimate Resource Name or Location, T1036.006 Space after Filename; 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 |
| Discovery and Collection | T1083 File and Directory Discovery, T1005 Data from Local System, T1119 Automated 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.
Where modification genuinely bites (NHI Mgmt Group view): delivery. Spearphishing attachments (T1566.001), malicious files the user opens (T1204.002) and Office template macros (T1137.001) all rely on active content surviving the journey to the user, and excision or conversion removes it. Masquerading tricks such as T1036.006 Space after Filename fail when the output is regenerated with a type-correct name. Most host-side rows, such as credential dumping or log clearing, are artefact overlaps rather than real coverage. Defensive context for the delivery techniques is in MITRE ATT&CK T1566 Phishing and T1204 User Execution.
Where it is implemented
| Placement | What gets modified | Practical note |
|---|---|---|
| Email security gateways and cloud mail filtering | Attachments before delivery; links rewritten | Decide whether the user receives only the modified file or can request the original. See the Email Security Guide |
| Secure web gateways and browser isolation | Downloads rewritten or converted on the way in | Encrypted traffic must be inspected for the gateway to see the file. See the Secure Web Gateway and Web Filtering Guide |
| Application upload pipelines | Images decoded and re-encoded, documents passed through CDR, metadata stripped | The OWASP File Upload Cheat Sheet recommends image rewriting and CDR for supported document types. See the Secure File Upload Handling Guide |
| Cross domain and data import gateways | Complex formats transformed to simple ones, then verified on the trusted side | The NCSC pattern places transformation before the protocol break and verification after it |
| Removable media kiosks and file transfer services | Files from USB or partner transfers sanitised before entering the network | Treat the kiosk as untrusted and keep it separate from internal management |
Choosing what to remove
- Active content: macros, scripts, embedded executables and OLE objects. Removing them is the core of the control and breaks very little for most users.
- External references: remote templates, linked images and auto-loading URLs. Removal stops callbacks and template injection.
- Metadata: author names, paths and revision history. Stripping protects outbound privacy as much as inbound safety.
- Formatting fidelity: conversion to PDF or image is safest but loses editing. Offer it to groups that only need to read.
Where some users really need macros, keep modification on for everyone else and handle the exception through a controlled release from quarantine, as described in D3-CQ Content Quarantine, not by turning the control off for a mailbox or a domain.
Rolling it out
- Write the content policy. List file types accepted, what is removed from each and which types are converted. The policy is the artefact D3FEND says the technique enforces.
- Inventory the traffic. Measure which file types and how many macro-enabled or script-bearing files arrive through each channel today.
- Pilot in report mode where the product allows it. Log what would be removed without changing files, and review with the business teams that receive most documents.
- Enforce for one channel and one group. Start with inbound email for a pilot ring, keep originals in a protected store and publish how to request one.
- Add verification after modification. Check output files against the expected format, as in D3-CV Content Validation, so a failing transformation is noticed.
- Extend channels. Web downloads, upload services and file transfer.
- Roll back cleanly. If a format breaks a business process, move that one type to quarantine-and-review rather than to pass-through, fix the policy and re-enable.
How to verify it works
- Known active-content samples: send safe test documents containing a harmless macro, an embedded object, a PDF with a JavaScript action and a remote template reference through each channel. Confirm each element is gone in the delivered file and logged.
- Fidelity checks: open modified files from a sample of real business documents and confirm they remain usable.
- Nested content: test an archive containing a document containing an embedded file. The NCSC pattern says nested content should be unpacked, transformed and verified, with limits on nesting depth.
- Failure path: submit a malformed or encrypted file and confirm it is quarantined or rejected, not passed through untouched.
- Engine alerts: confirm transformation errors and verification failures reach the SOC. The NCSC notes a verification failure after correct transformation suggests the transformer has malfunctioned or been compromised.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Files in scope that passed through modification | Close to 100% per channel | Shows no bypass route exists |
| Files passed through unmodified because they could not be processed | Zero; such files quarantined instead | Unprocessable files are the obvious evasion route |
| Requests for originals per 1,000 modified files | Tracked by business unit | High rates show the policy is too strict for that group |
| Test documents with active content left in after modification | Zero in monthly tests | Direct proof the control works |
| Engine version lag behind vendor release | Within your patch window for internet-facing services | The engine parses hostile content |
Limits, bypasses and failure patterns
- Encrypted and password-protected files: the engine cannot open them. If policy lets them through unmodified, attackers will send passwords in the email body. Quarantine them instead.
- Unsupported formats passing through: every format the engine does not understand is a gap. Default to quarantine or block for unknown types.
- Payload in the visible content: modification removes active content, not a convincing lure or a link the user types in. Phishing awareness and link controls still apply.
- Bypass by request: if users can self-release originals without review, the control becomes a delay. Route releases through review for files that had active content.
- Engine compromise: parsers in transformation engines handle hostile input; the NCSC pattern assumes this component can be compromised and puts verification after it. Isolate, patch and monitor the engine. See T1027 Obfuscated Files or Information Defensive Guide for the obfuscation side.
- Outbound blind spot: modification is often configured inbound only. Metadata removal on outbound documents is a separate decision.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | Removing malicious code at entry points |
| NIST SP 800-53 Rev 5 | SI-10 Information Input Validation | Paired verification of modified content |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Placement at mail, web and import boundaries |
| NIST CSF 2.0 | PR.PS-05 | Preventing execution of unauthorised software such as macros and scripts |
| MITRE ATT&CK mitigations | M1049 Antivirus/Antimalware, M1021 Restrict Web-Based Content | Closest mitigations (NHI Mgmt Group view); see M1049 Antivirus/Antimalware and M1021 Restrict Web-Based Content |
| MITRE D3FEND | D3-CF, D3-CM, D3-CNE, D3-CFC, D3-CNR, D3-CNS | Parent, technique and children |
Practitioner checklist
- Write a content policy per channel: accepted types, removed elements, converted types.
- Default unprocessable, encrypted and unknown files to quarantine, never to pass-through.
- Verify modified output against the expected format and alert on failures.
- Keep originals in a protected store with a reviewed release path.
- Patch, isolate and monitor the transformation engine as an exposed service.
- Test monthly with safe active-content samples through every channel.
- Track original-file requests by team and tune the policy.
- Decide separately whether to strip metadata from outbound documents.
Standards and references
- MITRE D3FEND: Content Modification (D3-CM)
- OPSWAT: Method For Content Disarm and Reconstruction (US20190268352A1)
- NCSC: Pattern, Safely Importing Data
- NCSC: 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, D3-CQ Content Quarantine, D3-CV Content Validation, D3-FCOA File Content Analysis.