{
	"id": "7d2c53a4-b7f2-4232-8b16-c4ad1a06e926",
	"created_at": "2026-04-06T00:22:32.551655Z",
	"updated_at": "2026-04-10T13:12:11.367517Z",
	"deleted_at": null,
	"sha1_hash": "9e3685a9158e344a72ca5003b249efe3f5bd7127",
	"title": "Sophisticated New Packer Identified in CryptXXX Ransomware Sample",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 54782,
	"plain_text": "Sophisticated New Packer Identified in CryptXXX Ransomware\r\nSample\r\nBy Joseph Landry\r\nPublished: 2016-05-05 · Archived: 2026-04-05 20:18:20 UTC\r\nSummary of Execution\r\nThis sample is being delivered using the Angler Exploit Kit within a\r\ndrive-by download attack. The exploit is the latest Adobe Flash exploit.\r\nThe packing on the sample is very sophisticated; far more sophisticated than\r\nthe final payload. The packer looks to be written in C and utilizes many\r\ntechniques used by shellcode, but is repurposed to evade static analysis. The\r\npacker also has many unnecessary API calls whose purpose could only be to\r\nconfuse dynamic and behavioral detection. Multiple layers of packing are\r\nused to further conceal itself.\r\nThe ransomware payload is written in Delphi and only has a few dirty tricks\r\nto mask it’s malicious intent. In addition to the ransom, the payload\r\nhunts down bitcoin wallet files on the disk to steal their contents.\r\nWhy would an adversary spend more resources in the packing of ransomware instead\r\nof the ransomware itself? I maintain that they are trying to increase the time\r\nbetween the initial release of the malware and the time of detection by the\r\nantivirus software. This longer time period will net them more infections, and\r\nin turn, increase revenue on an individual campaign. It makes economical sense\r\nto spend more resources on gumming up the antivirus analysis and detection\r\nprocess, than building a better ransomware.\r\nPacked Sample\r\nFilename: api-ms-win-system-hid-l1-1-0.dll\r\nFile size: 252,416 bytes\r\nMD5: 8D044D1FC07526FA0B1ADADD1FBDAA28\r\nSHA-1: 41A70AD7D7D43C33C73485C827ADAEF30C86597A\r\nSHA-256: 175e01b113bbd7637adb88e4f1d3bc526dc429b221465a7a1fbd5bf1ed22662f\r\nUnpacked Sample\r\nFile size: 394,240 bytes\r\nMD5: BAF5EC28F7E25FB3C54153C509940712\r\nhttps://www.sentinelone.com/blog/sophisticated-new-packer-identified-in-cryptxxx-ransomware-sample/\r\nPage 1 of 6\n\nSHA-1: C47A6626CAB9BE3904AA70CF24910A26E46F16BF\r\nSHA-256: A386FE46D245BC3C53DD9154266557E19219DB0086DCBE1BC6FD7B9B0EC9B70B\r\nPacker Layer 0 (Psychological)\r\nFrom an initial inspection, the sample looks like an innocuous DLL from Microsoft.\r\nThe file has a good sounding scary-to-delete-me name. The version strings\r\nin the resource section are formatted exactly to Microsoft style. Most malware\r\nI’ve seen that tries to masquerade as a Microsoft binary forgets certain features\r\nlike the copyright symbol.\r\nAll the DLL export symbol names are in the format lua_*. It looks like a\r\nlegitimate Lua library, but the disconnect begins here. When have you ever\r\nheard of a Microsoft product written in Lua?\r\nAll of these exports are just stub functions. Just standard procedure\r\nprolog and epilogs with no implementation in-between.\r\nThe sample is also hard to get started unless you have full context of how it is supposed to be run.\r\nThe sample is initially run using rundll32.exe\r\nC:WindowsSystem32rundll32.exe api-ms-win-system-hid-l1-1-0.dll,Working\r\nWhen first loaded, a call to the dll entry point is made, then a call to Working(). The\r\npacked DLL does not have an export named Working(), but the unpacked payload\r\ndoes. Working() will check the the command line string to ensure that it\r\nwas launched with rundll32.exe. If it isn’t, It will create a new process\r\nusing rundll32.exe. Once Working() is sure that the process was created\r\nwith rundll32.exe, it will then start a new process using rundll32.exe, but\r\nthis time it will run the AccessToken() export. AccessToken() is the\r\nbeginning of the ransomware code.\r\nTo successfully launch the ransomeware, you must pass the “Working” or\r\n“AccessToken” parameter in the rundll32 command line. Without it, it will not\r\nrun. Why would the author be troubled to limit the infection?\r\nI postulate that the author did this on purpose. I can see the scenario playing\r\nout in my head: A forensics analyst has found this DLL, and determines that\r\nit is related to the compromise. He sends the sample\r\nto a malware analyst who tries running the DLL, but can’t get the\r\nransomeware to invoke.\r\nThe malware analyst will incorrectly respond to the forensic analyst,\r\nsaying that there must be more to the infection. This will slow down the\r\ninitial response process, allowing more infections. Before the malware analyst\r\nhttps://www.sentinelone.com/blog/sophisticated-new-packer-identified-in-cryptxxx-ransomware-sample/\r\nPage 2 of 6\n\ncan get the ransomeware to run, he will have to unpack the sample to get the\r\npayload, and see the two exports of the payload.\r\nThe packer is riddled with API calls that have no effect whatsoever. This\r\nmakes it a nightmare for manual dynamic analysis. It was hard to tell what\r\ncode is important, and what is just a red herring. An analyst who sees\r\na call to GetLogicalDrives() might think, “I must be really close to the\r\nransomware code!” but only to be disappointed to find that the ransomware isn’t\r\neven unpacked. Here is a call to MoveFile(), that might look like it’s using\r\nobfuscated strings statically, but dynamically, you can see the function\r\nreturn 0 indicating failure.\r\nThere are imports to winmm.dll (multi-media) that are never used. This might\r\nbe an attempt\r\nto make the DLL look more legitimate (since the filename has HID in the name\r\nand most MIDI devices also have a HID component), but I believe the author’s\r\nreasoning to include all these unused imports is to hide one crucial\r\nimport: VirtualProtect().\r\nThis one call to VirtualProtect() opens the gate to the rest of the packer.\r\nPacker Layer 1\r\nThe first software layer of protection used by the packer is an encrypted region\r\nof code. The code is decrypted in place, but because the “.text” section\r\nis marked as read-execute in the PE header, a call to VirtualProtect() must\r\nbe made to allow write access.\r\nOnce the region is decrypted, it is run. Unfortunately, OllyDBG has determined\r\nthis region to be data, not code. So in the debugger, Olly will not display\r\nthe disassembly. I eventually discovered that you can remove Olly’s analysis\r\nfor a section using ctrl+backspace:\r\nAt this point, I made a dump of the DLL to analyze the uncovered region.\r\nPacker Layer 2\r\nThe windows loader was not able to patch the relocations for this encrypted\r\nregion, because it was still encrypted during the loading process. As a result,\r\nmany restrictions are on the author for this region of code.\r\nAll the code must be written similar to shellcode. It has to run wherever it\r\nis loaded in memory. This means no access to global variables, the import\r\ntable, or string literals.\r\nhttps://www.sentinelone.com/blog/sophisticated-new-packer-identified-in-cryptxxx-ransomware-sample/\r\nPage 3 of 6\n\nThe first thing that is done, is a large structure is allocated on the stack.\r\nThis structure contains the ‘global variables’ for this section of code. because\r\nIt doesn’t know where the “.data” segment is to access normal global variables.\r\nYou can see in my reverse engineered version of this structure, there\r\nare pointers to API calls. This is done because the encrypted portion\r\nof the packer was not linked during compile time. It also hides these\r\nentries from the import section.\r\nNow, the base address of the DLL is recovered using a technique similar to an\r\negghunter. a call $+5; pop eax is used to find the value of EIP, and\r\nmemory is search for ‘MZ’ at the start of a each 4k page. This value is stored\r\nfor later use.\r\nBecause this section of code isn’t linked into the main binary at compile time, its imports\r\nhave to manually be resolved. This is done with a technique commonly used in windows\r\nshellcode. A pointer to a linked list of loaded modules is stored inside the\r\nProcess Environment Block (PEB). By traversing this linked list, the required\r\nmodules containing the exported functions needed can be found. Once the modules\r\nare found, the individual exports can be found by following the PE structure.\r\nAlso, because this section of code can’t use any string literals, instead\r\nof using a string compare, all strings needed are hashed and the hashes are compared.\r\nIn the following image, the hash value of the string “kernel32.dll” is 0x6a4abc5b.\r\nThe most important symbols to resolve are LoadLibrary() and GetProcAddress().\r\nBoth are in kernel32. Using these two functions, all other symbols can be resolved.\r\nBut because of the limitation of no string literals, some strings have to be built\r\non the stack first.\r\nNow that all the prep-work for this stage is done, it must now unpack the payload\r\nand position it in memory.\r\nFirst the packed dll is read off of the disk and into memory. The region\r\ncontaining the compressed payload is found.\r\nThe payload dll is decompressed using “RtlDecompressBuffer()”. The PE header is\r\nparsed and the image is reconstructed in memory. This image must have its\r\nimports manually linked in and relocations patch. But the address range the\r\npayload image has been reconstruced in is not it’s final resting place. The\r\npacked dll is occupying that region.\r\nTo remove the packed image from memory to make room for the final position of\r\nthe unpacked payload DLL, a bit of code must be placed outside of these two regions.\r\nThis portion of the code is identified by a ‘MOV EAX, 0x11223344’ instruction.\r\nhttps://www.sentinelone.com/blog/sophisticated-new-packer-identified-in-cryptxxx-ransomware-sample/\r\nPage 4 of 6\n\nA VirtualAlloc() is performed, and the code is copied to the newly allocated region.\r\nExecution continues at this region.\r\nThis last bit of code will unmap the packed dll from memory using a call\r\nto UnmapViewOfFile(). Next, it reallocates this exact same region to copy\r\nthe unpacked payload image. The unpacked payload is freed from it’s temporary\r\nposition and execution continues at the entry point of the payload dll.\r\nFrom here, the ransomware runs.\r\nRansomware\r\nThe ransomware communicates to one of two hard coded command servers.\r\nThe IP addresses of the command servers are 146.185.250.152 and 217.23.6.40.\r\nThere are no domain names stored in the sample, only the IP addresses.\r\nWhois records for these ip ranges appear to be issued to Ukraine and Netherlands.\r\nDomain names that are associated with these ip addresses in the past are:\r\n146.185.250.152\r\nf0rget–a00lls.com\r\nweeell-drive.com\r\n647hnhjnnc-nje00l.com\r\nfeeeel–t00ll.com\r\ndaertnw90-kola.com\r\n217.23.6.40\r\np3.regularclass.com\r\nregularclass.com\r\nns2.streamingmp4.net\r\nns1.streamingmp4.net\r\nns2.streamingmp4.net\r\nns1.streamingmp4.net\r\nns2.streamingmp4.net\r\nns1.streamingmp4.net\r\ncdn78.livefile.org\r\nvenusbjerget.dk\r\nsemi2.wrzhost.com\r\nkidshot.ijustcantbelieve.com\r\ncallspoof.ijustcantbelieve.com\r\ncelebrityhotnews.net\r\njustinbieberoncam.ijustcantbelieve.com\r\nMany of these records appear to be old by at least a year, and are probably not used in the attack.\r\nhttps://www.sentinelone.com/blog/sophisticated-new-packer-identified-in-cryptxxx-ransomware-sample/\r\nPage 5 of 6\n\nOnce the local files are encrypted, the user is presented with a ransom notice:\r\nConclusion\r\nAs adversaries continue to invest resources on packing we should expect to see more examples of how these tricks\r\nwill still slow down the detection pipeline.\r\nSentinelOne detects this specific attack at the initial exploit phase, before the ransomeware is even unpacked.\r\nTo learn more about how SentinelOne can help you prevent these kinds of attacks, please click here to download\r\nSentinelOne’s Technical Overview.\r\nSource: https://www.sentinelone.com/blog/sophisticated-new-packer-identified-in-cryptxxx-ransomware-sample/\r\nhttps://www.sentinelone.com/blog/sophisticated-new-packer-identified-in-cryptxxx-ransomware-sample/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.sentinelone.com/blog/sophisticated-new-packer-identified-in-cryptxxx-ransomware-sample/"
	],
	"report_names": [
		"sophisticated-new-packer-identified-in-cryptxxx-ransomware-sample"
	],
	"threat_actors": [],
	"ts_created_at": 1775434952,
	"ts_updated_at": 1775826731,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9e3685a9158e344a72ca5003b249efe3f5bd7127.pdf",
		"text": "https://archive.orkl.eu/9e3685a9158e344a72ca5003b249efe3f5bd7127.txt",
		"img": "https://archive.orkl.eu/9e3685a9158e344a72ca5003b249efe3f5bd7127.jpg"
	}
}