{
	"id": "22f0e305-b335-405c-81f6-2daa2b15468b",
	"created_at": "2026-04-06T00:10:06.971317Z",
	"updated_at": "2026-04-10T03:23:51.95391Z",
	"deleted_at": null,
	"sha1_hash": "fc31ff3edd2f3c812757f3abfde3193a5819dc7c",
	"title": "Rhadamanthys malware analysis: How infostealers use VMs to avoid analysis",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 194356,
	"plain_text": "Rhadamanthys malware analysis: How infostealers use VMs to\r\navoid analysis\r\nBy mpeintner\r\nPublished: 2023-10-03 · Archived: 2026-04-05 21:32:32 UTC\r\nWritten By\r\nDavid Catalán Senior Malware Reverse Engineer, Outpost24\r\nThe infostealer malware Rhadamanthys was discovered in the last quarter of 2022. Its capabilities showed a\r\nspecial interest in crypto currency wallets, targeting both wallet clients installed in the victim’s machine and\r\nbrowser extensions. The main distribution methods observed for this threat are fake software websites promoted\r\nthrough Google Ads, and phishing emails, without discriminating by region or vertical. \r\nWhile its information stealing capabilities and distribution mechanisms have been seen before, it is its downloader\r\ncomponent that truly stands out. By mixing advanced anti-analysis techniques coupled with heavy obfuscation, it\r\nmakes analysis by traditional security methods incredibly difficult. \r\nThe Rhadamanthys downloader is mainly coded in C++ and features a staged execution that makes use of a\r\nvariety of anti-analysis techniques: \r\nVirtual machine (VM) obfuscator. \r\nHeavy VM and sandbox detection capabilities. Both custom and imported from the open-source tool al-khaser. \r\nEmbedded file system that employs custom file formats. \r\nRhadamanthys’ anti-analysis features haven’t gone unnoticed. Zscaler investigators found that the VM obfuscator\r\nused is the Quake 3 VM. Furthermore, the analysts related those custom file formats to the ones used by the crypto\r\nminer Hidden Bee. Recently, CheckPoint published an in-depth analysis of the inner workings of the virtual\r\nfilesystem.  \r\nIn this post we take a look at what Rhadamanthys developers are using the Quake VM for, which modifications\r\nhave been made to it, and how the virtualized code has evolved through the different versions of the malware. We\r\nhave also published IDA Pro modules for disassembling standard and Rhadamanthys’ QVM binaries which you\r\ncan find in our public GitHub repository. \r\nDevirtualizing Quake VM \r\nAs a very brief introduction to the concept, VM obfuscators aim to hide code by implementing a custom\r\nprocessor, with its own set of instructions and an interpreter that translates custom instructions into native code.\r\nThere is plenty of documentation on the fundamentals and components of this obfuscation mechanism, such as\r\nthis article by Tim Blazytko. \r\nhttps://outpost24.com/blog/rhadamanthys-malware-analysis/\r\nPage 1 of 8\n\nTo study the Rhadamanthys downloader it is necessary to analyze the Quake 3 VM. Fortunately, there is great\r\ndocumentation on its inners and an open-source version was published on GitHub.  \r\nThis kind of open-source project can be attractive for malware developers willing to use VM obfuscators as they\r\nprovide widely tested components. The task of implementing a custom virtual processor is not trivial and can lead\r\nto bugs of all sorts and/or a considerable loss of performance if the developer lacks experience and solid\r\nknowledge on the matter. \r\nAfter locating the Q3VM interpreter within Rhadamanthys’ first stage and extracting the embedded code it\r\nprocesses, we decided to make a disassembler to take a look at its features. \r\nDefault Q3VM interpreter loop found in early 2023 versions of the malware.\r\nEarly versions of Rhadamanthys loader \r\nWithin the malware samples distributed during the first months of 2023 it is possible to spot the Q3VM interpreter\r\nloop as it is implemented in the original Github repository. The main changes the malware developers made to the\r\nVM are found on the syscalls. Within the Q3VM project, and for the rest of this article, the term syscall is used to\r\nrefer to functions implemented in native code, that are available to the virtualized code and allow it to interact\r\nwith the native ecosystem, for example, calling functions from Windows dlls or transferring memory from the VM\r\nspace to the native program. \r\nhttps://outpost24.com/blog/rhadamanthys-malware-analysis/\r\nPage 2 of 8\n\nInners of QVM CALL instruction.\r\nThese calls can be spotted within QVM files by searching for CALL instructions with a negative argument.\r\nOriginally, the syscalls of the Q3VM project are 4, and they allow to call the functions printf, fprintf, memset and\r\nmemcpy from the virtualized code. \r\nHowever, this version of the malware contains a total of 12 syscalls that replace the original ones. Apart from\r\nproviding access to the memset and memcpy functions, the modified syscalls allow the virtualized code to interact\r\nwith key components of the native program, enabling to read the memory space of kernel32.dll and resolving its\r\nexports, as well as providing some utilities to decode and transfer strings from the embedded QVM file to the\r\nmain program. \r\nSyscall that allows the virtualized code to call kernel32.GetProcAddress.\r\nVM to native program string transferring syscall.\r\nhttps://outpost24.com/blog/rhadamanthys-malware-analysis/\r\nPage 3 of 8\n\nOnce reviewed the basic features of the Quake VM we can now discuss the inners of Rhadamanthys’ obfuscated\r\ncode. For this version of the malware the code has 4 different paths that will be picked depending on the first\r\nargument received by the VM: \r\n0: Decode shellcode received as an argument. \r\n1: Resolve VirtualProtect. \r\n2: Use VirtualProtect to set execution permissions to shellcode. \r\n3: Transfer and decode to the main program the strings ‘Avast’ and ‘snxhk. Rhadamanthys’ loader will\r\ncheck for the presence of Avast AV before executing its next stage. \r\nVirtualProtect ROR13 withing the QVM file.\r\nInitializing ‘kernel32.dll’ string in QVM’s assembly.\r\nRhadamanthys 4.5 and above \r\nhttps://outpost24.com/blog/rhadamanthys-malware-analysis/\r\nPage 4 of 8\n\nWith the introduction of version 4.5 and the posterior versions, the VM component of the loader has received\r\nsubstantial changes. The logic of the virtualized code has been reworked, and thus syscalls have been modified. \r\nOn the native side, the number of syscalls has been reduced although their main functionality is still the same.\r\nProviding means to access the memory space of loaded modules and transferring data between the virtual and the\r\nnative environments. \r\n4.8 version syscall that retrieves the address of a module by its name and stores it in a collection.\r\nQVM assembly from version calling syscall –3.\r\nThe interpreter of the VM has also been updated, the opcodes of the instructions have been modified in an aim to\r\nprevent the identification of the VM and its disassembly. Within the embedded QVM file it is possible to observe\r\nhttps://outpost24.com/blog/rhadamanthys-malware-analysis/\r\nPage 5 of 8\n\na new logic. The new operations, depending on the argument passed from the native program are: \r\n0: Resolve an export of ntdll. Hashes are no longer hardcoded within the QVM file but passed as an\r\nargument. The ROR13 encoding prevails. \r\n1: Not implemented. \r\n2: Resolve kernel32 function. \r\n3: Decrypt stage 2 using an algorithm of the TEA family, \r\nTEA algorithm constant.\r\nNew module heur.bin \r\nApart from rebuilding the VM components of the stage 1, Rhadamanthys developers have recently added a new\r\nmodule with anti-VM capabilities that will execute before al-khaser‘s checks during the execution of the\r\ndecrypted shellcode. \r\nInternally the module contains 3 methods to detect virtualized environments, all of them involving the cpuid\r\ninstruction. \r\nThe first check compares the time the victim machine takes to execute the cpuid instruction against the\r\nperformance of the fyl2xp1 instruction. Due to how VMs need to handle the execution of the cpuid instruction, it\r\ntakes longer to execute it in such environments than it would take in a bare metal machine. For a more in-depth\r\nexplanation of this behavior, you can check the talk My Ticks Don’t Lie New Timing Attacks for Hypervisor\r\nDetection by Daniele Cono. \r\nhttps://outpost24.com/blog/rhadamanthys-malware-analysis/\r\nPage 6 of 8\n\nheur.bin detecting VMs by measuring cpuid’s performance.\r\nThe other 2 checks are very similar and use the cpuid instruction with the parameter 0x40000000, which should\r\nreturn no results on physical machines. Then compares it with the result of calling cpuid with an invalid input. If\r\neither of the results are not 0, heur.bin assumes it is being executed in a VM.  \r\nThe implementation described serves two purposes, not only detecting the presence of a hypervisor but also\r\npossible manipulations done to the output of cpuid in an attempt to harden analysis tools against these detection\r\ntechniques.  \r\nDetecting cpuid tampering and virtualization.\r\nDisassembling standard and Rhadamanthys’ Quake VM binaries \r\nAlthough Rhadamanthys’ activity has fallen since it reached its peak at the beginning of the year, it is still\r\nreceiving significant updates. The constant addition of new anti-analysis features and the upgrading of the existing\r\nones, as well as their complexity, shows the maturity of the threat actor behind its development. \r\nHowever, often obfuscation is a double-edged sword, as very specific protections can lead to very accurate\r\ndetection means, thus the importance of thorough analysis. To ease the task, you can find the source code of the\r\nhttps://outpost24.com/blog/rhadamanthys-malware-analysis/\r\nPage 7 of 8\n\nQVM processor and loader modules for IDA Pro in our GitHub repository.  \r\nIOCs\r\n0843a128cf164e945e6b99bda50a7bdb2a57b82b65965190f8d3620d4a8cfa2c\r\ne915dccc9e65da534932476e8cec4b7e5446dbd022f242e9302ac18d2a041df5\r\n9950788284df125c7359aeb91435ed24d59359fac6a74ed73774ca31561cc7ae\r\ndd4bb5e843a65e4e5a38032d12f19984daad051389853179bd8fdb673db82daf\r\n4b350ae0b85aa7f7818e37e3f02397cd3667af8d62eb3132fb3297bd96a0abe2\r\nAbout the Author\r\nDavid specializes in malware reverse engineering. With more than 7 years of experience in the field, he dismantles\r\nevery sample to uncover its features. Eager to find novel malware approaches being used on the wild, he focuses\r\non technical research.\r\nSource: https://outpost24.com/blog/rhadamanthys-malware-analysis/\r\nhttps://outpost24.com/blog/rhadamanthys-malware-analysis/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://outpost24.com/blog/rhadamanthys-malware-analysis/"
	],
	"report_names": [
		"rhadamanthys-malware-analysis"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434206,
	"ts_updated_at": 1775791431,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/fc31ff3edd2f3c812757f3abfde3193a5819dc7c.pdf",
		"text": "https://archive.orkl.eu/fc31ff3edd2f3c812757f3abfde3193a5819dc7c.txt",
		"img": "https://archive.orkl.eu/fc31ff3edd2f3c812757f3abfde3193a5819dc7c.jpg"
	}
}