Critical Diagnosis: What You Can Do To Mitigate the Scourge of Microsoft CVE-2022-30190

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 exploit was discovered and reported on May 27 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 and \rich text format (.rtf) files within Microsoft Word. This is different from the traditional code execution security analysts are used to seeing that requires 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 previously documented. 

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 Proof of Concepts – 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.

Mitigations

Unfortunately, at the time of this blog post, Microsoft has not published an official patch yet; however, they have published a Microsoft Security Response Center (MSRC) blog suggesting workarounds. In short, Microsoft suggests disabling the ms msdt URL protocol (used to interpret the malicious external HTML) via a registry key modification. 

Other researchers have gone further, suggesting:

• Disabling “Troubleshooting Wizards” VIA Group Policy Object (GPO).

• Using Defender’s attack surface reduction capabilities, one can activate a rule to block all office applications from creating child processes.

• Removing the ms msdt handler entirely via registry 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 (EDR) and antivirus (AV) 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, but 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 Kibana Query Language (KQL) queries can be found here.

Signatures

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 registry 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 exploit 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.