What are the signs that Follina exploitation is underway on an endpoint?

The clearest signs are an Office parent process creating a new child process, followed by msdt.exe running with suspicious ms-msdt parameters and references such as PCWDiagnostic, IT_RebrowseForFile, or IT_LaunchMethod. In the article’s test case, calculator execution confirmed the chain, but the telemetry signals are the useful detection indicators.

Endpoint clues that distinguish Follina from ordinary Office activity

Follina is not just “a suspicious Word document.” The useful question is whether the endpoint shows a chain that points to Office abusing a legitimate Windows diagnostic path, because that is what separates exploitation from benign document handling. The NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here only at the control level, because the detection problem depends on process monitoring and audit visibility rather than on the document format itself. In practice, many security teams identify Follina only after the payload stage has already started, rather than from the document open event that began the chain.

What makes this attack observable is the mismatch between the expected Office workflow and the actual endpoint behaviour. A document viewer should not normally trigger a diagnostic utility with attacker-shaped arguments, nor should it create a follow-on process chain that looks unrelated to the user action. That is why analysts focus on parent-child process relationships, command-line content, and unusual helper process invocation. The endpoint story matters because the attack often uses trusted binaries and built-in Windows logic to hide the real abuse path.

How the detection chain unfolds on a compromised host

The core pattern is a staged process sequence. First, Office or another document-associated application launches something it normally would not need for document rendering. Then msdt.exe appears with a suspicious ms-msdt: command line and arguments that indicate diagnostic workflow abuse. Those parameters are important because they reveal the exploit path, not just the presence of a process named msdt.exe.

On a well-instrumented endpoint, defenders should look for the whole chain rather than a single indicator in isolation. Useful signals include:

Office spawning a child process that is not typical for the user’s normal workflow.
msdt.exe starting from an Office context rather than from a help or troubleshooting action.
Command-line references such as PCWDiagnostic, IT_RebrowseForFile, or IT_LaunchMethod.
Subsequent execution of an unexpected payload process, which may be a benign test artifact or an actual attacker payload.

Telemetry quality matters because Follina often relies on legitimate components. If the EDR stack does not capture full command lines, parent-child linkage, or process creation timelines, the chain can appear fragmented and the true origin can be missed. File-based inspection alone is usually insufficient, because the decisive signal is behavioural: a document-triggered transition into a diagnostic handler that should not be part of ordinary user activity. That is why endpoint detection should be correlated with document open events, process ancestry, and any network activity that follows the suspicious launch.

The guidance breaks down when logging is too sparse to reconstruct ancestry, when command lines are truncated, or when defenders monitor only the final payload process and not the Office-to-msdt transition.

When the usual indicators need a second look

Tighter process monitoring often increases alert volume, so teams need to balance early abuse detection against the noise created by legitimate Office add-ins, automation, and help-related workflows. Not every Office child process is malicious, and not every msdt.exe execution is an exploit, which is why context determines whether the event is suspicious.

There is also a practical distinction between confirmed exploitation and a failed attempt. A chain that reaches msdt.exe with the right parameters is highly suspicious even if no payload is observed, while a benign-looking calculator launch in a lab proves execution only in a test environment, not on its own as a production indicator. Organisations should treat the command line and process ancestry as the primary evidence, and treat payload execution as supporting confirmation rather than the sole trigger.

Some environments introduce legitimate diagnostic or automation activity that can resemble exploitation. In those cases, the strongest discriminator is whether the process chain aligns with a user-initiated troubleshooting action. If it does not, the event deserves escalation. In practice, many security teams encounter Follina only after the exploit path has already been normalised as “just another Office process tree,” rather than through intentional detection tuning.

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 abuses document open to execute code on the endpoint.
Recommendation — Map Office-to-msdt chains to T1203 and alert on client-side execution abuse.
CIS Controls v8	8 — Audit Log Management	Detection depends on preserving process ancestry and command-line telemetry.
Recommendation — Retain detailed process and command-line logs needed to reconstruct the exploit chain.
NIST CSF 2.0	DE.CM-8 — Vulnerability Scanning and Monitoring	Endpoint monitoring must surface suspicious process behaviour and exploitation indicators.
	DE.AE-2 — Detected Anomalous Events	Follina should be treated as anomalous endpoint execution arising from trusted binaries.
Recommendation — Tune endpoint monitoring to flag abnormal Office and msdt.exe activity quickly. Classify Office-initiated msdt.exe launches as anomalous events for investigation.

Practitioner Guidance

What to verify: Check whether your telemetry preserves Office parent-child relationships and full msdt.exe command lines before you trust any negative result. If those fields are missing, the environment is under-instrumented for this attack pattern.

What to prioritise: Focus on the earliest durable indicators, especially Office spawning unexpected children and msdt.exe launched with ms-msdt: arguments. That is the point where containment is still most practical.

Escalation / exception: Treat the event as higher priority when the process chain appears without a clear troubleshooting context, even if the final payload is not obviously malicious. The absence of visible payload activity does not make the chain safe.

Practitioner takeaway: The best Follina detections are behavioural, not file-centric: if you can reconstruct the Office-to-msdt chain with command-line detail, you can separate exploit activity from ordinary document handling much faster.