Breaking: Follina (MSDT) Vulnerability

There’s a new vulnerability abusing the ms-msdt protocol handler to execute arbitrary code in Office. Since “msdt vulnerability” is hard to track, Kevin Beaumont dubbed this vulnerability Follina (and we’ll continue to use that nomenclature in this post).

High-level Exploit Background

The exploit abuses functionality in MS Word. Linked HTML pages referenced in a document are automatically retrieved when the document is opened. This is expected functionality. What isn’t expected is that by using JavaScript in the linked webpage, the page can be redirected from an http/https protocol scheme to the ms-msdt protocol scheme. This is where the vulnerability lies. Side note: there’s no conceivable reason JavaScript should be processed at all in an HTML document linked in an Office document.

The ms-msdt protocol handler interprets data passed via the msdt.exe command line tool. MSDT is the Microsoft Support Diagnostic Tool, typically used to collect debugging information. One of the arguments passed to msdt is named IT_BrowseForFile. When combined with the argument IT_RebrowseForFile, msdt.exe can be tricked into executing an arbitrary application. Maybe “tricked” is a bit much here - msdt.exe executing a specific application to diagnose problems appears to be semi-intended functionality on the part of Microsoft. What is certainly not intended is the ability for a threat actor to trigger this behavior from MS Word.

The vulnerability does not appear to be present in all versions of Office. Kevin Beaumont reported that it is exploitable on Office 365 Semi-annual channel, but not the current or insider channels. 

Technical Details

When the linked document is retrieved, JavaScript is used to update the window.location.href to point to the ms-msdt protocol handler. Note that the string “ms-msdt” need not be present anywhere in a malicious document.

Upon processing the new protocol handler, the msdt.exe command is called with a parent process of Winword.exe. It also has a number of parameters, many of which are unusual (and poorly documented). Note the sysmon example detection below.

Parameters for msdt.exe in the original malicious document detected in the wild are:

• IT_RebrowseForFile
• IT_LaunchMethod
• IT_SelectProgram
• IT_BrowseForFile
• IT_AutoTroubleshoot

Of these arguments, the two that appear pivotal to exploitation are IT_RebrowseForFile and IT_BrowseForFile. In testing, we discovered that failing to provide the IT_SelectProgram would cause an additional popup (displayed below) to be displayed prior to code execution.

Network connections are made for the linked html document through winword.exe. 

If the msdt.exe tool is used to create a callout (likely through PowerShell), this network traffic will be generated through sdiagnhost.exe (in this case, there was an additional call to Pastebin to get a second stage payload directly through msdt.exe).

Any follow-on command execution triggered by msdt.exe are then executed by sdiagnhost.exe, as seen below.

Malicious Sample Analysis

The original exploit document was identified in the wild by nao_sec. The document runs PowerShell to deobfuscate a payload and execute it. The ultimate payload executed is displayed below.

The sample was likely distributed with a file with the .rar extension. The findstr command is used to locate a base64 encoded string that begins with the letters MSCF. The string “MSCF” is the file magic for the Microsoft cabinet file format. This base64 data is extracted from the “.rar file” and is decoded using certutil.exe. For those performing detection engineering, this use of certutil.exe is already highly suspicious activity. Then the expand.exe utility is used to unpack the cabinet file to the current working directory. Finally, the executable payload rgb.exe is executed. Because we do not have the “.rar file” distributed with the document, we do not know what the rbg.exe payload ultimately does.

Detection

The most obvious first step in detecting this exploitation is looking for msdt.exe execution with a parent process of an Office application. Kevin Beamont published his Defender query here.

Even ignoring the parent process of msdt.exe, the IT_RebrowseForFile and IT_BrowseForFile seem to be abnormal in most common use of msdt.exe. Execution of msdt.exe with these two command line arguments should be investigated as msdt.exe will certainly be used as a LOLBin outside of Office exploitation cases.

Network traffic from winword.exe is probably in itself not a reliable indicator, since MS Word is a bit chatty. However, you can look for network traffic to non-Microsoft domains emanating from WinWord.exe. Any such traffic would be highly suspicious. I haven’t yet fully evaluated exploitation cases in other Office products. Detection in Outlook using this heuristic (if vulnerable, it would likely be through the preview pane) would be substantially more difficult.

Looking for sdiagnhost.exe execution and network connections is also a potential detection opportunity. Note that the original exploit document identified in the wild by nao_sec would not have made additional outbound connections through sdiagnhost.exe as the maldoc was likely delivered with its second stage payload (probably as part of an archive).

Emulation Plans

We’ve whipped up a simple proof of concept emulation plan (Follina_msdt_calc) that tests msdt.exe execution by simply launching cacl.exe on test systems. Note that this can be run on systems without Office installed since it simply uses msdt.exe for execution (in sample documents, Word would call msdt.exe just as we are). When executing, the campaign will appear to hang because the msdt.exe command is continuing to execute. When the windows are closed, msdt.exe returns a failure code since it did indeed fail to execute as intended. You will need to review your telemetry to determine if calc was indeed launched successfully.

A second emulation plan (Follina_msdt_calc-callout) makes a web request to malwarejake.com via sdiagnhost.exe to retrieve PowerShell commands to execute calc.exe. Again, the SCYTHE UI will hang while the msdt.exe executable is still active and will present failure once the command returns.

Mitigation

Removing the protocol handler for ms-msdt is likely the safest mitigation vector until there’s an official response from Microsoft. We have not tested this method in large enterprises, so there may be some secondary effects of widely disabling the protocol handler. However, considering the implications of successful exploitation (arbitrary code execution), this seems like a reasonable risk-based approach (at least on any systems where Office documents are opened).

Removing the protocol handler is as simple as executing the following command in an elevated command prompt:

reg delete HKEY_CLASSES_ROOT\ms-msdt /f

Note that you should back up contents of this key before deleting contents so it can be merged back into the registry once a patch is available.

There was some initial discussion on Twitter that disabling this protocol handler might impact Office licensing due to a tweet by Didier Stevens. I’ve been in contact with him and can confirm that Office was not licensed on that machine. He stated the tweet was not intended to showcase a licensing concern with removing the protocol handler.

Closing Thoughts

Expect to see additional use of msdt.exe a LOLBin in the near future. Also, expect to see researchers explore other abuses of protocol handlers, including ms-msdt. Some have already been researching this as noted here and here. 

As always, detection engineering is your friend in cases like these. There wasn’t a single EDR I’m aware of that was blocking this execution. But with good detection engineering, you’ll at least be able to see where exploitation occurred. Happy hunting friends!

This post discusses active research by SCYTHE and other cited third parties into an ongoing threat. The information in this post should be considered preliminary and may be updated as research continues. This information is provided “as-is” without any warranty or condition of any kind, either express or implied.