Microsoft confirmed a security vulnerability tracked as CVE-2022-30190 and released it on their MSRC portal on May 30th, 2022. The vulnerability allows for a remote code execution (RCE) when MSDT (Microsoft Support Diagnostic Tool) is called using URL protocol from a calling application. “An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application.” Microsoft explained. This allows attackers to perform several critical functions such as installing new programs, modifying data and creating new accounts in context allowed by the user’s rights.
Security researchers at Proofpoint were able to spot Chinese APT group (TA413) actively exploiting this vulnerability by executing malicious code when targets open or preview Word documents delivered in ZIP archives.
Conscia Cyberdefense SOC can reliably detect the exploitation of this vulnerability in real time for our MDR customers who use Cortex XDR and Microsoft Defender for Endpoint data sources.
How to detect the potential exploit
While Microsoft recommends disabling the MSDT URL protocol in order to mitigate this vulnerability, our Conscia Cyberdefense Threat Detection engineer Tom Kern developed custom detection rule, for those who are not keen on the workaround and are interested in robust detection.
One of the most obvious ways to detect the exploitation is to focus on process relationship between Office software (such as MS Word) and msdt.exe. The following figure shows detection logs when opening a weaponized Word document:
This is definitely something to look for. However, in this case we assume the payload will be delivered in the form of weaponized Word file. Remember, this vulnerability is not in Microsoft Office, but in Support Diagnostic Tool, therefore it can be delivered and exploited in many ways. Limiting our detection efforts only to this scenario gives the attacker opportunity to bypass our defenses by choosing another delivery method.
To define more universal detection logic, we focused on the code execution itself. In our testing, the exploit code is set up to open notepad.exe.
Here we observed that the sdiagnhost.exe is the one which spawns the payload, in this case notepad.exe. The blacklist approach to detecting this relationship would be searching for any suspicious child processes of sdiagnhost.exe, such as:
This approach is flawed since it focuses on the known executables that are typically abused by attackers. A more sustainable approach is by whitelisting expected child processes. This means we need to define a rule that triggers if sdiagnhost.exe creates a child process that is not normal for this executable.
Understanding SDIAGNHOST
To find out what is normal for sdiagnhost.exe, we first need to understand how it is used by the operating system. You are probably familiar with the feature in Microsoft Windows that tries to troubleshoot a problem for you. It looks like this:
The troubleshooting is handled by sdiagnhost.exe which spawns different processes which are used to gather more information about the problem. For example, if a network issue is being troubleshooted, the sdiagnhost.exe will spawn route.exe which provides local routing table to identify issues with the default gateway.
There is a limited number of executables that sdiagnhost.exe will spawn. In our customer’s environment, those were:
Detecting suspicious child process of SDIAGNHOST
It is normal for sdiagnhost.exe to spawn the above executables, therefore anything that is not on the list above can be considered anomalous. The list, however, is not necessarily complete and should be verified in your environment for any additional executables that were observed in the past.
The detection rule would look like this:
- Parent process name is sdiagnhost.exe AND
- Process name is not in [the list above]
The best thing about such approach to rule logic is that it will most likely detect also any other future RCE vulnerabilities in Microsoft Support Diagnostic Tool as the logic focuses on deviations from normal behavior and not on the known bad behavior.