On Monday, May 30, 2022, Microsoft issued CVE-2022-30190, a zero-day remote code execution (RCE) vulnerability in the Microsoft Support Diagnostic Tool (
MSDT). The first detections in the wild indicate that this vulnerability is triggered remotely from Microsoft Office documents.
This is a critical issue as cybercriminals often choose Office documents as a popular tactic to infect victims with their malicious content. This vulnerability (referred to as “Follina”) only requires users to open a single document and no further interactions are necessary before the system is compromised. The end-user doesn’t even need to open the document in certain situations (document with RTF extension and the preview pane enabled).
A CVE has been assigned by Microsoft, but there is no patch available as of May 31st, 2022. This is a critical issue, as it is not mitigated by disabling macros and Protected View offers only limited protection.
It is important to note that this vulnerability is related to the Microsoft Support Diagnostic Tool (MSDT), not necessarily to Microsoft Office. Office has been used to weaponize this vulnerability in the wild, but it is not needed to trigger this vulnerability. There are also methods to trigger this vulnerability. There are effectively two vulnerabilities: 1) Microsoft Office template injection trusting the MS-MSDT protocol and 2) the MS-MSDT protocol allowing malicious code execution.
CVE-2022-30190 “Follina” Vulnerability Analysis
At its core, the Follina zero-day vulnerability is made possible by custom protocol handlers in the Windows operating system. Custom protocol handlers often allow threat actors to exploit local vulnerabilities using the browser.
In Windows, a protocol scheme can be registered (for example
martinz) and associate an executable to handle this protocol. When Windows encounters a URI in the format of
martinz://open, it will locate the associated executable and run the specified executable with arguments. For example, if the program
C:\Temp\MyTest.exe is associated with
martinz protocol using a syntax like
C:\Temp\MyTest.exe %1, clicking on the link
martinz://hello-world will execute the command
While it is triggered by an Office document, the Follina vulnerability is being exploited via one of these custom protocol schemes, used as part of the Windows Troubleshooting Platform (WTP). WTP was introduced in Windows 7 and Windows Server 2008 R2 as a way for users (or 3rd party applications) to trigger troubleshooting scenarios and automatically fix various problems. Under the hood, WTP is relying on Windows PowerShell and the concept of troubleshooting packs.
There are different ways that the troubleshooting pack (which is just a PowerShell code and manifest file) can be executed. It is available in GUI (see screenshot below), the command line (
msdt.exe), it can be used by the PowerShell module (see Invoke-TroubleshootingPack), or it can be executed with a protocol handler
ms-msdt:/ to integrate it with the application. For example, if a tool for online collaboration is experiencing problems with audio, it can provide a user with a link to start audio troubleshooting.
Fig. 1 Various troubleshooting packs are included in Windows
In the case of the Follina vulnerability, threat actors are using the Microsoft Office template injection method to force the MS-MSDT protocol into executing custom PowerShell code. Microsoft Office encounters a trusted protocol
MS-MSDT://, and starts the custom protocol handlers (
MSDT.exe) to handle the request.
The request triggers the diagnostic test called “Program Compatibility Troubleshooter” (
/id PCWDiagnostic), which attempts to fix incompatible programs. A set of parameters is passed to this diagnostic test, including instructions to skip the program selection (
IT_SelectProgram=NotListed) and the embedded PowerShell code.
Fig. 2 Screenshot from the first report. Source: nao_sec
The PowerShell code is embedded in the parameter
IT_BrowseForFile, which normally defines the location of the executable that requires troubleshooting. This parameter is not supposed to contain any PowerShell code, only the location of the file.
Threat actors are abusing that this file is processed by the PowerShell engine, and by using the
$() syntax in this string, they force the PowerShell interpreter to resolve their expression before processing the rest of the string. This code is not executed by
msdt.exe, which is just a launcher (wizard) and protocol handler for various diagnostic tests. Instead, it is executed by
sdiagnhost.exe, the host process of the WTP framework.
Recommendations and Guidelines
As of May 31st, 2022, Microsoft has released a security guidance note, but has not yet released a patch to address this vulnerability. This is a critical security vulnerability, and we urge organizations to make sure all endpoints are up to date with the latest security updates applied and installed once the patch is available
Various components from Bitdefender endpoint security can prevent and detect this vulnerability.
Bitdefender core antimalware includes signatures for the following detections:
- HTML components of this vulnerability are generically detected by
- DOCX files are detected by
- RTF files are detected by
- Final payloads can vary, but our telemetry detections are reporting mostly
Bitdefender Advanced Threat Control (behavior-based process monitor) detects suspicious process behavior. This detection is effective not only for attacks triggered by Microsoft Office but also for other methods that try to weaponize
Bitdefender IP and URL reputation service will also block connection attempts for remote template injection for known malicious sites.
Threat intelligence is also featured in our Bitdefender Managed Detection and Response offering. Learn more about Bitdefender’s MDR Service, and get to know the Bitdefender experts who work in our security operations center (SOC).
Additional recommendations include:
- Ensure your system is up to date: Bitdefender Patch Management can help with quick scanning and management of the needed upgrades to prepare your system against this issue when the patch is available.
- Disable MS-MSDT protocol and/or disable troubleshooting through Group Policy.
- Continue to monitor your endpoints for suspicious activity, even after the previous steps have been conducted. Also, make sure your XDR solution can detect attempts to execute anomalous child processes.
We would like to thank David Acs, Vlad Cîncean, Bogdan Ionuț Lazăr, Dan Horea Lutas, Adrian Stefan Popescu, and Alexandru Mihai Postolache for their help in putting this advisory report together.