Why does Follina create meaningful risk for Windows and Office users?

Follina is risky because a crafted Word document can trigger Microsoft Office to retrieve remote content and launch MSDT, which can execute code on the target endpoint. That means a file opened by a user can become a code execution path without an obvious executable attachment, making it attractive for initial access and payload delivery.

Why a Word Document Can Become a Code Execution Path

Follina is not just a “malicious document” story. The risk comes from how ordinary Office content can be used to reach an operating-system tool that was not meant to be a document parser. That changes the trust boundary: a user opening a file is no longer dealing only with document content, but with remote retrieval, process launch, and potential code execution on the endpoint. For Windows and Office users, the practical problem is that the attack looks like routine productivity activity until the execution chain is already underway. Microsoft documents the underlying behavior in its security guidance for the issue.

Attackers value this because it reduces the need for obvious malware delivery and can help a payload blend into normal user workflows. In practice, many security teams encounter Follina-like abuse only after a document has already been opened and the endpoint has already begun executing an unexpected chain.

When the same document workflow can cross from Office into system-level execution, the impact is larger than a single file compromise. It creates a path for initial access, payload staging, and follow-on activity on a trusted workstation.

How the Exploit Chain Works in Practice

The mechanism is straightforward but dangerous. A crafted document can cause Office to fetch remote content, then invoke MSDT through a path that allows command execution on the local machine. The user does not need to run a separate installer or open a macro-enabled attachment in the classic sense. The document itself becomes the delivery vehicle for a chained action that ultimately runs with the context of the user or the launched process.

That matters operationally because defenders often model risk around obvious executable files, blocked macros, or suspicious archive attachments. Follina bypasses that mental model by using document rendering, remote content retrieval, and a trusted Windows diagnostic path. The result is an execution sequence that can start with what appears to be a normal document open event and end with arbitrary commands on the endpoint.

Office is used as the initial entry point because users trust it and routinely open its files.
Remote content retrieval introduces an external dependency that defenders may not immediately associate with the document itself.
MSDT provides the execution bridge, turning a document interaction into local command execution.
Once code runs, the attacker can stage additional tooling, steal data, or establish persistence depending on the environment.

This is why the issue is significant even where macro controls are strong. The exploit path does not rely only on classic macro abuse, so security teams need to think in terms of content-triggered execution chains, not just file type blocking. For general control planning, the NIST Cybersecurity Framework 2.0 offers a useful structure for aligning protection, detection, and response, especially where document abuse leads to endpoint compromise. The guidance breaks down where organisations treat Office documents as safe by default and fail to inspect how they can trigger external retrieval or system utilities.

Where the Risk Becomes Worse in Real Environments

Tighter document controls often improve safety but increase friction for business users, so organisations have to balance usability against the ability to stop chained execution. In practice, the risk is highest where users regularly receive external documents, endpoints are broadly trusted, and security tooling is tuned to look for standalone malware rather than living-off-the-land execution paths.

There are also important edge cases. A fully patched environment reduces exposure, but patching alone does not remove the broader lesson that document-triggered execution chains can exist outside the classic macro model. If a team only hunts for suspicious attachments, it may miss documents that look benign while still reaching risky system functionality. Conversely, overly aggressive blocking can disrupt legitimate Office workflows, so controls need to be proportionate and tested against actual user scenarios.

Guidance is clearer than consensus on one point: organisations should not assume that “no macro” means “no execution risk.” The more a workflow depends on remote document sources, the more valuable it is to validate what Office can invoke, what the endpoint allows, and what telemetry will confirm that an apparently harmless file started an abnormal process chain. The answer stops being simple where custom line-of-business add-ins, legacy Office versions, or incomplete application control create alternate paths that security teams have not mapped.

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	Office documents can trigger execution on the victim endpoint.
Recommendation — Map document-triggered execution paths to T1203 and hunt for exploit delivery via user-opened files.
CIS Controls v8	16 — Application Software Security	Follina exploits application behavior and unsafe content handling.
	8 — Audit Log Management	Detection depends on visibility into document-to-process chains.
Recommendation — Apply Control 16 to restrict risky document execution behavior and harden Office handling. Use Control 8 to retain endpoint and process logs that reveal document-driven execution.
NIST CSF 2.0	PR.IP-1 — Baseline Configuration	Reducing exposure requires hardened Office and endpoint baselines.
	DE.CM-1 — Networks and systems are monitored	Teams need monitoring for abnormal document-open and child-process activity.
Recommendation — Enforce hardened baselines to remove or constrain document-to-execution paths. Monitor for document-open events that spawn unexpected processes or outbound retrieval.

Practitioner Guidance

What to prioritise: Treat externally sourced Office documents as a process-execution risk, not only as a content-risk problem. The first question is whether your environment can prevent or detect document-driven launches of unexpected system utilities.

What to verify: Confirm that endpoint telemetry can show document open events, child processes, and any outbound retrieval that precedes execution. If you cannot reconstruct that chain, you will struggle to tell benign document activity from exploit activity.

Decision rule: If your users regularly exchange Word documents with outside parties, raise the control bar around document handling, attachment inspection, and endpoint hardening rather than relying on macro policy alone. If that workflow is rare, focused restriction may be easier to enforce without broad user impact.

Practitioner takeaway: The key judgement is to treat Office documents as potential execution initiators whenever they can reach external content or system tools, because the real risk is the hidden process chain, not the file extension.