Follina: The Office Zero-Day That Needed No Macros

On 27 May 2022, security researcher nao_sec publicly documented a Microsoft Office zero-day they’d found in the wild: a malicious Word document, opened from a path referencing a remote UNC template, that invoked the Windows support diagnostics tool — MSDT — via a crafted ms-msdt: protocol URI, loading attacker-hosted HTML whose script then executed PowerShell with SYSTEM-level privileges. The bug needed no macros; the document wasn’t even a real .docx but a renamed RTF/external-template trick that pulled content remotely, so traditional macro-blocking and attachment filtering missed it entirely. Microsoft’s initial response was to describe the issue as informational-with-workarounds — recommending customers disable the MSDT URI handler via a registry key — and to delay the patch past June’s Patch Tuesday before yielding to escalating pressure and shipping an out-of-band fix on 14 June 2022 as CVE-2022-30190, forever nicknamed Follina after the dance of DLL references in the malicious code’s debug path (specifically, 0438-1Follina.doc, a file name referencing an Italian town). The wait between disclosure and patch overlapped exactly with a state-actor exploitation window: in early June, researchers and Chinese-vendor telemetry documented China-nexus actors (including a group tracked as TA413, known for Tibet-focused campaigns) using Follina against targets in Europe, the US, and Russia — proof the technique had migrated from criminal spammers to intelligence collectors within days of disclosure. Follina’s legacy: another entry in the long catalog of “Office supports code-adjacent features nobody asked for”, a case study in Microsoft’s awkward middle era of protocol-handler attack surface, and a rehearsal for the industry’s broader reckoning with living-off-the-land URI schematics that 2023’s “Microsoft Office is not your friend” hardening wave would formalise.

What happened

The discovery sequence set the tone. On 27 May 2022, nao_sec (a Japan-based researcher) tweeted a VirusTotal-hunted sample: a Word document with a Russian-internship lure that, when opened, reached out over SMB to fetch a remote template containing an ms-msdt: URI. The URI — a protocol handler meant to launch Microsoft’s Support Diagnostics Tool with diagnostic parameters — was crafted so that MSDT’s rendering of parameters executed attacker script with the privileges of the Office process. Because the malicious logic lived in the fetched template rather than the document body, default macro policies and many sandbox configurations observed nothing alarming; because MSDT is a signed Windows binary, the execution blew past application allowlisting tuned to block scripts.

Microsoft’s first move was underwhelming: a 30 May advisory acknowledging the class of attack vector with the registry workaround (delete/rename the ms-msdt handler key) but no CVE and no patch commitment — the company initially treated it as an informational issue reducible to abuse-of-feature. The security community’s pushback (PoCs were public within a day of nao_sec’s find) and the evidence of active exploitation forced escalation: CVE-2022-30190 was assigned, and on 14 June — deliberately ahead of the regular cycle — Microsoft shipped the out-of-band patch that blocked Office content from invoking the MSDT URI scheme.

The exploitation window’s occupant history is the dark part: by early June, vendors documented Follina in campaigns attributed to Chinese-nexus actors — TA413’s Tibet-themed lures prominent among them — alongside commodity criminal distribution (coinminer droppers, info-stealers) and hacktivists’ opportunism. The technique had crossed from researcher PoC to state collection in under two weeks.

The execution chain

Follina exploit chain (CVE-2022-30190):

  DELIVERY
    phishing lure document
    (.doc which is actually a
    container/RTF with external
    template reference)

  LOAD
    Word resolves remote template
    path (UNC \\attacker\share or
    WebDAV http)
    -> fetches attacker HTML
    (Protected View mismatch: the
    document opens "trusted"
    because lure file itself is
    local/attachments-opened)

  TRIGGER
    fetched content carries
    ms-msdt:-prefixed URI
    e.g. ms-msdt:/id
      IT_RebroadcastsXML?/..\
      ...\shell\open\command
    = malicious.html mhtml path
    traversal payload

  EXECUTION
    MSDT (signed Windows diag
    tool) launches via protocol
    handler
    parameter parsing reaches
    embedded script execution
    -> sdiageng.dll-era harness
    runs JavaScript calling
    PowerShell
    code runs in Office-process
    context (user privileges;
    elevated paths documented)

  WHY DEFENSES MISSED IT
    no macros involved
    MSDT = signed MS binary
      (allowlist-clean)
    Execution lived in remote
    template + protocol handler,
    not document body

  PATCH (2022-06-14)
    Office blocks MSDT URI
    invocation from document
    content; interim workaround:
    disable ms-msdt handler
    registry key

Impact and numbers

Timeline

Why it still matters in 2026

Because Follina crystallised a threat-model shift the industry keeps re-learning: the document format is an execution framework. Word’s external-template resolution, OLE embeddedness, DDE fields, and protocol-handler reach mean a text file with formatting can fetch code over the network and execute it with a signed Microsoft binary — macros disabled or not. The post-Follina hardening wave (Attack Surface Reduction rules covering Office-spawned processes, protocol-handler allowlisting, external-content blocking by default in newer Office builds, “any scheme handlers reachable from rendered content” audits) all descend from this incident, and its siblings — 2023’s continued URI-scheme findings and the Office-related CTAs of subsequent years — keep the lesson current. The disclosure dynamics aged worse than the bug: Microsoft’s initial downgrade-to-informational call, followed by an out-of-band patch within days of state-actor exploitation reporting, is now case-study material in vulnerability-handling courses for exactly that arc. And TA413’s speed — researcher PoC to intelligence-collection lures inside a fortnight — is a permanent tempo argument: any window between public PoC and patch is state-actor usage time, priced in days. 2026 defenders inherit all three: reduce Office’s ambient capability surface (so the next ms-msdt has less to launch), watch process ancestry (Office → diagnostic/shell tools) rather than signatures, and treat “we’ll patch next cycle” as the riskiest sentence in vulnerability management.

Detection and hardening takeaways

• Kill the handler, save the user. Disable or restrict protocol handlers (ms-msdt:, search-ms:, ms-officeCmd:-class reachability) on managed estates — removing the launch path stops whole exploit families regardless of document creativity; the 2022 registry workaround remains a valid defence-in-depth layer post-patch.
• Block Office’s remote-content resolution. External templates, OLE network fetches, and DDE updates are entry valves; group policy/Intune settings blocking remote-content retrieval by Office apps cut the delivery path Follina depended on (fetch happens before any macro-policy decision).
• Detect on process ancestry, not file hash. The reliable Follina signature was genealogical: Office process spawning WINWORD→MSDT→(sdiageng-era script host)→PowerShell; EDR rules keyed on diagnostic-and-shell tools spawning from document applications catch variants that repurpose other handlers.
• Compress the PoC-to-patch window operationally. Treat public-PoC zero-days as active incidents regardless of observed targeting: your SLA for workaround deployment (handler disable, ASR rules) should be hours, with the patch SLA independent and tracked — the TA413 timeline proved adversaries weaponise faster than monthly cycles.
• Audit URI-scheme attack surface annually. New Windows/Office builds keep shipping protocol handlers with diagnostic and automation powers; inventory them (per-user vs system registrations included), test what they can invoke from rendered HTML/RTF, and expect the next Follina to arrive via a handler nobody reviewed this year.

FAQ

Why is it called Follina?

From the malicious sample’s file name 0438-1Follina.doc — Follina being a town in the Italian province of Treviso, and 0438 the timestamp component that shared the file path. The researcher who surfaced the sample assigned the name, and the security community, ever allergic to dry CVE references, adopted it within a day; the name has no technical meaning beyond that artefact.

Did disabling macros protect against Follina?

No — and that was the point. Follina never touched the macro engine: malicious behavior lived in an externally-fetched template and the ms-msdt protocol URI, so macro-blocking policies, attachment inspection tuned for VBA, and even “Protected View”-bypassed scenarios left it fully functional. It’s the definitive example of why Office hardening must cover document behaviour (external resolution, protocol handlers) and not just VBA.

Was Follina ever wormed?

No self-propagating Follina worm emerged — exploitation stayed at the phishing-lure granularity (state-actor spearphish, criminal malspam, hacktivist opportunism). The patch-gap momentum went into payload variety (RATs, coinminers, info-stealers) rather than lateral-spread automation. That kept the incident serious-but-contained: a snapshot of how quickly state actors adopt handy primitives, not a preview of a wormable apocalypse.