Well, like clockwork, another critical vulnerability has been found in a widely-used product. 

This time it comes in the form of a zero-day code execution exploit involving the Microsoft Support Diagnostic Tool (“ms-msdt”) protocol within Microsoft Office. This zero-day was discovered and reported on May 27th by security researcher “nao_sec”, but was discovered to have been exploited by attackers as early as April of this year. 

This vulnerability, tracked as CVE-2022-30190, can be exploited to achieve code execution when opening or previewing Word documents (.doc and .docx) and Rich Text Format. (.rtf) files within Microsoft Word. This is different from the traditional code execution security analysts are used to seeing that require a click to “enable macros” to run. This exploit, instead, runs whether macros are enabled or not. 

Furthermore, researchers have identified zero-click exploits on all versions of Microsoft Office products, including the most up-to-date channel of Office365 products. Several researchers report that an embedded payload can be executed when a weaponized “.rtf” file is previewed in Windows Explorer, and an .rtf exploit can also bypass Word’s “Protected Mode” protections. 

Technical Details

Colloquially dubbed “Follina”, the exploit itself uses the “ms-msdt” Diagnostic Tool protocol to query a malicious URL, which is loaded and interpreted to achieve code execution with equivalent privileges of the parent Office process. This is achieved by leveraging the Word “Remote Template” feature to reach out for a malicious HTML file, which is loaded using the “ms-msdt” URL scheme. Once loaded, this HTML file is then interpreted and calls the Native PCWDiagnostic pack using the “IT_BrowseForFile” parameter, ultimately resulting in code execution via PowerShell.

Malicious use of “msdt.exe” has been documented before. 


So what does this mean?

This is an evolution of Maldoc threats that already exploit Microsoft tools like Word and Excel to infect systems. This new method requires no additional authorization from the user other than opening (and in some cases, simply previewing) the file. Additionally, vendor detection on exploit files found in the wild (and POCs developed by researchers) is poor.  

One can expect this to become part of most attackers’ arsenal moving forward and should take measures against it. This is being actively weaponized and exploited, and therefore poses a significant risk to an organization, even one with up-to-date detection and mitigation strategies.


Unfortunately, at the time of this blog post, Microsoft has not published an official patch yet, however they have published a MSRC blog suggesting workarounds. In short, Microsoft suggests disabling the MSDT URL protocol (used to interpret the malicious external HTML) via a Registry Key modification. 

Other researchers have gone further, suggesting:

Disabling Troubleshooting WizardsVIA GPO.

Using Defender’s Attack Surface Reduction capabilities, one can activate a rule to Block all Office Applications from creating Child Processes.

Removing the MSDT handler entirely via reg key modification. 

With these mitigations, your mileage may vary based on your organization’s needs. Expect things to change rather rapidly over the next few days, so keep an eye out for any talk of improved mitigations (or ways your mitigation can be bypassed).

What about detections?

Unfortunately, many researchers have found current endpoint detection and response (EDRs) and anti-virus (AVs) technologies are somewhat limited in their ability to detect Follina exploits, however they do follow a pattern that can be identified by threat hunters. Expect detection capabilities to improve moving forward, however obfuscation and encoding within commands can be expected to change and improve from the attacker’s perspective as well. Active threat hunting can help mitigate that.

Do you have an EDR with process auditing?

Look for systems in your environment spawning “msdt.exe” as a child process of WINWORD.EXE, EXCEL.EXE, OUTLOOK.EXE, or POWERPNT.EXE. 

A similar Parent-Child process hunt can be performed looking for “conhost.exe” sessions or other processes with the parent process “sdiagnhost.exe”.

Similarly, keep an eye out for any network connection events spawned by the “sdiagnhost.exe” process not reaching out to an official Microsoft resource. 

Also, if you have command-line auditing enabled (either in EDR or in event logs), look for “IT_BrowseForFile”, as it is not a common parameter. 

SentinelOne KQL queries can be found here.


EmergingThreats has published a signature to detect potential exploitation attempts in their Open rule set with the message “ET EXPLOIT Possible Microsoft Support Diagnostic Tool Exploitation Inbound (CVE-2022-30190)”.

Other reports seem to be regarding targeted attacks, leveraging the following domains:

  • Tibet-gov.web[.]app
  • Xmlformats[.]com
  • Sputnikradio[.]net

Joe Security has a YARA rule for Command-Line auditing.

SecurePeacock wrote this Sigma Rule

@kostastsale wrote a sigma rule for detection as well. 

Looking for evidence of previous execution?

The “PCW.debugreport.xml” file within %localappdata%\Diagnostics and %localappdata%\ElevatedDiagnostics (depending on the level of privileges the exploit achieved) has been reported to contain the payload in some instances, which can be useful for historical threat hunts. 

The “hkcu\software\microsoft\office\16.0\common\internet\server cache” Reg Key can also be queried for all URLs contacted via Office. Note that this is an HKCU (Current User) key, and therefore is user-specific. Also note this contains legitimate URLs as well.

Final notes

This exploit is reminiscent of the Log4j exploits identified in late 2021, wherein an underlying subsystem with an external connection functionality was similarly exploited to achieve code execution. In that case, the quick-and-dirty solution seemed to be to disable the functionality entirely as a long-term solution was developed. In the case of the Log4j exploit, the first round of patches didn’t fully mitigate the threat, and we should account for that possibility in this case as well. 

P.S.: Security researchers should be cautioned against blindly running reportedly benign “POC” exploits during their exploration of this particular vulnerability, as several have been reported to drop Cobalt Strike beacons.