{"id":25072,"date":"2024-08-14T11:21:29","date_gmt":"2024-08-14T19:21:29","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2024\/08\/14\/news-18802\/"},"modified":"2024-08-14T11:21:29","modified_gmt":"2024-08-14T19:21:29","slug":"news-18802","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2024\/08\/14\/news-18802\/","title":{"rendered":"Ransomware attackers introduce new EDR killer to their arsenal"},"content":{"rendered":"

Credit to Author: Andrew Brandt| Date: Wed, 14 Aug 2024 16:00:19 +0000<\/strong><\/p>\n

\n

Sophos analysts recently encountered a new EDR-killing utility being deployed by a criminal group who were trying to attack an organization with ransomware called RansomHub. While the ransomware attack ultimately was unsuccessful, the postmortem analysis of the attack revealed the existence of a new tool designed to terminate endpoint protection software. We are calling this tool EDRKillShifter.<\/span>\u00a0<\/span><\/p>\n

Since 2022, we\u2019ve seen an increase in the sophistication of malware designed to disable EDR systems on an infected system, as customers increasingly adopt EDR tooling to protect endpoints. Sophos previously published <\/span>research about AuKill<\/span><\/a>, an EDR killer tool Sophos X-Ops discovered last year that was being sold commercially within criminal marketplaces.<\/span>\u00a0<\/span><\/p>\n

During the incident in May, the threat actors \u2013 we estimate with moderate confidence that this tool is being used by multiple attackers — attempted to use EDRKillShifter to terminate Sophos protection on the targeted computer, but the tool failed. They then attempted to run the ransomware executable on the machine they controlled, but that also failed when the endpoint agent’s CryptoGuard feature was triggered.<\/span>\u00a0<\/span><\/p>\n

How EDRKillShifter works<\/span>\u00a0<\/span><\/h3>\n

The EDRKillShifter tool is a “loader” executable \u2013 a delivery mechanism for a legitimate driver that is vulnerable to abuse (also known as a “bring your own vulnerable driver,” or BYOVD, tool).\u00a0 Depending on the threat actor’s requirements, it can deliver a variety of different driver payloads.<\/span>\u00a0<\/span><\/p>\n

There are three steps to the execution process of this loader. The attacker must execute EDRKillShifter with a command line that includes a password string. When run with the correct password, the executable decrypts an embedded resource named BIN and executes it in memory.<\/span>\u00a0<\/span><\/p>\n

The BIN code unpacks and executes the final payload. This final payload, written in the Go programming language, drops and exploits one of a variety of different vulnerable, legitimate drivers to gain privileges sufficient to unhook an EDR tool’s protection.<\/span>\u00a0<\/span><\/p>\n

\"A<\/a>
High-level overview of the loader execution process<\/figcaption><\/figure>\n

Peeling off the first layer<\/span>\u00a0<\/span><\/h3>\n

A superficial analysis reveals that all samples share the same version data. The original filename is Loader.exe and its product name is ARK-Game. (Some members of the research team speculated that the threat actor tries to masquerade the final payload as a popular computer game named ARK: Survival Evolved.)\u00a0<\/span>\u00a0<\/span><\/p>\n

The binary’s language property is Russian, indicating that the malware author compiled the executable on a computer with Russian localization settings.<\/span>\u00a0<\/span><\/p>\n

\"Version<\/a>
Version info of EDRKillShifter\u00a0as shown in CFF Explorer<\/figcaption><\/figure>\n

All samples require a unique 64-character password passed to the command line. If the password is wrong (or not provided), it won’t execute.<\/span>\u00a0<\/span><\/p>\n

\"Execution<\/a>
Execution fails if the user doesn’t provide the correct password into the console as the program executes<\/figcaption><\/figure>\n

When executed, EDRKillShifter loads an encrypted resource named BIN, embedded inside itself, into memory. It also copies that data into a new file named Config.ini and writes that file to the same filesystem location where the binary was executed.\u00a0<\/span>\u00a0<\/span><\/p>\n

The loader code then allocates a new memory page using VirtualAlloc, and writes the encrypted content into the newly allocated page. The malware then deletes the config.ini file and proceeds with decrypting the next set of payloads \u2013 the abusable driver and a Go binary. The loader uses a SHA256 hash of the input password as the decryption key of the second-layer payloads.<\/span>\u00a0<\/span><\/p>\n

\"Pseudocode<\/a>
Pseudocode of the EDRKillShifter malware second-layer decryption routine<\/figcaption><\/figure>\n

If the malware successfully decrypts the second-layer payloads, it creates a new thread and begins execution in that thread.<\/span>\u00a0<\/span><\/p>\n

Loading the final EDR killer into memory<\/span>\u00a0<\/span><\/h3>\n

The second stage is obfuscated through the use of a self-modifying code technique. During runtime, the second layer alters its own instructions. Since the actual executed instructions are only revealed during execution, additional tooling or emulation is required for analysis.\u00a0<\/span>\u00a0<\/span><\/p>\n

The figure below further illustrates the technique. The first section shows the beginning of the self-modifying code layer. All instructions after the first call in the disassembly are nonsense at this point. If we revisit the same instruction block after executing the first call, we see a different set of instructions. The first call modifies the next set of instructions, which then modifies the next set of instructions, and so on.\u00a0<\/span>\u00a0<\/span><\/p>\n

\"A<\/a>
The EDRKillShifter uses self-modifying code to change every subsequent instruction<\/figcaption><\/figure>\n

The sole purpose of the final, decoded layer is to load the final payload dynamically into memory and execute it.<\/span>\u00a0<\/span><\/p>\n

Analysis of the ultimate payload<\/span>\u00a0<\/span><\/h3>\n

All of the samples we analyzed executed a different EDR killer variant in memory. They are all written in Go and obfuscated (possibly through the use of an open-source tool named <\/span>gobfuscate<\/span><\/a>)<\/span>. Obfuscators are tools designed to hinder reverse engineering. There may be legitimate reasons for software engineers to obscure the software, such as to prevent competitors from stealing intellectual property. However, malware authors also use obfuscators to make it more difficult for security researchers to analyze malware.<\/span>\u00a0<\/span><\/p>\n

Most reverse engineers rely on this obfuscated data when analyzing malware written in Go, but in this case, this key data is obscured in the compiled code. Some of this information includes:<\/span>\u00a0<\/span><\/p>\n