If you thought we were done with the era of “open a Word document, get compromised,” think again. A new zero-day vulnerability tracked as CVE-2022-30190 — nicknamed “Follina” — has been actively exploited in the wild, and it’s a nasty one. It abuses the Microsoft Support Diagnostic Tool (MSDT) through specially crafted Office documents, and the truly alarming part: it doesn’t require macros to be enabled.
How Follina Works#
The attack chain is deceptively elegant in its simplicity. An attacker creates a Word document that contains an external OLE object reference pointing to a malicious URL. When the document is opened (or even previewed in Explorer), Word fetches the remote HTML, which then invokes MSDT via the ms-msdt: protocol handler. From there, arbitrary PowerShell code executes with the privileges of the calling application.
Let me break down why this is particularly dangerous:
No macro prompt: Unlike traditional Office-based attacks, the user never sees a “Enable Macros” warning. The payload executes through the MSDT protocol handler, bypassing the protections that organizations have spent years building around macro security.
Preview pane exploitation: In some configurations, simply previewing the document in Windows Explorer is enough to trigger the exploit. The user doesn’t even need to fully open the file.
Wide attack surface: MSDT is present on virtually every Windows installation. The vulnerability affects Office 2013, 2016, 2019, 2021, and Microsoft 365 — essentially the entire modern Office ecosystem.
Security researcher Kevin Beaumont, who gave the vulnerability its name (after the Italian town of Follina, referencing a 0438 area code in a malicious sample), documented the timeline showing that samples exploiting this technique were uploaded to VirusTotal as far back as April 2022. The vulnerability was only widely disclosed in late May.
The Deeper Problem: Protocol Handlers as Attack Surface#
What makes Follina particularly interesting from a security architecture perspective is that it highlights a long-standing problem with Windows protocol handlers. The ms-msdt: URI scheme is just one of hundreds of registered protocol handlers on a typical Windows installation, and the trust model around how Office applications interact with these handlers has always been questionable.
This isn’t the first time protocol handlers have been weaponized. We saw similar issues with ms-officecmd: handlers and various browser-to-application protocol bridges over the years. The fundamental design flaw is that these handlers were built with functionality in mind, not security. They accept complex parameter strings that can include commands, file paths, and scripts — exactly the kind of input that an attacker dreams about controlling.
For developers building applications that register custom protocol handlers, Follina should serve as a wake-up call. If your application accepts parameters through a URI scheme, ask yourself: what happens if an attacker controls that input entirely? Have you validated and sanitized those parameters as rigorously as you would for a web API endpoint?
Mitigation and Response#
Microsoft’s initial response was to publish guidance recommending that administrators disable the MSDT URL protocol by deleting the HKEY_CLASSES_ROOT\ms-msdt registry key. That’s a reasonable emergency mitigation, but it’s the kind of heavy-handed approach that tells you there’s no clean fix yet.
reg delete HKEY_CLASSES_ROOT\ms-msdt /fFor organizations running Microsoft Defender, attack surface reduction rules can help detect and block the exploit chain. Specifically, the rule “Block all Office applications from creating child processes” will prevent the most common exploitation path.
If you’re running a SOC or doing incident response, the detection opportunities are solid. Look for:
msdt.exespawned as a child process of any Office application- PowerShell execution initiated from
msdt.exe - Network connections from
msdt.exeto external hosts - Suspicious
sdiagnhost.exeactivity
The YARA rules and Sigma detections from the security community have been excellent — check the Huntress blog post for a thorough technical breakdown and detection guidance.
What This Means for Development Teams#
You might think “I’m a developer, not a sysadmin — this doesn’t affect me.” But it does. If your CI/CD pipeline processes documents (think: automated document conversion, content extraction, or testing), you could be exposed. Any system that renders or processes Office documents in an automated fashion needs to be evaluated.
I’ve worked on projects where document processing was treated as a purely functional concern — convert this DOCX to PDF, extract this text, merge these templates. Security considerations around the processing of untrusted documents were an afterthought at best. Follina is a reminder that document formats are complex attack surfaces.
Consider sandboxing any document processing workloads. Run them in containers with restricted network access and minimal system privileges. Don’t process untrusted documents on the same systems that have access to your source code, deployment credentials, or customer data.
My Take#
Follina is a masterclass in why defense in depth matters. Every individual component in the attack chain — OLE references, external URL fetching, protocol handlers, diagnostic tools — was working as designed. The vulnerability exists in the composition of these features, in the trust boundaries (or lack thereof) between them.
This is the kind of bug that makes me deeply uncomfortable about the complexity of modern software stacks. We’re running systems where no single person fully understands the interaction between all the components, and attackers only need to find one unexpected interaction to get code execution.
Patch when Microsoft releases a fix. Disable MSDT in the meantime. And take a hard look at how your organization handles document-based threats, because I guarantee this won’t be the last protocol handler vulnerability we see.