mrobson
Staff
Staff

Introduction

 

This article demonstrates how FortiEDR provides protection against post-exploitation behavior associated with the CVE-2022-30190 vulnerability.

 

On 28 May 2022 Twitter user nao_sec identified an anomalous word document submitted from Belarus that exploits a new vulnerability in MS Office protocols. This vulnerability allows for remote code execution from Microsoft Word or RTF documents.

 

This remote code execution, when combined with common initial access methods such as phishing provides a similar level of access more commonly gained through the use of macros. Given Microsoft’s recent crackdown on macros, expect actors to employ alternative methods of gaining execution like exploitation of this vulnerability.

 

Scope

 

Protections cover both version 4.x and 5.x collectors.

 

Solution

 

The initial sample requires the user to open the malicious attachment for the exploit to work however with further investigation, researchers have identified this vulnerability can also be exploited through the ‘preview pane’ in Windows Explorer effectively making this vulnerability ‘zero click’.

 

Whilst PoC code and ITW samples currently circulating focus on the exploitation of Microsoft Word and Windows explorer this vulnerability is present in MS Office protocols used throughout the Microsoft Office suite. As a result, it should be expected, like with the swathe of Exchange vulnerabilities found last year, that additional vulnerabilities are identified in other Microsoft Office products or applications that employ these protocols over the next few months.

 

FortiEDR Detection and Protection – User initiated exploitation

To demonstrate FortiEDR coverage of this exploit a Microsoft Word document (.docx) was created that contained exploit code that called back to the loopback on the test ‘victim’. A test webserver was setup to serve a dummy payload in response to the exploit callback that wrote a test file to a simulated user desktop.

 

Details of the exploit have already been documented by the cybersecurity community, find information on the technical machinations of the exploit in Kevin Beaumont’s blog post or the Huntress teams webpage.

 

When the malicious test document was created three FortiEDR security events were triggered at various stages of the exploit’s execution, all were related to behavior from a script executing in a suspicious context and were triggered from the ‘Execution Prevention’ security policy. All these detected events would have resulted in the failure of the exploit.

 

mrobson_0-1654001131370.png

 

Figure 1. FortiEDR shows the anomalous process chain associated with the exploitation of the Follina vulnerability.

 

The screenshot in Figure 2 below shows the FortiEDR forensics interface ‘Stacks View’. This view allows us to see the cmdline arguments passed to the Microsoft Diagnostic Tool (msdt.exe) that match the ‘malicious payload’ served by the simulated malicious webpage hosted on localhost.

 

mrobson_1-1654001131381.png

 

Figure 2. FortiEDR Stacks View showing the cmdline arguments for the msdt.exe process containing the simulated ‘malicious payload’ retrieved from a simulated malicious webpage.

 

The final figure, Figure 3, shown below shows the third security event showing the creation of a child process for the ‘echo’ command that formed the final part of the simulated ‘malicious payload’.

 

mrobson_3-1654001623351.png

 

Figure 3. Third FortiEDR security event generated from the execution of the text exploits showing execution of the ‘simulated malicious payload’.

 

Mitigations

FortiEDR will provide protection from exploitation of this vulnerability and subsequent post-exploitation activity. As of 31 May 2022, Microsoft has not released a patch that addresses this issue.

Until a proper patch is released, additional guidance on hardening endpoints against exploitation through workarounds can be found here: https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-...

Conclusion

Whilst this vulnerability is significant, it should be considered in the context of a full intrusion. For this vulnerability to be exploited in a target environment, a threat actor must deliver a suitable malicious document to a victim, and the user must download and open/mouse over the malicious document for it to execute.

 

Email filtering may prevent the malicious document from getting to the victim (FortiMail for example).

Even after successful exploitation, observed samples from in the wild reach back to adversary C2 to download secondary payloads. If this C2 is known and automatically ingested into firewalls (like through FortiGate or FortiAnalyzer with FortiGuard Labs threat intelligence subscription) this C2 connection will be blocked or, as outlined in this article, network connections to C2 should be blocked by an EDR solution like FortiEDR.

 

Lastly, this vulnerability demonstrates a method of code execution but any post-exploitation activity should be blocked by an EDR solution like FortiEDR.

Threat Hunting Queries

The following threat hunting queries can be used to identify potential endpoint activity associated with the exploitation of the above-outlined vulnerability.

 

This query will identify the Microsoft Diagnostic Tool (msdt.exe) being spawned from Microsoft Office processes. Whilst current POCs only demonstrate exploitation of WINWORD through this vulnerability the query has been extended to cover future exploitation in other common Microsoft Office applications. This query has a low false-positive rate in the test environment.

 

Type:"Process Creation" AND Target.Process.Name:"msdt.exe" AND (Source.Process.Name:"WINWORD.exe" OR Source.Process.Name:"POWERPNT.exe" OR Source.Process.Name:"EXCEL.exe" OR Source.Process.Name:"OUTLOOK.exe")

 

 

 

 

This query will identify the Scripted Diagnostics Native Host process (sdiagnhost.exe) spawning from the Microsoft Diagnostic Tool (msdt.exe).

This query has a low false-positive rate in the test environment.

 

Type:"Process Creation" AND Target.Process.Name:"sdiagnhost.exe" AND Source.Process.Name:"msdt.exe"

 

 

 

 

The query will identify a Console Host process (conhost.exe) spawning from the Scripted Diagnostics Native Host process (sdiagnhost.exe).

This is a high confidence query with a low positive rate in the test environment.

This detection works for all tested payload variants i.e. cmd commands, PowerShell commands and executable payloads.

 

Type:"Process Creation" AND Target.Process.Name:"conhost.exe" AND Source.Process.Name:"sdiagnhost.exe"

 

 

 

 

This query will identify a Microsoft Diagnostic Tool (msdt.exe) process spawning with cmdline arguments indicative of this exploitation technique. Current PoC research has not identified a way for an adversary to obfuscate this cmdline call so this is a very high-level indicator with no false positives observed in test environment.

 

Type:"Process Creation" AND Target.Process.Name:"msdt.exe" AND (Target.Process.CommandLine:"ms-msdt\:-id" OR Target.Process.CommandLine:"ms-msdt\:\/id")

 

 

 

Contributors