Scratching the Surface of Rhysida Ransomware

A few days ago, I was scrolling through Twitter and came across a post by the MalwareHunterTeam briefly discussing a new Ransomware group - Rhysida. A lack of results from a Google search shows this is a newer group prepping to start operations. I grabbed a sample and downloaded it, and the executable confirmed that this group is indeed in its early stages based on the breadth of print debugging and the lack of a victim target in the ransom note. This appeared to be a pre-finished test file. Here's what I found.

Original File Name: fury_ctm1042.bin

MD5: 0c8e88877383ccd23a755f429006b437

SHA1: 69b3d913a3967153d1e91ba1a31ebed839b297ed

SHA256: a864282fea5a536510ae86c77ce46f7827687783628e4f2ceb5bf2c41b8cd3c6

The sample was written in C++ and was compiled using MinGW (mingw32). It was about 1.2 MB and wasn't packed.

A glance at the strings shows that the ransomware deletes the wallpaper in a few different ways. Although, there is a typo with "Conttol Panel" when it attempts to delete the wallpaper registry setting via the Control Panel. Encryption and a PowerShell invocation with a hidden window are also mentioned. All of these are highlighted below.

The Rhysida encryptor allows two arguments -d and -sr, which the authors define as parseOptions. The picture below shows the parseOptions function.

-d: select a directory to encrypt

-sr: File deletes itself after running ("I'm will be selfremoved")

Rhysida uses the following command to delete itself; as you can tell, that is the PowerShell string from earlier.

Everything is revealed in the main function, and there is no obfuscation. It begins by getting the number of processors on the system and printing it. It then performs a series of memory allocations for future encryption operations, defines mutexes, and queries the files on the system. It then performs another print of the current program and directory. Right before LABEL_8, at the bottom of the picture, is where the encryption process begins.

The init_prng(&prng, &PRNG_IDX) function is where the Chacha20 algorithm parameters are defined. Chacha20 is a symmetric stream cipher used to encrypt the file contents.

The first part of the encryption algorithm is a series of conditionals to build the ciphers and import keys. I've numbered them below to make it easier to follow what's going on. Below the picture, I also go into detail on some of the steps.

init_prng(&prng, &PRNG_IDX) defines Chacha20 characteristics.
Imports an RSA-4096 public key
Registers the AES encryption cipher
defines a CIPHER constant set to aes
Registers the Cipher Hash Construction (CHC) hash type, allowing a user to use a block cipher and turn it into a hash function.
Registers AES as the block cipher for the CHC hash.
Defines a HASH_IDX constant set to the resulting CHC hash.

The authors of the Rhysida ransomware used the LibTomCrypt open-source library to create the encryption modules in the payload. Once the ransomware encrypts files with Chacha20, the authors used RSA-4096-OAEP to encrypt the Chacha20 keys.

Below is the RSA public key in memory. Interestingly, it's between the ransom note file name - CriticalBreachDetected.pdf - and its contents.

When keys get encrypted with RSA, the authors use the CHC hash as entropy for the cipher IVs.

I've posted the CHC entry from the LibTomCrypo developers manual below.

On to the next part of the main function, the AES key size is set to 32, which results in AES-256-ECB, according to the developer's manual. Once all the encryption mechanisms are established, the sample defines global counters to track the progress of file encryption. The box on the bottom is where the actual encryption occurs. Although, most of the functionality is within the processFiles and openDirectoryNR functions. The for loop on the bottom loops between all system drives (65 = A and 90 = Z, in ASCII).

The main function ends with a printout of the encryption process showing how many directories and files were processed; how many files failed to encrypt; how many files were accessed; and "readme files."

Stepping through the sample as it executes shows how it prints out the results as it goes. However, if you run it, it will move fast and be unreadable during execution. So, to get more granular data, set proper breakpoints.

It then spits out the final results (If you don't set a breakpoint, this will exit immediately):

Upon execution, Rhysida excludes files with the following extensions from encryption:

.bat
.bin
.cab
.cmd
.com
.cur
.diagcab
.diagcfg
.diagpkg
.drv
.dll
.exe
.hlp
.hta
.ico
.lnk
.ocx
.ps1
.psm1
.scr
.sys
.ini
Thumbs.db
.url
.iso
.cab

*.cab is listed twice

Rhysida excludes the following directories:

$Recycle.Bin
Boot
Documents and Settings
PerfLogs
Program Files
Program Files (x86)
ProgramData
Recovery
System Volume Information
Windows
$RECYCLE.BIN