{
	"id": "f0e1ebc4-5949-42a2-9b24-39d12c3e3755",
	"created_at": "2026-04-06T00:07:01.057471Z",
	"updated_at": "2026-04-10T03:21:16.213568Z",
	"deleted_at": null,
	"sha1_hash": "99bd27bf6767d64b85785ccaa400da7bfc405c69",
	"title": "RTM Locker Ransomware as a Service (RaaS) Now on Linux - Uptycs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1871376,
	"plain_text": "RTM Locker Ransomware as a Service (RaaS) Now on Linux -\r\nUptycs\r\nBy Uptycs Threat Research\r\nPublished: 2023-04-26 · Archived: 2026-04-05 18:57:48 UTC\r\nThe Uptycs threat research team has discovered a new ransomware binary attributed to the RTM group, a known\r\nransomware-as-a-service (RaaS) provider. This is the first time the group has created a Linux binary. Its locker\r\nransomware infects Linux, NAS, and ESXi hosts and appears to be inspired by Babuk ransomware's leaked source\r\ncode. It uses a combination of ECDH on Curve25519 (asymmetric encryption) and Chacha20 (symmetric\r\nencryption) to encrypt files.\r\nRTM Locker was identified during Uptycs' dark web hunting. Its malware is specifically geared toward ESXi\r\nhosts, as it contains two related commands. Its initial access vector remains unknown. Both asymmetric and\r\nsymmetric encryption make it impossible to decrypt files without the attacker's private key.\r\nNotable similarities between RTM Locker and Babuk ransomware include random number generation in addition\r\nto using ECDH in Curve25519 for asymmetric encryption. Babuk differs slightly from RTM Locker by using\r\nsosemanuk for asymmetric encryption, while RTM Locker uses ChaCha20.\r\nThe good news is that Uptycs extended detection and response (XDR) provides advanced detection capabilities\r\nand YARA rules for detecting RTM Locker malware.\r\nFAQ\r\nQ. How are RTM Locker and Babuk ransomware related?\r\nIt appears RTM Locker leverages leaked source code from Babuk ransomware. Both malware types use random\r\nnumber generation, Curve25519 implementation.\r\nQ. How does this new ransomware infect Linux, NAS, and ESXi hosts?\r\nThe initial access vector for RTM Locker is unknown at this time.\r\nQ. Can the encrypted files be decrypted without the attacker's private key?\r\nSorry, no. The combination of asymmetric and symmetric encryption makes decryption impossible without the\r\nprivate key.\r\nQ. What are some unique RTM Locker features compared to other ransomware strains?\r\nRTM Locker specifically targets ESXi hosts, contains two ESXi commands, and is the first Linux binary created\r\nby the RTM group. It is also inspired by leaked source code from Babuk ransomware.\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 1 of 17\n\nQ. How did the Uptycs threat research team discover this threat actor’s ransomware?\r\nWe identified the RTM Locker threat during our ongoing dark web hunting. Such continual research is imperative\r\nto better serve our customers.\r\nQ. What measures can be taken to detect and mitigate RTM Locker?\r\nOrganizations can use advanced detection solutions such as Uptycs XDR. Its built-in YARA rules and other\r\nadvanced detection capabilities identify and mitigate RTM Locker ransomware. To this end the Uptycs threat\r\nresearch team has shared a YARA rule to detect RTM Locker.\r\nThreat Attribution\r\nThe threat group RTM Locker was discovered by the Uptycs Threat Intelligence team during our dark web\r\nhunting. Figure 1 shows the post made by the RTM group about their Locker, which targets Windows,\r\nESXi/Linux, and NAS systems.\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 2 of 17\n\nFig. 1 - The post made by RTM group about its locker\r\nA previous Windows version of this ransomware was reported by Trellix, in which it mentions an onion site link\r\nto contact the threat actor. This appears to have prompted the team to move to Tox. The binary for this report\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 3 of 17\n\ncontains no mention of the onion site; only a Tox ID is mentioned (Figure 18).\r\nFig. 2 - Attacker update about moving from an onion site to Tox\r\nTechnical Analysis\r\nFig. 3 - Mind map of the Linux executable\r\nThe ransomware binary seems to be geared towards ESXi, because of the two ESXi commands that were noticed\r\nat the start of the program. It is statically compiled and stripped, making reverse engineering more difficult and\r\nallowing the binary to run on more systems. The initial access vector is unknown.\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 4 of 17\n\nFig. 4 - Main procedure of the ransomware\r\nname_threads, run_esxi_commands and pthread_wrapper_main are the important functions in this binary.\r\nname_threads uses sysconf(3) with _SC_NPROCESSORS_ONLN as argument to find out the number of threads\r\nto use in the program, and calls name_thread_routine in the pthread_wrapper routine to name each thread as\r\nshown in Figure 5.\r\nFIg. 5 - pthread_wraper calls pthread_create with name_thread_routine as an argument\r\nname_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\r\nprctl(2) with PR_SET_NAME as its argument. \r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 5 of 17\n\nFig. 6 - Threads being named inside name_thread_routine\r\nAfter naming each thread, the run_esxi_commands routine is called. Notably, this is not called on the NAS variant\r\nof the binary, since a NAS does not run ESXi.\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 6 of 17\n\nFig. 7 - Two ESXi commands are run using this program\r\nThe two ESXi commands are:\r\n1. “esxcli vm process list \u003e\u003e vmlist.tmp.txt”\r\nThis command lists all the ESXi VMs currently running on the system.\r\n2. “esxcli vm process kill -t=force -w”\r\nThis command kills all the ESXi VMs that were found by the previous command\r\nInterestingly, the file read by the program, vmlisttmp.txt, isn’t the file that it writes to (vmlist.tmp.txt). The\r\ndiffering filenames are a mistake made by the ransomware author, which suggests this ransomware might still be\r\nunder development.\r\nAfter the binary successfully kills all the running ESXi VMs, it begins the encryption routine by calling\r\npthread_wrapper_main. \r\npthread_wrapper_main seems to be a custom function that calls multiple pthread commands to run the encryption\r\nprocess more efficiently. Figure 8 shows a snippet of FUN_00407580, a function that is used to read the entire\r\nsystem using opendir(3), after which it performs lstat(2) on the file descriptor and progresses through the function\r\nbased on the results of the system call.\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 7 of 17\n\nFig. 8 - A FUN_00407580 excerpt\r\nTwo parts of this function are intriguing: 1) the call to the actual encryption routine (i.e., encrypt_file referenced in\r\nthe main function, and 2) how it finds which file to encrypt.\r\nThe lstat(2) system call returns 4 for a directory or 8 for a file. Figure 9 shows a function excerpt where a\r\nchecksum is performed, after which the encrypt_file function is called. This checksum seems to only check file\r\nextensions and, like the source code that inspired it, currently works for the following extensions:\r\n.log .vmdk .vmem .vswp .vmsn\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 8 of 17\n\nFig. 9 - Excerpt from FUN_00407580\r\nThe encryption function also uses pthreads to speed up execution. It obtains locks on particular threads to prevent\r\nrace conditions, then runs another function that encrypts a single file.\r\nFigure 10 shows the function called by encrypt_file. It has two constants, `expand 16-byte k` and `expand 32-byte\r\nk` related to the Salsa20/ChaCha family of ciphers. This leads us to believe the file is encrypted using the same\r\ncipher family. Figure 11 shows the constants as found in the function.\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 9 of 17\n\nFig. 10 - The FUN_00406680 function that encrypts a single file\r\nThe function in Figure 10 essentially encrypts a chunk of bytes read from fread(3) and writes that, after which it\r\nprobably seeks to the next chunk before reading it and encrypting the next chunk of bytes.\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 10 of 17\n\nFig. 11 - Constants related to the Salsa20/ChaCha cipher family\r\nAfter searching through the entire file, the filename has an .RTM extension appended to it.\r\nFile encryption on Windows and Linux versions\r\nThe encryption algorithm has two steps:\r\n1. Asymmetric encryption is initially used. The bad actor embeds a public key in the file, with its\r\ncorresponding private key remaining with the attacker. It generates a 32-byte shared secret between the\r\nattacker's public key and the file ephemeral keys using the Diffie-Hellman key exchange protocol.\r\n2. It then uses ChaCha20 symmetric encryption. The shared secret is hashed to obtain a 32-byte key to be\r\nused with an asymmetric encryption algorithm. After encryption, each public key is written at the end of its\r\ncorresponding file (as with Linux) or appended as an extension for Windows.\r\nBoth ECDH on Curve25519 and ChaCha are statically implemented without using any libraries or crypt function. \r\nThe Encryption Process\r\n1. An ephemeral key is generated by using:\r\nWindows – SystemFunction36 resolves to bcryptprimitives.ProcessPrng, which generates a specified\r\nnumber of random bytes from the user-mode per-processor random number generator.\r\nLinux – By reading /dev/urandom to generate a random sequence.\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 11 of 17\n\nThese random bytes are used as a private key during the Elliptic-Curve Diffie-Hellman (ECDH) algorithm\r\nimplemented on Curve25519.\r\nFig. 12 - Random number generator as ephemeral key\r\n2. The private key is now used to generate the public key on Curve25519. \r\nWindows – The public key is appended as an extension to the encrypted file.\r\nLinux – The public key is appended to the end of the encrypted file. This public key is used for decryption\r\nin the event of a victim paying ransom.\r\nFig. 13 - Encrypted files\r\n3. A shared key is now generated, using the private key from step 1 and the attacker's public key hardcoded in the\r\nfile on Curve25519. This shared secret is now used in symmetric ChaCha20 encryption.\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 12 of 17\n\nFig. 14 - Code snippet showing shared key generation Curve25519\r\nChaCha20 is a symmetric encryption where:\r\nKey – 32-byte shared key from step 3\r\nNonce – 8 bytes 0000000000000000\r\nCounter – 0\r\nChaCha20 is used for symmetric encryption in both Windows and Linux\r\nFor Windows, only the first 8000 hex bytes are encrypted, and the remaining bytes remain intact\r\nFor Linux, the entire file is encrypted\r\nFig. 15 - ChaCha key structure along with constants, key, counter, and nonce\r\nFile decryption\r\nTo decrypt the file, the public key, which is present in extension (WIndows) / end of the file (Linux), is read and\r\nalong with the attacker's private key the shared secret is obtained allowing file decryption. Use of both asymmetric\r\nand symmetric encryption makes it impossible to decrypt the encrypted files without the attacker's private key. \r\nSimilarities with Babuk ransomware\r\nAs mentioned, RTM Locker was likely inspired from leaked source code of Babuk ransomware. \r\nLinux random number generation is done by reading /dev/urandom, the same as for Babuk ransomware \r\nWindows and Linux Curve25519 implementation is based on Babuk ransomware \r\nBoth Linux versions encrypt files using the .log,  .vmdk, .vmem, .vswp, and  .vmsn file extensions \r\nBoth use ECDH in Curve25519 for asymmetric and ChaCha for symmetric encryption.\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 13 of 17\n\nFig. 16 - Similarities between RTM and Babuk ransomware\r\nAfter the entire directory is read, FUN_0047580 leaves a ransom note in the current directory that has a !!!\r\nWarning!!! filename (Figure 18). \r\nFig. 17 - Excerpt from FUN_0047580 that writes the ransom note\r\nFigure 18 shows the RTM Locker ransom note. They group has left a Tox ID to contact it to decrypt the files after\r\npaying the ransom.\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 14 of 17\n\nFig. 18 - Ransom note\r\nFig. 19 - Files encrypted by the RTM Locker ransomware\r\nUptycs XDR Coverage\r\nIn addition to having YARA built in and being armed with other advanced detection capabilities, Uptycs XDR\r\nusers can easily scan for RTM Locker. XDR contextual detection provides important details about identified\r\nmalware. Users can navigate to the toolkit data section in the detection screen, then click a detected item to reveal\r\nits profile (Fig. 20).\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 15 of 17\n\nFig. 20 - Uptycs detection\r\nIOC\r\nSHA256\r\n55b85e76abb172536c64a8f6cf4101f943ea826042826759ded4ce46adc00638\r\nb376d511fb69085b1d28b62be846d049629079f4f4f826fd0f46df26378e398b\r\nd68c99d7680bf6a4644770edfe338b8d0591dfe143278412d5ed62848ffc99e0\r\nYARA\r\nUptycs XDR scans the memory of newly launched processes and detects any presence of suspicious strings by\r\nusing YARA rules. The rule for detecting this RTM Locker has already been made available to our customers.\r\nIf you’re not an Uptycs XDR customer, you can use either the YARA tool or a third-party tool to scan suspicious\r\nprocesses. Here we share the rule for your convenience.\r\nrule Uptycs_Ransomware_RTM_Locker\r\n{\r\n    meta:\r\n        malware_name = \"RANSOMWARE\"\r\n        description = \"Ransomware is a malware that encrypts sensitive information on your system and asks for\r\nransom in exchange for restoring the encrypted data.\"\r\n        author = \"Uptycs Inc\"\r\n        version = \"1\"\r\n    strings:\r\n        $Ransomware_RTM_Locker_0 = \"esxcli vm process list\"  ascii wide\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 16 of 17\n\n$Ransomware_RTM_Locker_1 = \"vmlist.tmp.txt\"  ascii wide\r\n        $Ransomware_RTM_Locker_2 = \"esxcli vm process kill\"  ascii wide\r\n        $Ransomware_RTM_Locker_3 = \"!!! Warning!!!\"  ascii wide\r\n        $Ransomware_RTM_Locker_4 = \"Your network is infected by the RTM Locker command\"  ascii wide\r\n    condition:\r\n        all of ($Ransomware_RTM_Locker*)\r\n}\r\nSource: https://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nhttps://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux\r\nPage 17 of 17\n\nThe encryption race conditions, function also then runs another uses pthreads function to speed up execution. that encrypts a It obtains single file. locks on particular threads to prevent\nFigure 10 shows the function called by encrypt_file. It has two constants, `expand 16-byte k` and `expand 32-byte\nk` related to the Salsa20/ChaCha family of ciphers. This leads us to believe the file is encrypted using the same\ncipher family. Figure 11 shows the constants as found in the function.  \n   Page 9 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.uptycs.com/blog/rtm-locker-ransomware-as-a-service-raas-linux"
	],
	"report_names": [
		"rtm-locker-ransomware-as-a-service-raas-linux"
	],
	"threat_actors": [],
	"ts_created_at": 1775434021,
	"ts_updated_at": 1775791276,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/99bd27bf6767d64b85785ccaa400da7bfc405c69.pdf",
		"text": "https://archive.orkl.eu/99bd27bf6767d64b85785ccaa400da7bfc405c69.txt",
		"img": "https://archive.orkl.eu/99bd27bf6767d64b85785ccaa400da7bfc405c69.jpg"
	}
}