This blog will be about how I am protecting my Windows 10 Pro devices to ensure they aren’t vulnerable to the nasty CVE-2022-30190 bug, also known as Follina, but I prefer to call it the Protocol Nightmare.
Somehow it reminds me of the Printer Nightmare bug(s) from some time ago. I am mentioning it because just a few days after the Follina CVE was released another Zero Day popped up that also makes use of the MSDT.exe. This additional Zero-day is called “DogWalk.”
1. Introduction
I guess the CVE-2022-30190 Follina bug doesn’t need much introduction, but a little bit wouldn’t do any harm.
https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-30190
The MSRC link above tells us, “A remote code execution vulnerability exists when MSDT is called using the URL protocol from a calling application such as Word. An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application. The attacker can then install programs, view, change, or delete data, or create new accounts in the context allowed by the user’s rights.”
Let me explain in some simple words what a URL protocol does. For example, when accessing an https: URL it will launch a nice browser, when accessing msdt: URL it will launch the msdt.exe process. This CVE abuses the Microsoft Support Diagnostic Tool MSDT.EXE
As I told you in the beginning, just after this Zero-day arrived, the “DogWalk” Zero-Day arrived! This bug will try to copy an executable file to the Windows startup folder when the target opens a maliciously .diagcab file. This CAB file includes a Mark-of-the-Web (MOTW), but because it’s a CAB file, it won’t be blocked, and you won’t be warned!
2. Possible Solutions
Luckily, we have multiple solutions to ensure our devices aren’t vulnerable to the MS-MSDT issue. I am going to explain 4 of them
2.1 Deleting the MSDT URL
When looking at Microsoft their official statement they are telling us to disable the MSDT URL protocol to make sure our devices are not vulnerable
When choosing this path, we can simply disable this MSDT url with a nice PowerShell script. In my opinion, it’s not the nicest option but it gets the job done!
Detection Script
New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR -ErrorAction SilentlyContinue | out-null
try {
Get-Item HKCR:\ms-msdt -ErrorAction Stop
Write-host "MS-MSDT exists. Remediate."
Exit 1
}
catch {
Write-host "MS-MSDT doesn't exist. No action needed."
Exit 0
}
Remediation script
$regBkpPath = "C:\Intune\RegBackup\"
if ( -not (Test-Path $regBkpPath)) {
New-Item -Path $regBkpPath -ItemType Directory
}
Invoke-Command {reg export 'HKCR\ms-msdt' $regBkpPath\msmsdtBkp.reg /y}
New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR -ErrorAction SilentlyContinue | out-null
Remove-Item -Path 'HKCR:\ms-msdt\*' -Recurse -Force -Confirm:$false
Remove-Item -Path 'HKCR:\ms-msdt\' -Force -Confirm:$false
2.2 Applocker
For as long as I can remember, we have been using Applocker (with DLL and MSI/script rules) to ensure the security of all devices. To do so, we are using our own baseline.
Deploy Applocker to Intune with PowerShell (call4cloud.nl)
In this baseline, we made sure the msdt.exe is excluded from the default Windows allow path
Another possibility would be to explicitly block the MSDT process by creating a new publisher rule as shown below to make sure access to MSDT.exe is always blocked!
When this baseline is deployed to your devices and you are trying to open that bad MSDT process, you will be prompted with the “your system administrator has blocked this app” message.
Please Note: Of course, you could do the same with Windows Defender Application Control (WDAC), but I still prefer a well-configured Applocker setup.
2.3 ASR Rules
I am hoping that all of you are already using Attack Surface Reduction and have configured the required rules to make sure some important stuff is secured. If not, please read my blog about the Magnificent ASR Rules first
When you need to protect your device against CVE-2022-30190, you could also configure this ASR rule to make sure your device is safe: d4f940ab-401b-4efc-aadc-ad5f3c50688a AKA Block all Office applications from creating child processes
That specific rule makes sure that it blocks child processes from being created in the Office Apps. When the ASR rule kicks in, a nice new event 1121 will show up in the Windows Defender event log.
When this action is blocked, you are also protected, but in my opinion, it is not the best option out there. The issue isn’t the Office Apps; it’s the protocol handlers themselves!
When configuring ASR Rules, please beware that they could also break some of your Office Add-Ons or Plugins, so please make sure you Audit first!
2.4 Intune Settings Catalog
The last option I am going to show you would be to use a Settings Catalog in Intune to configure the scripted diagnostics. When disabling the possibility to allow users to access and run the troubleshooting wizard you are also making sure your device is secured.
When you have blocked access to these kinds of wizards (msdt.exe) you will notice you will be prompted with the message that an error occurred and error code: 0x80070005
3. Settings Catalog Error
We were already using Applocker on all our devices, but better safe than sorry, so I decided to push this settings catalog to our devices.
After a while, the first devices began to check in and received this policy, but as shown below, some gave us an error.
Taking a closer look at that message, I noticed it was the famous 65000 not applicable error.
It’s the same licensing error I was talking about in this 65000 Days Of Night blog
https://call4cloud.nl/2021/07/65000-days-of-night
That’s odd because, if I remember correctly, Mike Danoski told us they removed the applicability filter on the service side.
The only requirement would be to have a device with the March 2022 update installed, as shown below.
To be sure my device was up to date, I opened WINVER. As shown below, my Windows 11 Business build is 22000.675.
As I mentioned in that 65000 blog post, I needed to ensure the required ADMX registry key was available.
Luckily, as shown above, that isn’t my issue…. Mmm, could it still be that licensing error?? I opened the DeviceManagement-enterprise-Diagnostics-Provider event log to check it out.
Noooo!! The same 0x82b00006, Policy is rejected by licensing error! Sarcasm on: It’s a good thing we also have Windows Enterprise devices that are still enterprise… Sarcasm Off
When looking at the same Settings catalog report, I see that the enterprise device has the status of successful.
I have contacted the IntuneSupport team and Mike Danoski to inform them of this issue. It looks like these settings work on Windows Pro devices, but when using Microsoft 365 Business Premium, you get a nice Windows Business Device.
Hopefully, it will be resolved within a few days so we can also make use of this setting on Windows Business devices
4. The Search-MS Protocol
The search-ms URI protocol allows applications to launch custom searches on a device. Just as with the MSDT protocol, it can be abused with the Office Apps.
The PowerShell remediation script I showed you earlier focuses on the MS-MSDT Protocol, but because this blog is becoming the Protocol Nightmare blog, I will also show you how to fix the search-ms protocol nightmare.
Detection Script
New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR -ErrorAction SilentlyContinue | out-null
try {
Get-Item HKCR:\search-ms -ErrorAction Stop
Write-host "Search-MS exists. Remediate."
Exit 1
}
catch {
Write-host "Search-MS doesn't exist. No action needed."
Exit 0
}Remediation Script
$regBkpPath = "C:\Intune\RegBackup\"
if ( -not (Test-Path $regBkpPath)) {
New-Item -Path $regBkpPath -ItemType Directory
}
Invoke-Command {reg export 'HKCR\search-ms' $regBkpPath\searchmsBkp.reg /y}
New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR -ErrorAction SilentlyContinue | out-null
Remove-Item -Path 'HKCR:\search-ms\*' -Recurse -Force -Confirm:$false
Remove-Item -Path 'HKCR:\search-ms\' -Force -Confirm:$falseWhen this remediation has run, people who are using or abusing this protocol will end up with the error that the protocol search-ms does not have a registered program
Conclusion
In this blog, I showed you the options to ensure your device is protected against the ms-msdt and the search-ms Protocol Nightmare. When looking at the options I gave you to block the available, I prefer the Applocker method, as it blocks the whole MSDT.exe process!
Hopefully, when we all have implemented a fix by now we can sit back and enjoy our #MEMBEER
I just saw your post on Linkedin; You should include “out-null” to avoid a loop, otherwise it will always try to execute the remediation, as there is an output with New-PSDrive.
Example:
New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR -ErrorAction SilentlyContinue | out-null
Hi… I noticed the same indeed… Someone else was also mentioning the error .. I adjusted the script.. thanx for noticing it
Thanks for sharing – I have found this article very usefull!
Best,
Stefan
Great write up Rudy, thanks for sharing some possible options.
Imho the easiest way to nullify this exploit is just to use a GPO or Intune to disable the troubleshooting tool. No scripts to test, no reg keys to eventually have to reverse, and obviously easier to push through change control.
Hi..
That’s indeed true. just as I was explaining in the blog… But with windows 10 business that settings catalog doesn’t (yet) seem to be working.
Hello, When i have copied the script and run, however the script finds the Reg msdt but then stops as if the switch “remediate” is not not connecting to the next cmd
Hi. what kinda error do you get when running it manually in system context?