Ransom Cartel Ransomware: A Possible Connection With REvil

This post is also available in: 日本語 (Japanese)

Executive Summary

Ransom Cartel is ransomware as a service (RaaS) that surfaced in mid-December 2021. This ransomware performs double extortion attacks and exhibits several similarities and technical overlaps with REvil ransomware. REvil ransomware disappeared just a couple of months before Ransom Cartel surfaced and just one month after 14 of its alleged members were arrested in Russia. When Ransom Cartel first appeared, it was unclear whether it was a rebrand of REvil or an unrelated threat actor who reused or mimicked REvil ransomware code.

In this report, we will provide our analysis of Ransom Cartel ransomware, as well as our assessment of the possible connections between REvil and Ransom Cartel ransomware.

Palo Alto Networks customers receive help with the detection and prevention of Ransom Cartel ransomware through the following products and services: Cortex XDR and Next-Generation Firewalls (including cloud-delivered security services such as WildFire).

If you think a cyber incident may have impacted you, the Unit 42 Incident Response team is available 24/7/365. You can also take preventative steps by requesting any of our cyber risk management services.

Indicators of compromise and Ransom Cartel-associated tactics, techniques and procedures (TTPs) can be found in the Ransom Cartel ATOM.

We updated this blog on Oct. 15 based on further analysis, additional evidence and discussion around the complexities of redirects from REvil’s dark web leak site. Updated sections include our History of the REvil Disappearance and the Ransom Cartel Overview.

History of the REvil Disappearance

In October 2021, REvil operators went quiet. REvil’s dark web leak site  became unreachable. Around mid-April 2022, individual security researchers and cybersecurity media outlets reported a new development with REvil that could signify the gang’s return. REvil’s name-and-shame blogs at the dnpscnbaix6nkwvystl3yxglz7nteicqrou3t75tpcc5532cztc46qyd[.]onion and aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion domains started redirecting users to a new name-and-shame blog available at blogxxu75w63ujqarv476otld7cyjkq4yoswzt4ijadkjwvg3vrvd5yd[.]onion/Blog.

This redirect was documented in our post, “Understanding REvil,” in Bleeping Computer’s post on REvil’s TOR sites redirecting to a new ransomware operation and in a Twitter post from vx-underground. 

Later the same day, the redirect was removed (as noted by vx-underground). At the time, it was not possible to make a definitive attribution stating which group was behind the redirect because the new name-and-shame blog did not claim any name or affiliation.

At the start of the redirect, no breached organizations were listed on the site. Over time, the threat actors began adding records that had  appeared on “Happy Blog,” mostly from  late April to October 2021. They also included the old file-sharing links previously used by REvil as proof of compromise.

The newly established blog listed Tox Chat ID for communication with the ransomware operator. The blog hinted at its operators’ connection to REvil with the claim that the newer group offered “the same, yet improved software.” 

Unit 42 initially believed that this blog was linked to Ransom Cartel and that the “improved software” the threat actors referred to was a new Ransom Cartel variant. However, after further analysis and seeing more evidence, we believe it is also possible that the name-and-shame blog and Ransom Cartel are two separate operations. 

Whether this blog is operated by Ransom Cartel or a different group, what is clear is that, while REvil may have disappeared, its malicious influence has not. The operator of the newly established blog appears to have some type of access to REvil or ties to the group. At the same time, our analysis of Ransom Cartel samples (detailed in the sections below) provides strong evidence of ties to REvil as well. 

To read more about REvil, its disappearance and the redirect, please refer to our blog, Understanding REvil.

Ransom Cartel Overview

We first observed Ransom Cartel around mid-January 2022. Security researchers at MalwareHunterTeam believe the group to have been active since at least December 2021. They observed the first known Ransom Cartel activity and noticed several similarities and technical overlaps with REvil ransomware.

There are a number of theories about the origins of Ransom Cartel. One theory in the community suggests that Ransom Cartel could be the result of multiple groups merging. However, researchers at MalwareHunterTeam have put forward that one of the groups believed to have merged has denied any connection with Ransom Cartel. Additionally, Unit 42 has seen no connection between these groups and Ransom Cartel other than that many of them have connections to REvil. 

At this time, we believe that Ransom Cartel operators had access to earlier versions of REvil ransomware source code, but not some of the most recent developments (see our Ransom Cartel and REvil Code Comparison for more details).  This suggests there was a relationship between the groups at some point, though it may not have been recent.

Unit 42 has also observed Ransom Cartel group breaching organizations, with the first known victims observed by us around January 2022 in the U.S. and France. Ransom Cartel has attacked organizations in the following industries: education, manufacturing, and utilities and energy. Unit 42 incident responders have also assisted clients with response efforts in several Ransom Cartel cases.

Like many other ransomware gangs, Ransom Cartel leverages double extortion techniques. Unit 42 has observed the group taking an aggressive approach, threatening not only to publish stolen data to their leak site, but also to send it to the victim’s partners, competitors and the news in an effort to inflict reputational damage.

Ransom Cartel typically gains initial access to an environment via compromised credentials, which is one of the most common vectors for initial access for ransomware operators. This includes access credentials for external remote services, remote desktop protocol (RDP), secure shell protocol (SSH) and virtual private networks (VPNs). These credentials are widely available in the cyber underground and offer threat actors a reliable means to gain access to victims' corporate networks.

These credentials can also be obtained through the work of ransomware operators themselves or by purchasing them from an initial access broker.

Initial access brokers are actors who offer to sell compromised network access. Their motivation is not to carry out cyberattacks themselves but rather to sell the access to other threat actors. Due to the profitability of ransomware, these brokers likely have working relationships with RaaS groups based on the amount they are willing to pay.

Unit 42 has seen evidence that Ransom Cartel has relied on this type of service to gain initial access for ransomware deployment.

Unit 42 has also observed Ransom Cartel encrypting both Windows and Linux VMWare ESXi servers in attacks on corporate networks.

Tactics, Techniques and Procedures Observed During Ransom Cartel Attacks

Unit 42 observed a Ransom Cartel threat actor using a tool called DonPAPI, which has not been observed in past incidents. This tool can locate and retrieve Windows Data Protection API (DPAPI) protected credentials, which is known as DPAPI dumping.

DonPAPI is used to search machines for certain files known to be DPAPI blobs, including Wi-Fi keys, RDP passwords, credentials saved in web browsers, etc. To avoid the risk of detection by antivirus (AVs) or endpoint detection and response (EDR), the tool downloads the files and decrypts them locally. To compromise Linux ESXi devices, Ransom Cartel uses DonPAPI to harvest credentials stored in web browsers used to authenticate to the vCenter web interface.

We also observed the threat actor using additional tools, including LaZagne to recover credentials stored locally and Mimikatz to steal credentials from host memory.

In order to establish persistent access to Linux ESXi devices, the threat actor enables SSH after authenticating to vCenter. The threat actor will create new accounts and sets the account’s user identifier (UID) to zero. For Unix/Linux users, a UID=0 is root. This means any security checks are bypassed.

The threat actor was observed downloading and using a cracked version of a legitimate tool called PDQ Inventory, which is a legitimate system management solution that IT administrators use to scan their network and collect hardware, software and Windows configuration data. Ransom Cartel used this as a remote access tool to establish an interactive command and control channel and to scan the compromised network.

Once a VMware ESXi server is compromised, the threat actor launches the encryptor, which will automatically enumerate the running virtual machines (VMs) and shut them down using the esxcli command. Terminating the VM processes ensures that the ransomware can successfully encrypt VMware-related files.

During encryption, Ransom Cartel specifically seeks out files with the following file extensions: .log, .vmdk, .vmem, .vswp and .vmsn. These extensions are associated with ESXi snapshots, log files, swap files, paging files and virtual disks. Post-encryption, the following file extensions have been observed: .zmi5z, .nwixz, .ext, .zje2m, .5vm8t and .m4tzt.

Ransom Notes

Unit 42 has observed two different versions of ransom notes sent by Ransom Cartel. The first note was first observed around January 2022, and the other one first appeared in August 2022. The second version appeared to be completely rewritten, as shown in Figure 1.

It's interesting to note that the structure of the first ransom note used by Ransom Cartel shares similarities with a ransom note sent by REvil, as shown in Figure 2. In addition to the use of similar wording, both notes employed the same format of a 16-byte hexadecimal string for the UID.

Ransom Cartel TOR Site

Ransom Cartel’s website for communication with victims was available via a TOR link provided in the ransom note. We’ve observed multiple TOR URLs belonging to Ransom Cartel, which likely indicates that they had been changing infrastructure and actively developing their website. A TOR private key is needed to access the website.

When the key is entered, the following page is loaded:

Upon entering the TOR site through the Authorization button, a screen requesting input of the details included in the ransom note is requested.

Once authorization is completed on the TOR site, the page shown in Figure 5 appears. The site includes details such as ransom demand, in both US dollars and bitcoin, and the Bitcoin wallet address.

Technical Details

Two Ransom Cartel samples were used during this analysis:

File one SHA256: 55e4d509de5b0f1ea888ff87eb0d190c328a559d7cc5653c46947e57c0f01ec5
File two SHA256: 2411a74b343bbe51b2243985d5edaaabe2ba70e0c923305353037d1f442a91f5

Both of the samples contained three total exports:

Rathbuige
ServiceMain
SvchostPushServiceGlobals

The samples also contain a DllEntryPoint, should the DLL be executed without specifying an export. The DllEntryPoint leads to a function that iterates over a call to the Curve25519 Donna algorithm 24 times. Once the iteration ends, the sample will query the system metrics, specifically for the SM_CLEANBOOT value. If this value is anything other than 0, the ransomware will proceed to spawn another instance of itself via rundll32.exe, specifying the Rathbuige export.

Table 1. SM_CLEANBOOT values.

The Rathbuige export starts by creating the following mutex:

Global\\266ee996-e1ac-4eaa-9bdb-0b639d41b32d

Once the mutex is created, the sample begins to decrypt and parse its embedded configuration. The configuration is stored as a base64-encoded blob, whereby the first 16 bytes of the base64-encoded blob is the RC4 key used for decrypting the rest of the blob once it has been decoded.

Once decrypted, the configuration is stored in JSON format and consists of information such as encrypted file extension, the threat actors' public Curve25519-donna key, a base64-encoded ransom note, and a list of processes and services to terminate prior to encryption.

A breakdown of the keys and their values within the configuration can be seen in Table 2.

Table 2. Configuration structure.

Table 3. Targeted process list.

Table 4. Targeted service list.

Table 5. Avoided extensions.

Following decryption of the configuration, certain system information is gathered, including the username, computer name, domain name, locale and product name. This information is then formatted into the following JSON structure:

{"ver":%d,"pk":"%s","uid":"%s","sk":"%s","unm":"%s","net":"%s","grp":"%s","lng":"%s","bro":%s,"os":"%s","bit":%d,"dsk":"%s","ext":"%s"}

Table 6 describes the purpose of each key within the structure.

Table 6. Hardcoded JSON format keys and values.

Once the gathered data has been formatted into the JSON structure, it is then encrypted using the same procedure that Ransom Cartel follows to generate session_secret blobs, which will be discussed shortly; put simply, it involves AES encryption, utilizing the SHA3 hash of a Curve25519 shared key for the AES key.

Once encrypted, it is written to the registry key SOFTWARE\\Google_Authenticator\\b52dKMhj, with the sample first attempting to write to the HKEY_LOCAL_MACHINE hive, before writing to HKEY_CURRENT_USER if the right permissions are not possessed. Once the data has been written to the registry, it is then base64-encoded and embedded within the ransom note, replacing the {KEY} placeholder.

Once the configuration has been parsed and stored within the registry, the command line provided to the ransomware is parsed. There are a total of five possible arguments, as shown in Table 7.

Table 7. Ransom Cartel accepted arguments.

With that, let’s move on to analyzing the session secret generation procedure.

Ransom Cartel first checks to see if the registry already contains previously generated values; if so, it will read those values into memory. Otherwise, it will generate a total of two session secrets at runtime, with each secret containing 88 bytes of data.

First, a public and private key pair will be generated using the code from this Curve25519 repository (session_public_1 and session_private_1). When generating the first session secret, another session key pair is generated, (session_public_2 and session_private_2) and session_private_2 is paired with attacker_cfg_public (the public key embedded within the configuration) to generate a shared key. This shared key is then hashed with the SHA3 hashing algorithm. The resulting hash is used as an AES key with a random 16-byte initialization vector (IV) for encrypting a data blob consisting of four null bytes followed by session_private_1.

From there, the encrypted blob is hashed using CRC-32, and then appended with the values session_public_2, the AES IV, and the calculated CRC-32 hash. The resulting value is session_secret_1. The second generated session secret follows the exact same procedure; however, instead of using attacker_cfg_public, it utilizes an embedded public key (attacker_embedded_public_1) within the binary to generate the shared key.

One final embedded public key (attacker_embedded_public_2) is used to encrypt the data formatted into the JSON structure described above.

This method of generating session secrets was documented by researchers at Amossys back in 2020; however, their analysis focused on an updated version of Sodinokibi/REvil ransomware, indicating a direct overlap between the REvil source code and the latest Ransom Cartel samples.

Once the session secrets have been generated, they are written to the registry, alongside session_public_1 and attacker_cfg_public.

Table 8. Registry paths and values used by Ransom Cartel.

At this point, all the required information is gathered and generated so that file encryption can begin.

For each file, a unique file public and private key pair are generated (file_public_1 and file_private_1), once again using Curve25519 Donna. file_private_1 and session_public_1 are paired together to generate a shared key, which is hashed using SHA3. The generated hash is used as the encryption key for Salsa20 (a symmetric encryption algorithm), and a random eight-byte nonce is generated using CryptGenRandom. The CRC-32 hash of file_public_1 is calculated, and then four null bytes are encrypted using the generated Salsa20 matrix.

Certain elements of the above data are then retained and used as part of the encrypted file footer; each file footer is 232 bytes in length and is made up of the following:

• session_secret_1 (88 bytes)
• session_secret_2 (88 bytes)
• file_public_1 (32 bytes)
• salsa_nonce (eight bytes)
• crc_file_public_1 (four bytes)
• encryption_type (four bytes)
• block_spacing (four bytes)
• encrypted_null (four bytes)

Similarly to the session_secret generation, this structure is identical to that of the REvil samples analyzed by Amossys, further showing that there have been very few changes to the REvil source code when developing Ransom Cartel samples.

Ransom Cartel and REvil Code Comparison

The Ransom Cartel samples analyzed revealed similarities with REvil ransomware.

The first notable similarity between Ransom Cartel and REvil is the structure of the configuration. Examining a sample of REvil from 2019 (SHA256: 6a2bd52a5d68a7250d1de481dcce91a32f54824c1c540f0a040d05f757220cd3), the resemblance can be seen. However, the storage of the encrypted configuration is slightly different, opting to store the configuration in a separate section within the binary (.ycpc19), with an initial 32-byte RC4 key followed by the raw encrypted configuration, whereas with the Ransom Cartel samples, the configuration is stored within the .data section as a base64-encoded blob.

Once the REvil configuration has decrypted, it utilizes the same JSON format, but contains additional values such as pid, sub, fast, wipe and dmn. These values indicate additional functionality within the REvil sample, which could mean that either the Ransom Cartel developers removed certain functionality or they are building off of a much earlier version of REvil.

As discussed previously, another major overlap is the code reuse across the two samples of Ransom Cartel. Both use an identical encryption scheme, generating multiple public/private key pairs, and creating session secrets using the same procedure found within REvil samples.

Both use Salsa20 and Curve25519 for file encryption, and there are very few differences in the layout of the encryption routine besides the structure of the internal type structs.

A particularly interesting difference between the two malware families is that REvil opts to obfuscate their ransomware much more heavily than the Ransom Cartel group, utilizing string encryption, API hashing and more, while Ransom Cartel has almost no obfuscation outside of the configuration, hinting that the group may not possess the obfuscation engine used by REvil.

It is possible that the Ransom Cartel group is an offshoot of the original REvil threat actor group, where the individuals only possess the original source code of the REvil ransomware encryptor/decryptor, but do not have access to the obfuscation engine.

Ransom Cartel Tactics, Techniques and Procedures

Below is a list of TTPs observed being used by Ransom Cartel affiliates:

Table 9. Tactics, techniques and procedures for Ransom Cartel activity.

Malware, Tools and Exploits Used

Table 10. Malware, tools and exploits used.

Conclusion

Ransom Cartel is one of many ransomware families that surfaced during 2021. While Ransom Cartel uses double extortion and some of the same TTPs we often observe during ransomware attacks, this type of ransomware uses less common tools – DonPAPI for example – that we haven’t observed in any other ransomware attacks.

Based on the fact that the Ransom Cartel operators clearly have access to the original REvil ransomware source code, yet likely do not possess the obfuscation engine used to encrypt strings and hide API calls, we speculate that the operators of Ransom Cartel had a relationship with the REvil group at one point, before starting their own operation.

Due to the high-profile nature of some organizations targeted by Ransom Cartel and steady stream of Ransom Cartel cases identified by Unit 42, the operator and/or affiliates behind the ransomware likely will continue to attack and extort organizations.

Palo Alto Networks customers receive help with detection and prevention of Ransom Cartel ransomware in the following ways:

• WildFire: All known samples are identified as malware.
• Cortex XDR:
  • Identifies indicators associated with Ransom Cartel.
  • Anti-Ransomware Module to detect Ransom Cartel encryption behaviors on Windows.
  • Local Analysis detection for Ransom Cartel binaries on Windows.
• Next-Generation Firewalls: DNS Signatures detect the known command and control domains, which are also categorized as malware in Advanced URL Filtering.

If you think you may have been compromised or have an urgent matter, you can get in touch with the Unit 42 Incident Response team or call:

• North America Toll-Free: 866.486.4842 (866.4.UNIT42)
• EMEA: +31.20.299.3130
• APAC: +65.6983.8730
• Japan: +81.50.1790.0200

Indicators of Compromise

Ransom Cartel Samples

9935DA29F3E4E503E4A4712379CCD9963A730CCC304C2FEC31E8276DB35E82E8
BF93B029CCA0DE4B6F32E98AEEBD8FD690964816978A0EB13A085A80D4B6BF4E
55e4d509de5b0f1ea888ff87eb0d190c328a559d7cc5653c46947e57c0f01ec5
2411a74b343bbe51b2243985d5edaaabe2ba70e0c923305353037d1f442a91f5

Network-based IoCs

185.239.222[.]240 TOR Exit Node
108.62.103[.]193 TOR Exit Node
185.129.62[.]62 TOR Exit Node
185.143.223[.]13 Bulletproof hosting server
185.253.163[.]23 PIA VPN exit node

Indicators of compromise and Ransom Cartel-associated TTPs can be found in the Ransom Cartel ATOM.

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Updated Oct. 15, 2002, at 11:15 a.m. PT.