{
	"id": "f9efc468-237d-44ab-93d1-15b9b98d2e52",
	"created_at": "2026-04-06T00:07:15.818944Z",
	"updated_at": "2026-04-10T03:21:18.720039Z",
	"deleted_at": null,
	"sha1_hash": "5833a520361b071bff76551ad3a1101ef45dbe4d",
	"title": "One Source to Rule Them All: Chasing AVADDON Ransomware | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 81859,
	"plain_text": "One Source to Rule Them All: Chasing AVADDON Ransomware |\r\nMandiant\r\nBy Mandiant\r\nPublished: 2022-01-19 · Archived: 2026-04-05 14:21:03 UTC\r\nAVADDON operates similarly to other ransomware samples and contains an embedded configuration. AVADDON’s\r\nconfiguration is stored in the form of global stdstring variables that are initialized prior to main as a C++ global initializer.\r\nThe strings are decoded as they are needed during execution. All configuration encoding is performed using Base64 and\r\nmultiple iterations of arithmetic operations utilizing a hardcoded single-byte key that varies per binary. Figure 7 is an\r\nexample python script used for decoding configuration data found in sample hash\r\n(MD5:ae663fa3b803d8c23e98373fa3f66d21).\r\nAVADDON’s execution flow begins by stopping and deleting services and processes that might interrupt its operation\r\n(Figure 8). Next, the configuration runs multiple commands that prevent a user from restoring from backup (Table 1).\r\nFinally, the ransomware begins its encryption operation by recursively iterating local drives and network shares while\r\navoiding directories (Figure 9) and files with specific extensions (Figure 10).\r\nAVADDON searches the following strings related to virtual machines, backups and antivirus services to stop and delete\r\nthem:\r\nThe following processes are stopped. The ransomware stores a short-hand form of the full process name, but it does not\r\nappear to be used during process identification or termination.\r\nAVADDON deletes the Windows shadow volumes and empties the recycle bin to avoid file recovery. Next, it executes the\r\nanti-recovery commands in Figure 9. Finally, to prevent the system from restarting, AVADDON leverages the Windows\r\nRestart Manager by adding files actively being encrypted to the Restart Manager registry.\r\nThe following directories are excluded from the encryption process and are consistent across different versions of\r\nAVADDON.\r\nAdditionally, directories containing the following keywords are excluded.\r\nWhen encrypting the filesystem, the following extensions are excluded to ensure the system can be recovered after paying\r\nthe ransom with the provided decryptor.\r\nThe ransomware includes a host survey as part of the ransom note. The host survey is comprised of two parts that are\r\nseparated by a hyphen character and then Base64 encoded. The first part is a plaintext victim id, the second part is an RSA\r\nencrypted JSON structure of data containing the fields in Figure 13.\r\nStructure Description\r\next Encrypted file extension\r\nrcid AES key and file extension encrypted with RSA key and stored in hex format\r\nhdd Detected and connected drives to the host\r\nhdd.name Drive letter A-Z\r\nhdd.size Drive size in GB\r\nhdd.type Drive type local/network\r\nhttps://www.mandiant.com/resources/chasing-avaddon-ransomware\r\nPage 1 of 9\n\nlang Default locale language\r\nname Hostname\u003c/span\r\nThe following is an example JSON string containing the information gathered from the compromised system. This JSON\r\nstring is not written to disk and is only stored in memory.\r\n{\r\n \"ext\": \".eDDDbCADB\",\r\n \"rcid\": \"796249FF39A076F96C3261D0913FEEF832759C1D2CA83DA9AF38D582B8C3E638E71F73\r\n206D405BC60C0DFBC18DF9E0E8C404F8FE396D60BF7C478F0B74ACF678A163BC021AC53\r\n82F683088E871687EF1F5D70E137152B90C4F5FB025CFF70DBC679259B2DAEE3A76D2AB\r\nC5B6FD8CB1B7105DAD21D816A736239500BEB95BFA2538A5732A660B31571D36E22C55\r\nE7C1B86B94B31D1208C1D6D077A2D52F65FD12F8A1E18FD63557DA0FEAF2781694DECD\r\n7BA0080464401EBBED45E2213B15D868DF2384D0369D50BA075EDB852AFB8406D735B0\r\n0EBD56A73FEB304F18B9A92C63C333A1CB90E2AFBFFDD1F4B1666BF37F8B75A7DD3014\r\nA3A00F8C4FC09589B186F498C9ACC510EA05B7BA3C5BA44723DEE00CC905230AB6E4C9\r\n0C6DA3F703CD3AAE1003479DBF4707E2060BCC2E1316E4C05BFBAEB508C6A99107042D\r\n37C92B50E468D805C67690788AC6B6A1A1BDEE3C2F87236F74A2868AA76E48E010F8C4\r\nCDB998DEE1C47C946BAF596D315C1AB40D14A3E248072F5677D0CE5B1C3621F753E466\r\nAD438ABA7726CC46C85F697890BEC2F414D18B752180721D4E05B496790FFE45C505D9\r\n756ABE6368CFE6D89EE36013A6BB20D7B27613D275E7D7AD2B7EA1FED7D729526F5D7\r\nD5E58AF3A90F01A2F0C257842D8B9909EA32FC82ED8D2A6B8361E058CBA08BA43C633F\r\n1F9B37E96671DFBBB3F0B8F80A7CB0271FA66990F30\",\r\n \"hdd\": [{\r\n \"name\": \"C\",\r\n \"size\": 118,\r\n \"type\": \"local\"\r\n },\r\n {\r\n \"name\": \"D\",\r\n \"size\": 0,\r\n \"type\": \"local\"\r\n }\r\n ],\r\n \"lang\": \"English\",\r\n \"name\": \"DESKTOP-AA1OUBT\"\r\n}\r\nFigure 14: JSON blob containing host, user and encryption details\r\nEarlier builds of AVADDON ransomware had a User Access Control (UAC) bypass module to abuse CMSTPLUA COM\r\ninterface. This UAC bypass is common and has been used by multiple ransomwares such as DARKSIDE due to its easy\r\nimplementation and the availability of public Proof of Concept (PoC) code. AVADDON added modifications over time and\r\nremoved the UAC bypass.\r\nAVADDON Encryption Evolution\r\nInitially, AVADDON generated a single AES-256 key residing in memory during the encryption process, this key would stay\r\nresident until the process exited and was used to encrypt every file. This allowed researchers to develop a decryptor tool\r\nreleased in February 2021 on GitHub, abusing this flaw and dumping the cryptographic materials from the suspended\r\nprocess. Developers of the ransomware fixed this issue by generating a single AES key per file being encrypted.\r\nhttps://www.mandiant.com/resources/chasing-avaddon-ransomware\r\nPage 2 of 9\n\nAVADDON, when initially released, used a single AES key for encrypting all files. There are three ways to recover a file’s\r\nAES session key:\r\nThe ransom note, as part of the victim ID, requires attackers’ private RSA key.\r\nEach file has a footer appended that contains the session key used to encrypt the file. The key can be extracted with\r\nthe private RSA key.\r\nFind the session key resident in memory.\r\nAVADDON later moved to using a “one key per file” method which resolved the third item of finding a key resident in\r\nmemory. The other two methods require a private key and are therefore protected. One interesting note: the AES key\r\ngenerated and stored in the ransom note for later versions is never used, only the session keys stored in the file are correct,\r\nthis is remnant of moving to a “one key per file” methodology vs a single key that could be stored once.\r\nAnalysis across AVADDON samples containing the file encryption fix showed the replacement of the used C++ structures\r\nfor global variables indicating a quick fix was made by the threat actors developing AVADDON.\r\nSamples observed later in 2021 with PE timestamps of April 2021 include improvements such as the addition of\r\nIOCompletionPort multithreading and the replacement of these global variables again for structures just like the original\r\nrelease.\r\nThis indicates that the threat actor implemented a quick fix after the release of the PoC decryptor to continue with the\r\noperations while improved and more consistent versions of the software were under development.\r\nAdditionally, latest versions of AVADDON had a function to force the restart of the victim host in safemode prior to\r\nencrypting the filesystem by providing the command line parameter “-safe” to the encryptor executable; mimicking other\r\nRaaS services that implemented similar features in attempt to bypass Antivirus and EDR software.\r\nRansomware Similarities and Technical Comparison\r\nMandiant analyzed multiple samples of MEDUSALOCKER, Ako, ThunderX, AVADDON and RANZY, finding multiple\r\nsimilarities between these ransomwares including the programming language, code similarities and functionalities, many of\r\nthese can be observed in Figure 15.\r\nAdditionally, there’s a significant overlap in their infrastructure as Ako and RANZY used the same Tor onion address\r\n7rckgo66iydpvgpwve7b2el5q2zhjw4tv4lmyewufnpx4lhkekxkoqd[.]onion.\r\nThis Tor site was used for the purposes of shaming victims and coercing them to pay ransom demands, showing another\r\ndegree of relationship between them.\r\nSimilar PDB strings have been seen across multiple samples of MEDUSALOCKER, ThunderX (MD5:\r\nfedadfa6ce199900ca0a6a1f588f8beb), RANZY (MD5: d3774470f4a1b2451fb314d6c37a7763) and in a sample of\r\nAVADDON decryptor (MD5: 01422fd3eec0d1a0ce238df01edf8a50) contributing to show potential links between them.\r\nNote that both ThunderX and RANZY share the same PDB string.\r\nExample PDB paths:\r\nC:\\Users\\Gh0St\\Desktop\\MedusaLockerInfo\\MedusaLockerProject\\MedusaLocker\\Release\\MedusaLocker.pdb\r\nC:\\Users\\Gh0St\\Desktop\\MedusaLockerInfo\\MedusaLockerProject\\MedusaLocker\\Debug\\MedusaLockerXP.pdb\r\nC:\\Users\\Gh0St\\Desktop\\MedusaLockerInfo\\MedusaLockerProject\\MedusaLocker\\Release\\MedusaLockerXP.pdb\r\nC:\\Users\\Gh0St\\Desktop\\MedusaLockerInfo\\MedusaLockerProject\\MedusaLocker\\Debug\\MedusaLocker.pdb\r\nC:\\Users\\Gh0St\\Desktop\\MedusaLockerInfo\\MedusaLockerProject_v2\\MedusaLocker\\Debug\\MedusaLocker.pdb\r\nC:\\Users\\Gh0St\\Desktop\\AvaddonProjectInfo\\AvaddonProject\\AvaddonLockerLite\\Release\\AvaddonUnlockerGlobalLiteXPStu\r\nC:\\Users\\Gh0St\\Desktop\\ThunderX\\Release\\LockerStub.pdb\r\nhttps://www.mandiant.com/resources/chasing-avaddon-ransomware\r\nPage 3 of 9\n\nFeature   MEDUSALOCKER Ako* AVADDON ThunderX* RANZY\r\nProgramming\r\nLanguage  \r\nC++   C++ C++   C++   C++  \r\nSymmetric\r\nEncryption  \r\nAES-256 CBC  \r\nAES-256\r\nCBC\r\nAES-256 CBC   Salsa20   Salsa20  \r\nAsymmetric\r\nEncryption  \r\nRSA    RSA    RSA   RSA RSA\r\nKey Generation \r\nSame key per\r\nexecution\r\nSame key\r\nper\r\nexecution \r\nDepends on\r\nversion \r\nUnique key\r\nper file \r\nUnique\r\nkey per\r\nfile \r\nLanguage check   No   No   Yes   No No\r\nUAC bypass\r\nCMSTPLUA COM\r\ninterface\r\nNo\r\nCMSTPLUA COM\r\ninterface, depends\r\non version\r\nNo No\r\n Network discovery\r\ntechnique  \r\nICMP ICMP\r\nARP, depends on\r\nversion\r\nICMP ICMP\r\n Process and\r\nservice termination\r\nsimilarity  \r\nYes No Yes Yes Yes\r\nFigure 15: Table showing similarities between ransomware\r\n*Ako (MEDUSALOCKER variant)\r\n*ThunderX (RANZY variant)\r\nEncryption Operations\r\nCode reuse appeared very similar throughout initializing a cryptographic context for all of them. After analyzing each\r\nransomware extensively, many functions had the same architecture and similar structure for storage and were found to\r\nalways be evident and easy to pick out once reversing a sample.\r\nBetween the five ransomware, there are four modes of file encryption supported describing how much of the file to encrypt\r\nand in one case wiping the contents of the file instead of encrypting. These modes are the same across each ransomware.\r\nFile Signature\r\nhttps://www.mandiant.com/resources/chasing-avaddon-ransomware\r\nPage 4 of 9\n\nMEDUSALOCKER initially did not use file signature to append to the encrypted files, however Ako appends the hex value\r\n0xBEEFCACE.\r\nAVADDON appends the hex value 0x1030307 to the end of the file within a 24-byte structure.\r\nRANZY and ThunderX use the signature hex value 0xB0E0E0F0.\r\nThese signatures are part of a 24-byte structure that is very similar across all of them, prior to this footer is the file’s session\r\nkey encrypted with the attacker’s public key.\r\nIdentifier Format\r\nAko, ThunderX and RANZY construct highly similar JSON blobs that are encoded and written to the ransom notes. These\r\ncontain multiple keywords that overlap between them.\r\nAko and AVADDON written identifiers contain similarities and overlap some keywords, however, AVADDON constructs a\r\nlarger JSON (seen in Figure 14) and uses additional keywords not present in Ako.\r\nObfuscation\r\nMEDUSALOCKER and Ako contain plain text strings and only the RSA key blob is base64 encoded. AVADDON,\r\nThunderX and RANZY have different implementations to obfuscate both the RSA key and the strings.\r\nUAC Bypass\r\nMEDUSALOCKER and AVADDON use a similar UAC bypass functionality abusing the CMSTPLUA COM interface\r\nwhile ThunderX and RANZY don’t include a bypass.\r\nBackup Deletion\r\nThe ransomware families delete backups by executing very similar command arguments to delete the Windows Shadow\r\nCopies invoking wbadmin, bcedit.exe and vssadmin.exe and to empty the recycle bin.\r\nService and Process Enumeration\r\nThese pieces of ransomware use a remarkably similar list of process and services to scan and stop if found and following a\r\nsimilar order. However, AVADDON contains more processes and services related to VMWare, Antivirus, SQLServer and\r\nTomcat services and processes.\r\nThunderX and RANZY have different process and services lists and only some overlap. Additionally, the list of services to\r\nstop is considerably shorter than the rest of the ransomware, while the list of processes is larger.\r\nFile and Directory Exclusions\r\nMEDUSALOCKER and AVADDON contain nearly identical file and directory exclusions, however, AVADDON contains\r\nadditional directories that are skipped including TOR browser directories and a shorter list of file extensions skipped from\r\nthe encryption process.\r\nNetwork Scanning\r\nMEDUSALOCKER, Ako, ThunderX and RANZY contain similar code to scan the victim’s network by using\r\nIcmpSendEcho function.\r\nFirst builds identified for AVADDON rely on SendARP function, however, some of the AVADDON samples with PE\r\ntimestamps from February 2021 show a replacement in the network reconnaissance module to use the IcmpCreateFile and\r\nIcmpSendEcho functions.\r\nhttps://www.mandiant.com/resources/chasing-avaddon-ransomware\r\nPage 5 of 9\n\nOther Differences\r\nDifferent versions of AVADDON have added exclusion folders and it can receive a CLI argument.\r\nThunderX and RANZY can receive the CLI argument –nolan.\r\nConclusion\r\nThe similarities between these ransomware families and the timespan of activity suggest that the MEDUSALOCKER code\r\nbase was likely reused by different threat actors that started operating RaaS in 2020. The binary similarities and techniques\r\nused show a certain degree of relationship between them. However, the technical skills of each threat actor involved in the\r\ndevelopment of these RaaS and the implementations vary per ransomware.\r\nAVADDON constitutes a considerable evolution compared to MEDUSALOCKER, however, it is unclear whether\r\nAVADDON was the successor of MEDUSALOCKER due to technical differences and overlap in their activity. The\r\nAVADDON service was operational for about a year and gained considerable popularity among threat actors to extort\r\nvictims across multiple regions and industries until events forced a fast exit followed by the shutdown of its operations and\r\nthe release of the victim's private keys.\r\nGiven the similarities suggesting code overlap between these ransomware families, the different skillsets of the involved\r\noperators and the overlap in time, it is unclear whether the Law Enforcement disruption of ransomware operations at this\r\ntime will be definitive for the threat actors responsible for AVADDON.\r\nRebranding, code sharing, or the purchase of source code by different threat actors are practical possibilities to get back into\r\nextortion operations as seen in previous cases such as SODINOKIBI’s connections with GANDCRAB ransomware, or the\r\nrebuild and rebrand of a new ransomware using another’s code base such as BLACKMATTER.\r\nAppendix: ATT\u0026CK Mapping\r\nATT\u0026CK Tactic Category Techniques\r\nResource Development\r\nAcquire Infrastructure (T1583)\r\n·      Virtual Private Server (T1583.003)\r\nInitial Access\r\nExternal Remote Services(T1133)\r\n·      Valid Accounts(T1078)\r\nExecution\r\nUser Execution (T1204)\r\n·      Malicious File (T1204.002)\r\nScheduled Task/Job (T1053)\r\n· Scheduled Task (T1053.005)\r\nhttps://www.mandiant.com/resources/chasing-avaddon-ransomware\r\nPage 6 of 9\n\nPersistence\r\nValid Accounts (T1078)\r\nBoot or Logon Autostart Execution (T1547)\r\n· Registry Run Keys / Startup Folder (T1547.001)\r\nPrivilege Escalation Valid Accounts (T1078)\r\nDefense Evasion\r\nImpair Defenses (T1562)\r\n·      Disable or Modify Tools (T1562.001)\r\nObfuscated Files or Information (T1027)\r\n· Software Packing (T1027.002)\r\nProcess Injection (T1055)\r\nIndicator Removal on Host (T1070)\r\n· File Deletion (T1070.004)\r\nModify Registry (T1112)\r\nDeobfuscate/Decode Files or Information (T1140)\r\nVirtualization/Sandbox Evasion (T1497)\r\n· System Checks (T1497.001)\r\nCredential Access OS Credential Dumping (T1003)\r\nDiscovery\r\nAccount Discovery (T1078)\r\nDomain Trust Discovery (T1482)\r\nPermissions Groups Discovery (T1069)\r\nLateral Movement\r\nRemote Services (T1021)\r\n·      Remote Desktop Protocol (T1012.001)\r\nCollection\r\nArchive Collected Data (T1560)\r\n·      Archive via Utility (T1560.001)\r\nCommand and Control Application Layer Protocol (T1071)\r\n·      Web Protocols (T1071.001)\r\nhttps://www.mandiant.com/resources/chasing-avaddon-ransomware\r\nPage 7 of 9\n\nEncrypted Channel (T1573)\r\nIngress Tool Transfer (T1105)\r\nExfiltration\r\nExfiltration Over Web Service (T1567)\r\n·      Exfiltration to Cloud Storage (T1567.002)\r\nMandiant Security Validation Action\r\nOrganizations can validate their security controls using the following actions with Mandiant Security Validation.\r\nVID Name\r\nA151-063 Command and Control - AVADDON, DNS Query, Live Host Check\r\nA151-064 Host CLI - AVADDON, bcdedit Commands\r\nA151-067 Malicious File Transfer - AVADDON, Download, Variant #1\r\nA151-069 Protected Theater - AVADDON, Execution\r\nA151-085 Protected Theater - AVADDON, Execution, Windows 10 Variant\r\nA151-086 Protected Theater - AVADDON, Execution, Windows 7 Variant\r\nA104-775 Protected Theater - WMIC Shadowcopy Delete, Variant #1\r\nAppendix: Malware definitions\r\nAVADDON\r\nAVADDON is ransomware written in C++ that encrypts files stored locally and on mapped network shares. AVADDON\r\nterminates targeted processes and services prior to encrypting files. AVADDON uses the AES-256 encryption algorithm to\r\nencrypt files. AVADDON is a Windows ransomware written in C++. It is run as an affiliate program, RaaS. System files are\r\nencrypted using a single AES-256 key. The AES-256 key is generated at run-time and encrypted using an embedded RSA\r\npublic key. The malware also has anti-analysis techniques and check that it is not running in a system with Russian\r\nlanguage.\r\nMEDUSALOCKER\r\nMEDUSALOCKER is ransomware written in C++ that encrypts files stored locally and on network shares with a randomly\r\ngenerated AES-256 key. MEDUSALOCKER can bypass User Account Control (UAC) and terminates targeted processes\r\nhttps://www.mandiant.com/resources/chasing-avaddon-ransomware\r\nPage 8 of 9\n\nand services prior to encrypting files. Persistence is established using a scheduled task. MEDUSALOCKER empties the\r\nRecycle Bin and delete volume shadow copies.\r\nRANZY\r\nRANZY is a ransomware written in C++ that encrypts files stored locally and on mapped network shares appending the\r\nextension \"[.]ranzy\" to them. RANZY uses Salsa20 stream cipher to encrypt files.\r\nDARKRAVEN\r\nDARKRAVEN is an ASPX webshell written in C# that functions as a backdoor. The backdoor supports shell command\r\nexecution and file transfer. Supplied data is decrypted and decoded using 3DES and a custom Base64 decoding routine.\r\nBLACKCROW\r\nBLACKCROW is an ASPX webshell written in VB[.]NET that functions as backdoor. BLACKCROW expects an attacker\r\nto upload a [.]NET DLL payload alongside additional arguments. These arguments are used to invoke a series of methods\r\nwithin the DLL. The results of the final invocation are displayed to the attacker.\r\nSYSTEMBC\r\nSYSTEMBC is a tunneler written in C that retrieves proxy-related commands from a C2 server using a custom binary\r\nprotocol over TCP. A C2 server directs SYSTEMBC to act as a proxy between the C2 server and a remote system.\r\nSYSTEMBC is also capable of retrieving additional payloads via HTTP. Some variants may utilize the Tor network for this\r\npurpose. Downloaded payloads may be written to disk or mapped directly into memory prior to execution. SYSTEMBC is\r\noften utilized to hide network traffic associated with other malware families. Observed families include DANABOT,\r\nSMOKELOADER, and URSNIF.\r\nAcknowledgements\r\nAdvanced Practices team, FLARE team, Threat Pursuit team and Yash Gupta\r\nSource: https://www.mandiant.com/resources/chasing-avaddon-ransomware\r\nhttps://www.mandiant.com/resources/chasing-avaddon-ransomware\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE",
		"Malpedia"
	],
	"references": [
		"https://www.mandiant.com/resources/chasing-avaddon-ransomware"
	],
	"report_names": [
		"chasing-avaddon-ransomware"
	],
	"threat_actors": [],
	"ts_created_at": 1775434035,
	"ts_updated_at": 1775791278,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5833a520361b071bff76551ad3a1101ef45dbe4d.pdf",
		"text": "https://archive.orkl.eu/5833a520361b071bff76551ad3a1101ef45dbe4d.txt",
		"img": "https://archive.orkl.eu/5833a520361b071bff76551ad3a1101ef45dbe4d.jpg"
	}
}