Taking down Turla: Balancing act between visibility & usability with ESET

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.

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.

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.

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.

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.

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.

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.