The newest Microsoft Office zero-day vulnerability, Follina, has been causing a buzz around much of the security community. The largest differences between it and most other Office vulnerabilities are that it has found a way around the use of macros and that it does not have any planned patches in the pipeline.
Rather than tiptoeing around a commonly used and patched vector for Office malware like macros, the vulnerability uses the Microsoft Support Diagnostic Tool (MSDT). A call out from the Word application triggers MSDT to run, and in this case, creates an easy avenue for arbitrary code execution. The vulnerability also appears to be exploitable via .RTF and .DOCX files on all versions of Office365 as of the time of this writing. An exploit with the extension changed to .RTF can sometimes even run without the document being opened.
The confirmed active campaigns using this vulnerability are now widespread and several proof of concept (PoC)s have already been published. Since the publication of the vulnerability, threat actors like Chinese actor TA413 have begun taking advantage of its ease of use, and other possible state-backed attackers have been seen. Activity using this vulnerability has been seen going back into April.
As with all arbitrary code execution vulnerabilities, this is a very serious threat to those with MSDT enabled on their environment. Arbitrary execution allows an attacker to upload and execute their own code, enabling them to make changes outside of allocated permissions, exfiltrate documents, spy on operations, and pivot to other machines within the network.
Especially with an application so heavily used as Microsoft Word, this is an important vulnerability to keep an eye on and properly mitigate. Unchecked, a zero-day vulnerability like this can wreak havoc on an entire network in a very short amount of time.
Monitoring and Detection
Automating detection for this vulnerability is thankfully quite straightforward based on how it executes. The primary method for finding this activity in monitoring is searching specifically for WINWORD.exe, EXCEL.exe, or OUTLOOK.exe opening MSDT.exe with an emphasis on file browsing activity. Another effective method was searching through conhost.exe and sdiagnhost.exe logs for unusual new processes (like conhost launching cmd or sdiagnhost launching conhost, both of which are indicators of compromise).
If executions have already been performed, traffic monitoring from any of the three applications listed above that does not go to either ‘visualstudio.com’ or ‘microsoft.com’ or their subdomains should be investigated thoroughly.
Extensive endpoint monitoring is a must for this specific vulnerability, which can make dealing with it difficult. Enterprises should ensure that, if this vulnerability is a significant concern to them, they pull Windows process creation event logs (code 4688) from each endpoint, though this may be difficult for some organizations to do if limited on resources.
There are some current options for remediation that can prevent the worst of the problem. Microsoft suggests that the MSDT URL protocol be manually disabled via registry key changes, and that Defender be turned on. Defender can alert on any unusual uses of MSDT.
Microsoft also recommends that Protected View and Application Guard be turned on for Microsoft Office, which will assist with macro use, as well.