{
	"id": "8ca2e326-afcc-475b-832f-c1f784d582d3",
	"created_at": "2026-04-06T00:18:49.843556Z",
	"updated_at": "2026-04-10T03:22:11.42541Z",
	"deleted_at": null,
	"sha1_hash": "dbc144a8848f865d7c6b188fec91ee19779d4de2",
	"title": "Looking Inside Pandora’s Box | FortiGuard Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 504698,
	"plain_text": "Looking Inside Pandora’s Box | FortiGuard Labs\r\nPublished: 2022-04-07 · Archived: 2026-04-05 20:15:22 UTC\r\nIn Greek mythology, opening of the infamous Pandora’s box (jar) introduced terrible things to the world. That can\r\nalso be said about today’s ransomware. The newly emerged Pandora ransomware that crowned the name is no\r\nexception. It steals data from the victim’s network, encrypts the victim’s files, and unleashes the stolen data if the\r\nvictim opts not to pay. The Greek myth says hope was left in the box. Does that hold true for Pandora\r\nransomware, an emerging malware that shows all techniques used by modern ransomware? In this blog we are\r\ntaking a hammer and crowbar to look inside today’s Pandora’s box to find out what mysteries it holds. We will\r\ndiscuss:\r\nHow this ransomware tries to evade detection\r\nThe numerous obfuscation and anti-analysis techniques that are used to hinder analysts\r\nHow multi-threading is used to speed up processing\r\nHow the filesystem is processed\r\nHow and which files are encrypted.\r\nAffected Platforms: Windows\r\nImpacted Users: Windows users\r\nImpact: Most files on the compromised machines are encrypted\r\nSeverity Level: Medium\r\nPandora Group\r\nThe Pandora ransomware group emerged into the already crowded ransomware field as early as in mid-February\r\n2022 and targets corporate networks for financial gain. The group got recent publicity after they announced that\r\nthey acquired data from an international supplier in the automotive industry. The incident came as surprise as the\r\nattack came two weeks after another automotive supplier was reportedly hit with unknown ransomware, which\r\nresulted in one of the world’s biggest car manufacturers suspending factory operations. The threat group uses the\r\ndouble extortion method to increase pressure on the victim. This means that they not only encrypt the victim’s\r\nfiles, but also exfiltrate them and threaten to release the data if the victim does not pay.\r\nThe Pandora Group has a leak site in the Dark Web (TOR network), where they publicly announce their victims\r\nand threaten them with the data leak. There are currently three victims listed on the leak site (see Figure 1), a U.S.-\r\nbased real estate agency, a Japanese technology company, and a U.S. law firm.\r\nhttps://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nPage 1 of 13\n\nFigure 1 - Pandora's leak site\r\nMalware Analysis\r\nWe analyzed the sample with the SHA-256 hash\r\n5b56c5d86347e164c6e571c86dbf5b1535eae6b979fede6ed66b01e79ea33b7b, which is a 64-bit Windows PE file.\r\nIt is the ransomware itself, so by the time this file is executed during an attack, the attackers probably already had\r\nextensive access to the victim’s network, and they had already exfiltrated the data they will use for the extortion.\r\nThis sample does not have the capability to communicate with the threat actors. Its sole purpose is to find and\r\nencrypt files. However, it does this in an interesting and complex manner.\r\nIn the following sections these interesting aspects of the malware will be discussed.\r\nExecution Flow\r\nThe sample goes through the following steps:\r\nNote that “T” followed by numbers within brackets refers to MITRE ATT\u0026CK technique ID, which are\r\nsummarized at the end of the post.\r\n 1) Unpacking: The sample is packed with a modified UPX packer (T1027.002), so the first step is to unpack the\r\nreal content to memory and jump to it. This will be discussed later.\r\n 2) Mutex: It creates a mutex called ThisIsMutexa.\r\nhttps://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nPage 2 of 13\n\n3) Disable Security Features: It can delete Windows shadow copies (T1490), bypass AMSI (T1562.001), and\r\ndisable Event Logging (T1562.002). More on these features later.\r\n 4) Collects system information: GetSystemInfo()is used to collect information about the local system.\r\n 5) Loads Hardcoded Public Key: A public key is hardcoded in the malware sample. This is used to set up the\r\ncryptography for encryption.\r\n 6) Store Private and Public Keys in Registry: A private key is generated, and both the hardcoded public key\r\nand the newly generated private key are stored in the registry       (T1112).\r\n 7) Search Drives: It searches for unmounted drives on the system and mounts them to encrypt them as well\r\n(T1005).\r\n 8) Setup Multi-Threading: The sample uses worker threads to distribute the encryption process. More on this\r\nlater.\r\n 9) Enumerate Filesystem: The worker threads start to enumerate the filesystems of the identified drives (T1083).\r\n10) Drop Ransom Note: The ransom note is dropped in every folder in Restore_My_Files.txt.\r\n11) Check File Name Blacklist: For every file and folder a blacklist of file/folder names is checked. If the\r\nfile/folder is on the blacklist it will not be encrypted. More on this later.\r\n12) Check File Extension Blacklist: Each file is checked against a file extension blacklist. If the extension is on\r\nthe list, it will not be encrypted.\r\n13) Unlock File: If the file is locked by a running process, the sample will try to unlock it using the Windows\r\nRestart Manager(T1489).\r\n14) Encrypt File: The worker threads will encrypt(T1486) the file and write it back to the original file.\r\n15) Rename File: Once the encryption is finished the file is renamed to[original_filename].pandora.\r\nAnti-Reverse Engineering Techniques\r\nOne of the most significant aspect of the Pandora ransomware is the extensive use of anti-reverse-engineering\r\ntechniques. This is not new for malware, but Pandora lies on the extreme side of how much is invested in slowing\r\nanalysis down. In this section we will go through the different techniques that were identified.\r\nPacked\r\nThe sample is packed with a modified UPX packer, which can be easily detected with Detect It Easy (see Figure\r\n2).\r\nhttps://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nPage 3 of 13\n\nFigure 2: Detect It Easy can identify UPX\r\nHowever, the standard UPX unpacker does not work, which indicates that the packer was modified to make sure\r\nthat off-the-shelf tools cannot be used to unpack it.\r\nUnpacking is still relatively easy, by scrolling down from the entry point to the end of the code in a debugger. The\r\ncode will end with a jump (Figure 3). This is typical with packers, that after unpacking the original code\r\nsomewhere in memory they will jump there, instead of returning from the main function.\r\nFigure 3: Tail jump at the end of the unpacking\r\nBy putting a breakpoint to the tail jump we can dump the PE file from memory including the unpacked code. With\r\nthe dumped file we can analyze the ransomware statically as well.\r\nControl-Flow Flattening\r\nControl-Flow Flattening is an obfuscation technique that can hide the structure of the program by modifying the\r\ncontrol-flow. In the simplest case, it replaces the normal control flow of each function with a state machine, thus it\r\nmakes harder for an analyst to quickly understand how each function works. Pandora uses a more complex\r\ncontrol-flow flattening combined with opaque predicates, to complicate the control flow even further.\r\nFigure 4: Graph view of main()\r\nhttps://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nPage 4 of 13\n\nFigure 4 shows the graph view of the main function in the unpacked code. We can see that it does not resemble a\r\nnormal function’s control flow. It looks like a huge switch-case statement, which is the result of the control-flow\r\nflattening that implements a state machine. However, in Pandora’s case most of the basic blocks are not connected\r\nat all. This is the result of the opaque predicates. Most of the jumps between basic blocks are calculated at\r\nruntime, as shown in Figure 5.\r\nFigure 5: Calculating the address for the jmp in runtime\r\nThe first cmp instruction checks the current state of the state machine and depending on that calculates the value\r\nof the rdx register for the jmp at the end of the basic block. Because of this static analysis tools, such as IDA Pro\r\ncannot understand where the control flow will continue, and thus cannot connect the basic blocks in Figure 4.\r\nEmulation can be used to understand the control flow to a limited degree but debugging had to be applied\r\nextensively to be sure how the execution flows.\r\nString Encoding\r\nSome strings can be found in the unpacked binary, but most of them are from the statically linked libraries.\r\nHowever, the strings that would help us understand what is happening in the code are encoded. Figure 6 shows\r\nhow one of the string decryption functions is called.\r\nFigure 6: Calling one of the string decryption functions\r\nBoth the address of the decryption function, which is called through rax, and the address of the encoded string, are\r\ncalculated at runtime. This way, when looking at this code statically, there is no way to know what is happening\r\nhere. The comment on the right side is the result of an IDAPython script that uses the flare-emu project to emulate\r\nthe code and calculate the addresses of the function call, as well as emulate the decryption function. This solution\r\nhttps://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nPage 5 of 13\n\nwas very effective in recovering the encoded strings in the binary. The decryption function implements an XOR\r\ndecoding. The decryption keys are stored together with each encoded string. As a bonus, the malware uses\r\nmultiple decryption functions. We identified 14 separate functions that are used for string decoding.\r\nFunction Call Obfuscation\r\nIt was already mentioned in the previous section that most function calls are not calling a direct address, but a\r\nregister. Its value is calculated at runtime.\r\nIf we use Figure 6 as an example the address in rax is calculated like this:\r\nrax = *(*address_table_base + 638300900) - 1426601284)\r\nAs mentioned, this was solved using emulation. By emulating the execution of a function, we could calculate the\r\nregister values at CALL instructions. This allowed us to resolve function calls at scale.\r\nWindows API Call Obfuscation\r\nContrary to other malware, the Windows API function names are not encoded, but another obfuscation technique\r\nis used to hide their usage. As shown in Figure 7, the Windows API functions are organized in a jump table. At\r\neach address there is a jmp instruction that redirects to the library function. \r\nFigure 7: Windows API function jump table\r\nResolving the API functions was implemented in the same flare-emu IDAPython script that resolves the function\r\ncalls. Whenever a CALL [register] points to a jmp instruction (see Figure 8), instead of the beginning of a\r\nfunction, then we assumed that it points to the API function jump table. So we took the name of the operand of the\r\njump and used that to generate the comments for the function call (see Figure 9).\r\nFigure 8: Recovering API function name in the emulation script\r\nhttps://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nPage 6 of 13\n\nFigure 9: The script recovered that this is a function call to OpenMutexA\r\nMulti-Threading\r\nPandora uses multiple threads to speed up the encryption process. For that it uses Windows’s IO Completion\r\nPorts concept. This allows threads to wait for a file/network handle to appear in the IO Completion Port queue and\r\nprocess them. Pandora uses unassociated IO Completion Ports and sends any data through it using the\r\nOVERLAPPED structure. In this case drives and file paths will be passed to threads to process (enumerate or\r\nencrypt) them. The IO Completion Port is set up using the CreateIOCompletionPort() API function as shown in\r\nFigure 10. By passing INVALID_HANDLE_VALUE as the first parameter (rcx = 0xFFFFFFFFFFFFFFFF) and\r\nNULL as the second (rdx = 0x0) an unassociated IO Completion Port is created. The fourth parameter is the\r\nNumberOfConcurrentThreads, which is set to 4 (r9 = 0x4), defines that maximum 4 threads are allowed to work\r\nwith this IO Completion Port.\r\nFigure 10: Initializing an IO Completion Port\r\nAfter this, the main function will start the new threads. The communication between the threads is done using the\r\nGetQueuedCompletionStatus() and PostQueuedCompletionStatus API functions. Figure 11 shows how a\r\ndiscovered file (pydisas.py) is put in the queue with PostQueuedCompletionStatus(). Another thread will pick up\r\nthis task with GetQueuedCompletionStatus(), and since it receives a full path to a file it will encrypt and rename\r\nit.\r\nhttps://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nPage 7 of 13\n\nFigure 11: Posting the file path to the IO Completion Port's queue\r\nRestart Manager\r\nThe Restart Manager is a Windows feature to reduce the number of restarts needed during installation and updates.\r\nThe reason for a restart is usually because a file that needs to be updated is locked by a running process. The\r\nRestart Manager can save the state and stop the locking process to unlock the target file. Once the update is\r\nfinished, it can restore the locking process again. Pandora uses the Restart Manager to make sure that even files\r\nthat are currently locked will be encrypted. For each file the following process is executed:\r\n1)      Create Restart Manager session with RmStartSession()\r\n2)      Register the target file as a resource with RmRegisterResource()\r\n3)      Check if the target file is locked by any process with RmGetList()\r\n4)      If so, terminate locking processes\r\n5)      End Restart Manager session with RmEndSession()\r\nEncryption\r\nBefore a file is encrypted, Pandora does the following checks to make sure that it does not render the\r\nmachine inoperable. Each target file is checked against the following blacklist of file and folder names. If\r\nthe target file is on the list, Pandora will not encrypt it.\r\nAppData\r\nBoot\r\nWindows\r\nWindows.old\r\nTor Browser\r\nInternet Explorer\r\nGoogle\r\nOpera\r\nOpera Software\r\nMozilla\r\nMozilla Firefox\r\n$Recycle.Bin\r\nProgramData\r\nAll Users\r\nautorun.inf\r\nboot.ini\r\nbootfont.bin\r\nbootsect.bak\r\nbootmgr\r\nbootmgr.efi\r\nbootmgfw.efi\r\ndesktop.ini\r\niconcache.db\r\nntldr\r\nntuser.dat\r\nntuser.dat.log\r\nntuser.ini\r\nthumbs.db\r\nProgram Files\r\nProgram Files (x86)\r\n#recycle\r\n..\r\n.\r\nhttps://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nPage 8 of 13\n\nEach target file is compared to the following list of file extensions. If the file’s extension is on the list, the\r\nfile will not be encrypted:\r\n.hta .exe .dll .cpl .ini .cab .cur .drv .hlp .icl .icns .ico .idx .sys .spl .ocx\r\nThe ransom note, shown in Figure 12, promises an RSA-2048 encryption. The fact that malware is shipped with a\r\nhardcoded RSA-2048 public key (Figure 13) confirms this claim. \r\nFigure 12: Ransom note\r\nFigure 13: Hardcoded RSA public key\r\nA private key is also generated and both of these keys are stored in the registry under HKCU\\SOFTWARE\\\r\n[Private,Public] (see Figure 14).\r\nhttps://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nPage 9 of 13\n\nFigure 14: Cryptographic keys are stored in the Registry\r\nThe unpacked binary contains the Mbed TLS cryptographic library statically linked.\r\nOnce a file is encrypted in memory, it is written to disk. After that the file is renamed to have the .pandora\r\nextension.\r\nDisabling Security Features\r\nThe Pandora ransomware has the capabilities to disable some of the security measures on the target machine.\r\nDeleting Shadow Copies\r\nLike a lot of other ransomware, Pandora deletes the Windows Shadow Copies, which could help the operator\r\nrestore the machine to a state before the infection. Figure 15 shows the call to ShellExecuteW() with the\r\nparameters from runtime(T1059). We can see that it uses the vssadmin.exe.\r\nFigure 15: Deleting shadow copies with ShellExecuteW\r\nAMSI Bypass\r\nThe Antimalware Scan Interface (AMSI) allows security products to integrate better with Windows to be able to\r\nscan all kinds of different objects, such as PowerShell scripts, JavaScript, VBScript, etc. By bypassing AMSI, the\r\nmalware can take away significant capabilities from the security products running on the machine. Pandora\r\nbypasses AMSI by patching the AmsiScanBuffer() function in the amsi.dll in memory.\r\nDisable Event Log\r\nSimilar to the AMSI bypass, Pandora disables the Event Tracing for Windows (ETW) feature, by patching\r\nthe EtwEventWrite() function in the Windows kernel (ntdll.dll). Figure 16 shows that the first byte of the function\r\nhttps://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nPage 10 of 13\n\nis replaced with 0xC3, which is the ret instruction. This renders the EtwEventWrite() function useless, because\r\nafter every call it return immediately without logging the event.\r\nFigure 16: Patching the EtwEventWrite function to return immediately\r\nConclusion\r\nThe Pandora ransomware contains all of the most important features that state-of-the-art ransomware samples\r\nusually contain. The level of obfuscation to slow down analysis is more advanced than average malware. The\r\nthreat actor also paid attention to unlock files to guarantee the maximum encryption coverage, while still allowing\r\nthe machine to run. We can already see anti-security product features. We can expect the threat actor to develop\r\nthese capabilities further. There is currently no proof that Pandora operates as Ransomware-as-a-Service (RaaS),\r\nbut the time investment in the complexity of the malware might indicate that they are moving in that direction in\r\nthe long term. The current attacks and leaks might be a way to make their name in the ransomware field, which\r\nthey could capitalize on if they adopt the RaaS model later. It is worth tracking the threat actor to monitor how\r\ntheir malware changes.\r\nFortinet Protection\r\nThe analyzed Pandora ransomware sample is detected by the following (AV) signature:\r\nW64/Filecoder.EGYTYFD!tr.ransom\r\nFortiEDR also detects and mitigates execution of Pandora ransomware through the combination of behavioral\r\nanalysis, and integration with machine learning and threat intelligence feeds. Execution of the Pandora sample\r\nanalyzed as part of this blog triggers seven rules resulting in nine security events. Triggered rules were a result of\r\npre-execution analysis and post-execution behaviors. These security events can be observed below in Figure 16.\r\nhttps://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nPage 11 of 13\n\nFigure 16. FortiEDR security events generated following execution of Pandora ransomware sample. Note that\r\nduring this execution FortiEDR was set to only log events rather than mitigate to properly demonstrate detections\r\npost-execution.\r\nPre-execution detections included; identifying the malicious file (hash based), detection of a suspicious packer and\r\npresence of writeable code. Post-execution detections included; detection of each file encryption attempt,\r\ndetection of encrypted file rename attempt, dropping of the ransom-note and attempts to access SMB shares.\r\nIn Protect mode FortiEDR will detect and mitigate detected behavior. In the case of Pandora this will prevent\r\nexecution of the ransomware, mitigating malicious activity before it occurs, and will prevent subsequent file\r\nencryption attempts if the adversary is able to execute the sample. The post exploitation detections are not\r\ndependent on signature meaning they will effectively mitigate this activity for newer Pandora variants even with\r\nno prior knowledge of the samples.\r\nIOCs:\r\nMutex: ThisIsMutexa\r\nRansom note: Restore_My_Files.txt\r\nSHA256 hash of hardcoded public key:\r\n7b2c21eea03a370737d2fe7c108a3ed822be848cce07da2ddc66a30bc558af6b\r\nSHA256 hash of sample: 5b56c5d86347e164c6e571c86dbf5b1535eae6b979fede6ed66b01e79ea33b7b\r\nATT\u0026CK TTPs\r\nTTP Name TTP ID Description\r\nhttps://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nPage 12 of 13\n\nObfuscated Files or Information: Software\r\nPacking\r\nT1027.002 Modified UPX packer\r\nImpair Defenses: Disable Windows Event\r\nLogging\r\nT1562.002 Disable Event Logging\r\nImpair Defenses: Disable or Modify Tools T1562.001 Bypass AMSI\r\nData from Local System T1005 Searches unmounted drives and partitions\r\nModify Registry T1112 Cryptographic keys are stored in the registry\r\nData Encrypted for Impact T1486 As a ransomware it encrypts files\r\nCommand and Scripting Interpreter T1059 Uses cmd.exe to remove the shadow copies\r\nSystem Information Discovery T1082\r\nCollects system information with\r\nGetSystemInfo()\r\nFile and Directory Discovery T1083 Discovers drives and enumerates filesystems\r\nInhibit System Recovery T1490 Deletes shadow copies\r\nService Stop T1489 Terminates processes if they lock a file\r\nLearn more about Fortinet’s FortiGuard Labs threat research and intelligence organization and the FortiGuard\r\nSecurity Subscriptions and Services portfolio.\r\nSource: https://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nhttps://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://www.fortinet.com/blog/threat-research/looking-inside-pandoras-box"
	],
	"report_names": [
		"looking-inside-pandoras-box"
	],
	"threat_actors": [],
	"ts_created_at": 1775434729,
	"ts_updated_at": 1775791331,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dbc144a8848f865d7c6b188fec91ee19779d4de2.pdf",
		"text": "https://archive.orkl.eu/dbc144a8848f865d7c6b188fec91ee19779d4de2.txt",
		"img": "https://archive.orkl.eu/dbc144a8848f865d7c6b188fec91ee19779d4de2.jpg"
	}
}