{
	"id": "62b45060-250e-4cad-9034-403bb8c2bb97",
	"created_at": "2026-04-06T00:09:45.79108Z",
	"updated_at": "2026-04-10T03:20:54.381141Z",
	"deleted_at": null,
	"sha1_hash": "ffb07fd296f04211524b7f5a87cc9f2e61debba9",
	"title": "Tech Analysis of Rhadamanthys Obfuscation Techniques | Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 68277,
	"plain_text": "Tech Analysis of Rhadamanthys Obfuscation Techniques | Blog\r\nBy Nikolaos Pantazopoulos, Sarthak Misraa\r\nPublished: 2023-02-21 · Archived: 2026-04-05 12:59:18 UTC\r\nTechnical Analysis\r\nThe following subsections focus on the technical analysis of the Rhadamanthys components.\r\nLoader\r\nThe loader consists of different stages until the actual loader starts its execution. We have categorized these stages\r\nas follows:\r\nInitialization Phase\r\nDecompression Phase\r\nLoader Phase\r\nInitialization Phase\r\nDuring the initialization phase, Rhadamanthys main task is to decode an embedded block and pass the execution\r\nthere. In addition, it detects and passes to the next phase the following information:\r\n1. Encrypted configuration\r\n2. A compressed blob that contains modules for assisting with code injection and the in-memory loader\r\nIn general, we have identified two different types of loaders. Interestingly in one of them, Rhadamanthys uses a\r\nvirtual machine (Q3VM) in order to obfuscate its code and hide certain code details.\r\nEach virtualized block of the protected code is executed by passing an integer value as a parameter to the\r\ninterpreter of the virtual machine. The identified features of the protected code are summarized in Table 1 below.\r\nParameter Code Description\r\n0 Decodes the next phase using the Base32 algorithm with the custom charset A-Z4-9=\r\n1\r\nLoads the Windows API functions GetProcAddress and VirtualProtect by using the ROR-13\r\nhashing technique.\r\n2 Calls the loaded VirtualProtect Windows API function to prepare the shellcode for execution.\r\n3\r\nGets a set of strings and searches for them in the current’s process memory space. These strings\r\nare:\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-rhadamanthys-obfuscation-techniques\r\nPage 1 of 4\n\ni) avast.exe\r\nii) snxhk\r\n                                                    Table 1 - Rhadamanthys Virtualized functions\r\nAdditionally, we identified a sample, which includes a de-virtualized version of the last code block (parameter 3)\r\nand the PDB path:\r\nd:\\debugInfo\\rhadamanthys\\debug\\sandbox.pdb\r\nNOTE: The magic bytes of the VM bytecodes have been modified by the threat actors as an attempt to hide the\r\nusage of the tool that was used. Moreover, in more recent samples, they have added the XTEA algorithm as an\r\nadditional layer of encryption for the decoded payload.\r\nDecompression Phase\r\nIn the second phase, the decoded shellcode loads dynamically a set of Windows API functions and decompresses\r\nthe loader’s code using the LZSS algorithm.\r\nLoader Phase\r\nIn the final stage, the loader decrypts its configuration using the RC4 algorithm and proceeds with the download\r\nprocess of the main module. The structure of the decrypted configuration is the following:\r\nstruct config\r\n{\r\n unsigned int Magic;\r\n unsigned int Flag; // Used during command line parsing since version 0.4.1\r\n unsigned char Key_Salt[0x10]; // Used during the AES decryption of the downloaded main module.\r\n unsigned char C2[]; // The URL path to download the main module. The main module uses the same path for data e\r\n};\r\nIt is worth to note that the final stage of the loader has its own header structure, which is described below. The\r\ninformation derived from this structure is necessary for the loader in order to apply necessary code relocations.\r\nstruct Loader_Header\r\n{\r\n unsigned __int16 Magic; // Set to 52 53\r\n unsigned __int16 Characteristics;\r\n unsigned __int16 Sections_Number;\r\n unsigned __int16 Sizeof_Header;\r\n unsigned int Entry_Point_Offset;\r\n unsigned int Stager_Size;\r\n unsigned int Imports_Offset;\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-rhadamanthys-obfuscation-techniques\r\nPage 2 of 4\n\nunsigned int\r\nImports_Size;\r\n unsigned intUnknown1;\r\n unsigned int Unknown2;\r\n unsigned int Relocation_Table_Offset;\r\n unsigned int Relocation_Table_Size;\r\n section Stager_Sections[5];\r\n};\r\nstruct section\r\n{\r\n unsigned int Disk_Section_Offset;\r\n unsigned int Rva_Section_Offset;\r\n unsigned int Section_Size;\r\n};\r\nEmbedded File System\r\nWhen Rhadamnthys compromises a 64-bit host, the loader decompresses (LZMA) an embedded file system. The\r\nembedded file system includes several modules that aim to assist the execution process of the main module. The\r\nstructure of the file system and its embedded modules along with a description of them (Table 2) are mentioned\r\nbelow.\r\nstruct loader_embedded_vfs\r\n{\r\n unsigned char hardcoded_value; // Set to 0xB\r\n unsigned char num_of_modules;\r\n unsigned __int16 base_Address;\r\n module_info modules[num_of_modules];\r\n};\r\n \r\nstruct module_info\r\n{\r\n unsigned int module_hash; // MurmurHash. Used to detect the module.\r\n unsigned char module_size_offset; // The byte is left shifted with the value 0xc.\r\n};\r\nModule Name Description\r\nprepare.bin Applies relocations and dynamic API loading.\r\ndfdll.dll Executable file written on disk. It loads and executes the downloaded payload.\r\nunhook.bin Detects if specified Windows API functions of NTDLL library have been hooked.\r\nphexec.bin Injects code by using the SYSENTER command while calling Windows API functions.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-rhadamanthys-obfuscation-techniques\r\nPage 3 of 4\n\nTable 2 - Identified embedded modules\r\nNOTE: In case of a 32-bit compromised host, none of the above modules are required. Instead, Rhadamanthys\r\ngenerates a key by doing a bitwise XOR operation of the first byte of the downloaded module with the hard-coded\r\nbyte value 0x21. The output is used as an XOR key to decrypt the first 108 bytes (header) of the downloaded\r\npayload\r\nMain module\r\nSimilarly with the loader component, the main module has its own set of modules and components. As can be seen\r\nin Table 3, the main module has a variety of embedded components.\r\nModule Name Description\r\nKeePassHax C# module to exfiltrate credentials of password management software KeePass.\r\nStubmod Assists with communication between modules and Coredll by using a named PIPE.\r\nStub Loads and executes the main module from disk.\r\nCoredll Main orchestrator.\r\nPreload Executes Coredll.\r\nRuntime C# module to execute PowerShell scripts.\r\nStubexec Module, which injects code to another process (regsvr32).\r\n/etc/license.key Unknown. Potentially related to a license key.\r\n/etc/puk.key Elliptic Curve (NIST P-256) public key\r\n/extension/%08x.lua A set of LUA scripts, which are used for extracting credentials.\r\n                                             Table 3 - Main module embedded components\r\nFurthermore, instead of using hardcoded offsets to detect and extract them, Rhadamanthys uses the MPQ hashing\r\nalgorithm to hash the name of the embedded component and generate a set of hashes. Then, it uses these hashes to\r\nscan its own memory in order to detect the appropriate component.\r\nExplore more Zscaler blogs\r\nSource: https://www.zscaler.com/blogs/security-research/technical-analysis-rhadamanthys-obfuscation-techniques\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-rhadamanthys-obfuscation-techniques\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.zscaler.com/blogs/security-research/technical-analysis-rhadamanthys-obfuscation-techniques"
	],
	"report_names": [
		"technical-analysis-rhadamanthys-obfuscation-techniques"
	],
	"threat_actors": [],
	"ts_created_at": 1775434185,
	"ts_updated_at": 1775791254,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ffb07fd296f04211524b7f5a87cc9f2e61debba9.pdf",
		"text": "https://archive.orkl.eu/ffb07fd296f04211524b7f5a87cc9f2e61debba9.txt",
		"img": "https://archive.orkl.eu/ffb07fd296f04211524b7f5a87cc9f2e61debba9.jpg"
	}
}