Countering Follina Attack (CVE- 2022-30190) with Trellix Network Security Platform’s Advanced Detection Features

By Vinay Kumar and Chintan Shah · July 19, 2022

Executive summary

During the end of May 2022, independent security researcher reported a vulnerability (assigned CVE-2022-30190) in Microsoft Support Diagnostic Tool (MSDT), which could be exploited to execute arbitrary code when MSDT is called using URI protocol. The URI protocol ms-msdt:/ could also be invoked from the malicious word document, which when opened by the victim, would allow malicious code to execute on the target machine with the privileges of the calling application. In response to the reported vulnerability, Microsoft released the advisory and guidance on disabling the MSDT URI protocol. Subsequently, the vulnerability, was patched in the June security updates released by Microsoft. Since then, this vulnerability has been found to be exploited by multiple state actors in targeted attack campaigns.

At Trellix, we are committed to protecting our customers from upcoming and emerging threats on the network inclusive of those that are found being exploited in the wild. Trellix Network Security Platform’s (Trellix NSP) Intrusion Prevention Research Team strives to build advanced detection features , improving product’s overall Threat Detection capabilities.

Over the next few sections of this blog, we will highlight couple of advanced detection features in Trellix NSP, which helps in protecting the customers against this and future attacks of similar nature.

Introduction

MS Word document exploiting Microsoft Support Diagnostic Tool vulnerability ( CVE- 2022-30190 ) was first found to be submitted to VT on 27th May 2022 from Belarus with the file name 05-2022-0438.doc. However, the number 0438 turns out to be the Area code of the regionFollina in Italy and hence the name. Exploit document is not found to be connected to Italy in any way.

Figure 1: Sample submission history on VirusTotal

There is no dearth of instances where one of the MS Office’s core features, Object Linking and Embedding ( OLE ) have been abused as an initial attack vector and CVE-2022-30190 was no different. This was yet another classic example of chaining OLE with another logic flaw to achieve arbitrary code execution on the target machine. Traditionally, Object Linking and Embedding had significantly contributed to building weaponized office exploits, and we believe this will continue to happen. As with previous CVE-2021-40444 and many other exploits, OLE was found to be used for linking the document to the externally hosted object, in this case, html file.

MS Office Open XML specifications mentions that an Office Open XML document facilitates embedding objects or link to external objects which can be specified via relationships. Any embedded or linked object specified in the container application ( OOXML document in this case ) must be identified by its unique ProgID string. As per the specifications, this string must be used to determine the type and the application used to load the object data. An excerpt from the document specifications is as shown below:

Figure 2: Specs on Embedded objects

As documented in the ISO-29500-4 specifications ST_OLEType defines the type of the OLE object in document.xml, either linked or embedded and theProgID=”htmlfile”indicates the type of linked object data. As shown in the CVE-2022-30190 exploit document below,document.xml.relsfile with Type attribute specifying relationship as “oleObject”,Targetattribute set to the OLE object link andTargetMode set as external. This allows the crafted document to link to the externally hosted potentially malicious object and invoke the respective protocol handlers for rendering the object which could lead to the exploitation of potential logic flaws in object renderers.

Figure 3: Structure of exploit document

As we notice the document.xml.rels file, it contains an external reference to the malicious domain for retrieving the html file :

hxxps://www.xmlformats.com/office/word/2022/wordprocessingDrawing/RDF842l.html!. Hosted html file on this domain contains script block with commented lines. This is required for making the HTML file sufficiently sized ( precisely greater than 4KB ) to be able to get it processed and rendered by mshtml.dll.

Figure 4: downloaded html file from server

Subsequently, script tries to invoke PCWDiagnostic package using MSDT URI protocol handler with multiple arguments out of which one argument is IT_BrowseForFile which can take embedded PowerShell script within $( ) as an argument , resulting into code execution. PowerShell script is Base64 encoded and decoded form is of the script is as shown below.

Figure 5: Decoded PowerShell script

As we see in the decoded payload, the script is intended to run the malicious rgb.exe on the target system. Summarizing the sequence involved in the attack:

• Malicious MS office document with linked object is delivered to the victim possibly, as a part of phishing campaign.
• On clicking the document, malicious HTML script is rendered, leading to arbitrary code execution on the affected system.

Windows system registers innumerable number of URI protocol handlers which could be potentially abused to exploit similar flaws. For instance, search-ms URI protocol handler , used to query windows search indexing feature can be abused by the attackers to connect to the remote SMB share on the attacker-controlled server. However, it does not directly lead to code execution as it requires multiple levels of user interaction, but a query can be crafted to lure the users to execute legitimate looking executables as shown below. Both these of URI protocol attacks were first reported here.

Figure 6: search-ms query to connect to remote location

How Trellix NSP protects against Follina

Trellix NSP has been one of the most advance and mature IPS in the security industry. Over a period, we developed some of the cutting-edge features to deal with complex attack scenarios which involved handling encoding, compressions, and complex file formats. Microsoft Office Deep File Inspection andMulti Attack ID Correlation being some of these. We use combination of these advance capabilities to detect entire attack cycle. In the following sections, we will try to understand how Trellix Network Security Platform’s advanced inspection capabilities highlighted above can help correlate multiple low or medium severity events to detect phases in the attack cycle, thereby raising overall confidence level.

Microsoft Open Office XML(OOXML) file format

OLE File format which was traditionally used in Microsoft office is replaced with Office open xml. Office Open XML (OOXML) is a zipped, XML-based file format developed by Microsoft for representing spreadsheets, charts, presentations, and word processing documents. In a nutshell this means that the whole document is contained in a zip package. Multiple files and directories together form the document. There are directories like _[Content_Types].xml , rels, docProps, which are basic part of all office zip packages, and then there is a directory specific to document type (word directory for docx, xl and ppt directory for xlsx and pptx respectively). For each of the document type the specific directory would contain different files limited to the type. Like in case of a docx type, the ‘word’ directory contains document.xml file which has the core content of the document. Here is a brief overview about important files under these directories:

[Content_Types].xml
This file contains the MIME type information for parts of the package. It uses defaults for certain file extensions and overrides for parts specified by Internationalized Resource Identifier.

_rels
This directory contains the relationship information for files within the package.

_rels/.rels
This is the location where applications look first to find the package relationships.

docProps/core.xml
This file contains the core properties for any Office Open XML document.

word/document.xml
This file is the main part for any Word document.

Zip file format specification specifies that a file in the zip archive is stored in a file record structure. For each file in the zip archive, there is a corresponding entry of this structure.

[local file header 1]
[file data 1]
[data descriptor 1]
.
.
.
[local file header n]
[file data n]
[data descriptor n]

[archive decryption header]
[archive extra data record]
[central directory header 1]
.
.
.
[central directory header n]
[zip64 end of central directory record]
[zip64 end of central directory locator]
[end of central directory record]

These structures are placed one after another, structure starts with local file header followed by optional Extra Data Fields and file data (optionally compressed/optionally encrypted). Local header contains details about the file data, encryption/compression mechanism along with filename, file size and few more things.

Local file header

Offset	Byte	Description
0	4	Local file header signature # 0x04034b50 (read as a little-endian number)
4	2	Version needed to extract (minimum)
6	2	General purpose bit flag
8	2	Compression method
10	2	File last modification time
12	2	File last modification date
14	4	CRC-32
18	4	Compressed size
22	4	Uncompressed size
26	2	File name length (n)
28	2	Extra field length (m)
30	n	File Name
30+n	m	Extra Field
0	4	Local file header signature # 0x04034b50 (read as a little-endian number)
4	2	Version needed to extract (minimum)
6	2	General purpose bit flag

For Microsoft documents, deflate compression is used commonly. In a nutshell, the files which constitutes the document are stored in possibly encrypted/compressed format inside the zip package. In the figure below, we dissect this structure for document.xml file present under word directory with a hex editor (010 editor) with zip parsing capabilities which will help us to investigate the details –

Figure 7: Structure for document.xml

Need for deep file inspection

We have seen in the past that different vulnerabilities may require the IPS devices to examine the content of the different files present inside zip package. Same is the case with Follina. As explained earlier, this vulnerability abuses Microsoft OOXML Object Linking and Embedding functionality linking a file to external resource via the relationship file to load malicious content. Hence it requires the detection device to check the external references used in word/rels/document.xml.rels file.

Figure 8: Structure of document.xml.rels

Since this file is present, as a compressed entity in the zip archive, a meaningful detection with IPS cannot be done until the file is decompressed. With NSP’s unique in industry capability, known as Deep File inspection, this is possible.

This is implemented using protocol parsing capability of the NSP. The local file header structure for the specific file is parsed and the compressed data of the file is decoded. This feature can be used by enabling it from the inspection option policy.

Figure 9: Policy configuration to enable MS Office Deep File Inspection

For more details, please refer to NSP documentation

Some of the key highlights: deep file inspection

• This feature helps to decompress the file contents inline; the complete file is not required to be downloaded for inspection
• It also gives the flexibility to decompress only the content of a selected file (individual file present inside zip achieve), yielding better performance since the whole zip archive is not required to be decompressed .
• The individual files (which are part of zip package) can be controllably decompressed by specifying byte limit per file. This plays a great role in improving performance while doing inline inspection.

Trellix NSP Attack ID 0x452a8400 - HTTP: OLE Object Linking Detected in OOXML File – uses the Microsoft Office Deep file inspection feature to detect signs of external object linking. However, just checking for external OLE references will not be sufficient until it is ascertained that the external URI does the malicious activity. Since we know that external URI loads the HTML which invokes the MSDT handler in a malicious fashion.

Invoking MSDT through HTML content is detected by Trellix NSP Attack ID 0x452ac200 – HTTP: Microsoft Support Diagnostic Tool Remote Code Execution Vulnerability (CVE-2022-30190)

Detecting the attack chain using multi attack ID Correlation

The attack visualization is better when the dots can be connected between different stages of the attack. Multi Attack ID Correlation capability helps achieve this by correlating multiple attacks.

Trellix NSP Attack ID 0x43f02000 HTTP: Microsoft Support Diagnostic Tool RCE Vulnerability (CVE-2022-30190) utilizes this capability and correlates “HTTP: OLE Object Linking Detected in OOXML File (0x452a8400) ” and “HTTP: Microsoft Support Diagnostic Tool Remote Code Execution Vulnerability (CVE-2022-30190) (0x452ac200)” to generate corelated attack event.

The alert generated using Multi AID correlation is of high confidence and severity and helps security admins to take further actions. This feature is built into Trellix NSP by default and there is no extra configuration required to enable it.

Some of the key highlights: multi attack ID Correlation

• Two or more attacks can be correlated
• Provides capability to quarantine the attacker (configurable from the policy)
• Correlation using attributes like –
  • source-IP/destination IP: This attribute helps correlating attack originating from same source IP and/or targeted to the same destination IP .
  • Lifetime: max time interval in which all correlation signature event should occur
  • Threshold: Detection of attack happening repeatedly in a specific period.

With these strong correlation capabilities for the complete attack cycle, Trellix Network Security Platform’s Threat Detection solution balances the effectiveness and performance extremely well. The Trellix NSP research and Engineering team actively monitors and keeps an eye on emerging threat patterns ,builds the features and capabilities to enhance overall detection efficacy of the Intrusion Prevention System.

Conclusion

We have seen multiple vulnerabilities in the past using exploitation techniques similar in nature and this is yet another addition to the series. In our previous blog, outlining the current state of memory corruption vulnerabilities and the challenges faced in exploiting them, we also highlighted the exploitation strategies of the future and the Follina attack very well validates our prediction. While exploiting different classes of memory corruption vulnerabilities can be eliminated by introducing mitigations as either operating system or hardware level, vulnerabilities exploiting design flaws will remain a challenge. Perimeter and endpoint security solutions will have to evolve to address those challenges by introducing the innovative inspection and detection techniques alongside applying secure software design and development practices during application development.