One Source to Rule Them All: Chasing AVADDON Ransomware |
Mandiant
By Mandiant
Published: 2022-01-19 · Archived: 2026-04-05 14:21:03 UTC
AVADDON operates similarly to other ransomware samples and contains an embedded configuration. AVADDON’s
configuration is stored in the form of global stdstring variables that are initialized prior to main as a C++ global initializer.
The strings are decoded as they are needed during execution. All configuration encoding is performed using Base64 and
multiple iterations of arithmetic operations utilizing a hardcoded single-byte key that varies per binary. Figure 7 is an
example python script used for decoding configuration data found in sample hash
(MD5:ae663fa3b803d8c23e98373fa3f66d21).
AVADDON’s execution flow begins by stopping and deleting services and processes that might interrupt its operation
(Figure 8). Next, the configuration runs multiple commands that prevent a user from restoring from backup (Table 1).
Finally, the ransomware begins its encryption operation by recursively iterating local drives and network shares while
avoiding directories (Figure 9) and files with specific extensions (Figure 10).
AVADDON searches the following strings related to virtual machines, backups and antivirus services to stop and delete
them:
The following processes are stopped. The ransomware stores a short-hand form of the full process name, but it does not
appear to be used during process identification or termination.
AVADDON deletes the Windows shadow volumes and empties the recycle bin to avoid file recovery. Next, it executes the
anti-recovery commands in Figure 9. Finally, to prevent the system from restarting, AVADDON leverages the Windows
Restart Manager by adding files actively being encrypted to the Restart Manager registry.
The following directories are excluded from the encryption process and are consistent across different versions of
AVADDON.
Additionally, directories containing the following keywords are excluded.
When encrypting the filesystem, the following extensions are excluded to ensure the system can be recovered after paying
the ransom with the provided decryptor.
The ransomware includes a host survey as part of the ransom note. The host survey is comprised of two parts that are
separated by a hyphen character and then Base64 encoded. The first part is a plaintext victim id, the second part is an RSA
encrypted JSON structure of data containing the fields in Figure 13.
Structure Description
ext Encrypted file extension
rcid AES key and file extension encrypted with RSA key and stored in hex format
hdd Detected and connected drives to the host
hdd.name Drive letter A-Z
hdd.size Drive size in GB
hdd.type Drive type local/network
https://www.mandiant.com/resources/chasing-avaddon-ransomware
Page 1 of 9

lang Default locale language
name Hostname</span
The following is an example JSON string containing the information gathered from the compromised system. This JSON
string is not written to disk and is only stored in memory.
{
 "ext": ".eDDDbCADB",
 "rcid": "796249FF39A076F96C3261D0913FEEF832759C1D2CA83DA9AF38D582B8C3E638E71F73
206D405BC60C0DFBC18DF9E0E8C404F8FE396D60BF7C478F0B74ACF678A163BC021AC53
82F683088E871687EF1F5D70E137152B90C4F5FB025CFF70DBC679259B2DAEE3A76D2AB
C5B6FD8CB1B7105DAD21D816A736239500BEB95BFA2538A5732A660B31571D36E22C55
E7C1B86B94B31D1208C1D6D077A2D52F65FD12F8A1E18FD63557DA0FEAF2781694DECD
7BA0080464401EBBED45E2213B15D868DF2384D0369D50BA075EDB852AFB8406D735B0
0EBD56A73FEB304F18B9A92C63C333A1CB90E2AFBFFDD1F4B1666BF37F8B75A7DD3014
A3A00F8C4FC09589B186F498C9ACC510EA05B7BA3C5BA44723DEE00CC905230AB6E4C9
0C6DA3F703CD3AAE1003479DBF4707E2060BCC2E1316E4C05BFBAEB508C6A99107042D
37C92B50E468D805C67690788AC6B6A1A1BDEE3C2F87236F74A2868AA76E48E010F8C4
CDB998DEE1C47C946BAF596D315C1AB40D14A3E248072F5677D0CE5B1C3621F753E466
AD438ABA7726CC46C85F697890BEC2F414D18B752180721D4E05B496790FFE45C505D9
756ABE6368CFE6D89EE36013A6BB20D7B27613D275E7D7AD2B7EA1FED7D729526F5D7
D5E58AF3A90F01A2F0C257842D8B9909EA32FC82ED8D2A6B8361E058CBA08BA43C633F
1F9B37E96671DFBBB3F0B8F80A7CB0271FA66990F30",
 "hdd": [{
 "name": "C",
 "size": 118,
 "type": "local"
 },
 {
 "name": "D",
 "size": 0,
 "type": "local"
 }
 ],
 "lang": "English",
 "name": "DESKTOP-AA1OUBT"
}
Figure 14: JSON blob containing host, user and encryption details
Earlier builds of AVADDON ransomware had a User Access Control (UAC) bypass module to abuse CMSTPLUA COM
interface. This UAC bypass is common and has been used by multiple ransomwares such as DARKSIDE due to its easy
implementation and the availability of public Proof of Concept (PoC) code. AVADDON added modifications over time and
removed the UAC bypass.
AVADDON Encryption Evolution
Initially, AVADDON generated a single AES-256 key residing in memory during the encryption process, this key would stay
resident until the process exited and was used to encrypt every file. This allowed researchers to develop a decryptor tool
released in February 2021 on GitHub, abusing this flaw and dumping the cryptographic materials from the suspended
process. Developers of the ransomware fixed this issue by generating a single AES key per file being encrypted.
https://www.mandiant.com/resources/chasing-avaddon-ransomware
Page 2 of 9

AVADDON, when initially released, used a single AES key for encrypting all files. There are three ways to recover a file’s
AES session key:
The ransom note, as part of the victim ID, requires attackers’ private RSA key.
Each file has a footer appended that contains the session key used to encrypt the file. The key can be extracted with
the private RSA key.
Find the session key resident in memory.
AVADDON later moved to using a “one key per file” method which resolved the third item of finding a key resident in
memory. The other two methods require a private key and are therefore protected. One interesting note: the AES key
generated and stored in the ransom note for later versions is never used, only the session keys stored in the file are correct,
this is remnant of moving to a “one key per file” methodology vs a single key that could be stored once.
Analysis across AVADDON samples containing the file encryption fix showed the replacement of the used C++ structures
for global variables indicating a quick fix was made by the threat actors developing AVADDON.
Samples observed later in 2021 with PE timestamps of April 2021 include improvements such as the addition of
IOCompletionPort multithreading and the replacement of these global variables again for structures just like the original
release.
This indicates that the threat actor implemented a quick fix after the release of the PoC decryptor to continue with the
operations while improved and more consistent versions of the software were under development.
Additionally, latest versions of AVADDON had a function to force the restart of the victim host in safemode prior to
encrypting the filesystem by providing the command line parameter “-safe” to the encryptor executable; mimicking other
RaaS services that implemented similar features in attempt to bypass Antivirus and EDR software.
Ransomware Similarities and Technical Comparison
Mandiant analyzed multiple samples of MEDUSALOCKER, Ako, ThunderX, AVADDON and RANZY, finding multiple
similarities between these ransomwares including the programming language, code similarities and functionalities, many of
these can be observed in Figure 15.
Additionally, there’s a significant overlap in their infrastructure as Ako and RANZY used the same Tor onion address
7rckgo66iydpvgpwve7b2el5q2zhjw4tv4lmyewufnpx4lhkekxkoqd[.]onion.
This Tor site was used for the purposes of shaming victims and coercing them to pay ransom demands, showing another
degree of relationship between them.
Similar PDB strings have been seen across multiple samples of MEDUSALOCKER, ThunderX (MD5:
fedadfa6ce199900ca0a6a1f588f8beb), RANZY (MD5: d3774470f4a1b2451fb314d6c37a7763) and in a sample of
AVADDON decryptor (MD5: 01422fd3eec0d1a0ce238df01edf8a50) contributing to show potential links between them.
Note that both ThunderX and RANZY share the same PDB string.
Example PDB paths:
C:\Users\Gh0St\Desktop\MedusaLockerInfo\MedusaLockerProject\MedusaLocker\Release\MedusaLocker.pdb
C:\Users\Gh0St\Desktop\MedusaLockerInfo\MedusaLockerProject\MedusaLocker\Debug\MedusaLockerXP.pdb
C:\Users\Gh0St\Desktop\MedusaLockerInfo\MedusaLockerProject\MedusaLocker\Release\MedusaLockerXP.pdb
C:\Users\Gh0St\Desktop\MedusaLockerInfo\MedusaLockerProject\MedusaLocker\Debug\MedusaLocker.pdb
C:\Users\Gh0St\Desktop\MedusaLockerInfo\MedusaLockerProject_v2\MedusaLocker\Debug\MedusaLocker.pdb
C:\Users\Gh0St\Desktop\AvaddonProjectInfo\AvaddonProject\AvaddonLockerLite\Release\AvaddonUnlockerGlobalLiteXPStu
C:\Users\Gh0St\Desktop\ThunderX\Release\LockerStub.pdb
https://www.mandiant.com/resources/chasing-avaddon-ransomware
Page 3 of 9

Feature   MEDUSALOCKER Ako* AVADDON ThunderX* RANZY
Programming
Language  
C++   C++ C++   C++   C++  
Symmetric
Encryption  
AES-256 CBC  
AES-256
CBC
AES-256 CBC   Salsa20   Salsa20  
Asymmetric
Encryption  
RSA    RSA    RSA   RSA RSA
Key Generation 
Same key per
execution
Same key
per
execution 
Depends on
version 
Unique key
per file 
Unique
key per
file 
Language check   No   No   Yes   No No
UAC bypass
CMSTPLUA COM
interface
No
CMSTPLUA COM
interface, depends
on version
No No
 Network discovery
technique  
ICMP ICMP
ARP, depends on
version
ICMP ICMP
 Process and
service termination
similarity  
Yes No Yes Yes Yes
Figure 15: Table showing similarities between ransomware
*Ako (MEDUSALOCKER variant)
*ThunderX (RANZY variant)
Encryption Operations
Code reuse appeared very similar throughout initializing a cryptographic context for all of them. After analyzing each
ransomware extensively, many functions had the same architecture and similar structure for storage and were found to
always be evident and easy to pick out once reversing a sample.
Between the five ransomware, there are four modes of file encryption supported describing how much of the file to encrypt
and in one case wiping the contents of the file instead of encrypting. These modes are the same across each ransomware.
File Signature
https://www.mandiant.com/resources/chasing-avaddon-ransomware
Page 4 of 9

MEDUSALOCKER initially did not use file signature to append to the encrypted files, however Ako appends the hex value
0xBEEFCACE.
AVADDON appends the hex value 0x1030307 to the end of the file within a 24-byte structure.
RANZY and ThunderX use the signature hex value 0xB0E0E0F0.
These 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
key encrypted with the attacker’s public key.
Identifier Format
Ako, ThunderX and RANZY construct highly similar JSON blobs that are encoded and written to the ransom notes. These
contain multiple keywords that overlap between them.
Ako and AVADDON written identifiers contain similarities and overlap some keywords, however, AVADDON constructs a
larger JSON (seen in Figure 14) and uses additional keywords not present in Ako.
Obfuscation
MEDUSALOCKER and Ako contain plain text strings and only the RSA key blob is base64 encoded. AVADDON,
ThunderX and RANZY have different implementations to obfuscate both the RSA key and the strings.
UAC Bypass
MEDUSALOCKER and AVADDON use a similar UAC bypass functionality abusing the CMSTPLUA COM interface
while ThunderX and RANZY don’t include a bypass.
Backup Deletion
The ransomware families delete backups by executing very similar command arguments to delete the Windows Shadow
Copies invoking wbadmin, bcedit.exe and vssadmin.exe and to empty the recycle bin.
Service and Process Enumeration
These pieces of ransomware use a remarkably similar list of process and services to scan and stop if found and following a
similar order. However, AVADDON contains more processes and services related to VMWare, Antivirus, SQLServer and
Tomcat services and processes.
ThunderX and RANZY have different process and services lists and only some overlap. Additionally, the list of services to
stop is considerably shorter than the rest of the ransomware, while the list of processes is larger.
File and Directory Exclusions
MEDUSALOCKER and AVADDON contain nearly identical file and directory exclusions, however, AVADDON contains
additional directories that are skipped including TOR browser directories and a shorter list of file extensions skipped from
the encryption process.
Network Scanning
MEDUSALOCKER, Ako, ThunderX and RANZY contain similar code to scan the victim’s network by using
IcmpSendEcho function.
First builds identified for AVADDON rely on SendARP function, however, some of the AVADDON samples with PE
timestamps from February 2021 show a replacement in the network reconnaissance module to use the IcmpCreateFile and
IcmpSendEcho functions.
https://www.mandiant.com/resources/chasing-avaddon-ransomware
Page 5 of 9

Other Differences
Different versions of AVADDON have added exclusion folders and it can receive a CLI argument.
ThunderX and RANZY can receive the CLI argument –nolan.
Conclusion
The similarities between these ransomware families and the timespan of activity suggest that the MEDUSALOCKER code
base was likely reused by different threat actors that started operating RaaS in 2020. The binary similarities and techniques
used show a certain degree of relationship between them. However, the technical skills of each threat actor involved in the
development of these RaaS and the implementations vary per ransomware.
AVADDON constitutes a considerable evolution compared to MEDUSALOCKER, however, it is unclear whether
AVADDON was the successor of MEDUSALOCKER due to technical differences and overlap in their activity. The
AVADDON service was operational for about a year and gained considerable popularity among threat actors to extort
victims across multiple regions and industries until events forced a fast exit followed by the shutdown of its operations and
the release of the victim's private keys.
Given the similarities suggesting code overlap between these ransomware families, the different skillsets of the involved
operators and the overlap in time, it is unclear whether the Law Enforcement disruption of ransomware operations at this
time will be definitive for the threat actors responsible for AVADDON.
Rebranding, code sharing, or the purchase of source code by different threat actors are practical possibilities to get back into
extortion operations as seen in previous cases such as SODINOKIBI’s connections with GANDCRAB ransomware, or the
rebuild and rebrand of a new ransomware using another’s code base such as BLACKMATTER.
Appendix: ATT&CK Mapping
ATT&CK Tactic Category Techniques
Resource Development
Acquire Infrastructure (T1583)
·      Virtual Private Server (T1583.003)
Initial Access
External Remote Services(T1133)
·      Valid Accounts(T1078)
Execution
User Execution (T1204)
·      Malicious File (T1204.002)
Scheduled Task/Job (T1053)
· Scheduled Task (T1053.005)
https://www.mandiant.com/resources/chasing-avaddon-ransomware
Page 6 of 9

Persistence
Valid Accounts (T1078)
Boot or Logon Autostart Execution (T1547)
· Registry Run Keys / Startup Folder (T1547.001)
Privilege Escalation Valid Accounts (T1078)
Defense Evasion
Impair Defenses (T1562)
·      Disable or Modify Tools (T1562.001)
Obfuscated Files or Information (T1027)
· Software Packing (T1027.002)
Process Injection (T1055)
Indicator Removal on Host (T1070)
· File Deletion (T1070.004)
Modify Registry (T1112)
Deobfuscate/Decode Files or Information (T1140)
Virtualization/Sandbox Evasion (T1497)
· System Checks (T1497.001)
Credential Access OS Credential Dumping (T1003)
Discovery
Account Discovery (T1078)
Domain Trust Discovery (T1482)
Permissions Groups Discovery (T1069)
Lateral Movement
Remote Services (T1021)
·      Remote Desktop Protocol (T1012.001)
Collection
Archive Collected Data (T1560)
·      Archive via Utility (T1560.001)
Command and Control Application Layer Protocol (T1071)
·      Web Protocols (T1071.001)
https://www.mandiant.com/resources/chasing-avaddon-ransomware
Page 7 of 9

Encrypted Channel (T1573)
Ingress Tool Transfer (T1105)
Exfiltration
Exfiltration Over Web Service (T1567)
·      Exfiltration to Cloud Storage (T1567.002)
Mandiant Security Validation Action
Organizations can validate their security controls using the following actions with Mandiant Security Validation.
VID Name
A151-063 Command and Control - AVADDON, DNS Query, Live Host Check
A151-064 Host CLI - AVADDON, bcdedit Commands
A151-067 Malicious File Transfer - AVADDON, Download, Variant #1
A151-069 Protected Theater - AVADDON, Execution
A151-085 Protected Theater - AVADDON, Execution, Windows 10 Variant
A151-086 Protected Theater - AVADDON, Execution, Windows 7 Variant
A104-775 Protected Theater - WMIC Shadowcopy Delete, Variant #1
Appendix: Malware definitions
AVADDON
AVADDON is ransomware written in C++ that encrypts files stored locally and on mapped network shares. AVADDON
terminates targeted processes and services prior to encrypting files. AVADDON uses the AES-256 encryption algorithm to
encrypt files. AVADDON is a Windows ransomware written in C++. It is run as an affiliate program, RaaS. System files are
encrypted using a single AES-256 key. The AES-256 key is generated at run-time and encrypted using an embedded RSA
public key. The malware also has anti-analysis techniques and check that it is not running in a system with Russian
language.
MEDUSALOCKER
MEDUSALOCKER is ransomware written in C++ that encrypts files stored locally and on network shares with a randomly
generated AES-256 key. MEDUSALOCKER can bypass User Account Control (UAC) and terminates targeted processes
https://www.mandiant.com/resources/chasing-avaddon-ransomware
Page 8 of 9

and services prior to encrypting files. Persistence is established using a scheduled task. MEDUSALOCKER empties the
Recycle Bin and delete volume shadow copies.
RANZY
RANZY is a ransomware written in C++ that encrypts files stored locally and on mapped network shares appending the
extension "[.]ranzy" to them. RANZY uses Salsa20 stream cipher to encrypt files.
DARKRAVEN
DARKRAVEN is an ASPX webshell written in C# that functions as a backdoor. The backdoor supports shell command
execution and file transfer. Supplied data is decrypted and decoded using 3DES and a custom Base64 decoding routine.
BLACKCROW
BLACKCROW is an ASPX webshell written in VB[.]NET that functions as backdoor. BLACKCROW expects an attacker
to upload a [.]NET DLL payload alongside additional arguments. These arguments are used to invoke a series of methods
within the DLL. The results of the final invocation are displayed to the attacker.
SYSTEMBC
SYSTEMBC is a tunneler written in C that retrieves proxy-related commands from a C2 server using a custom binary
protocol over TCP. A C2 server directs SYSTEMBC to act as a proxy between the C2 server and a remote system.
SYSTEMBC is also capable of retrieving additional payloads via HTTP. Some variants may utilize the Tor network for this
purpose. Downloaded payloads may be written to disk or mapped directly into memory prior to execution. SYSTEMBC is
often utilized to hide network traffic associated with other malware families. Observed families include DANABOT,
SMOKELOADER, and URSNIF.
Acknowledgements
Advanced Practices team, FLARE team, Threat Pursuit team and Yash Gupta
Source: https://www.mandiant.com/resources/chasing-avaddon-ransomware
https://www.mandiant.com/resources/chasing-avaddon-ransomware
Page 9 of 9