FAQ

Threat Attribution

The threat group RTM Locker was discovered by the Uptycs Threat Intelligence team during our dark web hunting. Figure 1 shows the post made by the RTM group about their Locker, which targets Windows, ESXi/Linux, and NAS systems.

Fig. 1 - The post made by RTM group about its locker

A previous Windows version of this ransomware was reported by Trellix, in which it mentions an onion site link to contact the threat actor. This appears to have prompted the team to move to Tox. The binary for this report contains no mention of the onion site; only a Tox ID is mentioned (Figure 18).

Fig. 2 - Attacker update about moving from an onion site to Tax

Technical Analysis

Fig. 3 - Mind map of the Linux executable

The ransomware binary seems to be geared towards ESXi, because of the two ESXi commands that were noticed at the start of the program. It is statically compiled and stripped, making reverse engineering more difficult and allowing the binary to run on more systems. The initial access vector is unknown.

Fig. 4 - Main procedure of the ransomware

name_threads, run_esxi_commands and pthread_wrapper_main are the important functions in this binary. name_threads uses sysconf(3) with _SC_NPROCESSORS_ONLN as argument to find out the number of threads to use in the program, and calls name_thread_routine in the pthread_wrapper routine to name each thread as shown in Figure 5.

FIg. 5 - pthread_wraper calls pthread_create with name_thread_routine as an argument

name_thread_routine names each thread to use later in the encryption process. The threads are named “Thread-pool-%d”, with the decimal number representing the index of the thread. Shown in Figure 6, this is done using prctl(2) with PR_SET_NAME as its argument. 

Fig. 6 - Threads being named inside name_thread_routine

After naming each thread, the run_esxi_commands routine is called. Notably, this is not called on the NAS variant of the binary, since a NAS does not run ESXi.

Fig. 7 - Two ESXi commands are run using this program

The two ESXi commands are:

1. “esxcli vm process list >> vmlist.tmp.txt”
   This command lists all the ESXi VMs currently running on the system.
2. “esxcli vm process kill -t=force -w”
   This command kills all the ESXi VMs that were found by the previous command

Fig. 8 - A FUN_00407580 excerpt

Fig. 9 - Excerpt from FUN_00407580

Fig. 10 - The FUN_00406680 function that encrypts a single file

The function in Figure 10 essentially encrypts a chunk of bytes read from fread(3) and writes that, after which it probably seeks to the next chunk before reading it and encrypting the next chunk of bytes.

Fig. 11 - Constants related to the Salsa20/ChaCha cipher family

After searching through the entire file, the filename has an .RTM extension appended to it.

File encryption on Windows and Linux versions

The encryption algorithm has two steps:

1. Asymmetric encryption is initially used. The bad actor embeds a public key in the file, with its corresponding private key remaining with the attacker. It generates a 32-byte shared secret between the attacker's public key and the file ephemeral keys using the Diffie-Hellman key exchange protocol.
2. It then uses ChaCha20 symmetric encryption. The shared secret is hashed to obtain a 32-byte key to be used with an asymmetric encryption algorithm. After encryption, each public key is written at the end of its corresponding file (as with Linux) or appended as an extension for Windows.

Both ECDH on Curve25519 and ChaCha are statically implemented without using any libraries or crypt function. 

The Encryption Process

1. An ephemeral key is generated by using:

• Windows – SystemFunction36 resolves to bcryptprimitives.ProcessPrng, which generates a specified number of random bytes from the user-mode per-processor random number generator.
• Linux – By reading /dev/urandom to generate a random sequence.

These random bytes are used as a private key during the Elliptic-Curve Diffie-Hellman (ECDH) algorithm implemented on Curve25519.

Fig. 12 - Random number generator as ephemeral key

2. The private key is now used to generate the public key on Curve25519. 

• Windows – The public key is appended as an extension to the encrypted file.
• Linux – The public key is appended to the end of the encrypted file. This public key is used for decryption in the event of a victim paying ransom.

Fig. 13 - Encrypted files

3. A shared key is now generated, using the private key from step 1 and the attacker's public key hardcoded in the file on Curve25519. This shared secret is now used in symmetric ChaCha20 encryption.

Fig. 14 - Code snippet showing shared key generation Curve25519

ChaCha20 is a symmetric encryption where:

• Key – 32-byte shared key from step 3
• Nonce – 8 bytes 0000000000000000
• Counter – 0
  
• ChaCha20 is used for symmetric encryption in both Windows and Linux
  
• For Windows, only the first 8000 hex bytes are encrypted, and the remaining bytes remain intact
  
• For Linux, the entire file is encrypted
  

Fig. 15 - ChaCha key structure along with constants, key, counter, and nonce

File decryption

To decrypt the file, the public key, which is present in extension (WIndows) / end of the file (Linux), is read and along with the attacker's private key the shared secret is obtained allowing file decryption. Use of both asymmetric and symmetric encryption makes it impossible to decrypt the encrypted files without the attacker's private key. 

Similarities with Babuk ransomware

As mentioned, RTM Locker was likely inspired from leaked source code of Babuk ransomware. 

• Linux random number generation is done by reading /dev/urandom, the same as for Babuk ransomware 
• Windows and Linux Curve25519 implementation is based on Babuk ransomware 
• Both Linux versions encrypt files using the .log,  .vmdk, .vmem, .vswp, and  .vmsn file extensions 
• Both use ECDH in Curve25519 for asymmetric and ChaCha for symmetric encryption.

Fig. 16 - Similarities between RTM and Babuk ransomware

After the entire directory is read, FUN_0047580 leaves a ransom note in the current directory that has a !!! Warning!!! filename (Figure 18). 

Fig. 17 - Excerpt from FUN_0047580 that writes the ransom note

Figure 18 shows the RTM Locker ransom note. They group has left a Tox ID to contact it to decrypt the files after paying the ransom.

Fig. 18 - Ransom note

Fig. 19 - Files encrypted by the RTM Locker ransomware

Uptycs XDR Coverage

In addition to having YARA built in and being armed with other advanced detection capabilities, Uptycs XDR users can easily scan for RTM Locker. XDR contextual detection provides important details about identified malware. Users can navigate to the toolkit data section in the detection screen, then click a detected item to reveal its profile (Fig. 20).

Fig. 20 - Uptycs detection

IOC

YARA

rule Uptycs_Ransomware_RTM_Locker
{
    meta:
        malware_name = "RANSOMWARE"
        description = "Ransomware is a malware that encrypts sensitive information on your system and asks for ransom in exchange for restoring the encrypted data."
        author = "Uptycs Inc"
        version = "1"
    strings:
        $Ransomware_RTM_Locker_0 = "esxcli vm process list"  ascii wide
        $Ransomware_RTM_Locker_1 = "vmlist.tmp.txt"  ascii wide
        $Ransomware_RTM_Locker_2 = "esxcli vm process kill"  ascii wide
        $Ransomware_RTM_Locker_3 = "!!! Warning!!!"  ascii wide
        $Ransomware_RTM_Locker_4 = "Your network is infected by the RTM Locker command"  ascii wide
    condition:
        all of ($Ransomware_RTM_Locker*)
}