The new exploit, CVE-2022-30190, is grabbing headlines this week. So what is it all about, and why is it important? Let’s take a quick look at what CVE-2022-30190 is and how we can defend against it.
Short on time? TLDR
Background on CVE-2022-30190
A Security Researcher discovered a malicious Word doc uploaded to VirusTotal exploiting the flaw in MSDT. So this exploit is a true zero-day, being actively exploited. There is NO patch from this bug at this time, and likely will not be one till next Patch-Tuesday.
What is MSDT(.exe)?
MSDT stands for Microsoft Diagnostic Troubleshooting Wizard. The MSDT Tool has been included in Windows since Windows 7. Its core function is to run diagnostic packages to resolve issues automatically. Under normal operation, when the program launches, it would stop and wait for a passkey before continuing. However, this behavior is bypassed.
How does the Exploit Work?
An analysis of the malicious Word doc reveals just how good this exploit is. Here is the Any.Run session with the full execution of the malicious Word Doc. At the time of writing(June 1, 2022), the backend malware infrastructure is offline. However, with this saved Any.Run session we can extract the exploits used when everything was still live.
In short, the only malicious part of the Word doc is a small reference to pull a remote resource, typically used to pull style and template data.
In this case, the remote resource is a simple HTML file with an embedded weblink. However, the embedded weblink is actually calling the MSDT.exe.
MS-Word downloads the HTML file, renders the HTML file, follows the javascript “window.location.href” weblink, the weblink runs the ms-msdt(msdt.exe) with code payload.
Within the above weblink, there is an embedded, base64 encoded, payload command. This payload command will be executed when msdt.exe is called via the weblink.
We can dig deeper into this, but I want to focus more on how we can defend against this attack. If you want more depth on how this attack works I recommend reading this great deep-dive blog.
Identified Malicious Behaviors
Here is a list of malicious actions that we need to defend against.
- Office calling the MSDT.exe(ms-msdt).
- Office being able to launch child processes.
- No macros are required, just rendering the document triggers the exploit.
Defending Against CVE-2022-30190
Now that we have identified the malicious activities that make up this exploit process we can craft our defenses.
Block Office from Launching Child Processes
Microsoft has a recently new security feature set called Attack Surface Reduction rules(ASR). ASR rules are a way of controlling OS components that are common targets for abuse. In our case, blocking Office applications from creating child processes. This feature may be used for legitimate uses, but is ripe for abuse. Let’s create a Group Policy that enables the ASR rule on systems and enables the “Block all Office applications from creating child processes” rule.
Open Group Policy Management Editor, create a new GPO Object, edit the new GPO Object, and navigate to the following location.
Computer configuration -> Policies -> Administrative templates ->Windows components > Microsoft Defender Antivirus > Microsoft Defender Exploit Guard > Attack surface reduction
Now we need to edit the “Configure Attack surface reduction rules” setting to match the below image.
- Enable ASR.
- Click “Show” to configure the ASR rules we want to use.
- In the “Value Name” enter the GUID of the “Block all Office applications from creating child processes” rule; “
d4f940ab-401b-4efc-aadc-ad5f3c50688a
“ - In the “Value” field enter “1” to enable the “Block all Office applications from creating child processes” rule.
- Click “OK” to confirm the new rule added.
- Click “OK” to finish configuring the new GPO.
You can now go ahead and applied the new GPO to your domain’s end-user systems. The new rule can be applied to any Windows 10(version 1709) and new. Additionally, Windows Server 2012R2 and newer can utilize this security feature.
Disable the MSDT URL Protocol
Microsoft’s guidance to mitigate this issue is to edit or remove the default action of the “ms-msdt” reference via a Registry change. We must think smarter when there are hundreds of end-points to set this mitigation action on. Let’s create a GPO that can apply our mitigations domain-wide.
Open Group Policy Management Editor, create a new GPO Object called “CVE-2022-30190_Mitigation”, edit the new GPO Object, and navigate to the following location.
Configuration -> Preferences -> Windows Settings -> Registry
Create a new Registry property and fill it in as below.
- Change the action to “Replace”.
- Select the “HKEY_CLASSES_ROOT” hive, and click “…“, and navigate to “Computer\HKEY_CLASSES_ROOT\ms-msdt\shell\open\command”
- Check “Default”.
- Change the “Value Type” to “REG_EXPAND_SZ”
- Enter the two double quotes (“”) into the “Value data” field.
- Click “OK”.
You can now go ahead and applied the new GPO to your domain’s end-user systems. This mitigation changes the default action of the “ms-msdt” reference within Windows, by unlinking “ms-msdt” from “%SystemRoot%\system32\msdt.exe” . So when the malware calls “ms-msdt” it will not be directed to the msdt.exe file.
Before Mitigation
After the New GPO is Applied
Wrapping-Up: TLDR
The CVE-2022-30190 vulnerability is dangerously simple to use. This makes it very likely it will be a new favorite among Attackers.
Email inboxes will flood with doc files leveraging this exploit. The real danger factor here is that this one does not rely on macros, unlike most other Office doc malware. We, as Defenders, have been training End-Users for years to be suspicious and vigilant for Office files with macros. So our first layer of defense is less effective against this exploit.
Malicious Behaviors to Block
- Office calling the MSDT.exe(ms-msdt).
- Office being able to launch child processes.
- No macros are required, just rendering the document triggers the exploit.
Defensive Layers to Mitigate the Attack
- Enable Attack Surface Reduction(ASR) and configure the “Block all Office applications from creating child processes” rule.
- Modify systems Registry to unlink “ms-msdt” from “%SystemRoot%\system32\msdt.exe”.
1 Pingback