Skip to main content

Microsoft Office Zero Day: Mitigate NOW

White Oak Security’s Microsoft Office Zero Day: Mitigate NOW blog post image of a lot up traffic cone in a dark hallway meaning ALERT. Photo caption: Free Red Led Traffic Cone Stock Photo

Microsoft has acknowledged a remote code execution vulnerability, CVE-2022-30190, which is possible in environments where Microsoft Office has been installed and Microsoft Support Diagnostic Tool (MSDT) is present – which it is on Windows installations by default. They have deemed this a high risk to the CIA triangle (Confidentiality, Integrity, and Availability) with a low level of complexity to exploit. Furthermore, to make matters worse, Proofpoint Threat Insight has reported that Chinese Threat Actor groups are already targeting organizations with the exploit… and there is no patch.

Replicating The Microsoft Office Exploit

In order to understand the seriousness of this exploit, we needed to be able to replicate it. First, we took time to track down the original notification of the vulnerability. We found that it was originally disclosed by a Japanese Cyber Security Research Team called nao_sec. Nao_sec was scanning through documents uploaded to and found an interesting vulnerability which allowed PowerShell commands to be executed through a MSDT URL. 

Using a test environment which had no internet access we transferred the Public PoC available to our systems and took a look. It was surprising on how simple the exploit was, thus Microsoft’s low level of complexity to exploit. All that was required to replicate the exploit was:

  • A web server hosting a web page with a JavaScript ‘window.location.href’ redirection to a specially crafted MSDT URL.
  • A .docx file (later converted into a .rtf to bypass protected view) which had an embedded document xml file containing a link to the forementioned web server.

With these two pieces to the puzzle, we pointed the document to an internal server hosting the malicious MSDT URL and observed exploitation in action.

New Packages Time To Discovery

One interesting aspect of the research was while we duplicated the public PoC exactly, only changing the URL to an internal server and enforcing egress restrictions, our payload was not detected nearly as much as the public PoC. This is very common in antivirus and EDR vendors as the rules they write are often hardcoded on specific known malicious values such as URL endpoints. While one of the early samples of this vulnerability had 38 antivirus or EDR vendors reporting it as malicious (at the time of writing):

Our samples of the Microsoft Office  vulnerability had 38 antivirus or EDR vendors reporting it is as malicious as captured here by White Oak Security

When uploading and analyzing the public PoC code, it was found that only 30 vendors flagged it as malicious:

When White Oak Security uploads and analyzes the public PoC code, it was found that only 30 vendors flagged it as malicious seen here.

And finally, our sample which executed the same commands as the public PoC – just from a different URL and egress controls standpoint – was only detected by 20 vendors:

White Oak Security’s sample which executed the same commands as the public PoC – just from a different URL and egress controls standpoint – was only detected by 20 vendors.

This goes to show how minuscule changes to a weaponized exploit can cause antivirus and EDR signatures to fail, as they may take more time to analyze the file and classify it as malicious. This is a common occurrence witnessed while performing penetration testing assessments. It also means that just because you see that your vendor has pushed a rule for a specific vulnerability, that you may not be completely protected and practicing defense in depth is a priority.

No Patch? Mitigate

While this is still considered a zero-day at the time of writing this article, there are actions that you can take suggested by Microsoft to attempt to mitigate the exploit. 

The first is to disable the MSDT URL Protocol. If this functionality is required or heavily used in your environment, you may need to seek alternative methods to remotely administer systems until a patch is provided. In order to disable MSDT URL’s, follow Microsoft’s guidance here:

Run Command Prompt as Administrator.
To back up the registry key, execute the command “reg export HKEY_CLASSES_ROOT\ms-msdt filename“
Execute the command “reg delete HKEY_CLASSES_ROOT\ms-msdt /f”.

The other action mentioned is to ensure that Microsoft Defender Detections and Protections is running. When enabling full internet access back to the lab, and enabling Microsoft Defender, we saw that our sample PoC was flagged as malicious. The problem we see here is that sometimes EDR vendors will disable the built in Microsoft Defender Detections to run their own engines and they may not have rules written for all variants or situations. 

Microsoft Defender Detections will see this as:

  • Trojan:Win32/Mesdetty.A  (blocks msdt command line)
  • Trojan:Win32/Mesdetty.B  (blocks msdt command line)
  • Behavior:Win32/MesdettyLaunch.A!blk (terminates the process that launched msdt command line)

And Microsoft 365 Defender will see it as:

  • Suspicious behavior by an Office application
  • Suspicious behavior by Msdt.exe

One suggestion from White Oak Security would be to scan all files coming in from the internet through downloads and emails, looking for and blocking .rtf files including those within compressed archives. While this won’t prevent all variations of the attacks, it will give you another level of defense.

Taking these actions, along with ensuring your antivirus and EDR is up to date, may not guarantee that you block the attack, but it will give you a better chance at it until a patch arrives.

More From White Oak Security 

White Oak Security is a highly skilled and knowledgeable cyber security testing company that works hard to get into the minds of opponents to help protect those we serve from malicious threats through expertise, integrity, and passion. 

Read more from White Oak Security’s pentesting team.


1. – Microsoft Vulnerability Description

2. – PoC Code and reference data

3. – Proofpoint Threat Insight Alert

5. – White Oak Security example

6. – In the wild observed sample

7. – Public PoC sample 

8. – Microsoft mitigation recommendations