Why do RTF-based exploit chains often work more reliably than DOCX-based payloads?

RTF can be more reliable because embedded object handling and preview-pane behavior may execute or render the payload without requiring full document interaction. In the article’s example, the RTF variant was designed to carry the exploit across many Windows versions, while the DOCX path was less consistent. That difference comes from how each format stores and activates embedded objects.

Why the file format changes exploit reliability

RTF and DOCX do not behave the same way at the parsing layer, so an exploit chain that depends on object activation, preview rendering, or embedded content can become more reliable in one format than the other. The difference is not just cosmetic. It changes how much user interaction is needed, which code paths are reached, and how consistently the payload survives across Microsoft Office versions and Windows builds.

RTF is older and more permissive in the way it represents embedded objects and document structure, so some exploit chains can trigger useful behavior earlier in the open or preview process. DOCX is XML-based and typically goes through a different set of validation and rendering steps, which can make timing, object handling, or activation less predictable. In practice, that means the same underlying bug may be easier to operationalise in RTF than in DOCX.

That reliability gap matters most when the chain depends on a specific parser quirk, legacy object model behaviour, or a preview-pane workflow. If the exploit needs a precise sequence of render, unwrap, and execute steps, the format that reaches those steps with fewer dependencies will usually be the more dependable delivery vehicle.

What RTF tends to preserve that DOCX can disrupt

RTF often preserves embedded objects, references, and formatting constructs in a way that aligns well with parser confusion and object activation bugs. That makes it useful when the attacker wants the document to do as little as possible before the vulnerable path is hit. DOCX, by contrast, can force the content through a more structured package and XML processing path, which may alter when or whether the malicious object is exposed to the vulnerable component.

In the example described in the source article, the RTF variant was built to travel across many Windows versions with a consistent object activation path. The DOCX path was less consistent because different versions and viewing contexts handled the payload differently. That is why exploit developers often prefer the format that is least likely to change the target’s parsing behaviour.

Reliability also depends on whether the exploit is meant to work when a user only previews the message or document. If the payload can be reached through a preview pane or partial rendering, the attacker gains a broader set of success conditions than if full document opening is required. RTF has historically been easier to abuse in those semi-automatic paths.

Why exploit developers still test both formats

Attackers often keep both RTF and DOCX versions in testing because the best format depends on the exact vulnerability, the target application build, and the security controls in place. A chain that is stable in one format may fail in another if the underlying object is rewritten, sanitised, or delayed by the container format. The most reliable payload is the one that matches the target’s document handling behaviour, not the one that looks cleaner on paper.

When reliability matters more than appearance, exploit writers tend to choose the format that creates the fewest moving parts between delivery and code execution. That usually means fewer assumptions about user clicks, fewer dependencies on optional features, and fewer opportunities for Office or Windows to normalise the content before the vulnerable code runs.

Risk and Threat Considerations

Document-based exploit chains are attractive because they can blend into everyday file exchange, and the most reliable ones are usually the ones that trigger during preview or on minimal interaction. The danger is not only initial compromise, but also the fact that a format difference can determine whether a campaign works at scale or fails intermittently across versions and viewing modes.

Failure mechanism: RTF can expose embedded objects or legacy rendering paths earlier and more consistently than DOCX, which lets a malformed object or parser bug reach the vulnerable code path with less user interaction and less format transformation.

Impact: A more reliable file format increases exploit success rates, broadens the set of vulnerable recipients, and makes detection harder because the malicious content may activate before a user meaningfully opens the document.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1203 — Exploitation for Client Execution	The question is about document-delivered exploit chains reaching code execution via client parsing.
Recommendation — Map document-triggered execution paths to client-execution techniques and harden the affected viewers.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Reliable exploit chains exploit unpatched client and document-rendering flaws.
Recommendation — Prioritise remediation for document parser and viewer vulnerabilities that enable active exploit chains.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	Document formats rely on parser behaviour, so robust input handling is central to the risk.
	SI-3 — Malicious Code Protection	The payload is delivered through a document and should be inspected and blocked at ingress.
Recommendation — Validate and constrain untrusted document content before it reaches rendering or processing components. Scan and block malicious document content before it can be opened or previewed.
OWASP ASVS	V5 — File Handling	The subject concerns how document containers carry malicious embedded content.
Recommendation — Apply strict file handling checks to untrusted documents and reject risky embedded content.

Practitioner Guidance

What to verify: Treat format as part of the exploit path, not a packaging detail. Validate how your document viewer, mail client, and preview pane handle embedded objects across supported Office and Windows versions, because reliability often depends on those exact code paths.

Decision rule: If your environment allows preview-based rendering of untrusted documents, assume an attacker will test the most permissive format path first. Prioritise controls that reduce automatic content activation, not just controls that block obvious malicious attachments.

Practitioner takeaway: The format that is easiest for the parser to reach is often the format that is easiest for the attacker to weaponise, so defensive testing should focus on document handling behaviour, not file extension alone.