The Good | Police Unmask 200 LockBit Affiliates

Following the takedown of their operations earlier in the year, the inner workings of LockBit’s affiliate infrastructure have become clearer this week as investigations continue. The UK’s National Crime Agency, with assistance from the FBI, have reportedly matched a list of pseudonyms used by the ransomware gang to suspected cybercriminals.

So far, investigators have been able to link some 200 affiliates of LockBit who were using nondescript usernames to real world identities. The NCA’s senior officer on the case further confirmed that authorities have been able to connect specific affiliates back to particular cyberattacks. As the investigations carry on, all details collected are helping law enforcement to pursue more of the gang’s influential members, as well as any associated money launderers and malware developers.

Over the past three years, LockBit’s Ransomware-as-a-Service (RaaS) operations have left a long line of victims in its wake, with their ransom demands totalling at least $120 million.

Despite a dramatic takedown in February and having a senior administrator sentenced in March, LockBit lingers on through a new blog and data leak site, though lacking its prior momentum. Still, the gang’s ringleaders remain at large and cyber defenders continue to monitor for signs of rebranding – a strategy used by Hive and predecessors of BlackCat/ALPHV. Law enforcement’s efforts in matching up outstanding LockBit usernames to known criminals is a major step in disrupting LockBit’s new and future operations.

The Bad | New Phishing Campaign Drops Multi-Stage Malware via SVG Files

Security researchers this week reported on a complex cyberattack leveraging phishing emails to spread a wide range of malware, including Venom RAT, Remcos RAT, XWorm, NanoCore RAT, and a crypto wallet stealer.

In this wave of phishing attacks, the threat actor emails fake invoices in the form of Scalable Vector Graphics (SVG) files, which trigger the infection process after the victim engages. Researchers pegged this technique to the use of BatCloak malware obfuscation engines and a crypter called ScrubCrypt to deliver obfuscated batch scripts carrying the malware.

According to the report, the SVG file drops a ZIP archive containing a batch script, likely crafted using BatCloak, which unpacks the ScrubCrypt batch file to deploy Venom RAT. The remote access trojan then establishes control over compromised systems, executing commands from a command-and-control (C2) server.

The threat actors has been observed using various methods to distribute additional plugins, including NanoCore RAT, XWorm, and Remcos RAT, with Remcos RAT distributed through obfuscated VBS scripts, ScrubCrypt, and GuLoader PowerShell. Finally, a stealer component targets crypto wallets and applications like Atomic Wallet and Telegram to send stolen data to a remote server.

Accounting for the multiple layers of obfuscation and plugin deployment via different payloads, the campaign demonstrates threat actors’ efforts to stay versatile in their approach in order to persist and evade detection<. Pairing consistent monitoring capabilities with cyber hygiene surrounding email security continues to be an effective approach to minimizing threats from increasingly intricate phishing campaigns.

The Ugly | Bug in Rust Could Allow Command Injection Attacks

Codenamed BatBadBut, a new and critical vulnerability (CVE-2024-24576) could allow threat actors to target Windows systems and execute command injection attacks. The flaw, rated 10/10 CVSS, arises from weaknesses in OS command and argument handling in a number of programming languages, including Rust.

BatBadBut permits remote exploitation by unauthenticated attackers without user interaction. The bug only impacts Windows and only when programs or their dependencies execute batch files with untrusted arguments. In their security advisory, the Rust Security Response Working Group attributed the flaw to improper argument escaping when invoking batch files on Windows using the Command API.

The flaw affects all Rust versions prior to 1.77.2. Addressing the complexity of parsing rules in cmd.exe, Rust’s security team have since enhanced the escaping code and Command API to mitigate the risk. They have also introduced an InvalidInput error if the Command API fails to safely escape arguments during process spawning.

Today, Rust 1.77.2 will be released with a critical security patch to the standard library for those on Windows using the Command API to invoke batch files with untrusted arguments. No other platform or use is affected.

See the announcement for details: https://t.co/uaLYGDjc2r

— Rust Language (@rustlang) April 9, 2024

Maintainers of other languages have either updated their documentation or provided a patch, with the exception of Java, which currently has a status of ‘Won’t fix’.

The emergence of CVE-2024-24576 draws attention back to a February statement made by the National Cyber Director who called for widespread adoption of memory-safe programming languages (like Rust) to bolster their software security. A report released by the White House also promoted tech manufacturers to be proactive about reducing risk by adopting memory-safe programming languages in their operations.

On Mar 29, 2024 details emerged about CVE-2024-3094, a vulnerability impacting the xz compression libraries used by Linux distributions.

The backdoor code was distributed to all rolling distributions. However, it was tailored to target distributions such as Debian and Fedora, which patch their SSH daemon with liblzma. Further, the backdoor scripts included system checks to guarantee that the object files were solely injected into Debian and Fedora distributions.

SentinelOne analyzed the technical implementation of the xz backdoor and the differences between the two versions. In this blog post, we describe and explore how subtle changes made by the threat actor in the code commits suggest that further backdoors were being planned.

XZ Compromise | A Technical Breakdown

In the first iteration of the compromise (version 5.6.0), the actor successfully added code to the xz repository that enabled injection of the backdoor on Debian and Fedora distributions. However, the second iteration (version 5.6.1) adds significantly more maturity by introducing the ability to execute additional shell scripts during the build phase via binary test blobs, presumably to make future updates to the backdoor less suspicious.

The injection of malicious shell scripts occurs during the execution of the configure command, which then inserts code inside the Makefile to build and replace object files with backdoor-infected counterparts.

Although the backdoor and its functionality remain the same across both versions, the setup to inject and replace object files differs. These discrepancies offer insights into the motivation and long-term plan of the threat actor.

Initial Setup

The first piece of the backdoor is the m4/build-to-host.m4 file. This file orchestrates minor modifications and conceals the extraction and execution of the Stage 1 backdoor file, bad-3-corrupt_lzma2.xz.

Note how the grep command matches one file in the source directory:

The actor introduced several new files that contributed to setting up Stage 2 of the backdoor in a later commit with the description, “Tests: Add a few test files”.

The next step extracts and stores the script from the bad-3-corrupt_lzma2.xz file within the variable gl_[$1]_config.

Here, the extracted script is executed, marking the progression towards the Stage 1 payload of the attack cycle.

Stage 1 Payload | System Checks & Extraction

The Stage 1 payload can be extracted from the bad-3-corrupt_lzma2.xz file via the following command:

cat bad-3-corrupt_lzma2.xz | tr "t -_" " t_-" | xz -d

This payload is responsible for extracting the Stage 2 payload from good-large_compressed.lzma and executing the setup script. There are several variables defined in this step that will be utilized in the later stages.

Another notable feature of this stage is the repeated use of the head command to discard 1024 bytes (1 KB) but use other 2048 bytes (2 KB) in a cyclic manner. This layer of obfuscation extracts another payload and removes junk data used to hide the payload, as shown in the following code from version 5.6.0:

This stage in version 5.6.1 has several differences from the previous version. One notable distinction is the inclusion of an operating system check to ensure that the backdoor is injected only when built on a Linux machine, which repeats five times.

Additionally, minor variations include changing the final byte count in the head command from 724 to 939, and adjusting the argument for the tr utility to account for this modified offset.

Following extraction, this payload is executed by piping it to bash, which advances the attack chain to Stage 2.

Stage 2 Payload | Injecting The Backdoor

The Second Stage Payload is responsible for the extraction, injection and cleaning of the backdoor files on Debian and Fedora builds. The script is broken in two execution phases:

• Phase 1: executed during the configure command; injects code into the makefile
• Phase 2: executed during the make command; injects the backdoor in object files

The script injects code in the makefile to execute the malicious code by running the make command. The script is aware of the phase it is executing in by checking the presence of config.status file and .libs/liblzma_la-crc64_fast.o.

This stage differs between versions. We believe the newer version seeks to make the backdoor modular so that other payloads could be injected down the line without adding new code to the build files.

The script defines several environment variables that should be considered indicators of compromise when present on a system:

• is_arch_extension_supported : a check that is replaced by _get_cpuid from a malicious object file
• __get_cpuid: function that is replaced by malicious function exported in the backdoor object file
• Good-large_compressed.lzma and bad-3-corrupt_lzma2.xz: Files that contain setup scripts for the backdoor

This step enables several checks which are performed before the backdoor is injected during the build process:

• Checks that the GCC compiler is installed
• Checks that the operating system is Linux and that the distribution is Debian or Fedora
• Checks for the presence of a file named config.status

During this stage, the difference between versions 5.6.0 and 5.6.1 becomes significant. In 5.6.1, the threat actor introduced a code snippet aimed at enhancing the modularity of the backdoor. This modification enables the potential injection of different variants via test files in subsequent stages.

If any test file exists within the directory srcdir/tests/files/ and contains the magic bytes ~!:_ W and |_!{ -, the file will be unpacked and subsequently processed to execute the embedded scripts.

This enables the threat actor to deploy multiple backdoors in upstream packages through binary test files without arousing suspicion in the commit tree. These test binary blobs typically serve the purpose of stress-testing compression algorithms, pushing them to their limits by providing unconventional binary data for decompression.

This backdoor feature addresses a significant challenge faced by the threat actor during the development of the backdoor in version 5.6.0. The commit history shows the actor fabricated a pretext to commit new test files in order to update the backdoor.

Such functionality isn’t limited to a single instance. Another similar code snippet can be observed in the elif branch of the script executed during phase 2: make command execution. In this case, a check for magic bytes jV!.^% and %.R.1Z is performed, but the core extraction and execution of the script remain unchanged.

The remaining part of Stage 2 is consistent across both versions. The backdoored object file is extracted from the file good-large_compressed via an intricate awk command.

This segment is an implementation of a modified RC4 algorithm, which decrypts the payload after processing the compressed data, and writes it to liblzma_la-crc64-fast.o. The process remains identical in both versions, differing only in the bytes that are written.

The backdoor leverages ifunc resolvers, a feature of glibc and a recent addition to the xz project. These resolvers enable developers to have multiple implementations of a function and dynamically select which one to use at runtime through a resolver function. In this context, the backdoor replaces existing functions, i.e crc32_resolve() and crc64_resolve(), to execute different code discreetly. This mechanism provides an ideal means to execute the backdoor’s code without raising suspicion.

The script then proceeds to modify the source code of crc64_fast.c and compile it dynamically to incorporate ifunc resolvers, linking the backdoored liblzma_la-crc64_fast.o. Once the backdoor is successfully linked and set up, the script initiates cleanup to remove the artifacts used to build the backdoor.

Analysis of Attack Execution

The overall compromise spanned over two years. Under the alias Jia Tan, the actor began contributing to the xz project on October 29, 2021. Initially, the commits were innocuous and minor. However, the actor gradually became a more active contributor to the project, steadily gaining reputation and trust within the community.

• Pressure emails
  While Jia Tan made active contributions to the project, the project maintainer Lasse Collin started receiving emails from different people that pressured Lasse to transfer maintainership of the project to Jia. It’s possible that these emails were orchestrated as part of the operation, purportedly originating from non-existent individuals.
• Addition Of Modularity in 5.6.1 release
  As outlined above, features that allow the build scripts to directly execute code from test binary files were added in the 5.6.1 release to the backdoor. This change indicates the actor planned to infect the xz repository with other vulnerabilities as well. This statement is also supported by the later commit made to break the LandLock functionality in xz util (not liblzma).
• Git Commit Forgery (disabling LandLock)
  The commit made February 28 2024 breaks the C program that is used to check support for LandLock. Landlock is a Linux kernel process sandboxing feature that restricts the rights of a set of processes, which would give the attacker more latitude to infect an impacted system. These commits are made under author Lasse Collin. It is possible commits were forged for these changes.

Attribution

The attribution of the operation and the intended targeting are currently unknown. Based on the sophistication and long timeframe required to execute this attack, we believe the actor is likely a state-aligned entity. It is plausible that this operation was outsourced by someone without necessarily revealing the true target of interest.

Conclusion

The operation that led to the xz backdoor demonstrates the risk of supply chain attacks in Open Source Software (OSS) projects. Open Source is often deemed safe from such attacks, given its scrutiny by a multitude of contributors, making it improbable to implant malicious code without detection.

The operation exploited gaps in the reputation process and the absence of audits on released tarballs. Moreover, commits to the LandLock functionality, along with code changes between versions, underscored the actor’s intention to introduce additional backdoors and sustain access to the repository.

SentinelOne is closely monitoring this supply-chain attack. SentinelOne Singularity detects malicious behaviors attempted by an adversary via this backdoor.

Indicators of Compromise

Imagine if hunting for emerging threats was as straightforward as asking a colleague a simple question in plain language. Today, I’m excited to announce that SentinelOne has turned this into a reality with the launch of Purple AI.

Last April, we unveiled a first-of-its-kind AI-assisted platform that fuses data from SentinelOne’s real-time, embedded neural networks with a large language model (LLM)-based natural language interface to simplify threat hunting and help analysts boost productivity and scale their operations.

Today, we are excited to announce that Purple AI, the industry’s most advanced AI security analyst, is now generally available worldwide. Purple AI helps security teams detect earlier, respond faster, and stay ahead of attacks. It radically accelerates threat hunting, investigations, and response so security teams can save time, reduce costs, and better protect their environments.

Scaling Autonomous Protection Across the Enterprise

Purple AI is a force multiplier for security teams. It translates natural language questions into sophisticated PowerQueries within seconds, facilitates deep log analysis of native and third-party data, and provides one-click hunting quickstarts, suggested queries, and shareable investigation notebooks.

Early adopters perceived threat hunting with Purple as 80% faster, and 78% of those surveyed found investigation notebooks to be very or extremely helpful.

“The security insights provided by Purple AI have surpassed anything PruittHealth had before,” said Richard Bailey, SVP of IT at PruittHealth Connect Inc. “Purple AI assists in identifying weaknesses and vulnerabilities, thus bolstering PruittHealth’s overall security. Additionally, it enhances accuracy and reduces human error in data queries, allowing more time for other tasks.”

Maximizing the SOC’s Full Potential

Today’s security teams are dealing with a sophisticated threat landscape and endless alert queues that grow far faster than what teams can even hope to resolve. Staying ahead of adversaries requires both innovation and scalability, and Purple AI was specifically designed to empower your team to maximize their productivity.

Purple provides the following key benefits:

• Simplifying the Complex – Querying your Singularity Data Lake is as easy as asking a colleague a question. Simply ask Purple a question like, “Am I being targeted by FIN12?” without needing to reference data schemas or create complex queries. This enables faster and more effective threat hunting for every analyst.
• Up-Leveling the Entire SOC Team – Investigation notebooks make whole teams more efficient. Notebooks are auditable and shareable, and early adopters have used this as a knowledge-amplification tool. Senior analysts write plain language queries shared in an investigation notebook with their colleagues, which makes their expertise more accessible.
• Taking Hunts from Hours to Minutes – Accelerate SecOps with AI-powered analyses, auto-summaries, and suggested next queries. Purple AI provides pre-populated threat hunting ‘quick starts’ and uses the latest threat intelligence so analysts can begin a hunt with a single click.
• Safeguarding Your Data – Purple is designed for data protection and privacy by design. It is never trained with customer data and is architected with the highest level of safeguards.

What’s the Purple AI Difference?

As criminals around the world are starting to leverage AI-based, automated tools to execute malicious attacks, SentinelOne is taking this technology to help enterprises control all aspects of their security posture, from visibility and response, to supercharging SecOps and building long-term cyber resilience.

Speed & Visibility One Console, Platform & Data Lake

Responding to emerging threats requires both speed and deep visibility. Purple AI provides both, so analysts can see the full picture within the Singularity Platform. This means one unified console built on top of the industry’s most performant data lake for lightning-fast queries.

Purple AI is also the only AI security platform that supports the widely adopted Open Cybersecurity Schema Framework (OCSF), providing analysts with full data visibility and a single normalized view of native and partner data.

Threat Hunting Quickstarts & Guided Investigations

One of modern SOC teams’ biggest challenges is dealing with alert fatigue, which precludes proactive threat hunting and leads to missed notifications and burnout. Purple AI takes an intelligent, action-oriented approach to make threat hunting simple.

Security analysts are able to reduce critical MTTD through the Purple AI quickstart library, which provides suggested prompts to kick off investigations in natural language with a single click. Further, Purple will provide contextual suggested next queries to help analysts conduct faster, deeper investigations to better understand and mitigate critical risk.

Accelerated Collaboration Across the Board

Purple goes far beyond the now-popular chatbot experience. It helps analysts conduct deeper investigations that they can share across teams with auditable and auto-saved investigation notebooks. Since security analysts can now use natural language to conduct investigations, this means that the notebooks become artifacts they can share even with management and leadership teams without investing additional effort to make them understandable.

Open & Reliable AI

Purple AI focuses on transparency, prioritizing SentinelOne’s commitment to security and privacy. The platform employs the highest level of safeguards to protect and ensure you own your data, and models are not trained using customer data or requests. Purple is also designed so that SOC teams can easily view query translations for verification and analyst training.

Conclusion | Learn More About Purple AI

Purple AI is set to enhance the threat hunting experience for modern enterprises and provide security professionals with the tools they need to secure today, tomorrow, and beyond. Saving time and maximizing resources through Purple AI ensures enterprises can focus on business-critical operations and build up a strong and lasting cyber posture against even the most sophisticated threats.

Book a demo with the SentinelOne team to learn more about how Purple AI can help untap the potential of your security teams.