{
	"id": "d617437b-89f9-4c96-a25c-164609789ee3",
	"created_at": "2026-04-06T00:13:58.692408Z",
	"updated_at": "2026-04-10T13:11:24.40615Z",
	"deleted_at": null,
	"sha1_hash": "7e9e8b0dce9d3a01dd92f1e146ce218d1d1c87d9",
	"title": "Technical Analysis of Crytox Ransomware | Zscaler Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1407974,
	"plain_text": "Technical Analysis of Crytox Ransomware | Zscaler Blog\r\nBy Romain Dumont\r\nPublished: 2022-09-21 · Archived: 2026-04-05 20:17:03 UTC\r\nKey points\r\nCrytox is a ransomware family consisting of several stages of encrypted code that was first observed in\r\n2020\r\nThe ransomware encrypts local disks and network drives and leaves a ransom note with a five day\r\nultimatum, but does not exfiltrate data from the victim\r\nCrytox drops the uTox messenger application on the infected system that enables the victim to\r\ncommunicate and negotiate with the threat actors\r\nCrytox uses AES-CBC with a per file 256-bit key that is protected with a locally generated RSA public key\r\nFile decryption may be possible via a known plaintext bruteforce attack\r\nSummary\r\nThe threat actor using Crytox ransomware has been active since at least 2020, but has received significantly less\r\nattention than many other ransomware families. In September 2021, the Netherlands-based company RTL publicly\r\nacknowledged that they were compromised by the threat actor. The company paid Crytox 8,500 euros. Compared\r\nwith current ransom demands, this amount is relatively low. Unlike most ransomware groups, the Crytox threat\r\nactor does not perform double extortion attacks where data is both encrypted and held for ransom.\r\nThe modus operandi of the group is to encrypt files on connected drives along with network drives, drop the uTox\r\nmessenger application and then display a ransom note to the victim as shown in Figure 1.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware\r\nPage 1 of 11\n\nFigure 1. Crytox ransom note\r\nThe ransom demand period is set to five days to pressure the victim into paying as soon as possible\r\nThe sample analyzed by ThreatLabz has the following SHA256 hash\r\n32eef267a1192a9a739ccaaae0266bc66707bb64768a764541ecb039a50cba67. In most cases, Crytox samples are\r\npacked with UPX. Once decompressed, a sample usually weighs in around 1.23MB because the whole uTox client\r\nis embedded inside the malware.\r\nCryptox uses different techniques to thwart static analysis including the following:\r\nAPI hashing\r\nEncrypted configurations\r\nEncrypted shellcode\r\nRemote thread injection\r\nSome parts of the malware look directly written in assembly. The most noteworthy thing is the use of a specific\r\nimplementation of AES-CBC shown in Figure 2.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware\r\nPage 2 of 11\n\nFigure 2. Crytox implementation of AES\r\nThe authors borrowed the AES code and modified some parts to meet their needs. They even added an alternative\r\nalgorithm using Intel x86 AES instructions. Oddly enough, the authors chose to only implement the\r\nRijndael_Encrypt routine to both decrypt their config and encrypt files. This means that when they embedded\r\ntheir configurations, they used the AES decryption routine to encrypt them. The key used for decrypting the\r\nCrytox configurations are either the first or second block of 32 bytes of the AES lookup table Te1 using a NULL\r\ninitialization vector (IV).\r\nFirst-Stage\r\nThe malware encrypts the first-stage configuration using the aforementioned implementation of AES-CBC. Here,\r\nthe AES key is the first 32 bytes of the Te1 lookup table\r\na5c6636384f87c7c99ee77778df67b7b0dfff2f2bdd66b6bb1de6f6f5491c5c5 as shown in Figure 3.\r\nFigure 3. Crytox first-stage configuration after decryption\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware\r\nPage 3 of 11\n\nThis configuration contains the following information:\r\nA hardcoded 2048-bit RSA public key\r\nThe path to drop the uTox client application\r\nThe Run registry value for the ransom note to be displayed at startup\r\nThe process name to inject\r\nThe class registry key to store the malware's configuration\r\nAfter this configuration has been decrypted, the malware locally generates a 2048-bit RSA key pair using the\r\nCryptGenKey function. The generated RSA private key is then encrypted five times using the hardcoded public\r\nkey.\r\nUnder the sub-key HKCR\\.waiting\\shell\\open\\command\\, the ransomware stores the following value-data pair\r\nshown in Table 1.\r\nValue Data\r\n\"en\" Generated RSA public key\r\n\"n\" Encrypted generated RSA private key\r\n\"\" C:\\Windows\\System32\\mshta.exe \"C:\\ReadMe.hta\"\r\nTable 1. Crytox registry configuration\r\nIn order to make sure the ransom note is displayed on startup, the registry value open along with the data\r\n\"C:\\ReadMe.hta\" are created under\r\nHKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\r\nOnce the Crytox configuration is stored, the code proceeds to locate a process to inject the second-stage. A remote\r\nthread is created to execute the first piece of shellcode.\r\nSecond-Stage\r\nThis stage decrypts a second configuration using AES-CBC with the following key\r\n5060303003020101a9ce67677d562b2b19e7fefe62b5d7d7e64dabab9aec7676 (which is the second block of 32\r\nbytes from the lookup table Te1). According to this decrypted configuration, the shellcode executes a batch file to\r\ndelete shadow copies and remove events from the logs. Essentially the following commands are run::\r\nfor /F \"tokens=*\" %%1 in ('wevtutil.exe el') DO wevtutil.exe cl \"%%1\"\r\nvssadmin.exe Delete Shadows /All /Quiet\r\ndiskshadow.exe /s ../pghdn.txt\r\nThe file pghdn.txt contains the line \"delete shadows all\".\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware\r\nPage 4 of 11\n\nGiven the following hashing algorithm, the second-stage searches for the process ID (pid) of the process for which\r\nthe hash of its name corresponds to 0xDCF164CD (explorer.exe) or 0x561F1820 (svchost.exe).\r\nname = process_name + \"\\x00\"\r\nhash = 0\r\nfor c in name.upper():\r\n    hash = ROTR32(hash, 0xD) + ord(c)\r\nInside a new thread, the shellcode creates a mutex by concatenating a hardcoded 4-letter word (e.g., \"CSWS\")\r\nwith some random characters based on the pid of the targeted process as shown in Figure 4.\r\nFigure 4. Crytox mutex creation\r\nThe thread then decrypts the content from the resource section of the original malware using the same algorithm\r\nand key as for the second configuration. This resource contains another shellcode, which is the final stage. This\r\nshellcode is injected inside the targeted remote process.\r\nThird and Final Stage\r\nUsing the same encryption algorithm, with the first 32-bytes of the Te1 lookup table as the AES key, this final\r\nstage decrypts the main configuration containing the following information:\r\nA seed for generating the file encryption key\r\nAn .hta formatted ransom note\r\nA simple regular expression for listing all files on the system\r\nThe encrypted file extension (e.g., YOUR ID.waiting)\r\nPrivileges to remove (SeBackupPrivilege, SeRestorePrivilege)\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware\r\nPage 5 of 11\n\nFirst, the code tries to retrieve the configuration that the first stage stored in the registry hive. If this configuration\r\ndoesn't exist, Crytox will create it. The code proceeds to set a countdown variable in the ransom note followed by\r\nreplacing the string YOUR ID in the ransom note template. The latter value is replaced with a unique victim ID\r\nthat is generated by the following pseudo-algorithm based on the encrypted locally generated RSA private key:\r\nFigure 5. Crytox victim ID generation algorithm\r\nBefore encrypting any files, the malware removes the SeBackupPrivilege and SeRestorePrivilege privileges.\r\nUsing the functions WNetOpenEnumW and WNetEnumResourceW, the malware retrieves connected drives\r\nand for each drive found, a thread is created to encrypt files. The same process is applied for every logical drive\r\nusing the function GetLogicalDrives. The malware then waits for a lock to be released before calling the\r\nShChangeNotify function in order to change the icon and file association and to display the ransom note to the\r\nvictim.\r\nFile encryption\r\nThe algorithm to discover all the files is relatively standard and relies on a recursive approach. The Windows\r\ndirectory is excluded from the search along with the ransom note and files with the .waiting extension. In addition,\r\nCrytox will only encrypt files that are larger than 16 bytes, which is the size of a block for AES. If the size of a file\r\nis not an exact multiple of 16 bytes, the malware will not pad and encrypt the last block of data. For large files,\r\nonly the first 1,048,576 (0x100000) bytes are read and encrypted to optimize encryption speed.\r\nFor each file, a new 256-bit AES key is generated and the content of the file is encrypted using AES-CBC. Crytox\r\nthen creates the following structure in Figure 6.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware\r\nPage 6 of 11\n\nFigure 6. Cryptox cipher footer structure\r\nThe BLOBHEADER structure is set like this:\r\n.bType = PLAINTEXTKEYBLOB\r\n.bVersion = CUR_BLOB_VERSION\r\n.aiKeyAlg = CALG_AES_256\r\nSince the structure is not initialized, the padding structure is filled with random data.\r\nThis structure is encrypted with the locally generated RSA public key. The resulting cipher is concatenated to the\r\nend of the encrypted file followed by the encrypted generated RSA private key. The encrypted file is renamed by\r\nappending YOUR ID.waiting to the original filename with YOUR ID replaced by the victim ID computed as\r\ndescribed previously.\r\nA ransom note is written to every directory after encrypting all files that are present. A process flow chart for\r\nCrytox is illustrated in Figure 7.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware\r\nPage 7 of 11\n\nFigure 7. Process flowchart for Cryptox encryption\r\nKey Generation Algorithm and Weakness\r\nAs stated previously, a 256-bit AES key is generated for each file that is encrypted.\r\nThe following algorithm in Figure 8 is used for the key generation.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware\r\nPage 8 of 11\n\nFigure 8. Crytox key generation algorithm\r\nThe custom pseudo random key generator functions relies on the variables below:\r\nA seed value determined by calling GetTickCount\r\nA 64-bit integer config_t.random_generated initially set to 0\r\nA 32-bit integer constant config_t.config_seed\r\nThe last value is stored inside the malware's configuration. This value has been the same across samples analyzed\r\nby ThreatLabz. The only unknown value necessary to determine the AES key is the value of GetTickCount at the\r\ntime of encryption. However, if some plaintext of a file is known, efforts to bruteforce the AES key are feasible.\r\nBased on file magic values, one can divise a bruteforce program with the following logic:\r\n1. Set a counter to 0\r\n2. Let the random generator create a key with the counter as the rotating seed\r\n3. Decrypt the first block of the encrypted file\r\n4. Compare a known magic value with the decrypted data\r\n5. If the value matches, the initial value of GetTickCount and the key have been successfully identified.\r\nElse, increment counter and loop back to 2.\r\nFigure 8 shows an bruteforce program running on a machine with 16 logic cores. Here, the encrypted file was\r\ndotnet-sdk-3.1.416-win-x64.exe (SHA1: 83A53E8770EDD38EDDD37DED63CEF2253FC16979) and the known\r\nplaintext was the Windows PE (MZ) file header 4D5A9000.\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware\r\nPage 9 of 11\n\nFigure 9. Cryptox example bruteforce key recovery\r\nThe method relies on knowing a part of the plaintext at a specific offset. Thus, only specific file types may be\r\ndecrypted. Because the seed is based on GetTickCount, if one has access to the master file table (MFT) and is\r\nable to locate and decrypt the first and last file encrypted, then the range of GetTickCount values can be deduced.\r\nTherefore, the bruteforce range can be greatly reduced to decrypt all files.\r\nConclusion\r\nCrytox exposes some interesting features to hinder static analysis by self-decrypting itself several times, injecting\r\nshellcode inside different processes, encrypting its configurations and using API hashing. The main file encryption\r\nlogic of Crytox is standard using a unique AES key per file that is protected with RSA. However, the author(s)\r\nchose to rely on a weak random generator to create new AES keys. Using a 32-bit integer as the seed is not\r\nsufficient with today's computational power.\r\nRansomware families have a lot in common due to their shared goals and most use secure encryption schemes.\r\nHowever, there may still be implementation weaknesses that enable file decryption without having access to a\r\nprivate key. The bruteforce methods described in this blog could be reused for similar scenarios.\r\nCloud Sandbox Detection\r\nIn addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to the\r\ncampaign with the following threat name:\r\nWin64.Ransom.Crytox\r\nIndicators of Compromise\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware\r\nPage 10 of 11\n\nHashes\r\n1c0bf0c2e7d0c34ec038a8b717bb19d9c4cf3382ada1412f055a9786d3069d78\r\n2115c4c859d497eec163ca33798c389649543d8a6e4db5806a791c6186722b71\r\n307c83924e90f4627f08c2f744cf51f18ec6e246687282a0c1794369ff084f42\r\n3764200cfa673e8796e7c955454b57c20852c2a7931fb9f632ef89d267bbd4c8\r\n6d4e75bc0cc095fef94b9d98a4e94ce9145890b435012b5624aa73621ba6e312\r\n79aff06385c16a98594c6fd314c572bfbe07fbe923f30a627e9b86ac3ab7c071\r\n8ee4a58699ecf02dca516dc6b5b72d93fd9968f672b2be6f8920dfec027d7815\r\nc5550f44332750552921cb5d685ccfbeefa2ab4b03aed8c51c5db52bbe2ff5d4\r\nd60dc6965f6d68a3e7c82d42e90bfda7ad3c5874d2c59a66df6212aef027b455\r\nFiles written\r\nC:\\ReadMe.hta\r\nFiles with \".waiting\" extension\r\nRegistry keys\r\nHKCR\\.waiting\\shell\\open\\command \r\nExplore more Zscaler blogs\r\nSource: https://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware\r\nhttps://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.zscaler.com/blogs/security-research/technical-analysis-crytox-ransomware"
	],
	"report_names": [
		"technical-analysis-crytox-ransomware"
	],
	"threat_actors": [],
	"ts_created_at": 1775434438,
	"ts_updated_at": 1775826684,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7e9e8b0dce9d3a01dd92f1e146ce218d1d1c87d9.pdf",
		"text": "https://archive.orkl.eu/7e9e8b0dce9d3a01dd92f1e146ce218d1d1c87d9.txt",
		"img": "https://archive.orkl.eu/7e9e8b0dce9d3a01dd92f1e146ce218d1d1c87d9.jpg"
	}
}