Last Updated on June 12, 2022 by rudyooms
This blog will be about me trying to protect my Windows 10 Pro devices to make sure they aren’t vulnerable to the nasty CVE-2022-30190 bug AKA Follina but I rather called 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”
I am going to divide this blog into multiple parts
1. Introduction
I guess the CVE-2022-30190 Follina bug doesn’t need much introduction but a little bit couldn’t do any harm I guess.
🔃 Security Update Guide – Loading – Microsoft
Looking at the MSRC link above, it’s telling 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
Like I was telling 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 make sure 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 remember we are using Applocker (with DLL and MSI/script rules) to make sure all of the devices are secured!. 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 “this app has been blocked by your system administrator” message
Please Note: Of course, you could do the same with Windows Defender Application Control (WDAC) but somehow I still prefer a good 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. Because the issue arent the Office Apps it are the protocol handlers themselves!
When configuring ASR Rules please beware that ASR rules could also break some of your Office Addons 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 of 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 of them were giving 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 telling about in this 65000 Days Of Night blog
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.
Like I was telling in that 65000 blog I wrote, I needed to make sure the required ADMX registry key are 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, that enterprise device has the succeeded status.
I have reached out to the IntuneSupport team and Mike Danoski to make them aware of this issue. It looks like these settings do work on Windows Pro devices, but when using Microsoft 365 business premium you got yourself 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 you have to make sure your device is protected against the ms-msdt and the search-ms Protocol Nightmare.
In my opinion, 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?