Avaddon ransomware: an in-depth analysis and decryption of infected systems
AAvaddon ransomware: an in-depth analysis and decryption of infected systems
Javier Yuste a, ∗ , Sergio Pastrana b a Universidad Rey Juan Carlos, Madrid b Universidad Carlos III, Madrid
Abstract
Malware is an emerging and popular threat flourishing in the underground economy.The commoditization of Malware-as-a-Service (MaaS) allows criminals to obtain financial benefits at a low risk andwith little technical background. One such popular product is ransomware, which is a popular malware traded in theunderground economy.In ransomware attacks, data from infected systems is held hostage (encrypted) until a fee is paid to the criminals.This modus operandi disrupts legitimate businesses, which may become unavailable until the data is restored, thuscausing additional financial and reputational losses. A recent blackmailing strategy adopted by criminals is to leak dataonline from the infected systems if the ransom is not paid before a given time, threatening businesses to have their dataexposed online. Besides reputational damage, data leakage might produce further economical losses due to fines imposedby data protection laws, e.g. GDPR in Europe. Thus, research on prevention and recovery measures to mitigate theimpact of such attacks is needed to adapt existing countermeasures to new strains.In this work, we perform an in-depth analysis of Avaddon, a ransomware offered in the underground economy as anaffiliate program business.This threat has been linked to various cyberattacks and has infected and leaked data from at least 23 organizations.Additionally, it also runs Distributed Denial-of-Service (DDoS) attacks against victims that do not pay the ransom. Wefirst provide an analysis of the criminal business model from the underground economy. Then, we identify and describeits technical capabilities, and dissect details of their inner structure. We provide empirical evidence of links between thisvariant and a previous family, suggesting that the same group was behind the development and, possibly, the operationof both campaigns. As a result, we provide tools to assist analysis, allowing to decrypt and label encrypted stringsobserved in the ransomware binary. Finally, we describe a method to decrypt files encrypted with Avaddon in realtime. We implement and test the decryptor in a tool that can recover the encrypted data from an infected system, thusmitigating the damage caused by the ransomware. The tool is released open-source so it can be incorporated in existingAntivirus engines.
Keywords:
Avaddon, Ransomware, Malware Analysis, Reverse Engineering, Cybersecurity
1. Introduction
In February, 2018, the USA government estimated thatcybercrime costs raised up to between 57 and 109 billionsof dollars in 2016 [1]. Cybercrime has been growing forthe last decades as it becomes more profitable. The mostcommon goal for cybercriminals is monetary gain and theycommonly organize to form online criminal enterprises andbusinesses [2]. The virtual battlefield where such criminalactivities operate allows miscreants to perpetrate crimesin countries with different extradition laws than those ofthe country where they reside. This strategy frequentlymakes cybercrime hard to prosecute, in addition to othertechnical characteristics that difficult attribution [3, 4]. Inrecent times, the underground economy has developed a ∗ Corresponding author
Email address: [email protected] (Javier Yuste) myriad of approaches that allow cybercriminals to acquirehigh financial profits. With the cybercrime growth andspecialization, many cybercriminals offer their productsin an “as-a-service” model, where the attacker can pur-chase the service through the internet with little technicalknowledge. These services reduce the entry level for newcriminals and motivate newcomers into the underground[5, 6].In 2017, Panda security analyzed around 15m bina-ries [7]. The most noticeable thing was that, upon re-viewing the data collected, they realized that 99.1% of thesamples were only seen once, probably due to binary pack-ing and encryption. Indeed, a common digital commod-ity offered in underground markets is malware [8]. Con-cretely, one of the most popular variants offered is ran-somware [9], where the attacker denies access to the dataof its victims until a ransom is paid (hence the name ofthe threat). When these attacks affect companies or public a r X i v : . [ c s . CR ] F e b rganizations, they might provoke business interruptions,thus increasing the economic and social damage [10]. Ran-somware operators often partner up with other criminalgroups, either in a customer-service relationship (offeringthe software for a fixed fee or via a subscription-based ac-cess to constant updates) or in a profit sharing scheme(one party is responsible for developing and maintainingthe ransomware while the other distributes it, both sharingan arranged percentage of the revenues). Previous worksshow that criminals can run ransomware campaigns withlittle technical knowledge, making use of the available ser-vices, with an estimated return of investment of between504% and 12,682% [5].Due to the profitability and specialization of cyber-crime, modern ransomware campaigns have improved theirsophistication. First, techniques from well-established cryp-tography schemes, so-called hybrid cryptosystems, havebeen recently adopted in ransomware operations, com-bining symmetric and asymmetric cryptography. Second,modern ransomware perpetrators have incorporated an-other monetizing technique that further pushes the vic-tims to pay a ransom: data leakage extortion. Apart fromencrypting the files, ransomware operators now steal datafrom the infected systems and threaten the victims to leakit online if no ransom is paid. This extortion scheme wasinitiated by a threat actor named TWISTED SPIDER inthe last quarter of 2019 [11], and was quickly followed byother ransomware groups [12, 13, 14]. In order to face theransomware threat, and to be able to recover the hijackedfiles, it is important to understand the criminal ecosystemand also how the malware evolves and operates.In this work, we study a novel ransomware campaign,dubbed Avaddon, which was launched on June 2020 in un-derground forums as a Ransomware-as-a-service (RaaS).Since then, Avaddon has been linked to various cyberat-tacks in 2020, and incorporates a recent trend on Ran-somware which is is to publicly ‘blame and shame’ victimsthat do not pay the ransom [15]. At the time of this writ-ing, more than 574GB of data from 23 companies havebeen leaked and exposed online . In addition, Avaddonoperators have recently started to blackmail victims byrunning DDoS attacks. Existing reports described differ-ent technical features of Avaddon [17, 18, 19, 20]. However,as far as the authors know, no public decryption procedureis available to recover files from an infection. We aim atfilling this gap by providing an in-deph analysis of Avaddonand proposing a decryption routine that can decrypt filesin real time, thus minimizing the impact of such attack.In particular, we analyze one of the first variants observedin early June, although the proposed decryption methodis still functional for the latest samples of Avaddon at thetime of this writing. The main contributions of this work For ethical and legal reasons, we have not downloaded norchecked the veracity of the exposed data since otherwise this wouldcause additional harm to users, and such analysis is not of publicinterest for the community [16] are the following:• We analyze the Avaddon business ecosystem and pro-vide an step-by-step analysis of its technical capa-bilities, using advanced static and dynamic analy-sis. This analysis can be generalized to grasp anoverview of how modern ransomware operates, sincetheir modus operandi is similar. As a result of ourstudy, we provide a set of indicators of compromise(IoCs) that may serve security analysts to developfurther tools and countermeasures to detect Avad-don, such as signatures or heuristics.• We showcase a typographical error in the list of ser-vices that Avaddon checks to avoid re-infecting vic-tims, which is also present in modern variants of an-other Ransomware family, i.e., MedusaLocker. Ad-ditionally, we highlight that some similarities on thecode of both families hint that they are operated ordeveloped by the same group.• We describe a method to recover the symmetric keysused for the encryption, thus allowing victims to re-cover the files from infected systems. Accordingly,we present and make publicly available a tool whichcan help victims to recover from these attacks in realtime. While this tool was designed using the analysisof the first versions of Avaddon, we have confirmedthat it still works with the most up-to-date versionsof the ransomware, released in mid-January 2021.The rest of this work is structured as follows. Section 2describes the Avaddon criminal ecosystem and how it op-erates and evolves in the underground economy. Next,Section 3 discusses the results obtained after reverse en-gineering the sample using static and dynamic analysisand provides details of the internals of the ransomware.Section 4 describes the method to recover the session keyused to encrypt the system and describes the remediationtool to decrypt the infected files. We provide experimentalresults in Section 5 by infecting a sandboxed environmentand decrypting the file system with the proposed approach.Finally, we conclude and discuss the implications and lim-itations of this paper in Section 6.
2. Background and related work
In this Section, we first provide background informa-tion about how Ransomware works and existing defensivemechanisms. Then, we present the criminal ecosystem be-hind Avaddon, including its evolution in the undergroundeconomy, and how this has been reflected in the wild, i.e.,leading to real-world cyberattacks.
Ransomware is a type of malware that interrupts thebusiness of the victim or denies access to its data until a2ansom is paid, by means of data encryption. This typeof malware has direct financial implications and has pro-moted the growth of cybercrime, where it is employed asa profitable business model [21].Before the popularization of cryptocurrencies, such asBitcoin, online payment methods were risky for malwareauthors. SMS text messages, pre-paid cards or premiumrate telephone numbers could be traced back easier thanBitcoin [22]. With the use of Bitcoin or other cryptocur-rencies to ask for ransoms, it became much harder to tracethe payments sent to criminals. Still, the characteristicsof some cryptocurrencies allow for tracking transactions(although not connecting them to the attacker). For in-stance, Huang et al. were able to track over $16 millionin likely ransom payments made by 19,750 potential vic-tims during a two-year period [23]. Thus, criminals haveadopted privacy-preserving cryptocurrencies such as Mon-ero that hinder tracking [24]. These cryptocurrencies, incombination with the cybercrime specialization, have pro-moted the ransomware threats as a profitable business forcybercriminals [25].Ransomware detection approaches often leverage clas-sical malware detection methods adopted for ransomware-specific behaviors. In this way, ransomware activities canbe split in 8 stages [26]: fingerprint , propagate , communi-cate , map , encrypt , lock , delete and threaten . Kharaz etal. focused the detection on common tasks performed byransomware, such as changing the desktop wallpaper [27].Some efforts have also been made to capture cryptogra-phy keys at runtime in order to facilitate decryption ofinfected systems [28]. Following recent trends in malwaredetection, some Machine Learning-based approaches havealso been proposed specifically targeting ransomware de-tection [29, 30, 31]. Avaddon is a ransomware that was offered as an affil-iate program on June, 2020 in a Russian underground fo-rum, only accessible by invitation or after the payment of aregistration fee. Concretely, the operators were looking forpartners for their campaign. Additionally, Avaddon waspromoted on other underground forums afterwards. Ac-tors that become affiliates are equipped with both the ran-somware binary and an administration panel from wherethey can control their infections. Access to the programis free and constrained only for reputed (and Russian-speaking) actors. In exchange for this, partners have toshare part of the obtained revenues from the ransomwareto the owners and operators. This share depends on theamount of infections, starting from 35% and decreasing upto 15% for larger volumes. Therefore, affiliates, who are The name of the ransomware, Avaddon, may be derived fromthe Hebrew term Abaddon, the name of an angel of the abyss in theBible, mainly associated with the meaning of “destruction” [18]. Due to ethical reasons, and to avoid promoting the site, we donot provide the name of the forums. only responsible for distributing and installing the mal-ware on infected systems, gain 65% of the revenues gen-erated by the ransomware, without the need of operatingthe payment system [17]. Such distribution often relies onbotnets hired in a Pay-Per-Install scheme [32]. Addition-ally, partners can purchase installs on RDP servers, whichis another popular product traded in underground econ-omy [33]. Thus, the supply chain needed to enter in thisbusiness does not require technical knowledge and it opensthe barrier to any criminal entrepreneur [34]. As a restric-tion in the affiliates program of Avaddon, it is forbiddento target victims in the Commonwealth of IndependentStates (CIS). We describe the mechanism used to achievethis restriction in Section 3.5.A few days after their publication on underground fo-rums (on 2020-06-04 at around 14:00:00 UTC) Avaddonwas observed in the wild. Concretely, it was distributedvia mail in a malspam campaign [19], that consisted inlow-quality phishing emails that attached a malicious file.These emails hinted that a compromising photo of the vic-tim had been leaked, inciting the victim to open the file outof fear. The attached file was a zip-compressed JavaScriptfile. This file tried to masquerade as a JPG photo, havingthe extension “.jpg” just before the “.js” extension (e.g.,“IMG123456.jpg.js”). Upon execution, the malicious filewould download and execute the ransomware. Allegedly,the first wave of this campaign targeted mostly Canada,concretely various education services [19]. However, theirtargets varied later. Indeed, as mentioned before, Avaddonwas launched as a RaaS, which means that the targets arenot chosen by the ransomware developers (apart from theban on CIS victims) but by the affiliates. Upon infectinga system, a ransom note is left to the victim with instruc-tions on how to pay the ransom. The note would lead thevictim to a Tor hidden service, where payment must bedone in exchange for the decryptor. At the time of thiswriting, the payment service is still operative, confirmingthat the campaign is ongoing.Shortly after Avaddon was first seen in the wild, TrendMicro conducted and released a technical analysis [20].The report offers an overview of the ransomware capabil-ities and modus operandi . However, no decryption optionis mentioned (it only indicates how to remove the ran-somware). Regarding the decryption process upon payingthe ransom, some stories from affected users state that itis unreliable and recovery is not ensured [35].Two months after the initial release, on August, 2020,Avaddon was updated to incorporate a new trending tech-nique to their features [36]: extortion to victims. Follow-ing the model from other ransomware campaigns, Avad-don operators decided to threat victims to exfiltrate theirdata, by making it publicly available if they do not pay theransom [37, 38]. By the end of January, 2021, Avaddonhas allegedly infected and leaked full dump data from 20companies (totalling 574.46 GB of data) and is extorting(i.e., threatening of leaking data) 3 other companies whichhave been recently infected. Finally, in January 2021 (con-3urrent to the writing of this paper), Avaddon included anew technique used for extortion: attacking their victimswith Denial-of-Service Attacks [39]. Therefore, the threatto victims is now three-fold, i) data is first encrypted inthe infected systems, so it becomes unavailable, ii) data isleaked publicly if the ransom is not paid, and iii) a DDoSattacks is performed to disrupt their businesses until theransom is paid.At the time of writing, we are not aware of any publicdecrypting tool for Avaddon. Additionally, various reportsand recent complaints from Avaddon victims about theirdecryption support [40, 41] show that the campaign is stilloperative. In this paper, we fill this gap and release anopen-source tool that automatically detects and decryptsfiles, which could be integrated in existing Antivirus solu-tions.
3. Ransomware analysis
In this section, we provide an analysis of the Avaddonransomware, concretely one released as part of their initialadvertising campaign on June 2020. We follow standardtechniques for malware analysis, concretely static and dy-namic analysis. To perform the aforementioned analysis,we utilize popular tools for binary analysis (i.e., BinaryNinja , x64dbg and Pestudio ) and a virtual machineto run the ransomware safely. We build the virtual envi-ronment on top of VirtualBox and install Windows 7 x64in the virtual system.The analyzed binary (MD5: c9ec0d9ff44f445ce5614cc87398b38d ) is a Portable Executable (PE) file. ThePE format describes the structure of executable programsin Windows Operating Systems (OS) [42]. PE files aremainly divided in two important pieces: headers and sec-tions. While headers contain information about the pro-gram itself and data to be read by the OS in order tocorrectly load and execute the program, sections containthe actual code and data of the program. Additionally, wesee that its size is 1.1 MB, so it is not a large program. Fi-nally, we see that the compilation time field of the binaryis set to June, 3, 2020, at 11:47:22 (UTC). Although thisfield is prone to be modified by malware authors in orderto confuse analysts, the timestamp is similar to the time ofthe first appearances of Avaddon samples [17], which con-firms that we are indeed analyzing one of the first versionsof Avaddon.We describe the packing protections of the analyzedbinary in Section 3.1. Next, we show the imported func-tions and the extracted strings in Sections 3.2 and 3.3, re-spectively. In Section 3.4, we show the anti-analysis tech-niques employed by the binary. Then, we show how the https://binary.ninja/ https://x64dbg.com/ ransomware authors implemented a protection to not in-fect Commonwealth of Independent States (CIS) victimsin Section 3.5 and analyze the privilege escalation tech-niques, step by step, in Section 3.6. The details of thepersistence mechanism are showcased in Section 3.7. Fol-lowing, interactions with other processes and services arepresented in Section 3.8. Finally, we expose the cryptogra-phy mechanisms used in the last two sections, concretelykey management (Section 3.9) and file encryption (Section3.10). Looking at some properties of the PE file, we concludethat the sample is not packed. First, we find that the PEfile contains 4 sections which have almost no differencesin size between disk and memory. This in an indicator ofthe PE file not being packed, since the presence of a vir-tual section (i.e., a section that requests space in memorybut does not occupy bytes in disk) is a common indicatorof packing protections. Then, we find over 200 importedfunctions and several meaningful strings, which presentsome useful information about the capabilities of the ran-somware. Often, packing protections attempt to hide im-ports and strings in order to difficult analysis. Finally,the entropy levels of the PE file are not high enough tohint the presence of a packer. The highest entropy level isreached in the “.text” section, whose entropy value is 6.62.However, this does not confirm the existence of packed orencrypted code, which often have values ranging from aminimum of 6.677 to a maximum of 6.926 [43].
The Windows OS offers an Application ProgrammingInterface (API) which abstracts many functionalities fromdevelopers, e.g to interact with files, processes, etc. Thisalso provides an abstraction layer regarding the underly-ing hardware. In order to call those functions, programsneed to know their location in memory. This need may befulfilled in different ways, but the most common methodconsists on importing the required functions prior to exe-cution. This is done by the OS loader before transferringcontrol to the program. To do so, the PE file contains anImport Address Table (IAT) in the headers, which includesa list of functions to be imported by the OS loader. Whenthe file is executed, the OS loads the file in memory andfills the IAT with the addresses of each requested function.Then, the program is able to call those functions becauseit now knows where each of these functions is allocated inmemory. Therefore, the IAT provides useful informationabout the capabilities and intentions of the program. Thefunctions imported by the Avaddon sample analyzed showcommon capabilities of ransomware, such as encryption(e.g.,
CryptGenKey or CryptEncrypt ), persistence (e.g.,
RegCreateKeyW , StartServiceW ), anti-analysis (e.g.,
Is-DebuggerPresent ) or activity control (e.g.,
DeleteService or TerminateProcess ).4 .3. Strings
Looking for strings through a PE file allows analysts toidentify capabilities of the binary, as well as looking at theIAT. Indeed, some imports will appear when searching forstrings if they are imported by name (external functionsmay be imported by name or ordinal [42]). Therefore, weproceed to extract all readable strings that have more than4 characters in the whole file. Then, we filter the extractedstrings and exclude those that are not meaningful (bytesthat are part of code may non-intentionally form readablestrings that are not meaningful). In this case, as aforemen-tioned, we find enough meaningful strings to think that thePE file is not packed. Many of the strings found were pathsto folders or files (e.g., “
C:\Temp ”). While we initially cannot know the actual purpose of those files, we hypothesizethat some of them may be used to drop additional pay-loads or to move the PE file upon infection to a differentlocation (we confirm this hypothesis in Section 3.7).Among the strings that are present in the PE file, weobserve two of them that refer to cryptography providers(i.e., “
Microsoft Enhanced Cryptographic Provider v1.0 ” and “
Microsoft Enhanced RSA and AES Cryptographic Provider ”). These strings are normally used to acquirecryptography contexts using the Windows API, which arelater needed to perform some cryptography operations.Additionally, some strings indicate that the ransomwarewas developed in C++. C++ is an object-oriented lan-guage. Although this characteristic does not provide anyinformation about the capabilities of the sample, the par-ticularities of C++ programs must be taken into accountin the analysis process. We will highlight some C++ prop-erties that allow us to extract conclusions in the reverseengineering process, but discussing the differences betweenC++ and other languages at assembly level is out of thescope of this work. For more information, we refer to Sa-banal et al. [44].Interestingly, we find many strings that are Base64 en-coded. However, upon decoding them, no legible stringis recovered. Therefore, we suspect that these strings areobfuscated by other means (i.e., encoding or encryption)in order to hide their content. This is a common mecha-nism in malware samples. In such case, those strings maybe of importance to understand additional capabilities ofthe malware that may not be retrieved without furtheranalysis. We thus confirm that these strings are indeedencrypted and are only decrypted at runtime on demand,i.e., when they are required by the program. First, globalvariables are created to hold the encrypted strings, mak-ing them accessible from every function in the binary. InAlgorithm 1, we show one of the functions (0x4012a0 inthis case) that creates a global variable pointing to an en-crypted string. There, the encrypted string and its size arepushed onto the stack (lines 1-2). Then, a global variableis created at 0x4f8a28 with the content of the encryptedstring (lines 3-4). Finally, a destruction function is regis-tered (lines 5-6). This function will be called when the pro-cess exits. The global variable is then referenced wherever this particular string is needed in the program, and eachencrypted string has its own initialization function. Thesefunctions are the constructors of the global variables. Weknow that these are global variables in the source codebecause:1. There is one global variable per encrypted string andone constructor function for each global variable.2. Each global variable has a predefined address. Theseaddresses are hardcoded in each constructor func-tion.3. After initializing the global variable, a destructorfunction is registered to be called upon terminatingthe program.
Algorithm 1:
One of the functions responsiblefor initializing a global variable with the value ofan encrypted string. // Size of the encrypted string // Encrypted string // Global variable // Creates a global variable at ecx(0x4f8a28 in this case) with the stringstored at the value previously pushed(0x49e180 in this case) // Destructor // Register the destructor function to becalled when the process ends CommandLine = DecryptString(GlobalVariable);CreateProcess(CommandLine);
The decryption function is located at address 0x40c780.First, the received string is decoded from Base64. Then,5 lgorithm 2:
Decryption of a global variableinto a temporary register. // Global variable that contains anencrypted string // Local variable that will hold thedecrypted string // Decrypts the string at edx (the globalvariable) and stores the result in ecx(the local variable) // eax now contains the decrypted string(it is equal to [esp+0x8], the localvariable) which, in this case, is acommand line // Creates a process with the command linereceived as argument as shown in Algorithm 3, each character is decrypted bysubstracting 2 units from its value (line 3) and XOR-ingthe result with 67 (line 5). These instructions are executedonce for every character in the string. Algorithm 3:
Characters decryption. // Move the current character to al (thelower 8 bits of eax) // Substract two units from the character // XOR the result with 0x43 Binary Ninja tool in ourpublic repository . Successfully infecting a system critically depends onnot being detected. Thus malware authors often imple-ment different techniques to evade antivirus systems or https://github.com/JavierYuste/AvaddonDecryptor sandboxes. Additionally, mechanisms are frequently put inplace in order to delay analysts and, therefore, incrementthe time needed for building detection tools for the sample(e.g., signatures). In the case of Avaddon, the binary is notpacked, which is a common obfuscation technique. How-ever, we observe other anti-analysis techniques, describednext. String obfuscation . As mentioned in prior sections,various of the strings are encrypted, which may hide im-portant functionality. This technique is commonly used to:i) evade detection, and ii) delay analysts. See Section 3.3for a detailed description of this obfuscation technique andthe process used to decrypt the strings.
Anti-debugging . We found a call to
IsDebuggerPre-sent at offset 0x42e03d. Debuggers are programs designedto analyze other programs at runtime (i.e., processes), andare used by security analysts to dynamically inspect mal-ware. Hence, malware authors often embed code in theirprograms that checks for debuggers and, if detected, ter-minates the process or changes their behavior. In par-ticular,
IsDebuggerPresent is a function provided by theWindows API. If a debugger was attached to the program,this function would return true and the binary would exit.To circumvent this protection, we consider two options:1. Hook the call to
IsDebuggerPresent so it always re-turns false. By doing this, we bypass any check doneby the malware, changing the code on the fly, andthe debugger would not be detected by the sample.2. Change a binary value in the the Process Environ-ment Block (PEB), a data structure that holds infor-mation about the process. That structure is built bythe OS when executing the program and is uniqueper process. Among other information, it contains abit that indicates if a debugger has been attached.When a call to
IsDebuggerPresent is made, it re-turns the value of that bit. Therefore, changing thevalue in the PEB would successfully hide the debug-ger from that call and from any manual checks (thePEB may also be walked through manually by pars-ing its structure).In order to avoid further anti-debugging mechanismsthat may parse the PEB (i.e., not using
IsDebuggerPre-sent ), we decided to implement the second option.
To avoid infecting systems in some countries, it is fre-quently observed that malware binaries implement tech-niques to check the country where the infected machineis located, so as to ensure that citizens from some regionsare not affected. It is common to see that CIS victimsare dodged in many malware samples, as it is the casefor this one. The most popular approach is to check forthe keyboard layouts and the OS language. In this sam-ple, we found both checks for different layouts and lan-guages (addresses 0x42e0ec and 0x42e0b6, respectively).6n particular, we discovered checks for language locales(i.e., Russian and Ukrainian) and keyboard layouts (i.e.,Russian, Sakha, Tatar and Ukrainian). If any of thesekeyboard layouts or OS locales is found, the binary exitswithout harming the landed system. That is, this sam-ple of Avaddon ransomware is designed to avoid infectingRussian and Ukrainian systems. This, together with thefact that the malware was first advertised in a Russian un-derground forum, provides strong (though not conclusive)evidence that the origin of the malware is Russia.
Malware authors often spend great resources in orderto infect systems, e.g. to gain initial access and evade de-tection by AV software. However, having invested so mucheffort in those tasks, their immediate post-infection activi-ties might fail due to the need for administrator privilegesif the user becomes suspicious after being requested to con-cede those privileges. Therefore, reducing the number ofclicks needed from the victim is critical. Indeed, malwareactions usually require administrator privileges in the in-fected system to accomplish some critical tasks (e.g., ac-quire persistence, infect system files or processes, etc.). Inthis particular case, escalating privileges is critical becausethe ransomware needs to i) acquire persistence throughregistry keys (Section 3.7), ii) stop processes and services(Section 3.8), and iii) delete backups (Section 3.10).The process implemented to elevate privileges in Avad-don is a well known User Account Control (UAC) bypass.Indeed, there are public open-source implementations [45]and it is not uncommon to find this technique in differentmalware families [46, 47]. Next, we briefly summarize thisprocess and how it is implemented in Avaddon. First, threeregistry keys are added or modified (at offset 0x40ed20).Concretely, these keys are:1.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System EnableLUA=0 (disables the “administrator in Admin ApprovalMode” user type [48])2.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System ConsentPromptBehaviorAdmin=0 (this option allows the Con-sent Admin to perform an operation that requireselevation without consent or credentials [49])3.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System EnableLinkedConnections=1 (makes user mapped drivesavailable to the administrator versions of those users[50])The first two registry key values allow the sample toelevate privileges without alerting the user, and the thirdenables the access to volumes of the current user whenadministrator privileges are acquired.Then, the sample checks its privileges (offset 0x41a5c0).If it has administrator privileges, it continues its execution without running the rest of the UAC bypass. Otherwise,administrator privileges are obtained by running the fol-lowing procedure (implemented at 0x40ef90):1. First, a class ID (CLSID) is decrypted. This CLSIDwas stored in the binary as an encrypted string, aswe described in Section 3.3. The decrypted valueis “ {3E5FC7F9-9A51-4367-9063-A120244FBEC7} ”,which corresponds to CMSTPLUA. For the rest ofthis section, we refer to it as CLSID_CMSTPLUA.2. Next, an IID is decrypted in the same way, obtainingthe value “ {6EDD6D74-C007-4E75-B76A-E5740995E24C} ”. For the rest of this section, we refer to it asIID_ICMLuaUtil.3. Then, a third string is decrypted, which contains thevalue “
Elevation:Administrator!new: ”.4. Once the three strings have been decrypted, a newstring is built by concatenating “
Elevation:Administrator!new: ” and CLSID_CMSTPLUA.5. Next, the execution calls the function
CoGetObject in order to obtain a pointer to CMLuaUtil. The pa-rameters of the call are as follows:
CoGetObject( “ Elevation:Administrator!new:{3E5FC7F9-9A51-4367-9063-A120244FBEC7} ” , 0x24, &IID_ICMLuaUtil, &CMLuaUtil) At this point, user interaction might be needed togrant administrator privileges for the program insome systems. In some cases, this might be ac-companied by social engineering techniques, e.g. in-structions accompanying the phishing email wherethe malware is attached. In this case, we have notobserved any particular behavior.6. If the call is successful, CMLuaUtil now points toa structure that contains the address of a functionnamed
ShellExec (CMLuaUtil −→ lpVtbl −→ ShellExec).7. After obtaining the absolute path of the malware PEfile (via a call to
GetModuleFileNameW ) the binaryexecutes itself with administrator privileges by call-ing
ShellExec with the following parameters:
ShellExec(CMLuaUtil, “ C:\[...]\sample.exe ” , [...]) In order to survive across reboots, malware samplesmust be run automatically on infected systems after theinitial foothold has been obtained [51]. Otherwise, theywould need to infect the system again if further runs arerequired. In order to achieve persistence in the system,there exist many approaches. Usually, malware authors ac-quire persistence by adding registry keys, creating servicesor registering scheduled tasks. By doing so, the malwaresample is automatically run by the OS (e.g., at scheduledtimes or at every reboot). Additionally, malware sam-ples often implement mechanisms to prevent re-infection7f already-infected systems, thus to minimize the risks ofdetection or to prevent disruption of previous runs.By looking at the imported functions (see Section 3.2)we hypothesize that persistence may be acquired via reg-istry keys or services. Then, using dynamic analysis weconfirm that persistence is obtained by adding two reg-istry keys. Upon inspecting the code of the binary, welocate the function responsible for acquiring persistence ataddress 0x40cf50. The only purpose of this function is toadd the following registry keys:•
HKU\S-1-5-21-2724635997-1903860598-4104301868-1000\Software\Microsoft\Windows\CurrentVersion\Run\update: "C:\Users\%UserProfile%\AppData\Roaming\%sample%.exe" • HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run\update: "C:\Users\%UserProfile%\AppData\Roaming\%sample%.exe"
With those registry keys in the system, the PE file isexecuted at each system reboot (notice that a copy of thesample is dropped at runtime in "C:\Users\%UserProfile%\AppData\Roaming\%sample%.exe" , where “ %sample% ”is the name of the PE file). To avoid re-infecting a systemmore than once, a mutex is created with the value {2A0E9C7B-6BE8-4306-9F73-1057003F605B} . If this mutex isalready present in the system, the binary exits and doesnot encrypt files. In addition, the ransomware takes mea-sures to avoid encrypting already encrypted files, as wedescribe in Section 3.10. Thus, having mechanisms to pre-vent re-infection of a machine might be to avoid reinfectingvictims that have already payed a ransom. Nevertheless,the fact that the presence of such mutex is checked allowsto prevent Avaddon infections. By creating such mutex ina healthy system, Avaddon ransomware samples will notexecute, acting as an Avaddon vaccine. However, not ev-ery sample of Avaddon uses the same mutex, as it maychange among versions.
In order to avoid being detected or neutralized, somemalware samples try to stop anti-malware solutions. Inorder to do so, administrator privileges must be acquired.However, it is often easier to acquire administrator privi-leges without being detected than to encrypt the whole filesystem without rising awareness. In Section 3.2, we high-lighted that the PE file imported some functions that mayindicate an attempt to control some anti-malware solutionsby interacting with services and processes. Additionally,before attempting to encrypt files, it is important to stopprocesses that may be locking some files. For instance,ransomware authors may look to stop database processesthat may be locking database files.In this case, we find two functions (located at offsets0x41a8f0 and 0x40c990 of the sample) that try to stop alist of services and processes, respectively, if found in the system. As expected, among those lists, we have foundanti-malware solutions (e.g., “DefWatch”) and databases(e.g., “sqlservr”).We notice that the name of one of the services is mis-spelled. Concretely, “vmware-usbarbitator64” is missingan ‘r’ (and should instead be “vmware-usbarbitrator64”).This typographical error was found in other ransomwarefamily, MedusaLockker. This indicates that developersreuse code from other families [52, 53]. We are unaware onwhether this is due to the same actor developing both fam-ilies, or due to code reuse from one to another (though wehave found no evidence of the source code of MedusaLockerbeing leaked). Indeed, we notice that the Tactics, Tech-niques and Procedures (TTPs) of Avaddon are very similarto those of MedusaLocker if we compare our analyses withthe report on MedusaLocker from Carbon Black’s ThreatAnalysis Unit [52]. This is an interesting fact regarding theattribution of this campaign which might require furtherinvestigation if future families share this peculiarity.
One of the most critical parts of a ransomware cam-paign is the encryption process. The keys used, how theyare imported or generated, how they are exported, the en-cryption algorithm chosen, etc., are important decisionsfor malware developers. An error in this process mayallow analysts to develop measures to recover encryptedfiles, completely neutralizing the campaign revenues. Inthis case, two keys are used in the encryption process in aso-called hybrid scheme. One key (the session key) is ran-domly generated in each execution and used to encryptthe files in the system. This key is used in a symmet-ric encryption scheme, AES256. Therefore, the same keymust be used to decrypt the affected files. The secondkey is a public one, part of an asymmetric scheme, RSA1.This key is imported (it is present in the PE file) and usedonly to encrypt the previously generated key. Therefore,the session key can only be decrypted by the malware au-thors, since the private key of the asymmetric scheme isonly known by them.The whole process that we described in the previousparagraph is split in three functions in the PE sample.These functions, responsible for key management, are lo-cated at offsets 0x413600, 0x413a60 and 0x413f50 respec-tively.
Public key import.
The function at 0x413600 is responsi-ble for importing the public key. The import is made bycalling the Windows API function
CryptImportKey withthe following parameters:
CryptImportKey(hProv:CSP, pbData: Key to be imported, dwDataLen: Length of the key, hPubKey: 0, dwFlags: 0, phKey: Handle to the imported key afterthe call) hPubKey must be equal to 0 when the key to beimported is a public key (a
PUBLICKEYBLOB object).This detail indicates that the imported key is actually thepublic one of the pair.
Generated key.
After importing the public key, a randomkey is generated. This randomly generated key (the ses-sion key) is used to encrypt the files of the system later,using an AES256 scheme. The function responsible of gen-erating the session key is the one located at 0x413f50. Togenerate it, a function from the Windows API is called,
CryptGenKey , with the following parameters:
CryptGenKey(hProv: CSP, Algid: CALG_AES_256, dwFlags: CRYPT_EXPORTABLE, phKey: Handle to the generated key after the call)
The parameter
Algid indicates that the generated keyis to be used in AES256. Additionally, notice that the flagspassed to the function indicate that the key must be ex-portable. Once the key has been generated, it is exportedand encrypted using the previously imported RSA1 key.The result is then included in the ransom note, in order toallow the ransomware operators to recover the encryptionkey and provide a decryption tool to those victims thatdecide to pay a ransom.
Keys destruction.
Finally, the function located at 0x413f50is the one responsible for securely destroying the keys.This function will destroy the public RSA1 key and thegenerated AES256 key. The purpose of this function isto ensure that they do not remain in memory after beingused. However, this function is only called when the pro-cess exits, which only occurs when the infected system isshutdown (the ransomware process remains active to alsoencrypt new files). Therefore, the session key is never de-stroyed if the system is not powered off. This is a mistakefrom the malware perspective since, as long as the com-puter remains active, the key is kept in memory and thuscan be retrieved using basic forensics techniques. In Sec-tion 4, we will take advantage of this detail to describe andpresent a tool to recover the symmetric key generated anddecrypt all the affected files.
In Section 3.9, we presented the mechanism used togenerate the key used to encrypt files. Additionally, weshowed that the algorithm used to encrypt files is AES256,a symmetric encryption scheme. In this Section, we willdescribe the process followed to encrypt files in the infectedsystem.The first step performed by the ransomware is to deletebackups so the original files cannot be restored by locallysaved security copies. To achieve that goal, the functionat 0x41a800 executes the following processes: • wmic.exe SHADOWCOPY /nointeractive • wbadmin DELETE SYSTEMSTATEBACKUP • wbadmin DELETE SYSTEMSTATEBACKUP -deleteOldest • bcdedit.exe /set {default} recoveryenabled No • bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures • vssadmin.exe Delete Shadows /All /Quiet In order to successfully execute those processes, admin-istrator privileges are needed, which were obtained usingthe procedure that we described in Section 3.6. Finally,the contents of the recycle bin are deleted by calling theWindows API function
SHEmptyRecycleBinW .Next, files are encrypted following a depth-first searchapproach. Microsoft SQL and Exchange folders are priori-tized, being the first ones to be encrypted. Then, the rootpath is encrypted (i.e.,
C:\\* ). Finally, shared folders andmapped volumes are enumerated and encrypted (e.g.,
D:\\* , Y:\\* , or \\VBoxSvr\\shared_folder\\* ). There-fore, the order in which folders are encrypted, following adepth-first approach, is the following:1.
C:\\Program Files\\Microsoft\\Exchange Server\\* C:\\Program Files (x86)\\Microsoft\\ExchangeServer\\* C:\\ProgramFiles\\Microsoft SQL Server\\* C:\\Program Files (x86)\\MicrosoftSQLServer\\* C:\\*
6. Shared folders and mapped volumesFor each file encountered, the process performs threechecks before the actual encryption.1.
Strings from a whitelist . The path is checkedto not contain specific strings (see Appendix 6 forthe list of skipped strings). If the absolute path ofthe file contains one of those strings, the file is leftuntouched. This check is excluded for the first fourfolders searched, those that belong to Microsoft SQLand Exchange servers. Therefore, this check is ap-plied only to searches initiated at the root folder (i.e.,C:\\*) or shared folders and mapped volumes.2.
File extensions . The extension of the file is checked.The extensions that are excluded (not encrypted) arethe following: bin , ini , sys , dll , lnk , dat , exe , drv , rdp , prf , swp , mdf , mds and sql .3. Prevent re-encryption . The third test checks ifthe file has already been encrypted by Avaddon. Todo so, a signature at the end of the file (that is leftafter encrypting a file by the ransomware, as we will9escribe later in this section) is read. In particu-lar, the last 24 bytes of the file are read. If the filehas been previously encrypted, it should contain thehexadecimal values 0x200 and 0x1030307 at offsets8 and 16 in those 24 bytes.If none of these checks is positive then the file is en-crypted. The encryption process is done by the functionlocated at virtual address 0x413bb0. This function re-ceives a copy of the AES256 key (see Section 3.9) and thename of the file to be encrypted. We present a high-levelpseudo code (some function signatures have been simpli-fied to avoid using pointers) extracted from the analyzedfunction in Algorithm 4. First, the size needed for thebuffer to hold the bytes after encryption is calculated (line1). Then, the file contents are read in chunks of 0x100000bytes (line 5) and encrypted in blocks of 0x2000 bytes(lines 8-9). However, although there exists a loop to readand encrypt the whole file, only the first 0x100000 bytesare encrypted. This is due to the last call to
SetFilePoint-erEx , which sets the file pointer to the end of the file (line18). When there are only 0x2000 or less bytes left to beencrypted (line 13), the last chunk of bytes is encrypted(lines 14-15) and written to the file (line 16). Notice thatthe parameter
Final (line 15) in the call to the encryptionroutine is always set to
False . This parameter should be
True if the block to encrypt is the last block of the file.We will need to take this detail into account in Section 4.Finally, 512 unused bytes and the signature are written atthe end of the file to mark it as encrypted (lines 20-22)Therefore, the process is summarized as:1. Calculate the size of the buffer needed to hold anencrypted block of 0x2000 (8192) bytes.2. Obtain the size of the file.3. Encrypt the first 0x100000 bytes of the file in blocksof 0x2000 (8192) bytes.4. Write the victim ID (512 bytes) and the signature(24 bytes) at the end of the file.Here, we show an example of a signature written at theend of an encrypted file and highlight its different fields:4E 4D 00 00 00 00 00 00 00 02 00 00 01 00 00 0007 03 03 01 01 01 E2 02First, in orange, the original length of the file is written(0x4e4d or 20045 bytes in this case). Then, a hard-codedmagic number is written at offset 16 (cian). This value ischecked prior to encrypting a file, as we discussed earlierin this section.
4. Decryption of infected systems
In Section 3.9, we described the functions responsi-ble for importing, generating and destroying the crypto-graphic keys needed by the ransomware. As we pointed
Algorithm 4:
Function responsible for encrypt-ing files.
Input:
File , file to be encrypted
Key , a duplicate of the AES256 key buffer_size ← CryptEncrypt(hKey: Key, Final:False, pbData: 0, pdwDataLen: 0x2000); file_size ← GetFileSizeEx(hFile: File); file_pointer ← do bytes_read , number_of_bytes_read ← ReadFile(hFile:
File , offset: file_pointer ,nNumberOfBytesToRead: 0x100000); i ← do bytes_to_encrypt ← bytes_read[i:i+0x2000] ; // The file is encrypted in blocksof 0x2000 bytes encrypted_bytes ← CryptEncrypt(hKey:
Key , Final: False, pbData: bytes_to_encrypt ); WriteFile(hFile:
File , lpBuffer: encrypted_bytes ); i = i + 0x2000; while i ≤ number_of_bytes_read - 0x2000 ; if number_of_bytes_read - i < then bytes_to_encrypt ← bytes_read[i:] ; encrypted_bytes ← CryptEncrypt(hKey:
Key , Final: False, pbData: bytes_to_encrypt ); WriteFile(hFile:
File , lpBuffer: encrypted_bytes ); end file_pointer ← SetFilePointerEx(hFile:
File ,liDistanceToMove: , dwMoveMethod: FILE_END ) ; // This call sets the file pointer tothe end of the file. This is doneto stop processing more bytes fromthe file while number_of_bytes_read ≥ < file_size ; WriteFile(hFile:
File , lpBuffer:
VictimID ); // The Victim ID is written to the end ofthe file signature ← GetSignature(); WriteFile(hFile:
File , lpBuffer: signature ); // The signature is also written at theend hCryptProv , pointsto the provider of the key and the functions (this providermust be first acquired before the key is generated via CryptAcquireContext or a similar function). Finally, thelast field points to another structure. This pointer is XOR-ed with a constant value, 0xE35A172C. Therefore, afterXOR-ing the pointer with that magic constant, it pointsto the following structure:struct magic_s{ key_data_s *key_data;}; which contains a pointer to the following structure:struct key_data_s{ void *unknown;uint32_t alg;uint32_t flags;uint32_t key_size;void* key_bytes;}; The key_data_s structure contains three fields whosevalues are known:• alg contains the algorithm ID of the algorithm forwhich the key has been generated. In this case, thevalue of this field is 0x00006610, which correspondsto AES256 [56].• flags contains the value of the flags parameter passedin the call to
CryptGenKey at 0x48f024. Therefore,its value is 0x00000001.• key_size , as it name hints, contains the size of thekey. In this case, the key is 32 bytes long (0x00000020).Finally, the fifth field contains a pointer to the actualkey. Since we know the value of 24 of the last 28 bytes thatform the structure (skipping the first field) we can searchfor this 28-byte pattern in the memory of the process. Wethus are able to obtain a pointer to the generated key thatwas used to encrypt the files and finally the key itself. Werecall that the only requisite is that the system has notbeen powered off since it was infected, in order to maintainthe key in memory.Now that we have the symmetric key generated by theransomware, we are able to decrypt the infected files. How-ever, to do so we need to implement the reverse operationthan the one performed by the ransomware (see Algorithm4). To decrypt any given file, we first parse the signatureat the end of the file. There, we obtain the original size ofthe encrypted file. Then, we truncate the file to eliminateboth the signature and the block of 512 bytes appended atthe end of the file by the ransomware (536 bytes in total,since the signature is 24 bytes in length). Once we havethe truncated file, we proceed to decrypt the first 0x100000bytes in blocks of 8192 (0x2000) bytes. Notice that, as weshowed in Algorithm 4, the
Final parameter in the
Cryp-tEncrypt calls was never set to
True . According to thedocumentation, this parameter should be
True when thelast block is encrypted. Although we do not know if thisnonstandard behavior is intentional or not, we are forcedto do the same in the decryption routine. Therefore, wealways set the Final parameter to be False in the calls to
CryptDecrypt . Then, we copy the rest of the file as is.Finally, if the file was smaller than 0x100000 bytes, wetruncate it once again, now to the original size recoveredearlier from the signature appended at the end, to removethe padding bytes.11btaining a memory dump of a process can be done bystandard forensic tools. Therefore, we open source the toolto recover the symmetric key from memory and decryptthe infected files: https://github.com/JavierYuste/AvaddonDecryptor .
5. Experimentation
We test our proposal in a virtual environment runninga Windows 7 x64 OS. In particular, we build this virtualmachine on top of a virtualization solution named Virtu-alBox in a 1.60 GHz Intel Core i5-8250U CPU with 16 GBRAM computer. From the available hardware, we assign2 cores and 4 GB of RAM to the aforementioned guestsystem.Then, we execute Avaddon on the virtual machine andlet it encrypt the whole system. When Avaddon has notutilized more than 0.5% of the CPU time in the last 60seconds, we understand that it has finished encrypting filesand confirm the infection due to the presence of ransomnotes and encrypted files through the whole file system.After infecting the virtual machine, we proceed to de-crypt all the affected files. First, we pause the ransomwareprocess with Process Explorer, a tool from the SysInter-nals suite . Note that we can freely drop executable filesin the system before stopping Avaddon, since the exe ex-tension is excluded. Once the process is suspended, wecan safely operate in the infected system. Next, we dumpthe memory of the ransomware process with ProcDump,which is also part of the SysInternals suite. Finally, we ex-ecute the proposed decryption tool, which we open source.This tool i) confirms the infection by extracting the sig-nature appended at the end of encrypted files, ii) obtainsthe AES256 symmetric key from the dumped memory ofthe ransomware process iii) and decrypts the whole filesystem.We show the results in Table 1. From 209,186 files thatwere present in the whole system, we found that 9,135(4.3%) were encrypted, making a total of 607 MB. Ourproposed tool successfully decrypted all the affected filesin 10 minutes and 35 seconds. Additionally, we have testedour tool with the most recent version of Avaddon, whichwas observed from a wild URL on mid-January 2021, whenthis paper was written. We confirm that the decryptor stillworks, since we were able to decrypt all the infected files.We must note some considerations. First, it is impor-tant to not turn off the computer after infection, since theproposed approach needs the encryption key to be presentin memory. Otherwise, this would be destroyed and couldonly be recovered by means of the official channel pro-posed by the criminals, i.e. paying the ransom. Second,the proposed tool needs the original version of at least oneencrypted file to find the correct symmetric key. This,however, can be easily achieved, e.g. by obtaining known https://docs.microsoft.com/en-us/sysinternals/ Files in the system 209,186Files encrypted by Avaddon 9,135Total size of files in the system 46.85 GBTotal size of encrypted files 607 MBTime spent decrypting files 558.54 sTotal time 635.63 s
Table 1: Results of the experimentation in a virtual environment. files present by default in the Windows OS version installedin the affected system.
6. Conclusions
Current approaches of cybercrime specialization, in-cluding new malware techniques, increase the threat ofmodern ransomware campaigns. In this work, we have an-alyzed a new ransomware, Avaddon, operated as a RaaS ina shared profit scheme, first seen on June 2020. Avaddonincorporates two techniques aimed at increasing their fi-nancial revenues which are growing in popularity: i) threat-ening victims that do not want to pay the ransom fee toleak personal data from infected systems, and ii) conduct-ing DDoS attacks against them. Data leakage have af-fected at least 23 organizations whose information is al-legedly exposed online. While having proper attributionis difficult, our analysis suggests that the threat actor be-hind Avaddon is from a CIS country. Indeed the initialannouncement of the ransomware was made in a Russianunderground forum, and it implements a policy to preventinfection of CIS-based victims. Moreover, a typographicerror found in one of the processes fingerprinted by Avad-don suggest that this family is related with a previous ran-somware, i.e. MedusaLocker, where the same error is alsopresent. Indeed, the modus operandi of Avaddon, that wedetailed in this work, is similar to that of MedusaLocker[52] and the list of services to stop is almost identical inboth cases.By examining a sample obtained from the first cam-paign of Avaddon and describing its behaviors, we tooka grasp on the general “Cyber Kill Chain” of ransomwarethreats (land, escalate privileges, deactivate defenses, ac-quire persistence, delete backups and encrypt files) and adetailed analysis of this ransomware in particular. Usingan hybrid scheme, Avaddon attempts to hide the sessionkey from defenders. However, due to the way in whichcryptography keys are managed in this ransomware, wehave developed a tool to recover the session key from thememory of the infected systems and decrypt all the af-fected files. The decryption tool also works with newervariants of the ransomware. The only requirement for thismethod to work is that the victim’s computer is not pow-ered off after the infection.Due to novelty of the ransomware, the business modelin terms of an affiliate program, and the ability to extortionand blackmail victims (by means of exfiltration and DDoS12ttacks), it is likely to expect new variants of Avaddon andsimilar ransomware samples improving their mechanismsand expanding in the future. Thus, we believe that theanalysis and tools provided in this paper can contributeto guide future analyses of such variants and to improveexisting mitigation mechanisms.
Acknowledgements
This work was supported by the Comunidad de Madrid(P2018/TCS-4566, co-financed by European Structural FundsESF and FEDER).
References [1] T. C. of Economic Advisers, The Cost of Malicious Cyber Ac-tivity to the U.S. Economy, , [Online; accessed 28-September-2020] (2 2018).[2] B. Collier, R. Clayton, A. Hutchings, D. Thomas, Cybercrimeis (often) boring: maintaining the infrastructure of cybercrimeeconomies, 2020, workshop on the Economics of InformationSecurity, WEIS ; Conference date: 14-12-2020 Through 15-12-2020.[3] National Intelligence Officer, A Guide to Cyber Attri-bution, , [Online; accessed 09-October-2020] (9 2018).[4] Infosec, The Attribution Problem in Cyber Attacks, https://resources.infosecinstitute.com/attribution-problem-in-cyber-attacks/ , [Online; accessed 09-October-2020] (2 2013).[5] K. Huang, M. Siegel, S. Madnick, Systematically understandingthe cyber attack business: A survey 51 (4).[6] S. Pastrana, A. Hutchings, A. Caines, P. Buttery, Character-izing eve: Analysing cybercrime actors in a large undergroundforum, in: International symposium on research in attacks, in-trusions, and defenses, Springer, 2018, pp. 207–227.[7] PandaLabs, PandaLabs Reveals its Predictions for Cyber-security Trends in 2018, , [Online; accessed 28-September-2020] (112017).[8] R. Van Wegberg, S. Tajalizadehkhoob, K. Soska, U. Akyazi,C. H. Ganan, B. Klievink, N. Christin, M. Van Eeten, Plug andprey? measuring the commoditization of cybercrime via onlineanonymous markets, in: 27th { USENIX } security symposium( { USENIX } security 18), 2018, pp. 1009–1026.[9] Auld, Andy, What’s behind the increase in ransomware attacksthis year?, , [Online; accessed 03-October-2020] (2020).[10] S. Ghafur, S. Kristensen, K. Honeyford, G. Martin, A. Darzi,P. Aylin, A retrospective impact analysis of the wannacry cy-berattack on the nhs, NPJ digital medicine 2 (1) (2019) 1–7.[11] The CrowdStrike Intel Team, Double Trouble: Ran-somware with Data Leak Extortion, Part 1, , [Online; accessed 28-September-2020] (9 2020).[12] Panda security, Ransomware has a new trick: pay up or suffera data breach, , [Online; ac-cessed 28-September-2020] (3 2020). [13] C. Cimpanu, Conti (Ryuk) joins the ranks of ran-somware gangs operating data leak sites, , [Online;accessed 28-September-2020] (8 2020).[14] M. J. Schwartz, Ransomware + Exfiltration + Leaks= Data Breach, , [On-line; accessed 28-September-2020] (7 2020).[15] Intel471, Ransomware-as-a-service: The pandemic within apandemic, https://intel471.com/blog/ransomware-as-a-service-2020-ryuk-maze-revil-egregor-doppelpaymer/ ,[Online; accessed 18-December-2020] (2020).[16] D. R. Thomas, S. Pastrana, A. Hutchings, R. Clayton, A. R.Beresford, Ethical issues in research using datasets of illicit ori-gin, in: Proceedings of the 2017 Internet Measurement Con-ference, IMC ’17, Association for Computing Machinery, NewYork, NY, USA, 2017, p. 445–462. doi:10.1145/3131365.3131389 .URL https://doi.org/10.1145/3131365.3131389 [17] S. Tripathi, Avaddon Ransomware, , [Online; accessed 22-September-2020] (6 2020).[18] A. Ivanov, Avaddon Ransomware, https://id-ransomware.blogspot.com/2020/06/avaddon-ransomware.html , [Online;accessed 14-October-2020] (6 2020).[19] H. Security, Avaddon: From seeking affiliates to in-the-wildin 2 days, , [Online; accessed 23-August-2020] (6 2020).[20] M. Malubay, Ransom.Win32.AVADDON.YJAF-A, , [Online; accessed22-September-2020] (6 2020).[21] R. Brewer, Ransomware attacks: detection, prevention andcure, Network Security 2016.[22] K. Zetter, What Is Ransomware? A Guide to the GlobalCyberattack’s Scary Method, , [Online; accessed 16-October-2020] (5 2017).[23] D. Y. Huang, M. M. Aliapoulios, V. G. Li, L. Invernizzi,E. Bursztein, K. McRoberts, J. Levin, K. Levchenko, A. C.Snoeren, D. McCoy, Tracking ransomware end-to-end, in: 2018IEEE Symposium on Security and Privacy (SP), 2018, pp. 618–631.[24] S. Pastrana, G. Suarez-Tangil, A first look at the crypto-miningmalware ecosystem: A decade of unrestricted wealth, in: Pro-ceedings of the Internet Measurement Conference, IMC ’19, As-sociation for Computing Machinery, New York, NY, USA, 2019,p. 73–86.[25] R. Richardson, M. North, Ransomware: Evolution, mitigationand prevention, International Management Review 13 (2017)10.[26] G. Hull, H. John, B. Arief, Ransomware deployment methodsand analysis: views from a predictive model and human re-sponses, Crime Science 8 (2019) 1–22.[27] A. Kharaz, S. Arshad, C. Mulliner, W. Robertson, E. Kirda,UNVEIL: A large-scale, automated approach to detectingransomware, in: 25th USENIX Security Symposium (USENIXSecurity 16), USENIX Association, 2016, pp. 757–772.URL [28] E. Kolodenker, W. Koch, G. Stringhini, M. Egele, Paybreak:Defense against cryptographic ransomware, in: Proceedings ofthe 2017 ACM on Asia Conference on Computer and Commu-nications Security, ASIA CCS ’17, Association for ComputingMachinery, 2017, p. 599–611.[29] D. Sgandurra, L. Muñoz-González, R. Mohsen, E. Lupu, Au-tomated dynamic analysis of ransomware: Benefits, limitationsand use for detection, ArXiv abs/1609.03020.