Category: Economics

Source: Securelist – Kaspersky

Headline: How ToddyCat tried to hide behind AV software

To hide their activity in infected systems, APT groups resort to various techniques to bypass defenses. Most of these techniques are well known and detectable by both EPP solutions and EDR threat-monitoring and response tools. For example, to hide their activity in Windows systems, cybercriminals can use kernel-level rootkits, in particular malicious drivers. However, in the latest versions of Windows, kernel-mode drivers are loaded only if digitally signed by Microsoft. Attackers get round this protection mechanism by using legitimate drivers that have the right signature, but contain vulnerable functions that allow malicious actions in the context of the kernel. Monitoring tools track the installation of such drivers and check applications that perform it. But what if a security solution performs unsafe activity? Such software enjoys the trust of monitoring tools and doesn’t raise suspicions.

And that’s precisely what ToddyCat attackers exploited by running their tool in the context of a security solution.

Detection

In early 2024, while investigating ToddyCat-related incidents, we detected a suspicious file named version.dll in the temp directory on multiple devices.

This 64-bit DLL, written in C++, turned out to be a complex tool called TCESB. Previously unseen in ToddyCat attacks, it is designed to stealthily execute payloads in circumvention of protection and monitoring tools installed on the device.

Kaspersky products detect this tool as Trojan.Win64.ToddyCat.a, Trojan.Win64.ToddyCat.b.

DLL proxying

Static analysis of the DLL library showed that all functions exported by it import functions with the same names from the system file version.dll (Version Checking and File Installation Libraries).

This indicates that the attackers use a DLL-proxying technique (Hijack Execution Flow, T1574) to run the malicious code. By means of this technique, a malicious DLL exports all functions of a legitimate one, but instead of implementing them, redirects calls to these functions to the original DLL. This way, an application that loads the malicious library will continue to work as normal, with the malicious code running in the context of this application in the background.

However, this is not enough to launch malware. For a malicious DLL to be able to take control, the application that loads it must contain insecure code. Such code searches for loaded dynamic library images in folders where they should not be located. If one of these folders contains a malicious library, the vulnerable application will load it instead of the legitimate one. Microsoft has an official advisory on preventing unsafe DLL loading.

CVE-2024-11859 vulnerability in ESET Command line scanner

It took us a while to find the file that loads the TCESB tool. We studied the system directories on devices where the malicious DLLs were found. On one of these, in the same folder as TCESB, there was an extensionless executable file named ecls. We believe that the operator, when transferring files to the device, made a mistake in the filename and moved two copies of it. After performing malicious activity, the file with the extension was deleted, while the other one remained in the system. This file turned out to be a component of ESET’s EPP solution – a scanner launched from the command line (ESET Command line scanner). Dynamic analysis showed that the scanner insecurely loads the system library version.dll, first checking for the file in the current directory, then searching for it in the system directories. This can result in a malicious DLL library being loaded, which constitutes a vulnerability. We compiled a report with a detailed description of it, and sent it to ESET as part of the Coordinated Vulnerability Disclosure process. ESET registered the CVE-2024-11859 vulnerability, then on January 21, 2025 released an update for the ecls file patching the security issue. On April 4, information about this vulnerability appeared in an ESET security advisory.

To analyze TCESB, we ran it in a virtual environment. In the address space of the ESET Command-line scanner process, we can see two version.dll files. One is the system library, the other is the DLL of the TCESB tool.

Basic functionality

To determine the main functions of the malicious tool, we examined the strings located in its DLL.

The strings are not obfuscated. The search shows that most of them belong to the open-source malicious tool EDRSandBlast, designed to bypass security solutions. Kaspersky solutions detect it with the verdict HEUR:HackTool.Win64.EDRSandblast.a. ToddyCat created the TCESB DLL on its basis, modifying the original code to extend the malware’s functionality. The resulting tool’s capabilities include modifying operating system kernel structures to disable notification routines, for example, about a process creation event in the system or a load event.

Searching for addresses in the kernel memory

To find the structures in the kernel memory needed to disable notification routines, TCESB determines the version of the Windows kernel in the context of which it is running. To do this, it uses the GetNtoskrnlVersion() function.

Next, to get information about the memory offsets of the structures corresponding to the operating system kernel version, TCESB uses one of two data sources: a CSV or PDB file.

First, the tool checks the CSV file contained in its own resources section. Stored there in table form is information about several popular kernel versions and their corresponding offsets.

TCESB searches this file line by line for a match with the previously obtained version of the current Windows kernel.

We studied the CSV file in the EDRSandBlast repository and its change history. The contents of the TCESB CSV fully match the CSV data in the EDRSandBlast version of August 13, 2022, while the original malware commit of October 6, 2023 adds lines that are missing in the TCESB resource. This indicates a time period during which the creators of TCESB used the EDRSandBlast code.

If the CSV file does not contain data on structures corresponding to the required kernel version, TCESB reads their addresses from the PDB file. To get it, the malware accesses the file C:WindowsSystem32ntoskrnl.exe, which contains information about the kernel file version, and inserts the data from this file into the following template, generating a URL:

This is the address of Microsoft debug information server, where TCESB sends a GET request to download the PDB file. The received file is saved in the current TCESB directory, and data on the offsets of the required kernel memory structures are read from it.

Vulnerable driver

To modify the kernel structures that store callbacks used to notify applications of system events, TCESB deploys the Bring Your Own Vulnerable Driver (BYOVD) technique (Exploitation for Defense Evasion, T1211). It does this by installing a vulnerable driver in the system through the Device Manager interface, using an INF file with installation information.

TCESB uses the Dell DBUtilDrv2.sys driver, which contains the CVE-2021-36276 vulnerability. This is a utility driver used to update PC drivers, BIOS and firmware.

Launching the payload

Once the vulnerable driver is installed in the system, TCESB runs a loop in which it checks every two seconds for the presence of a payload file with a specific name in the current directory – the payload may not be present at the time of launching the tool. Presumably, this is to allow the operator to verify that the tool was run without errors, so that the payload file can be moved without risk of detection. As soon as the file appears in the path being checked, it is passed to the decryption function.

The tool creates its own log file for recording all stages of execution in detail.

We studied two samples of the TCESB tool. Although we were unable to obtain the payload files, our research shows that they have different names ( kesp and ecore) and both are extensionless.

Our analysis of the tool code found that the data in the payload file is encrypted using AES-128.

The decryption key is in the first 32 bytes of the payload file, followed by the encrypted data block. Below is a snippet of code for reading the key:

The key decrypts the data block:

The read data is placed in memory and executed.

Takeaways

We discovered a sophisticated tool that the ToddyCat APT group tried to use for stealth execution in compromised systems. This tool exploits a chain of vulnerabilities, as well as an old version of a known open-source malware that the attackers modified to extend its functionality.

To detect the activity of such tools, it’s recommended to monitor systems for installation events involving drivers with known vulnerabilities. Lists of such drivers can be found on the loldrivers project website, for example. It’s also worth monitoring events associated with loading Windows kernel debug symbols on devices where debugging of the operating system kernel is not expected. We also advise using operating system tools to check all loaded system library files for the presence of a digital signature.

Indicators of compromise

Malicious Files Hashes

D38E3830C8BA3A00794EF3077942AD96       version.dll 008F506013456EA5151DF779D3E3FF0F       version.dll

Legitimate file for DLL proxying

8795271F02B30980EBD9950FCC141304       ESET Command-line scanner

Legitimate files for BYOVD

B87944DCC444E4C6CE9BB9FB8A9C0DEF       dbutildrv2.INF DE39EE41D03C97E37849AF90E408ABBE       DBUtilDrv2.cat DACB62578B3EA191EA37486D15F4F83C       dbutildrv2.sys