Search This Blog

Powered by Blogger.

Blog Archive

Labels

Showing posts with label Rust. Show all posts

Security Defenses Crippled by Embargo Ransomware

 


There is a new gang known as Embargo ransomware that specializes in ransomware-as-a-service (RaaS). According to a study by ESET researchers published Wednesday, the Embargo ransomware group is a relatively young and undeveloped ransomware gang. It uses a custom Rust-based toolkit, with one variant utilizing the Windows Safe Mode feature to disable security processes.

ESET researchers say that the Embargo ransomware group is developing custom Rust-based tools to defeat the cybersecurity defenses put in place by companies and governments. There is a new toolkit that was discovered in July 2024 during an attack on US companies by ransomware and is made up of a loader and an EDR killer, MDeployer, and MS4Killer, respectively, which can also be accessed and downloaded online. There are several ways in which MS4Killer can be utilized. 

For instance, it can be compiled according to each victim's environment, targeting only specific security solutions. As it appears that both tools were developed together, there is some overlap in functionality between them. Several of the programs that were developed as part of the group, including MDeployer, MS4Killer, and Embargo's ransomware payload, are written in Rust, thus suggesting that the language is one that the developers use most often. It is claimed that the group has committed ten acts of cybercrime on its dark web leak site, including a non-bank lender from Australia, a police department from South Carolina, and a community hospital from Idaho. 

An interview conducted in June with a self-proclaimed representative of Embargo said that the group specializes in ransomware-as-a-service, with affiliates taking an extortion payment of up to 80%. It is believed that the toolkit discovered by Eset consists of two primary components: MDeployer, which is designed to deploy Embargo's ransomware and other malicious payloads, and MS4Killer, which is built to exploit vulnerable drivers to disable endpoint detection and response systems. 

In both MDeployment and MS4Killer, Rust is used as the programming language. Because of its memory protection features as well as its low-level capabilities, it can be used to create malware that is both effective and resilient. A study conducted by Eset reported that Embargo can target both Windows and Linux systems with Rust. It was in May 2024, one month after the first observation of Embargo in the ESET telemetry in June 2024 that Embargo was publicly observed for the first time. There are several reasons why the group has drawn attention besides the fact that it successfully breached high-profile targets as well as the language it used for its ransomware payload that piqued people's curiosity. 

As part of its development, Embargo chose Rust, which is a cross-platform programming language that provided the potential to develop ransomware that targets both Windows and Linux platforms. The Embargo group follows in the footsteps of BlackCat and Hive as yet another group developing ransomware payloads using Rust programming language. It is clear from Embargo's mode of operation that it is a well-resourced group considering its modus operandi. This system also allows victims to communicate with it via Tox, which results in the communication being managed by the system itself. It is a group that uses double extortion to force victims to pay him and then publishes the stolen information on its leaked website too. 

It is the MDeployer that Embargo uses mainly to install malicious loads on victims' computers within the compromised network to destroy them. An application for this purpose is designed to make it easier to execute ransomware and encrypt files. Two payloads are executed, MS4Killer and Embargo ransomware. Additionally, two encrypted files, a.cache, and b.cache, which were dropped by an unknown stage in the previous step, are decrypted and delivered to the victim. 

If the ransomware finishes encrypting the system, the MDeployer terminates the MS4Killer process, deletes all the decrypted payload files and the driver file dropped by MS4Killer, and finally restarts the computer. Besides the fact that MDeployer can run as a DLL file with administrative privileges, it has also the ability to reboot the victim's system into a Safe Mode if it is executed with administrator access. This is because major cybersecurity defenses aren't switched on in Safe Mode, which allows threat actors to continue operating undetected. The initial intrusion vector is unknown, however, once MDeployer has installed itself on the victim machine, it decrypts MS4Killer from the encrypted file "b.cache" and drops the file "praxisbackup.exe" into the system. 

In every single case observed by ESET, the MDeployer used the same hardcoded RC4 key to decrypt both files from "a.cache" and dropped and executed them as "pay.exe." MDeployer decrypted both files using the same hardcoded RC4 key. It has been reported that MS4Killer allegedly builds upon the S4Killer proof-of-concept tool available on GitHub and drops the vulnerable mini-filter drive problem.sys version 3.0.0.4 as part of what is known as the "Bring Your Own Vulnerable Driver" idea (BYOVD), which is a technique developed to deal with driver vulnerabilities in general. The researchers wrote in their paper that MS4Killer exploits this vulnerability to obtain kernel-level code execution and interacts with security software to carry out its malicious purposes. 

The Embargo's version of MS4Killer differs from the original MS4Killer in that Embargo has hardcoded a list of the processes to be killed into its binary. It has also encrypted the embedded driver blob which is an RC4 hash. Using cloud-based techniques, ESET researchers describe how MS4Killer runs in an endless loop and constantly seeks out processes that need to be terminated.   

MDeployer, a component of the Embargo ransomware attack chain, meticulously logs any errors encountered during its operations in a file named “fail.txt.” Upon completion of the attack — whether by successful ransomware deployment or an error in loader execution halting the attack — the MDeployer initiates a cleanup routine. This process includes terminating the MS4Killer loop and deleting specific files such as praxisbackup.exe, pay.exe, and a vulnerable driver. 

Additionally, it generates a control file named “stop.exe,” which certain MDeployer versions reference to prevent re-execution and, consequently, double encryption. Embargo, developed in Rust, appends each encrypted file with a unique, randomly generated six-character extension combining letters and numbers, such as “.b58eeb.” It also drops a ransom note titled “HOW_TO_RECOVER_FILES.txt” in each affected directory. The group has established its secure infrastructure for covert communication with victims but provides the option to negotiate through Tox chat as well. 

Although still developing, Embargo shows signs of ambition, borrowing techniques from established ransomware-as-a-service (RaaS) groups. These include implementing the "bring your vulnerable driver" (BYOVD) strategy, exploiting Safe Mode, and leveraging the adaptable Rust programming language. ESET's analysis highlights Embargo’s indicators of compromise (IoCs) and its tactics, techniques, and procedures (TTPs), offering guidance to help organizations defend against this emerging threat.

Google's Move to Rust Reduces Android Security Flaws by 68%

 


Using memory-safe programming languages such as Rust, Google has moved towards safe memory, which resulted in a drastic drop in memory-related vulnerabilities of the Android codebase. Memory vulnerabilities in Android decreased from 76% six years ago to 24% now.


Role of Memory-Safe Programming

According to Google, using memory-safe languages like Rust can help cut security risks in the codebase itself. The company has focused on safe code practices so that vulnerabilities do not occur in the first place, which has made this process of coding more scalable and cost-efficient over time. The more unsafe development reduces over time, memory-safe practices take up more space and render fewer vulnerabilities in total. As Jeff Vander Stoep and Alex Rebert of Google explained, the memory vulnerabilities tend to reduce even with new memory-unsafe codes being introduced. This is because vulnerabilities decay in time. Newer or recently modified code is more likely to carry issues.


Google Goes for Rust

In April 2021, the company announced that it was embracing Rust as a memory-safe language for Android development. The company has begun to concentrate on Rust for new development since 2019 and has continued to do so. Since then, memory safety flaws in Android went down from 223 in 2019 to less than 50 in 2024. Such a drastic downfall is partly due to proactive measures and improvement in discoverability tools such as those utilised with Clang sanitizers. Google also shifted its strategy from reactive patching to vulnerability prevention work by its security teams. They now focus on preventing issues before the problems crop up.


Safe Coding: The New Way

Google has learned that memory safety strategies must be evolved. The company abandoned older interventional methods like mitigations and fuzzing, instead opting for more secure-by-design principles. This type of principle allows for the embedding of security within the foundational blocks of coding, and it enables developers to construct code that-in itself-prevents vulnerabilities. This is called Safe Coding and lets Google safely make propositions regarding the code with its properties.


Combining Rust, C++, and Kotlin

In addition to promoting Rust, Google is also aiming to interface the language with other languages such as C++ and Kotlin. Thus, this practical solution allows doing memory-safe practices in ways that are pretty easy for today's needs by not rewriting older code completely. Making memory-safe languages incrementally, in itself, will eliminate entire categories of vulnerabilities and ensure all Android code is safer in the long term.

For instance, the approach of Google is based on the presumption that as the number of vulnerabilities introduced decreased, the existing ones would automatically decrease over time. This change helps improve the design of security and scalability strategies concerning memory safety so they can be applied better to large systems.


Partnership between Arm and a System for Better Security

Related to this, Google has collaborated with Arm to further enhance the security of the GPU software and firmware stack across the Android ecosystem. The result was that the former identified several security issues in the code for it. Such were two memory problems in Pixel's driver - CVE-2023-48409 and CVE-2023-48421 - and a problem in the Arm Valhall GPU firmware, CVE-2024-0153. According to Google and Arm, proactive testing is a very key role to identify vulnerabilities before they are exploited.


Future Prospects

In the future, Google aims to build a safer Android by maintaining its main focus on memory safety while pushing ahead its approach to security. The company's efforts in lessening vulnerabilities in memory, codification practice improvement, and collaboration with industry partners are targeted towards minimising memory leakage, thus ensuring long-term security solutions.


This enhances the vulnerability of Android but also acts as a role model to other tech companies that should establish memory-safe languages and secure-by-design principles in their development processes.


Hive Gang Changes Programming from Go to Rust

About Hive Ransomware

Microsoft Security researchers found new versions of Hive ransomware written in the Go programming language but now in Rust. Hive surfaced in June 2021, it was found by the FBI in August. In November, Mediamarkt, a European electronics retail company was hit by Hive. 

It's a RaaS (Ransomware as a service) double extortion gang that has recently been attacking vulnerable Microsoft Exchange Servers, compromised VPN credentials, phishing, and vulnerable RDP servers to install the ransomware and steal information that can be leaked. 

Why the change from Go to Rust

The Rust change from Hive has been underway for quite some time, it took its lessons from BlackCat ransomware, written in Rust as well. Researchers from Group-IB in March discovered that Hive changed its Linux encryptor (for attacking VMware ESXi servers) to Rust to make it difficult for cybersecurity experts to monitor the ransom talks with targets. 

The Rust rewrite is much easier, Microsoft Threat Intelligence Center in its blog said, "the upgrades in the latest variant [of Hive] are effectively an overhaul: the most notable changes include a full code migration to another programming language and the use of a more complex encryption method. 

What is the impact

The implications of these updates are far-reaching, we should consider that Hive is a RaaS payload that Microsoft found in attacks against organizations in the software and healthcare industries from big ransomware actors like DEV-0237. 

Microsoft has mentioned some advantages of Rust over other languages that make it one of the most preferred languages among programmers, like good crypto library support and better memory security. 

Following are the benefits of Rust language, as per Microsoft: 

  • It offers memory, data type, and thread-safety It has deep control over low-level resources It has a user-friendly syntax 
  • It has several mechanisms for concurrency and parallelism, thus enabling fast and safe file encryption 
  • It has a good variety of cryptographic libraries 
  • It's relatively more difficult to reverse-engineer 

ZDNet reports "Microsoft found that the new ransom note differs from the one used in older variants. The new note instructs victims: "Do not delete or reinstall VMs. There will be nothing to decrypt" and "Do not modify, rename or delete *.key files. Your data will be undecryptable." The *.key files are the files that Hive has encrypted."