When the file is opened, or sometimes previewed in an email pane, the embedded content can trigger the vulnerability before the user realises it is malicious. The attacker may then execute arbitrary code on the victim system, causing a crash or gaining control of the affected machine. That makes attachment handling and preview behaviour part of the attack surface.
What makes a malicious RTF file dangerous in Word or Outlook?
RTF is not just text, it can carry embedded objects, scripts, links, and parser edge cases that the application must interpret safely. The danger comes from the document parser or rendering path itself, not from the visible content alone. If Word or Outlook processes a malformed or weaponised construct, the application can be forced into a crash or memory corruption before the user recognises the file as hostile.
In practice, the risk is highest when the file is handled by a rich-content path that auto-processes preview, indexing, or rendering features. That is why a file can be risky even when it is never fully opened in the classic sense, because the preview or mail-rendering pipeline may still invoke the vulnerable code path.
How does the attack usually execute?
Attackers typically rely on exploit delivery through a crafted document that triggers a parser weakness, an embedded object, or a malicious reference during rendering. The user interaction can be as small as selecting the message or letting the preview pane load the attachment, which may be enough to reach the vulnerable component. If exploitation succeeds, the attacker can move from document handling to code execution on the endpoint.
The exact outcome depends on the flaw being exploited. Some cases end in denial of service, while others produce memory corruption that can be turned into arbitrary code execution. In a successful exploitation chain, the attachment is only the entry point, and the real impact is whatever the delivered code can do with the user's process or session context.
For the underlying exploit path, MITRE ATT&CK Enterprise Matrix is useful for mapping how document-based payloads lead into execution, credential access, or lateral movement after the initial trigger.
What should practitioners watch for in email and document handling?
Focus on where rich-content processing happens, because that is where the risk becomes material. Preview panes, embedded object handling, and automatic content rendering are all part of the exposure window, especially when users routinely receive attachments from outside the organisation. A malicious file does not need to look obviously dangerous to be effective if the application interprets it before filtering or sandboxing can intervene.
Hardening the document path matters as much as patching the application. Disable or restrict preview behaviour where business use allows it, enforce attachment filtering, and make sure Office and mail clients are kept current so known parser flaws are closed quickly. The important operational question is whether the environment can stop a hostile file before it reaches a code path that can be abused.
For control design around file handling, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the relevant access control, integrity, and configuration management families that support safer attachment handling. For secure endpoint and email configuration, NIST Cybersecurity Framework 2.0 helps organise protect, detect, and recover actions around this exposure.
Risk and Threat Considerations
Malicious RTF files are dangerous because they turn ordinary document processing into an execution path. The main security concern is not the file format itself, but the fact that a parser weakness or unsafe rendering behaviour can give an attacker code execution through a trusted desktop application.
Failure mechanism: A crafted RTF document abuses a vulnerable parsing, preview, or rendering component, causing memory corruption, process crash, or execution of attacker-controlled code.
Impact: The attacker may gain control of the affected workstation, steal data available to the user session, or use the compromised system as a foothold for further access.
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 NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1204 — User Execution | RTF exploits often depend on user or preview-triggered document handling. |
| Recommendation — Map document-triggered execution paths to T1204 and monitor email-to-process launch chains. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Malicious attachments need filtering and detonation controls before execution occurs. |
| CM-7 — Least Functionality | Limiting preview and rich-content features reduces the exposed attack surface. | |
| Recommendation — Apply SI-3 to scan, block, or sandbox risky attachment content before delivery. Use CM-7 to disable unnecessary preview and content-processing features for untrusted mail. | ||
| NIST CSF 2.0 | PR.PS-04 — Adequate Capacity and Performance | Client protections and filtering must remain effective under normal user mail flow. |
| PR.AA-05 — Least Privilege | Code execution impact depends on the privileges of the user context that opens the file. | |
| Recommendation — Ensure protective mail and endpoint controls stay enabled and performant for all users. Limit user privileges so attachment exploitation yields the smallest possible blast radius. | ||
Practitioner Guidance
What to verify: Confirm whether your mail client and Office deployment actually expose preview, protected view, and embedded-object rendering paths to untrusted attachments. If those paths are enabled, treat them as part of the attack surface and validate that patches and exploit mitigations are current.
Common mistake: Teams often focus on whether users "opened" the file, but preview panes and background rendering can be enough to trigger the vulnerable code path. The control decision should be based on how the client processes content, not on whether the user double-clicked the attachment.
Practitioner takeaway: The key judgement is to treat RTF handling as a client-side code-execution risk, not a simple file-safety issue, and to harden the preview and rendering paths that attackers can reach first.
Related resources from NHI Mgmt Group
- What happens when a malicious .jar file is opened on a Mac without native Java installed?
- What happens after a malicious archive and shortcut file are opened in a multi-stage intrusion chain?
- How should teams reduce risk from malicious npm package installs?
- What happens when a malicious file is identified through threat intelligence and an active response removes it from the endpoint?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
