Targeted attacks

XZ backdoor: a supply chain attack in the making

On March 29, a message on the Openwall oss-security mailing list announced the discovery of a backdoor in XZ, a compression utility included in many popular Linux distributions. The backdoored library is used by the OpenSSH server process sshd. On a number of systemd-based distributions, including Ubuntu, Debian and RedHat/Fedora Linux, OpenSSH is patched to use systemd features and is therefore dependent on the library (Arch Linux and Gentoo are not affected). The code was inserted in February and March 2024, mostly by Jia Cheong Tan – probably a fictitious identity. We suspect that the goal of the attack was to introduce exclusive remote code execution capabilities into the sshd process by targeting the XZ build process; and then to push the backdoored code out to major Linux distributions as a part of a large-scale supply chain attack.

Timeline of events

2024.01.19 XZ website moved to GitHub pages by new maintainer (jiaT75)
2024.02.15 “build-to-host.m4” is added to .gitignore
2024.02.23 two “test files” containing the stages of the malicious script are introduced
2024.02.24 XZ 5.6.0 is released
2024.02.26 commit in CMakeLists.txt that sabotages the Landlock security feature
2024.03.04 the backdoor leads to issues with Valgrind
2024.03.09 two “test files” are updated, CRC functions are modified, Valgrind issue is “fixed”
2024.03.09 XZ 5.6.1 is released
2024.03.28 bug is discovered, Debian and RedHat notified
2024.03.28 Debian rolls back XZ 5.6.1 to version 5.4.5-0.2
2024.03.29 an email is published on the oss-security mailing list
2024.03.29 RedHat confirms backdoored XZ was shipped in Fedora Rawhide and Fedora Linux 40 beta
2024.03.30 Debian shuts down builds and starts process to rebuild them
2024.04.02 XZ main developer acknowledges backdoor incident

While earlier supply chain attacks we have seen in Node.js, PyPI, FDroid, and the Linux kernel consisted mostly of atomic malicious patches, fake packages and typo-squatted package names, this incident was a multi-stage operation that came close to compromising SSH servers on a global scale.

The backdoor in the liblzma library was introduced at two levels. The source code of the build infrastructure that generated the final packages was modified slightly (by introducing an additional file build-to-host.m4) to extract the next stage script hidden in a test-case file (bad-3-corrupt_lzma2.xz). This script, in turn, extracted a malicious binary component from another test-case file (good-large_compressed.lzma) that was linked to the legitimate library during the compilation process to be shipped to Linux repositories. Major vendors in turn shipped the malicious component in beta and experimental builds. The XZ compromise was assigned the identifier CVE-2024-3094 and the maximum severity level of 10.

The attackers’ initial goal was to hook one of the functions related to RSA key manipulation. In our analysis of the hook process, we focused on the behavior of the backdoor inside OpenSSH, specifically OpenSSH portable version 9.7p1 (the latest version). Our analysis revealed a number of interesting details about the backdoor’s functionality.

• The attacker set an anti-replay feature to prevent possible capture or hijacking of the backdoor communications.
• The author used a custom steganography technique in the x86 code to hide the public key.
• The backdoor hooks the logging function to hide its logs of unauthorized connections to the SSH server.
• The backdoor hooks the password authentication function to allow the attacker to use any username/password to log in to the infected server without any further verification. It does the same with public key authentication.
• The backdoor has remote code execution capabilities that allow the attacker to execute any system command on the infected server.

It’s clear that this is a highly sophisticated threat. The attackers used social engineering to gain long-term access to the development environment and extended it with fake human interactions in plain sight. They have extensive knowledge of the internals of open-source projects such as SSH and libc, as well as expertise in code/script obfuscation used to initiate the infection process. A number of things make this threat unique, including the way the public key information is embedded in the binary code itself, complicating the recovery process, and the meticulous preparation of the operation.

Kaspersky products detect malicious objects associated with the attack as HEUR:Trojan.Script.XZ and Trojan.Shell.XZ. In addition, Kaspersky Endpoint Security for Linux detects malicious code in sshd process memory as MEM:Trojan.Linux.XZ (as part of the Critical Areas Scan task).

For more information, read our initial analysis, incident assessment and in-depth hook analysis.

DuneQuixote campaign targeting the Middle East

In February, we discovered a new malware campaign targeting government entities in the Middle East that we dubbed DuneQuixote. Our investigation uncovered more than 30 DuneQuixote dropper samples being actively used in this campaign. Some were regular droppers, while others were manipulated installer files for a legitimate tool called Total Commander. The droppers carried malicious code to download a backdoor that we dubbed CR4T. While we have only identified two of these implants, we strongly believe that there may be more in the form of completely different malware. The group behind the campaign took steps to prevent collection and analysis of its implants and implemented practical and well-designed evasion techniques in both network communications and the malware code.

The initial dropper is a Windows x64 executable file, written in C/C++, although there are DLL versions of the malware that provide the same functionality. Upon execution, the malware initiates a series of decoy API calls that serve no practical purpose. These calls are primarily string comparison functions that are executed without any conditional jumps based on the comparison results. The strings specified in these functions are snippets of Spanish poetry. These vary from one sample to the next, changing the signature of each sample to evade traditional detection methods.

The primary goal of the CR4T implant is to give attackers access to a console for command line execution on the infected computer. It also facilitates the download, upload and modification of files.

We also discovered a Golang version of the CR4T implant that has similar capabilities to the C version. A notable difference of this version is the ability to create scheduled tasks using the Golang Go-ole library, which uses Windows Component Object Model (COM) object interfaces to interact with the Task Scheduler service.

Through the use of memory-only implants and droppers masquerading as legitimate software that mimics the Total Commander installer, the attackers demonstrate above-average evasion capabilities and techniques. The discovery of both C/C++ and Golang versions of the CR4T implant highlights the adaptability and ingenuity of the threat actor behind this campaign.

ToddyCat: punching holes in your infrastructure

The threat actor ToddyCat predominantly targets government organizations in the Asia-Pacific region, primarily to steal sensitive data. In our previous article, we described the tools the attackers use to collect and exfiltrate files (LoFiSe and PcExter). More recently, we examined how this threat actor maintains constant access to compromised infrastructure, the information they are interested in and the tools they use to extract it.

Our investigation revealed that ToddyCat was stealing data on an industrial scale. To steal large volumes of data, attackers need to automate the data harvesting process as much as possible, and provide several alternative means to continuously access and monitor the systems they attack.

ToddyCat used several methods to accomplish this. One was to create a reverse SSH tunnel. They launched this using the SSH client from the OpenSSH for Windows toolkit, along with the library required to run it, an OPENSSH private key file, and a script, a.bat, to hide the private key file. The attackers transferred files to the target host via SMB using shared folders.

The threat actor also made use of the server utility (VPN Server) from the SoftEther VPN package for tunneling. This package is an open-source solution developed as part of academic research at the University of Tsukuba, which allows the creation of VPN connections using a variety of popular protocols, such as L2TP/IPsec, OpenVPN, MS-SSTP, L2TPv3, EtherIP and others.

Another way ToddyCat accessed remote infrastructure was by tunneling to a legitimate cloud provider: an application running on the user’s host with access to the local infrastructure can connect to the cloud through a legitimate agent and redirect traffic or execute specific commands.

Ngrok is a lightweight agent that can redirect traffic from endpoints to cloud infrastructure and vice versa. The attackers installed Ngrok on target hosts and used it to redirect command and control (C2) traffic from the cloud infrastructure to a specific port on those hosts.

They also used Krong, a proxy that uses XOR to encrypt the data passing through it, thereby concealing the content of the traffic to avoid detection.

After creating tunnels on the target hosts using OpenSSH or SoftEther VPN, the threat actor also installed the FRP client, a fast reverse proxy written in Go that allows access from the internet to a local server behind a NAT or firewall.

ToddyCat used various tools to collect data. They used one of the tools, which we named “cuthead” (the name came from the file description field of the sample we found), to search for documents. They used “WAExp”, a WhatsApp data stealer, to search for and collect browser local storage files containing data from the web version of WhatsApp. The attackers also used a tool called “TomBerBil” to steal passwords from browsers.

To protect against such attacks, we recommend that organizations add the resources and IP addresses of cloud services that provide traffic tunneling to the corporate firewall denylist. We also recommend limiting the range of tools administrators can use to remotely access hosts: other tools should either be prohibited or closely monitored as possible indicators of suspicious activity. In addition, employees should avoid storing passwords in browsers, as this helps attackers gain access to sensitive information. Moreover, reusing passwords across services increases the amount of data available to attackers.

Other malware

QakBot attacks with Windows zero-day

In early April we investigated the Windows DWM (Desktop Window Manager) Core Library Elevation of Privilege Vulnerability (CVE-2023-36033), which was previously discovered as a zero-day being exploited in the wild. While searching for samples related to this exploit and attacks using it, we found a curious document uploaded to VirusTotal on April 1. This document caught our attention because it had a descriptive file name indicating that it contained information about a Windows vulnerability.

Inside we found a brief description of a Windows DWM vulnerability and how it could be exploited to gain system privileges – all written in very poor English. The exploitation process described in this document was identical to that used in the previously mentioned zero-day exploit for CVE-2023-36033 – but the vulnerability was different.

The poor quality of the writing, and the fact the document was missing some important details about how to actually trigger the vulnerability, suggested that the vulnerability described was completely made up or was present in code that could not be accessed or controlled by attackers.

However, a quick check revealed that this was a real zero-day vulnerability that could be used to escalate privileges, so we immediately reported our findings to Microsoft. The vulnerability was assigned CVE-2024-30051 and a patch was released as part of Patch Tuesday on May 14.

We also began closely monitoring our statistics for exploits and attacks using this zero-day, and in mid-April we discovered an exploit. We have seen this zero-day used in conjunction with QakBot and other malware, and believe that multiple threat actors have access to it.

Kaspersky products detect the exploitation of CVE-2024-30051 and related malware with the following verdicts:

• PDM:Exploit.Win32.Generic;
• PDM:Trojan.Win32.Generic;
• UDS:DangerousObject.Multi.Generic;
• Win32.Agent.gen;
• Win32.CobaltStrike.gen.

Using the LockBit builder to generate targeted ransomware

Last year, we published our research on the LockBit 3.0 builder. Leaked in 2022, this builder greatly simplified the creation of custom ransomware.

The keygen.exe file generates public and private keys used for encryption and decryption. The builder.exe file generates the variant according to the options set in the config.json file. The whole process is automated by the build.bat script.

The builder also allows attackers to choose exactly what they want to encrypt. If they know enough about the target’s infrastructure, they can create malware tailored to the specific configuration of the target’s network architecture, such as important files, administrative accounts and critical systems.

This has allowed attackers to generate customized versions of this threat to suit their needs, making their attacks more effective.

In February, the international law enforcement task force Operation Cronos gained insight into LockBit’s operations after taking down the group. The operation involved law enforcement agencies from 10 countries. They were able to seize the group’s infrastructure, obtain private decryption keys and create a decryption toolset based on a list of known victim IDs obtained by the authorities. However, just a few days later, the ransomware group announced that it was back in action.

In a recent incident response engagement, we were faced with a ransomware attack that involved a ransomware sample created with the same leaked builder. The attackers were able to find the admin credentials in plain text. They created a custom version of the ransomware that used the account credentials to spread across the network and perform malicious activities, such as killing Windows Defender and deleting Windows Event Logs to encrypt data and cover its tracks. In one of our latest articles, we revisited the LockBit 3.0 builder files and analyzed the steps the attackers took to compromise the network.

Stealers, stealers and more stealers

Stealers are a prominent feature of the threat landscape. They are designed to harvest passwords and other sensitive data from infected computers that can then be used in other attacks, resulting in financial loss to the target. Over the past year we have published a number of public and private reports on newly discovered stealers. We recently wrote reports on Acrid, ScarletStealer and Sys01: the first two are new, the latter has been updated.

Acrid, a new stealer discovered in December 2023, is written in C++ for the 32-bit system, despite the fact that most systems are now 64-bit. Upon closer inspection, it became apparent that the authors had compiled it for a 32-bit environment in order to use the “Heaven’s Gate” technique, which allows 32-bit applications to access the 64-bit space to bypass certain security controls. This malware is designed to steal browser data, local cryptocurrency wallets, files with specific names (wallet.dat, password.docx, etc.) and credentials from installed applications (FTP managers, messengers, etc.). The collected data are zipped and sent to the C2.

Last January, we analyzed a downloader we dubbed “Penguish”. One of the payloads it downloaded was a previously unknown stealer called “ScarletStealer” – an odd stealer, since most of its functionality is contained in other binaries (applications and Chrome extensions) that it downloads. When ScarletStealer is executed, it checks for the presence of cryptocurrencies and crypto wallets by looking for certain folder paths (e.g., %APPDATA%\Roaming\Exodus). If anything is detected, it starts downloading the additional executables using PowerShell. Most ScarletStealer executables are digitally signed. This stealer is very underdeveloped in terms of functionality and contains many bugs, errors, and redundant code. Considering the effort it takes to install the malware through a long chain of downloaders, the last of which is Penguish, it’s strange that it’s not more advanced.

SYS01 (aka Album Stealer and S1deload Stealer), a relatively unknown malware that has been around since at least 2022, has evolved from a C# stealer to a PHP stealer. What hasn’t changed is the infection vector. Users are tricked into downloading a malicious ZIP archive disguised as an adult video via a Facebook page.

The archive contains a legitimate binary that sideloads a malicious DLL. This DLL opens an adult video and executes the next payload, which is a malicious PHP file encoded with ionCube. The executed PHP file calls a script, install.bat, which ultimately executes the next stage by running a PowerShell command. This layer is conveniently named “runalayer” and runs what appears to be the final payload called “Newb”. However, we found a difference between the latest version and the previous publicly disclosed versions of the stealer. The current stealer (Newb) includes functionality to steal Facebook-related data and send stolen browser data to the C2. It also contains backdoor functionality. However, we found that the code that actually collects the browser data sent by Newb is in a different sample named “imageclass”. It is not 100% clear how imageclass was pushed to the system; but looking at the backdoor code of Newb, we concluded with a high degree of certainty that imageclass was later pushed through Newb to the infected machine. The initial ZIP archive also contains another malicious PHP file, include.php: this has similar backdoor functionality to Newb and accepts many of the same commands in the same format.

ShrinkLocker: turning BitLocker into a ransomware utility

During a recent incident response engagement, we discovered ransomware called “ShrinkLocker” that uses BitLocker to encrypt compromised computers. BitLocker is the full-disk encryption utility built into Windows that is designed to prevent data exposure on lost or stolen computers.

ShrinkLocker is implemented as a sophisticated VBScript. If the script detects that it’s running on Windows 2000, XP, 2003 or Vista, it shuts down. However, for later versions of Windows, it runs the appropriate portion of its code for the specific operating system. ShrinkLocker shrinks the computer’s drive partitions by 100MB and uses this slack space to create a boot partition for itself. The malware modifies the registry to configure BitLocker to run with the attacker’s settings. It then disables and removes all default BitLocker protections to prevent key recovery and enables the numeric password protection option. The script then generates this password and initiates encryption of all local drives before sending the password and system information to the attacker’s C2 server. Finally, the malware deletes itself and reboots the system.

If the user tries to use the recovery option while the computer is booting, they will see a message stating that no BitLocker recovery options are available.

ShrinkLocker changes the labels of all system drives to the attacker’s email address instead of leaving a ransom note.

You can read our full analysis of ShrinkLocker here.