RansomHouse encryptor malware analysis

Threat Landscape

The elusive RansomHouse group has been stirring up the ransomware market in the past six months, with recent attacks on the accounting firms Shipleys and Hbl Cpas as well as community hospital Dameron out of Stockton, California.

The group recently released an updated encryptor as well as an automation tool nicknamed 'MrAgent'. The typical tactics of spear-phishing campaigns against thier victims has proven successful, but once inside they would quickly deploy their encryptor and wreak havoc across the victims network.

Complexity is a growing problem for ransomware groups. Trying to track encrypted files and VM disks across a victims network is a complex problem. This causes an increase in time spent within the victims network which can lead to discovery by the victims security team. A solution to managing the complexity at speed and scale is the new automation tool 'MrAgent'.

Given the changes in their tactics, most notably the 'MrAgent' tool; it's clear the RansomHouse group expects their operation to ramp up.

Keypoints

No baked in VM management, relies on a third party tool
Uses the less common Sosemanuk stream cipher
Uses sysconf() to get processor information

The Encryptor

Hashes & Submission date

File: afe398e95a75beb4b0508c1bbf7268e8607d03776af0b68386d1e2058b374501
First Submission: 2023-11-27 07:23:56 UTC (https://www.virustotal.com/gui/file/afe398e95a75beb4b0508c1bbf7268e8607d03776af0b68386d1e2058b374501/details)

Compiler

Type: ELF64
Operation system: Unix Library: GLIBC (2.4)
Compiler: gcc ((Ubuntu4.4.3-4ubuntu5.1) 4.4.3)

Tactics and Techniques

Background on VM based ELF encryptors

The encryptor itself is fairly streamlined, it focuses on file and directory discovery and encrypting a file. The malware will attempt to use the sysconf to identify how many processors are available and as such setup the encryptors thread pool accordingly. This is typical for most ELF encryptors.

The malware is targeting a VM based system, but unlike other encryptors is not attempting to manipulate the VM instance by stopping any running VM related processes. This maybe a tactic to stay hidden, but there is a downside. The VM processes are responsible for reading and writing data to the VM files, these files are intended to be encrypted by the malware. If a VM process is still open, the write buffers may not have been flushed. This means that although the data on disk is encrypted, some of it will be corrupted once the buffer is flushed. This will result in unexpected results when decrypting a file.

Program flow

The main entrypoint starts by checking if a directory path was given as the first arguments to the program. If no arguments were given, the program will print the usage message and quit.

The number of processors are obtained via the sysconf() call for _SC_NPROCESSORS_ONLN . This value is used to control the number of threads to created in the thread pool.

If one or more directories were specified, the sample will iterate through each directory; if the -r switch was used, it will indicate that the sample should recursively iterate through the directory. For each directory specified, search for files to encrypt and drop the ransom note.

A condition var is used to communicate between worker threads, this is protected by a standard mutex lock using the default normal mutex type.

Once complete, the statistics are printed to STDOUT with a well formatted string and detailed information on how many files were encrypted.

Thread pool creation

The thread pool is configured using the result of the sysconf(_SC_NPROCESSORS_ONLN) from the main function described above.

For each active processor available, the pthread library is used to create a new worker thread. The worker thread is responsible for handling status updates for statistics and the overall encryption process.

The thread pool uses a standard mutex and condition var by calling the pthread_mutex_init() and pthread_cond_init() functions to control the stability of the encryption process. For any error raised, the error will be written to STDERR.

File and Directory discovery

The function handling the directory scan takes an argument related to the optional configuration to perform recursive directory scanning (-r switch). If this option is present, the sample will attempt to call itself recursively ensuring that nothing else is on the stack, this will reduce the chances of a stack overflow when calling largely nested directory structures.

The function will identify if the file is a directory or a regular file by using the d_type member of the directory structure. If the file is a directory, it will attempt to recursively iterate through it, provided it is not '.' or '..'.

If the file is a regular file, the function will identify if the extensions is valid or not.

Invalid extensions:

.mario
.wmario
.lmario
.emario
.nmario
.mmario

Valid extensions:

.vmdk
.ovf
.ova
.vmem
.vswp
.vmsd
.vmsn
.vib
.vbk
.vbm

The invalid extensions are clearly the re-named file extensions used by the encryptor after encrypting a file. It contains various version of the word 'mario', potentially from variants of the RansomHouse encryptor.

Valid extensions are clearly VM related. Although no other VM related tooling, such as the esxcli was used; the file extensions present in the malwares configuration block, makes it clear the target system is intended to be a VM.

Lastly, a new worker is created to perform the encryption. A pointer to the encryption function is passed into the work, and a condition var is used to signal the status update, this var is protected by a standard mutex.

Encrypting files

The encryption routine will use a few common linux APIs to determine information about the file prior to encryption. For instance the fopen() call will open the file in both read/write binary mode. The xstat64() is used to get the file size prior to encrypting. The value will be used to update the statistics counter once the encryption is done.

Once the file is open and the information about the file is obtained, the function will then setup the file extension with the value .emario. This extension is checked during the file discovery process, to exclude any existing encrypted files.

Before encrypting the file the system must retrieve random data using the /dev/urandom and asking the OS for 32 bytes of data. This is a non-blocking call, which means that any data in the entropy buffer will be used upto 32 bytes. This process is not a dedicated hardware backed CSPRNG, instead this process will use device driver or environmental noise. The Linux manual indicates that using this source is not suitable for cryptographic usage.

With entropy gathered, the function will iterate on reading, encrypting and writing the contents back to the original file and updating the file extension.

Before ending its encryption of the file, the function will clear the key and encryption context immediately after use. This is a strong design choice that limits potential key leakage.

The encryption algorithm is statically linked using the Sosemanuk stream cipher. This is a fairly uncommon cipher, but it has been observed in past ESXi based campaigns such as ESXiArgs in 2023.

Readme

The readme file contains information about what occured, the consequnces and how to handle the situation. The readme is specifically generic in terms of who it is addressed to, but it indicates that contact should be done via TOR.

## YARA
/*
MIT License
Copyright 2024 ShadowStackRe.com
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
rule RansomHouse {
    meta:
        description = "rule to detect RansomHouse"
        author = "ShadowStackRe.com"
        date = "2024-02-20"
        Rule_Version = "v1"
        malware_type = "ransomware"
        malware_family = "RansomHouse"
        License = "MIT License, https://opensource.org/license/mit/"
    strings:
            $strFileExt = ".emario"
            $strRestore = "How To Restore Your Files.txt"
            $strEncrypted = "/path/to/be/encrypted"
            $strCrypted = "Crypted:"
    condition:
            filesize < 100KB and all of ($str*)
}

RansomHouse Ransomware