{
	"id": "265cb254-a253-47b3-8f96-f6fe796a4c20",
	"created_at": "2026-04-06T00:07:15.753067Z",
	"updated_at": "2026-04-10T03:20:20.571367Z",
	"deleted_at": null,
	"sha1_hash": "8aab21eebea50322765ed6e0729d3a6ee281862a",
	"title": "The Curious Case of DeathRansom: Part I",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2618649,
	"plain_text": "The Curious Case of DeathRansom: Part I\r\nBy Minh Tran\r\nPublished: 2020-01-02 · Archived: 2026-04-05 18:05:37 UTC\r\nA FortiGuard Labs Threat Analysis Report\r\nIntroduction\r\nRansomware is certainly a significant global threat. According to one recent report, ransomware is estimated to\r\nhave cost businesses more than $8 billion in 2018, up from just $1 billion in 2016, while this year alone losses for\r\nthe healthcare industry have already reached $25 billion.\r\nPart of this increase is due to the rise of Ransomware as a Service, with variants such as GandCrab generating as\r\nmuch as $2 billion in revenue for its developers, and our observation in the FortiGuard Labs Threat Landscape\r\nReport for Q3 that two additional ransomware families – Sodinokibi and Nemty – have now been deployed as\r\nRaaS solutions as well. Another part of the reason for this growth is that cybercriminals continue to develop new\r\nransomware variants. This dramatic escalation of ransomware over the past few years is part of the reason why we\r\nhere at FortiGuard Labs keep such close track of it.\r\nAnd recently, our threat radar detected a new ransomware variant that we break down for you in this threat\r\nanalysis, ominously called DeathRansom. In this analysis, we will first be looking at a version with a SHA256\r\nsample of:\r\n7C2DBAD516D18D2C1C21ECC5792BC232F7B34DADC1BC19E967190D79174131D1\r\nSubsequent samples exhibit slightly different behaviors, as we describe later in our analysis.\r\nFigure 1. TimeDateStamp of the sample\r\nAs you can see, the TimeDateStamp of this sample is very new (Sat Nov 16 08:37:02 2019), so naturally, we\r\ndecided to dig deeper and learn more.\r\nThe Workflow of the DeathRansom Ransomware\r\nhttps://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html\r\nPage 1 of 12\n\nAt a high level, this ransomware follows a sensible design: it scans and encrypts files on local and network drives.\r\nFigure 2. start()\r\nIt’s clear that right off the bat (in start() ), that DeathRansom gets right to the business of being a ransomware: by\r\nenumerating and encrypting files. To enumerate network resources, the malware uses standard Windows APIs\r\n(WNetOpenEnumW, WNetEnumResourceW etc.)\r\nFigure 3. Recursively Scanning Network Resources\r\nInside this function (processNetwork), it recursively scans network resources until it hits a normal directory, at\r\nwhich point it processes it like a directory (processDir).\r\nhttps://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html\r\nPage 2 of 12\n\nFigure 4. processDir()\r\nJust like processNetwork, processDir is also recursive. The difference is that it needs to perform some sanity\r\nchecks to make sure that the item is indeed a folder (but not “.” or “..”), and further, that the item is not excluded\r\n(see exclusion2, below). \r\nFigure 5. Exclusions\r\nWe can see here that the malware author has made a number of reasonable choices, including:\r\nExcluding important Windows folders (Program Files, Windows, etc) to avoid rendering the system\r\nunusable\r\nWhen it comes to files, similar checks also occur.\r\nDeathRansom also avoids “encrypting” the systems files (ntuser.dat, etc)\r\nhttps://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html\r\nPage 3 of 12\n\nCertainly, this list is not comprehensive, but it does show that the author does have some skills and knowledge\r\nabout system programming.\r\nFigure 6. “Encrypting” Files\r\nAn astute reader may have noticed that DeathRansom does not really encrypt file content. In this case, victims\r\nonly have to rename the affected files (hint: remove the extension) to restore the system back to normal.\r\nhttps://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html\r\nPage 4 of 12\n\nFigure 7. Ransom Note\r\nIn spite of this, like almost all ransomware, DeathRansom still displays a ransom note called read_me.txt. In that\r\nnote one can see clearly that the author calls the malware DEATHRANSOM. The email also informs its victims\r\nthat they need to contact the culprits at death@cxxxxxxver.me and death@fxxxxxxx.cc\r\nOther Interesting Technical Details\r\nWhen the malware launches, but before it begins “encoding” files, it performs some interesting checks about the\r\nlanguages used in the victim’s system.\r\nFigure 8. Language Checks\r\nWe can use LangID to look up the names of these language from the authoritative source at Microsoft.\r\nhttps://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html\r\nPage 5 of 12\n\nFigure 9. Language Identifier Constants and Strings\r\nInterestingly, DeathRansom checks not just for one language but several languages, but we can still see a clear\r\npattern: it avoids infecting systems in Eastern European countries.\r\nWe also managed to extract some interesting information from an undocumented header (specifically, the Rich\r\nSignature):\r\nFigure 10. Rich Signature\r\nBased on this information, we were able to figure out the product used to make this malware. Notice the following\r\nextra marks used in the descriptions:\r\n+ [ C ] - object files produced by C compiler\r\n+ [IMP] - DLL import record in library file\r\n+ [LNK] - files produced by a linker\r\nhttps://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html\r\nPage 6 of 12\n\nproduct id: 0x0083 = MSVS2008 [ C ]\r\nproduct id: 0x0004 = MSVS6 [LNK]\r\nproduct id: 0x000E = ?\r\nproduct id: 0x0093 = MSVS2008 [IMP]\r\nproduct id: 0x0001 Objects without @comp.id\r\nproduct id: 0x0109 = ?\r\nproduct id: 0x0102 = VS 2019 / 2017 / 2015 [LNK]\r\nIt’s interesting that a product from 1998 (e.g. MSVS6) is still being used to make malware.\r\nNew Version Encrypts Files\r\nRecently, we found a new version of DeathRansom, and the primary change is that the malware now actually\r\nencrypts files. Our analysis is focused on a sample with the SHA256 hash of:\r\nab828f0e0555f88e3005387cb523f221a1933bbd7db4f05902a1e5cc289e7ba4.\r\nThe new version of this ransomware uses a combination of Curve25519 algorithm for the Elliptic Curve Diffie-Hellman (ECDH) key exchange scheme, Salsa20, RSA-2048, AES-256 ECB, and a simple block XOR algorithm\r\nto encrypt files. \r\nFigure 11. Key generation and file encryption\r\nhttps://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html\r\nPage 7 of 12\n\nDiffie-Hellman Key Exchange\r\n1. A random 32-byte value is generated using advapi32.SystemFunction036 (the same as RtlGenRandom). This\r\nserves as the victim’s curve25519 private key to the ECDH key exchange.\r\n2. Using the Curve25519 algorithm, the victim’s Curve25519 public key is derived from the victim’s Curve25519\r\nprivate key. This is the main information needed by the attacker to eventually decrypt the victim’s files. This is\r\nincluded in the registry “HKCU\\Software\\Wacatac\\private” as shown below.\r\nFigure 12. Added Registries\r\n3. Using the Curve25519 algorithm, a shared secret key is derived from a 32-byte hardcoded value (the attacker’s\r\nCurve25519 public key) and the previously generated victim’s Curve25519 private key described in step 1.\r\n4. The SHA256 hash of the shared secret key is computed, which will be used later on.\r\nRSA Key Pair Generation\r\n5. An RSA-2048 key pair is generated\r\n6. The RSA-2048 private key is encrypted using Salsa20, with the secret key’s SHA256 hash (from step 4, above)\r\nand then included in the registry file “HKCU\\Software\\Wacatac\\private” (see Fig 12).\r\nhttps://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html\r\nPage 8 of 12\n\n7. The RSA-2048 public key is written in the registry file “HKCU\\Software\\Wacatac\\public” (see Fig 12).\r\nFile Encryption\r\n8. A random 32-byte value is generated using the advapi32.SystemFunction036, which is used as the AES-256\r\nkey. This is done for every file.\r\n9. A 16-byte hardcoded value is encrypted with AES-256 ECB, using the previously generated random value as\r\nthe AES-256 key.\r\n10. The result from step 9 is the used as the key to a 16-byte block XOR operation with the content of the targeted\r\nfile.\r\n11. Repeat steps 9 and 10 while incrementing the hard-coded value by 1 on each loop until it encrypts the whole\r\nfile or until it encrypts 4 kilobytes (4096 bytes).\r\n12. The AES key (from step 8) is encrypted using the victim’s RSA-2048 public key (generated in step 5)\r\n13. The encrypted AES key and the marker 0xABEFCDAB, is then appended to the encrypted file.    \r\nFigure 13. Encrypted file format\r\nUltimately, for the victim files to be decrypted the shared secret must be generated. And for that, at least one of the\r\nfollowing pairs is needed:\r\nThe victim’s curve25519 public key (which can be obtained from registry or ransom note) and the\r\nattacker’s curve25519 private key (possessed by attacker)\r\nThe attacker’s curve25519 public key (embedded in the binary) and the victim’s curve25519 private key\r\n(lost after the malware’s execution)\r\nhttps://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html\r\nPage 9 of 12\n\nNOTE: Further investigation of this ransomware’s encryption behavior in underway to check for any\r\nimplementation flaws. We will be releasing updates for any new findings.\r\nAfter encryption, it drops a ransom note in every directory. It includes a LOCK-ID that is unique for every user.\r\nThis is the same data that can be found in the “HKCU\\Software\\Wacatac\\private” registry and encoded in base64.\r\nFigure 14. New Ransom Note\r\nAside from a connection to hxxps://iplogger[.]org/1Zqq77 to get the victim’s public IP address, the ransomware\r\ndoes not have any other network communication. However, as we discussed in the previous section, to generate\r\nthe shared secret key needed to decrypt the files the attacker must obtain the victim’s curve25519 public key. This\r\nis why the instruction to the victim in the ransom note is for them to send the LOCK-ID through email.\r\nSolution\r\nInternal testing by FortiGuard Labs shows that all networks and devices being protected by FortiGate solutions\r\nrunning the latest updates were automatically protected from this malware. In addition:\r\nhttps://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html\r\nPage 10 of 12\n\nThe FortiGuard Web Filtering service blocks hxxps://iplogger[.]org/1Zqq77\r\nThe FortiGuard Antivirus service detects the SHA 256 samples used in this analysis as the following:\r\n                    7C2DBAD516D18D2C1C21ECC5792BC232F7B34DADC1BC19E967190D79174131D1\r\n                        - This is detected as W32/Filecoder.B!tr.ransom\r\n                    13D263FB19D866BB929F45677A9DCBB683DF5E1FA2E1B856FDE905629366C5E1\r\n                    AB828F0E0555F88E3005387CB523F221A1933BBD7DB4F05902A1E5CC289E7BA4\r\n                        - These are detected as W32/Kryptik.ANT!tr\r\nFinally, as part of our membership in the Cyber Threat Alliance, details of this threat were shared in real time\r\nwith other Alliance members to help create better protections for customers.\r\nConclusion\r\nDeathRansom is a new malware. Naturally, things are moving fast. In our experience, a malware author changes\r\nthe malware often over time to improve features or to avoid detection. In fact, after our intital assessment of the\r\nfirst version of DeathRansom we noticed a short article describing how DeathRansom had begun encrypting files,\r\nmaking them inaccessible. Our research confirmed that, indeed, the malware author has addressed the missing part\r\nof the initial release and DeathRansom has now become a “proper” ransomware.\r\nIn our follow-up analysis we try to shed light on how DeathRansom can be associated with other attacks, and who\r\nmay be behind the creation of this malicious program. Continue reading to learn more in DeathRansom Part II:\r\nAttribution.\r\nThe author would like to thank Artem Semenchenko, Rommel Joven and Joie Salvio for additional insights during\r\nthe research process.\r\nIOCs\r\nSamples:\r\n7C2DBAD516D18D2C1C21ECC5792BC232F7B34DADC1BC19E967190D79174131D1\r\n13D263FB19D866BB929F45677A9DCBB683DF5E1FA2E1B856FDE905629366C5E1\r\nAB828F0E0555F88E3005387CB523F221A1933BBD7DB4F05902A1E5CC289E7BA4\r\nNetwork:\r\nhxxps://iplogger[.]org/1Zqq77\r\nLearn more about how FortiGuard Labs provides unmatched security and intelligence services using\r\nintegrated AI systems. Find out about the FortiGuard Security Services portfolio and sign up for our weekly\r\nFortiGuard Threat Brief. \r\nhttps://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html\r\nPage 11 of 12\n\nRead about the FortiGuard Security Rating Service, which provides security audits and best practices to guide\r\ncustomers in designing, implementing, and maintaining the security posture best suited for their organization.\r\nSource: https://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html\r\nhttps://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware.html"
	],
	"report_names": [
		"death-ransom-new-strain-ransomware.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434035,
	"ts_updated_at": 1775791220,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8aab21eebea50322765ed6e0729d3a6ee281862a.pdf",
		"text": "https://archive.orkl.eu/8aab21eebea50322765ed6e0729d3a6ee281862a.txt",
		"img": "https://archive.orkl.eu/8aab21eebea50322765ed6e0729d3a6ee281862a.jpg"
	}
}