An Upgrade in RansomHouse Encryption

RansomHouse is a ransomware-as-a-service (RaaS) operation run by a group that we track as Jolly Scorpius. Recent samples of the associated binaries used in RansomHouse operations reveal a significant upgrade in encryption. This article explores the upgrade of RansomHouse encryption and the potential impact for defenders.

Jolly Scorpius uses a double extortion strategy. This strategy combines stealing and encrypting a victim’s data with threats to leak the stolen data.

The scale of the group’s operations is significant. At the time of this article, at least 123 victims were listed on the RansomHouse data leak site as having their data disclosed or sold since December 2021.

This group has disrupted critical sectors including healthcare, finance, transportation and government. The consequences of these intrusions include significant financial losses, major data breaches and erosion of public trust in the affected organizations.

To better understand RansomHouse operations, we review its attack chain. We also examine the upgrade to this ransomware’s encryption from a simple, single-phase linear technique to a more complex, multi-layered method.

Palo Alto Networks customers are better protected from the threats described in this article through the following products and services:

Despite Jolly Scorpius positioning itself as a group that exposes corporate vulnerabilities, its actions reveal a straightforward extortion business. To better understand its RansomHouse operations, we can identify the specific actor roles, discern separate phases of the attack chain and determine how the roles and phases relate to each other.

Figure 1 illustrates these roles and their positions in the attack chain.

Figure 1. Actor roles and how they relate to phases of the RansomHouse attack chain.

The RansomHouse attack chain involves three distinct roles:

Operator: Operates the RaaS
Attacker: Deploys the ransomware
Victim: Targeted by the attacker

Operators are responsible for establishing and maintaining the RaaS, including the development of tools for data encryption and other functions. Individuals in this role manage the data leak site and architecture for victims to negotiate ransom payments. This includes managing the cryptocurrency wallets for ransom collection and laundering.

Attackers are typically known as affiliates because they are separate threat actors from the operators. As ransomware services rise and fall, attackers can switch their affiliation to different RaaS groups. Attackers are responsible for gaining initial access, moving laterally, exfiltrating data and deploying the ransomware.

In this phase, RansomHouse operators function as the backend providers, responsible for developing all aspects of the RaaS. Crucially, the operators typically do not conduct the initial intrusions. Instead, they rely on their affiliates (i.e., the attackers) to leverage the RaaS services developed in this phase.

In this phase, attackers compromise victims through spear phishing emails or other social engineering techniques. In addition to email, initial access vectors include vulnerable systems in a victim’s environment that attackers can compromise through zero-day or other exploits.

After achieving initial access, attackers typically use third-party tools and frameworks to explore the victim’s network. The remainder of the infiltration phase includes reconnaissance to map the environment, privilege escalation, lateral movement and identifying valuable or sensitive information.

Once attackers affiliated with RansomHouse have infiltrated a victim’s environment, they exfiltrate sensitive data and deploy the ransomware. Typical data exfiltration techniques involve file compression and file transfer utilities, and attackers usually send data to servers under their control.

The RansomHouse RaaS uses a modular architecture that consists of two components:

Management tool
Encryptor

Once a victim’s data has been stolen and encrypted, the attack chain transitions to the extortion phase. RaaS operators are generally responsible for this phase, which often involves negotiations via dedicated chat rooms. Operators validate their threats through strategic information disclosure on platforms like Telegram and the RansomHouse data leak site.

Now that we better understand the RansomHouse attack chain, let’s review how the components of this ransomware are used in attacks.

The two components of this ransomware (i.e., MrAgent and Mario) are specifically engineered to compromise virtualized environments. Figure 2 illustrates how these tools are used in a RansomHouse attack in an ESXi network.

Figure 2. Flow chart of how RansomHouse components are used in an ESXi environment.

After infiltrating the environment, an attacker deploys MrAgent onto the victim’s ESXi hypervisor. MrAgent establishes a persistent connection to the attacker’s command-and-control (C2) server.

Attackers then issue commands from the C2 server to MrAgent for further operations like data exfiltration. After the data is exfiltrated, attackers instruct MrAgent to download and execute the Mario encryptor, which runs directly on the hypervisor to encrypt virtual machine (VM) files.

Since MrAgent is the first component in the attack, let’s review how it works.

As the primary tool for RansomHouse operations, MrAgent provides attackers with persistent access to a victim’s environment and simplifies managing compromised hosts at scale. This management is accomplished through various functions of the tool.

The main functions of MrAgent are:

Acquiring host identifiers
Acquiring the host’s IP address
Disabling the firewall
Communicating with the attacker’s C2 server

MrAgent deploys Mario to accomplish the operation’s core function of encrypting critical VM files in the ESXi hypervisor. Our research uncovered two distinct versions of Mario that reveal an evolution in its encryption methods.

Both versions follow the same overall execution flow:

Create the ransom note
Target file extensions
Encrypt files
Report statistics

The first step in Mario’s execution flow is creating a ransom note. The ransom note is named How To Restore Your Files.txt and is located in the directory of any files that Mario encrypts.

Mario opens the ransom note in write mode and saves text to the file that provides instructions for victims to recover their files. Figure 3 below shows an example of this note.

The next step is directory traversal and extension targeting. Mario requires attackers to specify the directory path of the files to encrypt. Within the specified directory, Mario targets virtualization files based on the filename extensions listed in Table 2.

Extension
File Description

ova
Open Virtual Appliance (OVA): a single-file distribution of the OVF file package

ovf
Open Virtualization Format (OVF): an open standard for packaging and distributing virtual software

While encrypting targeted files, Mario displays its progress, as Figure 4 above shows. Encrypted files are renamed, appending the existing filename with an extension that includes the string mario. Figure 5 shows an example of .emario as the extension for encrypted files after running a Mario sample.

After Mario finishes encrypting targeted files, it displays statistics of the encryption results. These statistics, in order, are:

The number of files that could not be encrypted
The number of files that were encrypted
The number of skipped files
The total file count
The amount of data that was encrypted

Figure 6 shows an example of a statistics report after running a Mario sample.

Figure 6. Example of a Mario sample reporting its encryption statistics.

While all known samples of Mario follow the same execution flow, the process is more complex in recent Mario samples. The next section reviews the differences between the earlier and later Mario samples, revealing an upgrade in Mario’s encryption methods.

We identified two versions of Mario based on the differences in encryption routines among currently known samples. Comparing these two versions reveals that developers have updated Mario to use a substantially more complex encryption method. We refer to these two versions as:

Original version
Upgraded version

Comparing blocks of disassembled code for the encryption routine, there is a noticeably more complex block of functions in the upgraded version. Figure 7 compares the encryption code blocks for these two versions, showing noticeably more sections in the upgraded version on the right than in the original version on the left.

Figure 7. Comparison of encryption code blocks between the original and upgraded versions of Mario.

To demonstrate the upgrade in Mario’s encryption, we compare code from samples of the two versions across the following functions:

Encryption
Memory layout and buffer management
File processing
Output format

Improvements in these functions make the upgraded version of Mario significantly more efficient and resilient to analysis than the original version.

The original version of Mario has a straightforward and basic encryption routine. Figure 8 shows disassembled code from the original version. This code performs a single pass to transform a file’s data from unencrypted to encrypted.

Figure 8. Disassembled code for the original version’s single-pass file transformation.

In contrast, the upgraded version of Mario features a two-stage file transformation that includes a secondary encryption key. Figure 9 shows disassembled code from a sample of the upgraded version of Mario, revealing this more complex encryption process.

Figure 9. Disassembled code revealing the upgraded version’s more complex file transformation.

The upgraded version’s code reveals a two-factor encryption scheme where the file is encrypted with both a primary key and a secondary key. Data encryption is processed separately for each key. This significantly increases the difficulty of decrypting the data without both keys.

Figure 10 shows that the upgraded version of Mario uses random values to generate a 32-byte primary encryption key and an 8-byte secondary encryption key.

Figure 10. Disassembled code showing key generation used by Mario’s upgraded version.

These changes represent a significant upgrade in Mario’s encryption.

Mario’s original version uses a straightforward approach to file processing. It’s a linear process that encrypts the files as sequential fixed-size segments in a loop. After encrypting each segment, the code checks if the combined size of the processed segments exceeds a specified threshold. Once it passes that threshold, the code jumps from the loop to a different function.

Figure 11 illustrates this linear process in the disassembled code.

Figure 11. Disassembled code showing a linear process for encryption in Mario’s original version.

Code in Mario’s upgraded version reveals an encryption method that uses chunk processing with dynamic sizing. Figure 12 shows an example.

Figure 12. Disassembled code showing chunked processing with dynamic for encryption in Mario’s upgraded version.

Comparing the processing logic between these two versions, we find significant differences.

Mario’s original version uses a simpler programming loop that processes files in fixed segment lengths up to a threshold of 536,870,911 bytes, as noted in Figure 11. This version simply reports when the encryption is complete without showing any progress.

In comparison, Mario’s upgraded version implements a more robust file processing scheme for encryption that uses:

Variable segment lengths, with a size threshold of 8 GB
Calculations to determine chunk size and offsets
A sparse encryption technique where it encrypts only certain blocks of a file at specific offsets

In addition, the upgraded version of Mario displays the progress of encrypting chunks of each file, as noted below in Figure 13.

Figure 13. Disassembled code in the upgraded version of Mario to display the progress of chunk processing.

The chunked processing of Mario’s upgraded version makes static analysis more difficult because:

It processes files non-linearly
It uses complex mathematical formulas to determine processing order
It employs different strategies based on file size

In addition to displaying the processed chunks of files when encrypting them, Mario’s upgraded version also provides a more detailed summary when the encryption of each file is finished.

As previously stated, the original version simply reports that the encryption of a file is finished. Figure 14 shows this in the disassembled code.

Figure 14. Code from the original version of Mario to report when a file is finished processing.

Mario’s upgraded version includes more information when each file is finished processing, as Figure 15 below shows in the disassembled code.

Figure 15. Code from the upgraded version of Mario to report when a file is finished processing.

Ultimately, the core functionality of these two Mario samples (the original version and the upgraded version) remains the same. Both samples encrypt files and rename them by adding .emario extension. But the upgraded version implements a more complex and potentially more secure encryption methodology with selective file processing.

The upgrade in encryption used by RansomHouse RaaS, going from a simple linear model to a more complex multi-layered approach, signals a concerning trajectory in ransomware development. This demonstrates how threat actors are updating their techniques to enhance effectiveness.

This upgrade is built on several key technical improvements:

A two-factor encryption scheme that significantly increases the difficulty of decryption without both keys
Chunked file processing with dynamic sizing instead of a simpler method
The new file processing makes static analysis and reverse engineering more challenging

Threat actors could view this as a useful path for future ransomware variants. As other ransomware groups adopt these more sophisticated methods, the ransomware threat landscape will become more resilient to security controls. This upgrade underscores the need to adopt more dynamic, adaptive strategies capable of countering the next generation of complex and evasive threats.

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

SHA256 hash: 0fe7fcc66726f8f2daed29b807d1da3c531ec004925625855f8889950d0d24d8
File description: Sample of the upgraded version of Mario
SHA256 hash: ​​d36afcfe1ae2c3e6669878e6f9310a04fb6c8af525d17c4ffa8b510459d7dd4d
File description: Sample of the original version of Mario
SHA256 hash: 26b3c1269064ba1bf2bfdcf2d3d069e939f0e54fc4189e5a5263a49e17872f2a
File description: MrAgent sample
SHA256 hash: 8189c708706eb7302d7598aeee8cd6bdb048bf1a6dbe29c59e50f0a39fd53973
File description: MrAgent sample