{
	"id": "ea594af2-7c5f-45a3-aac0-9478fcd29811",
	"created_at": "2026-04-06T00:19:47.821143Z",
	"updated_at": "2026-04-10T03:20:38.478483Z",
	"deleted_at": null,
	"sha1_hash": "505edf175aa79822071371123501c8d417126565",
	"title": "Quick revs: Pandora Ransomware - The Box has been open for a while...",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 816340,
	"plain_text": "Quick revs: Pandora Ransomware - The Box has been open for a\r\nwhile...\r\nBy f0wL\r\nArchived: 2026-04-05 16:19:55 UTC\r\nHey there, I’m finally getting around to introducing the new post category “Quick revs”, which will feature short\r\nwrite-ups of various malware analysis and reverse engineering topics. This will allow me to post more frequently,\r\nsince I don’t always have to time to write deep-dive reports in my limited free time.\r\nToday we are going to be looking at “Pandora Ransomware”, a novel Ransomware strain that has been monitored\r\nfor a couple of days, e.g. by MalwareHunterTeam, but at first no sample was available.\r\nAt the time of writing Pandora is claiming on their Leak site to have compromised four companies, one of which\r\nis the japanese automotive OEM Denso, which has been covered extensively in the media. I’m bringing up Denso\r\nhere, because they were compromised by Rook Ransomware a few months earlier, which beggs the question if the\r\nattackers somehow were able to maintain access and just rebranded from Rook to Pandora. Of course this is just\r\nspeculation on my part and I don’t consider signifficant similarities in the ransomware samples of both strains as\r\nsufficient proof either, but in my opinion one could shed light on this relation by investigating their TTPs and\r\nother details of the intrusions.\r\nOn the 14th of March 2022 the Pandora sample below was obtained by vx-underground:\r\nPandora Ransomware (packed)\r\nOriginal file names: \"1vfrk1jrt.dll\", \"M3DO2.exe\"\r\nFile size: 223232 bytes\r\nArchitecture: x64\r\nhttps://dissectingmalwa.re/blog/pandora/\r\nPage 1 of 10\n\nMD5: 0c4a84b66832a08dccc42b478d9d5e1b\r\nSHA-1: 160320b920a5ef22ac17b48146152ffbef60461f\r\nSHA-256: 5b56c5d86347e164c6e571c86dbf5b1535eae6b979fede6ed66b01e79ea33b7b\r\nDownload: vx-underground | Malware Bazaar | VirusTotal\r\nI already tweeted about this sample, but since I got a few questions regarding the unpacking process and\r\nsimilarities to other ransomware strains (specifically Rook and NightSky) I thought I should write it down in a\r\nblog post.\r\nUnpacking\r\nAfter the initial assessment of the sample with Detect it Easy a signature for UPX Version 3 was found. Packer\r\ndetections in Detect it Easy should always be taken with a grain of salt, but it gives us a first hint as to what to\r\nlook for in the next steps.\r\nLooking at the Entropy graph we can see that we have one section ( cccc ) with a very high value, which\r\nindicates it contains packed code and a .rsrc section with a significantly lower value.\r\nhttps://dissectingmalwa.re/blog/pandora/\r\nPage 2 of 10\n\nSwitching over to pestudio Pro since its section layout is a lot cleaner than the one in Detect it easy we can see\r\nthat there is another section called pppp which is virtualized and therefore has a raw-size of 0 bytes. This section\r\nlayout closely resembles the one used by UPX. UPX0 ( pppp in this case) is the empty section where the\r\ncompressed contents of UPX1 ( cccc ) will be decompressed to by the unpacking program stub. At this point I am\r\nfairly confident to say that is packer is based on UPX, but looking at the section names they likely messed around\r\nwith their UPX version.\r\nA very simple way to test if we are dealing with a modified version of UPX is to just try to decompress the sample\r\nwith the vanilla UPX utility. As you can see below it does not decompress! UPX is even telling us that the file was\r\nlikely messed with. I was able to identify the following modifications to the UPX packer:\r\naltered section names (as we noticed before)\r\nhttps://dissectingmalwa.re/blog/pandora/\r\nPage 3 of 10\n\nold version of UPX / altered version number in the leading header\r\nmissing/overwritten 12-byte trailing header\r\nAlright, as the simple approach does not work and retdec also falls through for now, we’ll have to unpack it\r\nmanually. First of all I’ll switch to the Memory Map view and Follow in Dump on the pppp section (UPX0) to\r\nmonitor it.\r\nUp next I’m placing a Hardware Breakpoint on Access on the pppp section, so we can see when the data is\r\ndecompressed into it. Hit this breakpoint once or twice to check that it is working and we’ll continue onto the next\r\nstep.\r\nScroll down until you see the end of the stub with the two jumps followed by junk instructions for padding. The\r\nlast jump instruction is the so-called tail jump, which will transfer to the Original Entrypoint (OEP). I’ll place a\r\nbreakpoint on the tail jump to make sure Pandora doesn’t run away and potentially encrypt the VM :D Once we\r\nhit this breakpoint we can check in the dump of pppp that the section should be filled now, so let’s jump in!\r\nhttps://dissectingmalwa.re/blog/pandora/\r\nPage 4 of 10\n\nAfter following the tail jump we can scroll down a bit again to find the OEP ( push rbp ) and place a breakpoint\r\nthere. Get ready to dump it like it’s hot 🔥\r\nhttps://dissectingmalwa.re/blog/pandora/\r\nPage 5 of 10\n\nFire up Scylla and make sure that the correct process is selected (1). After that we’ll run the IAT Autosearch (2)\r\nand Get Imports (3) to show them in the textbox above (notice that they significantly differ from the functions\r\nimported by the UPX unpacking stub). Finally dump the process to disk (4) and fix the dump (5) to complete the\r\nunpacking process. Congratulations to the ones playing along at home, you are now able to manually unpack UPX\r\n(and it works for x86 binaries as well).\r\nIf you want to skip this step of the analysis you can also download my unpacked sample below:\r\nPandora Ransomware (unpacked)\r\nFile size: 509440 bytes\r\nArchitecture: x64\r\nMD5: 511501033ca23754113686ac70f629db\r\nSHA-1: 26a02a149aca6a8a43e2dca5c75a6360cfe54c50\r\nSHA-256: 2c940a35025dd3847f7c954a282f65e9c2312d2ada28686f9d1dc73d1c500224\r\nDownload: Malshare | VirusTotal\r\nSimilarities with Rook Ransomware\r\nAccording to the automated analysis by Intezer the Pandora sample from above is related to Rook Ransomware.\r\nSince Rook is based on the leaked source code of Babuk Ransomware so is Pandora probably.\r\nAs I already mentioned I’m not planning to do a deep-dive analysis of the features of Pandora, so we’ll just try to\r\ndo a high-level comparison between Pandora and Rook. If you are looking for a very in-depth analysis of Rook\r\nRansomware, check out Chuong Dong’s post about it.\r\nRook Ransomware\r\nOriginal file names: \"unknown\", \"7NM2J.txt\"\r\nFile size: 174080 bytes\r\nArchitecture: x64\r\nMD5: bec9b3480934ce3d30c25e1272f60d02\r\nSHA-1: 104d9e31e34ba8517f701552594f1fc167550964\r\nSHA-256: f87be226e26e873275bde549539f70210ffe5e3a129448ae807a319cbdcf7789\r\nDownload: vx-underground | Malware Bazaar | VirusTotal\r\nhttps://dissectingmalwa.re/blog/pandora/\r\nPage 6 of 10\n\nSince this sample of Rook Ransomware is also packed with a modified version of UPX (which differs from the\r\none used for Pandora though) I manually unpacked this sample as well using the process described above. You can\r\ndownload the unpacked sample here:\r\nRook Ransomware (unpacked)\r\nFile size: 415744 bytes\r\nArchitecture: x64\r\nMD5: afdf739eb186e2ec8088b008797d1f6d\r\nSHA-1: f611c2976ebb080214eddd905d30628230f2280d\r\nSHA-256: ebfdee6e5fe2aa5699280248a5e7b714ca18e5bfd284cac0ba4fb88ccbcec5b6\r\nDownload: Malshare | VirusTotal\r\nComparing the imported Windows functions of Pandora and Rook we can see the following changes in Pandora (+\r\n= added, - = removed):\r\nadvapi32.dll:\r\n - EnumDependentServicesA\r\n - CloseServiceHandle\r\n - OpenSCManagerA\r\n - ControlService\r\n - QueryServiceStatusEx\r\n - OpenServiceA\r\nkernel32.dll:\r\n + GetQueuedCompletionStatus\r\n + PostQueuedCompletionStatus\r\n + SetPriorityClass\r\n + CreateIoCompletionPort\r\n + SetThreadAffinityMask\r\n + ResumeThread\r\n + VirtualFree\r\n + CreateFileMappingW\r\n + MapViewOfFile\r\n + VirtualAlloc\r\n + UnmapViewOfFile\r\n + LoadLibraryW\r\n + VirtualProtect\r\n + VirtualProtectEx\r\n + WriteProcessMemory\r\n - GetTickCount\r\n - GetModuleFileNameW\r\n - ExitThread\r\n - SetFileInformationByHandle\r\n - ReleaseSemaphore\r\nhttps://dissectingmalwa.re/blog/pandora/\r\nPage 7 of 10\n\n- CreateSemaphoreA\r\n - RaiseException\r\n - Process32FirstW\r\n - Process32NextW\r\n - Sleep\r\n - CreateToolhelp32Snapshot\r\nmpr.dll:\r\n - WNetGetConnectionW\r\nshell32.dll:\r\n - CommandLineToArgvW\r\nshlwapi.dll:\r\n - PathFileExistsW\r\nuser32.dll:\r\n - wsprintfA\r\nFrom this comparison we can deduct that there have been changes in file handling and thread/process control.\r\nComparing the strings in both samples I found that Pandora removed the debug messages which are present in the\r\nBabuk source and the Rook sample. Additionally the Ransomnote of Pandora Ransomware has been obfuscated\r\nwhereas the Rook contained it in plain text.\r\nOf course I can’t wrap this post up before trying out a new tool, which kind of has become a tradition here. Since\r\nthe code similarities detected by Intezer are a black box for us we can try and replicate this analysis with binlex :\r\nBinlex allows us to extract basic blocks and functions from to samples we feed it as so-called traits. In the case of\r\nPandora and Rook these traits contain the re-used code and, with some careful filtering, we can use some of them\r\nto build a Pandora-Rook Yara rule. Unfortunately I currently don’t have the time to sift through all the extracted\r\ntraits manually (I don’t have a Goodware/Malware Traits Corpus yet to discard traits based on that), but I will get\r\nback to this in a few weeks. The long-boi bash command below shows my testing approach in this case, which\r\nextracted over 1700 unique (but unfiltered) shared traits from the Pandora and Rook samples.\r\nfind sim/ -type f | while read i; do binlex -m pe:x86_64 -i $i | jq -r '.[] | select(.type == \"block\" and .size\r\nOne example were I successfully used binlex for a Yara rule a couple of weeks earlier is for my BlackMatter\r\nRansomware ESXi rule, which you can find here.\r\nIf you would like to give binlex a try I recommend to watch the excellent demo below, which is a recording of a\r\nlive cooperation between c3rb3ru5d3d53c and OALabs. binlex is very easy to install and well documented, so you\r\nshould definitely give it a try.\r\nhttps://dissectingmalwa.re/blog/pandora/\r\nPage 8 of 10\n\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nAlright, that should conclude this first look into Pandora Ransomware. I’m sure there will be more in-depth\r\nreports about the ransomware itself and the modus operandi of the attackers in the coing days and weeks. As I\r\nalready mentioned I do not consider the relation “Pandora == Rook” proven based on the findings of this post, but\r\na connection is certainly plausible. Also Pandora will most likely not be the last Ransomware variant based on the\r\nBabuk source, since with the leak the metaphorical box cannot be closed again.\r\nI included a small Yara rule for the modified UPX packer below, happy hunting!\r\nThanks for reading this post and if you have any questions feel free to send me a message :)\r\nModified UPX Hunting rule\r\nimport \"pe\"\r\nrule upx_packer_modified_pandora : Packer {\r\nmeta:\r\n author = \"f0wL \u003chello@dissectingmalwa.re\u003e\"\r\n description = \"Detects modified UPX packer used by Pandora Ransomware\"\r\n reference = \"https://dissectingmalwa.re/blog/pandora/\"\r\n date = \"2022-03-16\"\r\n tlp = \"WHITE\"\r\n hash = \"5b56c5d86347e164c6e571c86dbf5b1535eae6b979fede6ed66b01e79ea33b7b\"\r\nstrings:\r\n $header = {33 2E 30 30 00 55 50 58 21} // 3.00.UPX!\r\ncondition:\r\n uint16(0) == 0x5a4d\r\nhttps://dissectingmalwa.re/blog/pandora/\r\nPage 9 of 10\n\nand pe.imphash() == \"51a8b4c9f41b0c0ca57db63e21505b0d\"\r\n and $header\r\n and for any i in (0..pe.number_of_sections):(\r\n pe.sections[i].name == \"pppp\" and\r\n pe.sections[i+1].name == \"cccc\")\r\n and filesize \u003e 112KB // Size on Disk/2\r\n and filesize \u003c 1MB // Size of Image*2\r\n}\r\nSource: https://dissectingmalwa.re/blog/pandora/\r\nhttps://dissectingmalwa.re/blog/pandora/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://dissectingmalwa.re/blog/pandora/"
	],
	"report_names": [
		"pandora"
	],
	"threat_actors": [],
	"ts_created_at": 1775434787,
	"ts_updated_at": 1775791238,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/505edf175aa79822071371123501c8d417126565.pdf",
		"text": "https://archive.orkl.eu/505edf175aa79822071371123501c8d417126565.txt",
		"img": "https://archive.orkl.eu/505edf175aa79822071371123501c8d417126565.jpg"
	}
}