February 2024

ESET technology blocked 10 out of 13 Protection tests, and detected 111 out of 143 substeps

Once again, the MITRE Engenuity team has put together an incredible round of the MITRE Engenuity ATT&CK® Evaluations: Enterprise, this time using techniques inspired by the Turla threat actor. The substeps selected by MITRE Engenuity tested the visibility and protection provided by ESET security technology across the cyberattack chain, from initial access through system discovery and lateral movement to data exfiltration.

In the Protection tests, our technology detected and blocked most threats – ultimately foiling the two attacks conducted on Day 1 and Day 2.

On the Detection days, ESET Inspect demonstrated good overall visibility into the attacks, recording most substeps and thus equipping defenders with the capability of reconstructing the attacks despite the use of multiple techniques to obfuscate the chains of execution.

Protection tests

The Protection scenario divided 129 substeps into 13 tests; the first substep of each test was allowed to run, disregarding any blocking of a previous substep that would have prevented the attack from reaching this stage. Blocking a substep typically means detecting a file as malware or as a potentially unwanted/unsafe application, but it could also mean blocking a domain or IP address, or killing a process.

If all the substeps in a test are allowed to execute, the test is classified as None. If a security vendor’s technology blocks any substep within a test, it is classified as Blocked. ESET technology blocked 10 tests, in most cases at the first substep of the test.

Because the Protection tests give the attackers free rein to execute substeps at a later stage of the attack, blocking multiple tests demonstrates our capability of stopping an attack at multiple points, which is due to our multilayered approach to protection.

Notably, our technology protected against the following threats:

• malicious executables,
• a vulnerable, signed driver, and
• a password-spraying attack.

Figure 1 shows ESET endpoint security software detecting and deleting the executables delivered during the initial access stage of both attacks, thus stopping the attacks right from the start.

Figure 1. ESET endpoint protection detected the malicious executables delivered during initial access

Because we had enabled the detection of potentially unsafe applications in ESET endpoint security software, we also blocked the attempt to install a vulnerable, signed driver. The attackers attempted to use the bring your own vulnerable driver (BYOVD) technique by installing a legitimate, signed driver with a known vulnerability to exploit it and gain kernel-level privileges. ESET Inspect also detected this driver as a known-vulnerable driver; see Figure 2.

Figure 2. ESET Inspect detects the loading of a known-vulnerable driver

Figure 3 shows ESET endpoint protection blocking the use of NTLM for authentication – the mechanism used by the password-spraying attack from the internal network.

Figure 3. ESET endpoint protection blocked the use of NTLM for authentication in the password-spraying attack

In addition to ESET Firewall blocking these authentication attempts during the evaluation, our Brute-force attack protection directly blocks password-spraying attacks by denying connections from IP addresses detected in attempts to brute force credentials via the Server Message Block (SMB) protocol or Remote Desktop Protocol (RDP).

Detection days

In the Detection scenario, the ATT&CK Evaluation conducted two attacks comprised of 19 steps over two days. The evaluation not only recorded the detections generated for substeps, but also the level of visibility into substeps that may not have had accompanying detections. ESET Inspect detected or recorded 111 out of 143 substeps.

Plenty of useful and actionable data was available for the analyst sitting at the ESET Inspect console to uncover the attackers’ activity. Even when the adversaries pulled off many techniques to obfuscate the full chain of attack by using code injection, named pipes, service persistence, lateral movement to Windows and Linux machines, and installation of a Microsoft Exchange transport agent, ESET Inspect provided enough of the pieces for the analyst to put them back together.

We were especially pleased with detections of the following:

• Mimikatz pass-the-hash attack,
• TCP filter installation on a Linux machine, and
• Microsoft Exchange transport agent installation.

The Mimikatz implementation of the pass-the-hash technique opens a process using a specific access mask. By monitoring this mask, ESET Inspect detected the use of Mimikatz to move laterally; see Figure 4.

Figure 4. ESET Inspect detects the Mimikatz pass-the-hash attack

When the attackers created and attached a TCP socket filter on a Linux machine, ESET Inspect detected these events too, signaling to defenders the presence of network sniffing; see Figure 5.

Figure 5. ESET Inspect detects the creation and attachment of a socket filter to sniff network traffic on a Linux machine

These Linux detections demonstrate some of the improvements brought to ESET Inspect since the previous round of the ATT&CK Evaluations: Enterprise, which tested version 1.6 whereas this year’s tested version 1.10.

Finally, to commandeer a Microsoft Exchange server, the attackers attempted to install an Exchange transport agent via PowerShell. However, ESET Inspect monitors the installation and enabling of transport agents, and can kill the PowerShell process and thus block the installation attempt; see Figure 6.

Figure 6. ESET Inspect detects the installation and enabling of an Exchange transport agent

Custom detections

One of the benefits of the MITRE Engenuity ATT&CK Evaluations is to help refine the balance between usability and visibility that we strive to achieve in detections by ESET Inspect. When a substep was visible in ESET Inspect but not pointed out by a detection, we created a new detection that, during a rerun, allowed the substep to be detected as well. MITRE Engenuity marked such enhancements in the detection results with the configuration change tag. These new detections are certainly noteworthy, but ultimately they will have to prove their value against real-world data before we decide to include them in a future version of ESET Inspect.

Even if these detections do not make the cut, customers may be interested in the capability to create custom detections in ESET Inspect. An open detection engine allows customers to adapt ESET Inspect to their specific detection needs – a feature not available in all XDR solutions.

Missed substeps

We classify the missed substeps on the Detection days into two groups. First, substeps that we assess provide the analyst with little to no value and almost no loss of information for reconstructing the attack. Second, substeps that add value for the analyst, which will be further assessed for possible inclusion in ESET Inspect.

Most missed substeps belong to the first group. For example, many substeps tested the product’s visibility into the very common actions of compressing, encoding, or encrypting data. Detecting such actions is generally only useful if what was compressed, encoded, or encrypted is also tracked, but this significantly increases data storage needs and imposes a huge hit on performance – both undesirable consequences for the security analyst to handle.

In the second group, an example substep that provides high value is writing executables to and reading executables from named pipes. Adding detections to ESET Inspect for these events could help the analyst reconstruct obfuscated process trees more easily and they are events expected to have low false positive rates on real-world data.

Putting the ATT&CK Evaluations in context

The MITRE Engenuity ATT&CK Evaluations are undoubtedly a solid reference point for understanding an XDR solution’s detection and response capabilities. However, the best solution is not necessarily the one that detects every substep, but rather the one that balances visibility with usability, placing the needs of the security analyst at the forefront.

Thus, when assessing an XDR solution, remember to zoom out and consider broader criteria than just how many detections were triggered in any given test, as these factors are just as indispensable. A complete assessment should include at least the following:

• false positives,
• performance,
• data storage,
• cost of detecting frequently occurring events,
• customization of detections and responses,
• integration with external data sources and other security tools,
• endpoint security detection capability,
• multiplatform support,
• security needs of your network, and
• vendor support services.

Putting the ATT&CK Evaluations in this context helps you better understand the full array of benefits that an XDR solution offers. We hope that this summary of ESET’s results and perspectives on the Evaluations has sparked your curiosity to explore the evaluation of ESET Inspect further on the results page provided by MITRE Engenuity.

* The views and opinions expressed in this blog are those of ESET and do not necessarily reflect the views or positions of any entities they represent.