Use process creation telemetry from Windows endpoints and look for an Office application spawning MSDT, especially when msdt.exe is launched with an ms-msdt URI and a PCWDiagnostic style command line. Combining parent process evidence from Word, Excel, Outlook, or PowerPoint with the MSDT argument pattern raises confidence and helps separate exploitation from ordinary user activity.
Why Office Process Chains Matter for Follina Detection
Follina is a practical detection problem because the abuse path looks like normal application behaviour until the command line is examined. Security teams should focus on the Office parent process, the MSDT child process, and the URI or diagnostic arguments that connect them, rather than on file names alone. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces the need to combine detection, monitoring, and response around a specific observable chain instead of relying on a single alert source. In practice, many teams discover this pattern only after suspicious Office activity has already produced a remote execution foothold.
How Follina Appears in Endpoint Telemetry
Detection works best when teams correlate endpoint process creation with the exact Office-to-MSDT sequence. The highest-value signal is not simply that MSDT ran, but that it was launched by Word, Excel, Outlook, or PowerPoint with an ms-msdt URI and diagnostic-style parameters that match the exploit path. That combination is materially different from routine helpdesk or troubleshooting use, which usually has clearer user intent and less suspicious parent-child context.
A practical hunting approach is to compare three elements together:
- the parent process name and image path for the Office application;
- the child process execution of msdt.exe;
- the command-line content, especially ms-msdt and PCWDiagnostic-like arguments.
Teams should also watch for cases where the document opens, then spawns MSDT quickly, because that short sequence often matters more than the document type itself. If process creation logs are available, that is usually the best starting point; if they are missing, defenders should expect lower confidence and more false positives. Endpoint telemetry becomes much more reliable when it is paired with script, Office, and network visibility, but the core detection logic still depends on the process chain. Where alerting is based only on IOC-style strings, it tends to miss renamed or repackaged lures and creates weak triage value.
This guidance breaks down when endpoint telemetry is incomplete, Office activity is heavily automated, or administrators still permit MSDT usage for legitimate support workflows.
Normal Support Use, Edge Cases, and Triage Friction
Tighter detection around MSDT often increases investigation volume, so teams need to balance sensitivity against support noise.
Legitimate troubleshooting activity can resemble exploitation if a user or technician actually launches MSDT, which is why context matters. Guidance around this issue is not fully uniform across enterprises: some organisations block the tool outright, while others retain it for legacy support workflows and accept the extra monitoring burden. The difference is operational, not theoretical, because the same executable may be benign in one environment and high risk in another.
Edge cases usually arise when Office is used in scripted, automated, or remote-assist workflows. In those environments, process ancestry alone may not be enough, so teams should look for additional indicators such as unusual user context, unexpected document origin, or MSI and child-process activity that follows the MSDT launch. Hunt logic should also be tuned to the specific Office applications that matter most in the estate, because an Outlook-initiated chain may carry a different confidence level from a lab system or a technician workstation. Overly broad suppression rules are a common mistake, because they can hide the very abuse path defenders are trying to see.
Practitioner Guidance
What to prioritise: Treat the Office parent process and MSDT command line as a single detection unit, not as separate weak indicators. The most useful triage question is whether the execution makes sense for the user and workstation role.
What to verify: Confirm the parent application, the exact msdt.exe arguments, and whether the activity aligns with approved support use. If the chain originates from a document opened from email, external download, or an untrusted location, escalate quickly.
Common mistake: Teams often overfit detections to a single string match and underweight the process relationship. That creates blind spots when the attacker changes the lure formatting but preserves the exploit chain.
Practitioner takeaway: Strong Follina detection is less about spotting MSDT in isolation and more about proving that Office launched it in a way that does not fit normal administrative or user support behaviour.
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 NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Follina abuse reaches execution through spawned commands. |
| T1203 — Exploitation for Client Execution | The exploit drives code execution through a user-facing document. | |
| Recommendation — Map Office-to-MSDT execution chains to T1059 and hunt for abnormal command-line launches. Correlate malicious documents with child-process execution to validate client-side exploitation. | ||
| NIST CSF 2.0 | DE.CM-1 — Monitoring for Unauthorized Personnel, Connections, Devices, Software, and Code | Detection depends on endpoint telemetry and abnormal process monitoring. |
| DE.AE-2 — Analyzed Events to Understand Attack Targets and Methods | Analysts must interpret the execution chain to distinguish abuse from support use. | |
| Recommendation — Collect and review endpoint process telemetry to spot suspicious Office-to-MSDT activity. Analyze Office-parented MSDT launches as a distinct attack pattern before triaging them as benign. | ||
| CIS Controls v8 | 8.2 — Audit Log Management | Process creation logs are the core evidence for this detection use case. |
| Recommendation — Enable and retain endpoint process logs so you can reconstruct suspicious Office execution chains. | ||
Related resources from NHI Mgmt Group
- How should security teams inventory Copilot agents in Microsoft environments?
- How should security teams detect living-off-the-land attacks in hybrid environments?
- How should security teams govern AI assistants in hybrid Microsoft environments?
- How should security teams detect phishing that comes from legitimate Microsoft identity workflows?
