When the document is opened, Microsoft Office can contact the attacker controlled server, retrieve remote HTML content, and pass execution into MSDT. If the exploit succeeds, the attacker’s payload runs on the endpoint, which is why the article describes the attack as a reliable remote code execution path rather than a simple document parsing flaw.
Why a Follina lure is dangerous even before payload execution
A malicious Follina document is dangerous because the document is not the real payload, it is the delivery trigger. The initial office file can reach out to a remote server, pull attacker-controlled content, and hand execution into a trusted Windows component, which means defenders are dealing with a chain that crosses application, network, and operating-system trust boundaries. That makes detection and containment harder than a simple malformed file event, especially when user interaction appears mundane. In practice, many security teams encounter the compromise only after endpoint telemetry already shows trusted processes behaving in an untrusted way.
The security issue is not limited to the exploit mechanics themselves. Once Office is used as the launch path, the attack can inherit the user's context, bypass some file reputation assumptions, and create a high-confidence execution path without requiring macro abuse in the usual sense. For that reason, organisations should treat suspicious Office documents as an execution risk, not just a content-safety problem.
How the exploit chain behaves on a Windows endpoint
Follina-style abuse works by blending document handling with remote content retrieval and built-in Windows diagnostic behavior. The important detail is that the document can cause Office to make an outbound request, which gives the attacker a chance to control the next stage of the chain. If the response is crafted correctly, the endpoint is steered into MSDT, and the attacker’s code can run without the victim having to install anything manually.
This matters operationally because the observable sequence often looks like normal application activity until the handoff occurs. Security teams should think in terms of stages:
- The document is opened and Office begins processing embedded or referenced content.
- Office reaches out to a remote location controlled by the attacker.
- Remote HTML or script content is retrieved and used to shape execution.
- MSDT is invoked as part of the abuse chain.
- The endpoint executes attacker logic in the victim context if the exploit succeeds.
That chain also explains why blocking a single indicator is often insufficient. A copied file name, a different hosting location, or a minor variation in payload delivery can preserve the core abuse pattern. Defenders should therefore monitor for the combination of Office-originated network activity, unexpected child processes, and suspicious launches of Windows troubleshooting components. Guidance from the OWASP Non-Human Identity Top 10 is not directly about this exploit, so it does not materially improve the answer here and is not necessary to understand the attack path.
Where this guidance breaks down is in heavily customised environments where endpoint controls suppress one stage of the chain but not the others, leaving only partial telemetry and making the abuse path look fragmented rather than continuous.
Common variations and edge cases in Follina-style abuse
Tighter endpoint hardening often reduces exploit reliability, but it also increases operational complexity when legitimate Office integrations and troubleshooting workflows depend on the same Windows behaviors. Organisations have to balance the value of blocking a known abuse path against the possibility of breaking approved support tooling or legacy document workflows.
One common edge case is that the document itself may look low risk, with no macros and no obvious embedded binary, yet still trigger remote content retrieval. Another is that defenders may focus too narrowly on the payload and miss the earlier network and process signals that reveal the exploit attempt. There is also a practical distinction between a fully successful compromise and a failed attempt: failed attempts can still be valuable detection opportunities if the control plane records the Office process, the outbound request, and the attempted invocation of troubleshooting components.
Consensus is strong that this should be treated as a remote code execution class event, but teams sometimes differ on whether to prioritise document filtering or endpoint hardening first. The better answer is usually both, with emphasis depending on where the organisation has the most exposure.
Risk and Threat Considerations
The material risk is endpoint compromise through trusted-document abuse. A malicious Follina file turns a user opening a document into an execution path that can bypass normal caution around file inspection, because the harmful action happens after the initial document interaction and through trusted Windows components.
Failure mechanism: The exploit leverages remote content retrieval and a trusted handoff into MSDT, so defensive controls that only inspect static document content may miss the actual execution stage.
Impact: If successful, the attacker gains code execution on the Windows endpoint, which can lead to credential theft, malware deployment, lateral movement, and broader environment compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1203 — Exploitation for Client Execution | Follina uses document interaction to drive code execution on the endpoint. |
| T1105 — Ingress Tool Transfer | The lure retrieves attacker-controlled remote content before execution. | |
| T1218 — System Binary Proxy Execution | The exploit abuses a trusted Windows component to execute attacker logic. | |
| Recommendation — Map the abuse chain to T1203 and hunt for client-side execution telemetry. Correlate remote content retrieval with the initial document-open event. Detect unexpected trusted-binary launches from Office and isolate the host. | ||
| CIS Controls v8 | 8 — Audit Log Management | Office-to-network and process telemetry are key to spotting the abuse chain. |
| 10 — Malware Defenses | The attack is delivered through a malicious document and follow-on payload. | |
| Recommendation — Centralise endpoint and proxy logs so Office-triggered execution paths are reviewable. Block known malicious document patterns and detonate suspicious Office files. | ||
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | Detection depends on correlating file, process, and network activity. |
| Recommendation — Correlate endpoint and network events to detect document-driven execution chains. | ||
Practitioner Guidance
What to prioritise: Treat Office-originated outbound traffic and suspicious child processes as the first containment signals, not just the document hash or email source. That is the most reliable way to catch the chain while it is still unfolding.
What to verify: Confirm whether the endpoint actually executed a trusted Windows troubleshooting path, whether the user context had access to sensitive data, and whether the same lure reached multiple users or systems. If those conditions are present, the issue is no longer isolated to a single workstation.
Common mistake: Teams often assume that removing the file is enough after the fact, but the real question is whether the execution chain already created persistence, staged follow-on payloads, or exposed credentials. The file is the trigger; the compromise may already be wider.
Practitioner takeaway: The key judgement is to investigate Follina as a process-and-network abuse chain, because the security value lies in interrupting the handoff between document opening and endpoint execution.
Related resources from NHI Mgmt Group
- What happens when BlackCat ransomware is executed on a Windows endpoint without recovery controls?
- What happens when ransomware deletes shadow copies and system state backups on a Windows endpoint?
- What happens when a malicious file is identified through threat intelligence and an active response removes it from the endpoint?
- What happens when a malicious 3MF model is opened in an affected slicer?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
