Avaddon ransomware: an in-depth analysis and decryption of infected systems Avaddon ransomware: an in-depth analysis and decryption of infected systems Javier Yustea,∗, Sergio Pastranab aUniversidad Rey Juan Carlos, Madrid bUniversidad 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 and with little technical background. One such popular product is ransomware, which is a popular malware traded in the underground 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, thus causing additional financial and reputational losses. A recent blackmailing strategy adopted by criminals is to leak data online from the infected systems if the ransom is not paid before a given time, threatening businesses to have their data exposed online. Besides reputational damage, data leakage might produce further economical losses due to fines imposed by data protection laws, e.g. GDPR in Europe. Thus, research on prevention and recovery measures to mitigate the impact 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 an affiliate 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. We first provide an analysis of the criminal business model from the underground economy. Then, we identify and describe its technical capabilities, and dissect details of their inner structure. We provide empirical evidence of links between this variant and a previous family, suggesting that the same group was behind the development and, possibly, the operation of both campaigns. As a result, we provide tools to assist analysis, allowing to decrypt and label encrypted strings observed in the ransomware binary. Finally, we describe a method to decrypt files encrypted with Avaddon in real time. We implement and test the decryptor in a tool that can recover the encrypted data from an infected system, thus mitigating the damage caused by the ransomware. The tool is released open-source so it can be incorporated in existing Antivirus engines. Keywords: Avaddon, Ransomware, Malware Analysis, Reverse Engineering, Cybersecurity 1. Introduction In February, 2018, the USA government estimated that cybercrime costs raised up to between 57 and 109 billions of dollars in 2016 [1]. Cybercrime has been growing for the last decades as it becomes more profitable. The most common goal for cybercriminals is monetary gain and they commonly organize to form online criminal enterprises and businesses [2]. The virtual battlefield where such criminal activities operate allows miscreants to perpetrate crimes in countries with different extradition laws than those of the country where they reside. This strategy frequently makes cybercrime hard to prosecute, in addition to other technical characteristics that difficult attribution [3, 4]. In recent times, the underground economy has developed a ∗Corresponding author Email address: javier.yuste@urjc.es (Javier Yuste) myriad of approaches that allow cybercriminals to acquire high financial profits. With the cybercrime growth and specialization, many cybercriminals offer their products in an “as-a-service” model, where the attacker can pur- chase the service through the internet with little technical knowledge. These services reduce the entry level for new criminals 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 the samples 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 data of its victims until a ransom is paid (hence the name of the threat). When these attacks affect companies or public ar X iv :2 10 2. 04 79 6v 1 [ cs .C R ] 9 F eb 2 02 1 organizations, they might provoke business interruptions, thus increasing the economic and social damage [10]. Ran- somware operators often partner up with other criminal groups, either in a customer-service relationship (offering the 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 maintaining the ransomware while the other distributes it, both sharing an arranged percentage of the revenues). Previous works show that criminals can run ransomware campaigns with little technical knowledge, making use of the available ser- vices, with an estimated return of investment of between 504% and 12,682% [5]. Due to the profitability and specialization of cyber- crime, modern ransomware campaigns have improved their sophistication. First, techniques from well-established cryp- tography schemes, so-called hybrid cryptosystems, have been 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 from encrypting the files, ransomware operators now steal data from the infected systems and threaten the victims to leak it online if no ransom is paid. This extortion scheme was initiated by a threat actor named TWISTED SPIDER in the last quarter of 2019 [11], and was quickly followed by other ransomware groups [12, 13, 14]. In order to face the ransomware threat, and to be able to recover the hijacked files, it is important to understand the criminal ecosystem and 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’ victims that do not pay the ransom [15]. At the time of this writ- ing, more than 574GB of data from 23 companies have been leaked and exposed online1. In addition, Avaddon operators have recently started to blackmail victims by running 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 procedure is available to recover files from an infection. We aim at filling this gap by providing an in-deph analysis of Avaddon and proposing a decryption routine that can decrypt files in real time, thus minimizing the impact of such attack. In particular, we analyze one of the first variants observed in early June, although the proposed decryption method is still functional for the latest samples of Avaddon at the time of this writing. The main contributions of this work 1For ethical and legal reasons, we have not downloaded nor checked the veracity of the exposed data since otherwise this would cause additional harm to users, and such analysis is not of public interest 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 an overview of how modern ransomware operates, since their modus operandi is similar. As a result of our study, we provide a set of indicators of compromise (IoCs) that may serve security analysts to develop further 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 the code of both families hint that they are operated or developed by the same group. • We describe a method to recover the symmetric keys used for the encryption, thus allowing victims to re- cover the files from infected systems. Accordingly, we present and make publicly available a tool which can help victims to recover from these attacks in real time. While this tool was designed using the analysis of the first versions of Avaddon, we have confirmed that it still works with the most up-to-date versions of the ransomware, released in mid-January 2021. The rest of this work is structured as follows. Section 2 describes 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 analysis and provides details of the internals of the ransomware. Section 4 describes the method to recover the session key used to encrypt the system and describes the remediation tool to decrypt the infected files. We provide experimental results in Section 5 by infecting a sandboxed environment and 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 defensive mechanisms. Then, we present the criminal ecosystem be- hind Avaddon, including its evolution in the underground economy, and how this has been reflected in the wild, i.e., leading to real-world cyberattacks. 2.1. The Ransomware threat Ransomware is a type of malware that interrupts the business of the victim or denies access to its data until a 2 ransom is paid, by means of data encryption. This type of malware has direct financial implications and has pro- moted the growth of cybercrime, where it is employed as a profitable business model [21]. Before the popularization of cryptocurrencies, such as Bitcoin, online payment methods were risky for malware authors. SMS text messages, pre-paid cards or premium rate telephone numbers could be traced back easier than Bitcoin [22]. With the use of Bitcoin or other cryptocur- rencies to ask for ransoms, it became much harder to trace the payments sent to criminals. Still, the characteristics of 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 million in likely ransom payments made by 19,750 potential vic- tims during a two-year period [23]. Thus, criminals have adopted privacy-preserving cryptocurrencies such as Mon- ero that hinder tracking [24]. These cryptocurrencies, in combination with the cybercrime specialization, have pro- moted the ransomware threats as a profitable business for cybercriminals [25]. Ransomware detection approaches often leverage clas- sical malware detection methods adopted for ransomware- specific behaviors. In this way, ransomware activities can be split in 8 stages [26]: fingerprint, propagate, communi- cate, map, encrypt, lock, delete and threaten. Kharaz et al. focused the detection on common tasks performed by ransomware, 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 of infected systems [28]. Following recent trends in malware detection, some Machine Learning-based approaches have also been proposed specifically targeting ransomware de- tection [29, 30, 31]. 2.2. The ecosystem of Avaddon Avaddon2 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 a registration fee. Concretely, the operators were looking for partners for their campaign. Additionally, Avaddon was promoted on other underground forums afterwards.3 Ac- tors that become affiliates are equipped with both the ran- somware binary and an administration panel from where they can control their infections. Access to the program is free and constrained only for reputed (and Russian- speaking) actors. In exchange for this, partners have to share part of the obtained revenues from the ransomware to the owners and operators. This share depends on the amount of infections, starting from 35% and decreasing up to 15% for larger volumes. Therefore, affiliates, who are 2The name of the ransomware, Avaddon, may be derived from the Hebrew term Abaddon, the name of an angel of the abyss in the Bible, mainly associated with the meaning of “destruction” [18]. 3Due to ethical reasons, and to avoid promoting the site, we do not 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 operating the payment system [17]. Such distribution often relies on botnets hired in a Pay-Per-Install scheme [32]. Addition- ally, partners can purchase installs on RDP servers, which is another popular product traded in underground econ- omy [33]. Thus, the supply chain needed to enter in this business does not require technical knowledge and it opens the barrier to any criminal entrepreneur [34]. As a restric- tion in the affiliates program of Avaddon, it is forbidden to target victims in the Commonwealth of Independent States (CIS). We describe the mechanism used to achieve this 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) Avaddon was observed in the wild. Concretely, it was distributed via mail in a malspam campaign [19], that consisted in low-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 out of fear. The attached file was a zip-compressed JavaScript file. This file tried to masquerade as a JPG photo, having the extension “.jpg” just before the “.js” extension (e.g., “IMG123456.jpg.js”). Upon execution, the malicious file would download and execute the ransomware. Allegedly, the first wave of this campaign targeted mostly Canada, concretely various education services [19]. However, their targets varied later. Indeed, as mentioned before, Avaddon was launched as a RaaS, which means that the targets are not chosen by the ransomware developers (apart from the ban on CIS victims) but by the affiliates. Upon infecting a system, a ransom note is left to the victim with instruc- tions on how to pay the ransom. The note would lead the victim to a Tor hidden service, where payment must be done in exchange for the decryptor. At the time of this writing, the payment service is still operative, confirming that the campaign is ongoing. Shortly after Avaddon was first seen in the wild, Trend Micro conducted and released a technical analysis [20]. The report offers an overview of the ransomware capabil- ities and modus operandi. However, no decryption option is mentioned (it only indicates how to remove the ran- somware). Regarding the decryption process upon paying the ransom, some stories from affected users state that it is 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 their data, by making it publicly available if they do not pay the ransom [37, 38]. By the end of January, 2021, Avaddon has allegedly infected and leaked full dump data from 20 companies (totalling 574.46 GB of data) and is extorting (i.e., threatening of leaking data) 3 other companies which have been recently infected. Finally, in January 2021 (con- 3 current to the writing of this paper), Avaddon included a new technique used for extortion: attacking their victims with Denial-of-Service Attacks [39]. Therefore, the threat to victims is now three-fold, i) data is first encrypted in the infected systems, so it becomes unavailable, ii) data is leaked publicly if the ransom is not paid, and iii) a DDoS attacks is performed to disrupt their businesses until the ransom is paid. At the time of writing, we are not aware of any public decrypting tool for Avaddon. Additionally, various reports and recent complaints from Avaddon victims about their decryption support [40, 41] show that the campaign is still operative. In this paper, we fill this gap and release an open-source tool that automatically detects and decrypts files, which could be integrated in existing Antivirus solu- tions. 3. Ransomware analysis In this section, we provide an analysis of the Avaddon ransomware, concretely one released as part of their initial advertising campaign on June 2020. We follow standard techniques for malware analysis, concretely static and dy- namic analysis. To perform the aforementioned analysis, we utilize popular tools for binary analysis (i.e., Binary Ninja 4, x64dbg 5 and Pestudio 6) and a virtual machine to run the ransomware safely. We build the virtual envi- ronment on top of VirtualBox 7 and install Windows 7 x64 in the virtual system. The analyzed binary (MD5:c9ec0d9ff44f445ce5614 cc87398b38d) is a Portable Executable (PE) file. The PE format describes the structure of executable programs in Windows Operating Systems (OS) [42]. PE files are mainly 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 to correctly load and execute the program, sections contain the actual code and data of the program. Additionally, we see 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 binary is set to June, 3, 2020, at 11:47:22 (UTC). Although this field is prone to be modified by malware authors in order to confuse analysts, the timestamp is similar to the time of the first appearances of Avaddon samples [17], which con- firms that we are indeed analyzing one of the first versions of Avaddon. We describe the packing protections of the analyzed binary 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 4https://binary.ninja/ 5https://x64dbg.com/ 6https://www.winitor.com/ 7https://www.virtualbox.org/ ransomware authors implemented a protection to not in- fect Commonwealth of Independent States (CIS) victims in Section 3.5 and analyze the privilege escalation tech- niques, step by step, in Section 3.6. The details of the persistence mechanism are showcased in Section 3.7. Fol- lowing, interactions with other processes and services are presented in Section 3.8. Finally, we expose the cryptogra- phy mechanisms used in the last two sections, concretely key management (Section 3.9) and file encryption (Section 3.10). 3.1. Packing protections Looking at some properties of the PE file, we conclude that the sample is not packed. First, we find that the PE file contains 4 sections which have almost no differences in size between disk and memory. This in an indicator of the PE file not being packed, since the presence of a vir- tual section (i.e., a section that requests space in memory but does not occupy bytes in disk) is a common indicator of packing protections. Then, we find over 200 imported functions and several meaningful strings, which present some 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 to hint the presence of a packer. The highest entropy level is reached in the “.text” section, whose entropy value is 6.62. However, this does not confirm the existence of packed or encrypted code, which often have values ranging from a minimum of 6.677 to a maximum of 6.926 [43]. 3.2. Imported functions The Windows OS offers an Application Programming Interface (API) which abstracts many functionalities from developers, e.g to interact with files, processes, etc. This also provides an abstraction layer regarding the underly- ing hardware. In order to call those functions, programs need to know their location in memory. This need may be fulfilled in different ways, but the most common method consists on importing the required functions prior to exe- cution. This is done by the OS loader before transferring control to the program. To do so, the PE file contains an Import Address Table (IAT) in the headers, which includes a list of functions to be imported by the OS loader. When the file is executed, the OS loads the file in memory and fills the IAT with the addresses of each requested function. Then, the program is able to call those functions because it now knows where each of these functions is allocated in memory. Therefore, the IAT provides useful information about the capabilities and intentions of the program. The functions imported by the Avaddon sample analyzed show common 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.3. Strings Looking for strings through a PE file allows analysts to identify capabilities of the binary, as well as looking at the IAT. Indeed, some imports will appear when searching for strings if they are imported by name (external functions may be imported by name or ordinal [42]). Therefore, we proceed to extract all readable strings that have more than 4 characters in the whole file. Then, we filter the extracted strings and exclude those that are not meaningful (bytes that are part of code may non-intentionally form readable strings that are not meaningful). In this case, as aforemen- tioned, we find enough meaningful strings to think that the PE file is not packed. Many of the strings found were paths to folders or files (e.g., “C:\Temp”). While we initially can not know the actual purpose of those files, we hypothesize that some of them may be used to drop additional pay- loads or to move the PE file upon infection to a different location (we confirm this hypothesis in Section 3.7). Among the strings that are present in the PE file, we observe two of them that refer to cryptography providers (i.e., “Microsoft Enhanced Cryptographic Provider v1 .0” and “Microsoft Enhanced RSA and AES Cryptograph ic Provider”). These strings are normally used to acquire cryptography contexts using the Windows API, which are later needed to perform some cryptography operations. Additionally, some strings indicate that the ransomware was developed in C++. C++ is an object-oriented lan- guage. Although this characteristic does not provide any information about the capabilities of the sample, the par- ticularities of C++ programs must be taken into account in the analysis process. We will highlight some C++ prop- erties that allow us to extract conclusions in the reverse engineering process, but discussing the differences between C++ and other languages at assembly level is out of the scope 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 string is recovered. Therefore, we suspect that these strings are obfuscated 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 may be of importance to understand additional capabilities of the malware that may not be retrieved without further analysis. We thus confirm that these strings are indeed encrypted and are only decrypted at runtime on demand, i.e., when they are required by the program. First, global variables are created to hold the encrypted strings, mak- ing them accessible from every function in the binary. In Algorithm 1, we show one of the functions (0x4012a0 in this case) that creates a global variable pointing to an en- crypted string. There, the encrypted string and its size are pushed onto the stack (lines 1-2). Then, a global variable is created at 0x4f8a28 with the content of the encrypted string (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 each encrypted string has its own initialization function. These functions are the constructors of the global variables. We know that these are global variables in the source code because: 1. There is one global variable per encrypted string and one constructor function for each global variable. 2. Each global variable has a predefined address. These addresses are hardcoded in each constructor func- tion. 3. After initializing the global variable, a destructor function is registered to be called upon terminating the program. Algorithm 1: One of the functions responsible for initializing a global variable with the value of an encrypted string. 1 0x4012a0: push 0x30; // Size of the encrypted string 2 0x4012a2: push 0x49e180; // Encrypted string 3 0x4012a7: mov ecx, 0x4f8a28; // Global variable 4 0x4012ac: call 0x40a390; // Creates a global variable at ecx (0x4f8a28 in this case) with the string stored at the value previously pushed (0x49e180 in this case) 5 0x4012b1: push 0x4874a0; // Destructor 6 0x4012b6: call _atexit; // Register the destructor function to be called when the process ends 7 0x4012bb: pop ecx; 8 0x4012bc: retn; Once initialized, the strings are decrypted and used as needed by referencing the global variables. In Algorithm 2, we show an example of this procedure. In particular, a string containing some command line arguments is de- crypted and used to create a process. In this case, the goal is to delete security backups. First, the decryption function is called passing the global variable as an argu- ment (lines 1-3). This function returns a new string with the decrypted value, which is immediately used to create the aforementioned process (lines 4-5). The sequence of instructions described can be summarized in the following pseudo code: CommandLine = DecryptString(GlobalVariable); CreateProcess(CommandLine); The decryption function is located at address 0x40c780. First, the received string is decoded from Base64. Then, 5 Algorithm 2: Decryption of a global variable into a temporary register. 1 0x40d110: mov edx, 0x4f8a28; // Global variable that contains an encrypted string 2 0x40d115: lea ecx, [esp+0x8]; // Local variable that will hold the decrypted string 3 0x40d119: call decrypt_string; // Decrypts the string at edx (the global variable) and stores the result in ecx (the local variable) 4 0x40d11e: push eax; // eax now contains the decrypted string (it is equal to [esp+0x8], the local variable) which, in this case, is a command line 5 0x40d11f: call create_process; // Creates a process with the command line received as argument as shown in Algorithm 3, each character is decrypted by substracting 2 units from its value (line 3) and XOR-ing the result with 67 (line 5). These instructions are executed once for every character in the string. Algorithm 3: Characters decryption. 1 0x40c820: mov al, byte [esi]; // Move the current character to al (the lower 8 bits of eax) 2 0x40c822: mov edx, dword [ebp-0x1c]; 3 0x40c825: sub al, 0x2; // Substract two units from the character 4 0x40c827: mov edi, dword [ebp-0x18]; 5 0x40c82a: xor al, 0x43; // XOR the result with 0x43 6 0x40c82c: mov byte [ebp-0x30], al; 7 0x40c82f: cmp edx, edi; 8 0x40c831: jae 0x40c84d; Since we know the address in which global variables are placed, we have automatically re-labeled them in order to improve the readability of the code for the analyst. To allow for reproducibility and to assist other analyses on this and similar malware samples, we publish a script that automates these tasks using the Binary Ninja tool in our public repository 8. 3.4. Anti-analysis techniques Successfully infecting a system critically depends on not being detected. Thus malware authors often imple- ment different techniques to evade antivirus systems or 8https://github.com/JavierYuste/AvaddonDecryptor sandboxes. Additionally, mechanisms are frequently put in place in order to delay analysts and, therefore, increment the time needed for building detection tools for the sample (e.g., signatures). In the case of Avaddon, the binary is not packed, which is a common obfuscation technique. How- ever, we observe other anti-analysis techniques, described next. 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.3 for a detailed description of this obfuscation technique and the process used to decrypt the strings. Anti-debugging. We found a call to IsDebuggerPre- sent at offset 0x42e03d. Debuggers are programs designed to analyze other programs at runtime (i.e., processes), and are used by security analysts to dynamically inspect mal- ware. Hence, malware authors often embed code in their programs that checks for debuggers and, if detected, ter- minates the process or changes their behavior. In par- ticular, IsDebuggerPresent is a function provided by the Windows 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 done by the malware, changing the code on the fly, and the 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 by the OS when executing the program and is unique per process. Among other information, it contains a bit 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 the value in the PEB would successfully hide the debug- ger from that call and from any manual checks (the PEB may also be walked through manually by pars- ing its structure). In order to avoid further anti-debugging mechanisms that may parse the PEB (i.e., not using IsDebuggerPre- sent), we decided to implement the second option. 3.5. Language checks 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 machine is located, so as to ensure that citizens from some regions are not affected. It is common to see that CIS victims are dodged in many malware samples, as it is the case for this one. The most popular approach is to check for the 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). 6 https://github.com/JavierYuste/AvaddonDecryptor In 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 these keyboard layouts or OS locales is found, the binary exits without harming the landed system. That is, this sam- ple of Avaddon ransomware is designed to avoid infecting Russian and Ukrainian systems. This, together with the fact 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. 3.6. Privilege escalation Malware authors often spend great resources in order to infect systems, e.g. to gain initial access and evade de- tection by AV software. However, having invested so much effort in those tasks, their immediate post-infection activi- ties might fail due to the need for administrator privileges if the user becomes suspicious after being requested to con- cede those privileges. Therefore, reducing the number of clicks needed from the victim is critical. Indeed, malware actions 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.). In this particular case, escalating privileges is critical because the ransomware needs to i) acquire persistence through registry 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 different malware families [46, 47]. Next, we briefly summarize this process and how it is implemented in Avaddon. First, three registry keys are added or modified (at offset 0x40ed20). Concretely, these keys are: 1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windo ws\CurrentVersion\Policies\System EnableLUA =0 (disables the “administrator in Admin Approval Mode” user type [48]) 2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windo ws\CurrentVersion\Policies\System ConsentPr omptBehaviorAdmin=0 (this option allows the Con- sent Admin to perform an operation that requires elevation without consent or credentials [49]) 3. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wind ows\CurrentVersion\Policies\System EnableL inkedConnections=1 (makes user mapped drives available to the administrator versions of those users [50]) The first two registry key values allow the sample to elevate privileges without alerting the user, and the third enables the access to volumes of the current user when administrator 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 CLSID was stored in the binary as an encrypted string, as we described in Section 3.3. The decrypted value is “{3E5FC7F9-9A51-4367-9063-A120244FBEC7}”, which corresponds to CMSTPLUA. For the rest of this section, we refer to it as CLSID_CMSTPLUA. 2. Next, an IID is decrypted in the same way, obtaining the value “{6EDD6D74-C007-4E75-B76A-E5740995E 24C}”. For the rest of this section, we refer to it as IID_ICMLuaUtil. 3. Then, a third string is decrypted, which contains the value “Elevation:Administrator!new:”. 4. Once the three strings have been decrypted, a new string is built by concatenating “Elevation:Admini strator!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}”, 0x 24, &IID_ICMLuaUtil, &CMLuaUtil) At this point, user interaction might be needed to grant administrator privileges for the program in some systems. In some cases, this might be ac- companied by social engineering techniques, e.g. in- structions accompanying the phishing email where the malware is attached. In this case, we have not observed any particular behavior. 6. If the call is successful, CMLuaUtil now points to a structure that contains the address of a function named ShellExec (CMLuaUtil−→lpVtbl−→ShellExec). 7. After obtaining the absolute path of the malware PE file (via a call to GetModuleFileNameW ) the binary executes itself with administrator privileges by call- ing ShellExec with the following parameters: ShellExec(CMLuaUtil, “C:\[...]\sample.ex e”, [...]) 3.7. Persistence and infection tracking In order to survive across reboots, malware samples must be run automatically on infected systems after the initial foothold has been obtained [51]. Otherwise, they would need to infect the system again if further runs are required. In order to achieve persistence in the system, there exist many approaches. Usually, malware authors ac- quire persistence by adding registry keys, creating services or registering scheduled tasks. By doing so, the malware sample is automatically run by the OS (e.g., at scheduled times or at every reboot). Additionally, malware sam- ples often implement mechanisms to prevent re-infection 7 of already-infected systems, thus to minimize the risks of detection 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 we confirm that persistence is obtained by adding two reg- istry keys. Upon inspecting the code of the binary, we locate the function responsible for acquiring persistence at address 0x40cf50. The only purpose of this function is to add the following registry keys: • HKU\S-1-5-21-2724635997-1903860598-41043018 68-1000\Software\Microsoft\Windows\CurrentV ersion\Run\update: "C:\Users\%UserProfile%\ AppData\Roaming\%sample%.exe" • HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows \CurrentVersion\Run\update: "C:\Users\%User Profile%\AppData\Roaming\%sample%.exe" With those registry keys in the system, the PE file is executed at each system reboot (notice that a copy of the sample is dropped at runtime in "C:\Users\%UserProfil e%\AppData\Roaming\%sample%.exe", where “%sample%” is the name of the PE file). To avoid re-infecting a system more than once, a mutex is created with the value {2A0E 9C7B-6BE8-4306-9F73-1057003F605B}. If this mutex is already present in the system, the binary exits and does not encrypt files. In addition, the ransomware takes mea- sures to avoid encrypting already encrypted files, as we describe in Section 3.10. Thus, having mechanisms to pre- vent re-infection of a machine might be to avoid reinfecting victims that have already payed a ransom. Nevertheless, the fact that the presence of such mutex is checked allows to prevent Avaddon infections. By creating such mutex in a healthy system, Avaddon ransomware samples will not execute, acting as an Avaddon vaccine. However, not ev- ery sample of Avaddon uses the same mutex, as it may change among versions. 3.8. Process and service manipulation In order to avoid being detected or neutralized, some malware samples try to stop anti-malware solutions. In order 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 file system without rising awareness. In Section 3.2, we high- lighted that the PE file imported some functions that may indicate an attempt to control some anti-malware solutions by interacting with services and processes. Additionally, before attempting to encrypt files, it is important to stop processes that may be locking some files. For instance, ransomware authors may look to stop database processes that may be locking database files. In this case, we find two functions (located at offsets 0x41a8f0 and 0x40c990 of the sample) that try to stop a list of services and processes, respectively, if found in the system. As expected, among those lists, we have found anti-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 missing an ‘r’ (and should instead be “vmware-usbarbitrator64”). This typographical error was found in other ransomware family, MedusaLockker. This indicates that developers reuse code from other families [52, 53]. We are unaware on whether this is due to the same actor developing both fam- ilies, or due to code reuse from one to another (though we have found no evidence of the source code of MedusaLocker being leaked). Indeed, we notice that the Tactics, Tech- niques and Procedures (TTPs) of Avaddon are very similar to those of MedusaLocker if we compare our analyses with the report on MedusaLocker from Carbon Black’s Threat Analysis Unit [52]. This is an interesting fact regarding the attribution of this campaign which might require further investigation if future families share this peculiarity. 3.9. Key generation One of the most critical parts of a ransomware cam- paign is the encryption process. The keys used, how they are imported or generated, how they are exported, the en- cryption algorithm chosen, etc., are important decisions for malware developers. An error in this process may allow analysts to develop measures to recover encrypted files, completely neutralizing the campaign revenues. In this case, two keys are used in the encryption process in a so-called hybrid scheme. One key (the session key) is ran- domly generated in each execution and used to encrypt the files in the system. This key is used in a symmet- ric encryption scheme, AES256. Therefore, the same key must be used to decrypt the affected files. The second key is a public one, part of an asymmetric scheme, RSA1. This key is imported (it is present in the PE file) and used only 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 is only known by them. The whole process that we described in the previous paragraph 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 by calling the Windows API function CryptImportKey with the following parameters: CryptImportKey(hProv:CSP, pbData: Key to be imp orted, dwDataLen: Length of the key, hPubKey: 0, d wFlags: 0, phKey: Handle to the imported key after the call) 8 The key (which is Base64 encoded) is part of a RSA1 public/private pair. As per the documentation [54], the parameter hPubKey must be equal to 0 when the key to be imported is a public key (a PUBLICKEYBLOB object). This detail indicates that the imported key is actually the public one of the pair. Generated key. After importing the public key, a random key 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. To generate it, a function from the Windows API is called, CryptGenKey, with the following parameters: CryptGenKey(hProv: CSP, Algid: CALG_AES_256, d wFlags: CRYPT_EXPORTABLE, phKey: Handle to the gen erated key after the call) The parameter Algid indicates that the generated key is to be used in AES256. Additionally, notice that the flags passed to the function indicate that the key must be ex- portable. Once the key has been generated, it is exported and encrypted using the previously imported RSA1 key. The result is then included in the ransom note, in order to allow the ransomware operators to recover the encryption key and provide a decryption tool to those victims that decide to pay a ransom. Keys destruction. Finally, the function located at 0x413f50 is the one responsible for securely destroying the keys. This function will destroy the public RSA1 key and the generated AES256 key. The purpose of this function is to ensure that they do not remain in memory after being used. However, this function is only called when the pro- cess exits, which only occurs when the infected system is shutdown (the ransomware process remains active to also encrypt new files). Therefore, the session key is never de- stroyed if the system is not powered off. This is a mistake from the malware perspective since, as long as the com- puter remains active, the key is kept in memory and thus can be retrieved using basic forensics techniques. In Sec- tion 4, we will take advantage of this detail to describe and present a tool to recover the symmetric key generated and decrypt all the affected files. 3.10. File encryption In Section 3.9, we presented the mechanism used to generate the key used to encrypt files. Additionally, we showed that the algorithm used to encrypt files is AES256, a symmetric encryption scheme. In this Section, we will describe the process followed to encrypt files in the infected system. The first step performed by the ransomware is to delete backups so the original files cannot be restored by locally saved security copies. To achieve that goal, the function at 0x41a800 executes the following processes: • wmic.exe SHADOWCOPY /nointeractive • wbadmin DELETE SYSTEMSTATEBACKUP • wbadmin DELETE SYSTEMSTATEBACKUP -deleteOlde st • bcdedit.exe /set {default} recoveryenabled No • bcdedit.exe /set {default} bootstatuspolicy i gnoreallfailures • vssadmin.exe Delete Shadows /All /Quiet In order to successfully execute those processes, admin- istrator privileges are needed, which were obtained using the procedure that we described in Section 3.6. Finally, the contents of the recycle bin are deleted by calling the Windows API function SHEmptyRecycleBinW. Next, files are encrypted following a depth-first search approach. Microsoft SQL and Exchange folders are priori- tized, being the first ones to be encrypted. Then, the root path is encrypted (i.e., C:\\*). Finally, shared folders and mapped volumes are enumerated and encrypted (e.g., D: \\*, Y:\\*, or \\VBoxSvr\\shared_folder\\*). There- fore, the order in which folders are encrypted, following a depth-first approach, is the following: 1. C:\\Program Files\\Microsoft\\Exchange Serve r\\* 2. C:\\Program Files (x86)\\Microsoft\\Exchange Server\\* 3. C:\\ProgramFiles\\Microsoft SQL Server\\* 4. C:\\Program Files (x86)\\MicrosoftSQLServer\ \* 5. C:\\* 6. Shared folders and mapped volumes For each file encountered, the process performs three checks before the actual encryption. 1. Strings from a whitelist. The path is checked to not contain specific strings (see Appendix 6 for the list of skipped strings). If the absolute path of the file contains one of those strings, the file is left untouched. This check is excluded for the first four folders searched, those that belong to Microsoft SQL and 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) are the following: bin, ini, sys, dll, lnk, dat, exe, dr v, rdp, prf, swp, mdf, mds and sql. 3. Prevent re-encryption. The third test checks if the file has already been encrypted by Avaddon. To do so, a signature at the end of the file (that is left after encrypting a file by the ransomware, as we will 9 describe later in this section) is read. In particu- lar, the last 24 bytes of the file are read. If the file has been previously encrypted, it should contain the hexadecimal values 0x200 and 0x1030307 at offsets 8 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 function located at virtual address 0x413bb0. This function re- ceives a copy of the AES256 key (see Section 3.9) and the name of the file to be encrypted. We present a high-level pseudo code (some function signatures have been simpli- fied to avoid using pointers) extracted from the analyzed function in Algorithm 4. First, the size needed for the buffer to hold the bytes after encryption is calculated (line 1). Then, the file contents are read in chunks of 0x100000 bytes (line 5) and encrypted in blocks of 0x2000 bytes (lines 8-9). However, although there exists a loop to read and encrypt the whole file, only the first 0x100000 bytes are encrypted. This is due to the last call to SetFilePoint- erEx, which sets the file pointer to the end of the file (line 18). When there are only 0x2000 or less bytes left to be encrypted (line 13), the last chunk of bytes is encrypted (lines 14-15) and written to the file (line 16). Notice that the parameter Final (line 15) in the call to the encryption routine 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 at the 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 an encrypted block of 0x2000 (8192) bytes. 2. Obtain the size of the file. 3. Encrypt the first 0x100000 bytes of the file in blocks of 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 the end of an encrypted file and highlight its different fields: 4E 4D 00 00 00 00 00 00 00 02 00 00 01 00 00 00 07 03 03 01 01 01 E2 02 First, in orange, the original length of the file is written (0x4e4d or 20045 bytes in this case). Then, a hard-coded magic number is written at offset 16 (cian). This value is checked prior to encrypting a file, as we discussed earlier in 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 1 buffer_size ← CryptEncrypt(hKey: Key, Final: False, pbData: 0, pdwDataLen: 0x2000); 2 file_size ← GetFileSizeEx(hFile: File); 3 file_pointer ← 0; 4 do 5 bytes_read, number_of_bytes_read ← ReadFile(hFile: File, offset: file_pointer, nNumberOfBytesToRead: 0x100000); 6 i ← 0; 7 do 8 bytes_to_encrypt ← bytes_read[i:i+0x2000] ; // The file is encrypted in blocks of 0x2000 bytes 9 encrypted_bytes ← CryptEncrypt(hKey: Key, Final: False, pbData: bytes_to_encrypt); 10 WriteFile(hFile: File, lpBuffer: encrypted_bytes); 11 i = i + 0x2000; 12 while i ≤ number_of_bytes_read - 0x2000 ; 13 if number_of_bytes_read - i < 0x2000 then 14 bytes_to_encrypt ← bytes_read[i:] ; 15 encrypted_bytes ← CryptEncrypt(hKey: Key, Final: False, pbData: bytes_to_encrypt); 16 WriteFile(hFile: File, lpBuffer: encrypted_bytes); 17 end 18 file_pointer ← SetFilePointerEx(hFile: File, liDistanceToMove: 0, dwMoveMethod: FILE_END) ; // This call sets the file pointer to the end of the file. This is done to stop processing more bytes from the file 19 while number_of_bytes_read ≥ 0x100000 && file_pointer < file_size; 20 WriteFile(hFile: File, lpBuffer: VictimID); // The Victim ID is written to the end of the file 21 signature ← GetSignature(); 22 WriteFile(hFile: File, lpBuffer: signature); // The signature is also written at the end 10 out, the key used for encrypting the system was randomly generated. Additionally, it was encrypted using a public key before being exported. Therefore, we are not able to know the key that is generated beforehand or to decrypt it after it has been exported, since we do not have the as- sociated private key needed. However, we also hinted that the function responsible for destroying the cryptographic material was in fact never called if the system was not pow- ered off. This is due to the ransomware process remaining in the background in order to encrypt new files or drives as they are created or connected. Since the keys are not de- stroyed and the ransomware process does not exit, we are able to recover the generated key. The only requirement is the memory of the ransomware process (i.e., a full dump). If such dump of the process (or the whole system) has been obtained, we may recover the key. This is of paramount importance, since users, upon seeing a ransom note, might be tempted to power off or reboot their systems in order to reestablish their machines, and would lose the opportunity of obtaining the key and thus decrypting the files. In order to recover the key, we leverage the knowledge acquired during the advanced analysis process (see Sec- tion 3) to identify the structure that points to the desired key. When a key is generated by using the Windows cryp- tography API (i.e., cryptsp.dll and rsaenh.dll) the key is an object of type HCRYPTKEY, which has the following structure [55]: struct HCRYPTKEY { void* CPGenKey; void* CPDeriveKey; void* CPDestroyKey; void* CPSetKeyParam; void* CPGetKeyParam; void* CPExportKey; void* CPImportKey; void* CPEncrypt; void* CPDecrypt; void* CPDuplicateKey; HCRYPTPROV hCryptProv; magic_s *magic; }; The first 10 fields of the structure point to functions of the Windows API. The eleventh field, hCryptProv, points to the provider of the key and the functions (this provider must be first acquired before the key is generated via CryptAcquireContext or a similar function). Finally, the last field points to another structure. This pointer is XOR- ed with a constant value, 0xE35A172C. Therefore, after XOR-ing the pointer with that magic constant, it points to 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 whose values are known: • alg contains the algorithm ID of the algorithm for which the key has been generated. In this case, the value of this field is 0x00006610, which corresponds to AES256 [56]. • flags contains the value of the flags parameter passed in the call to CryptGenKey at 0x48f024. Therefore, its value is 0x00000001. • key_size, as it name hints, contains the size of the key. In this case, the key is 32 bytes long (0x00000020). Finally, the fifth field contains a pointer to the actual key. Since we know the value of 24 of the last 28 bytes that form the structure (skipping the first field) we can search for this 28-byte pattern in the memory of the process. We thus are able to obtain a pointer to the generated key that was used to encrypt the files and finally the key itself. We recall that the only requisite is that the system has not been powered off since it was infected, in order to maintain the key in memory. Now that we have the symmetric key generated by the ransomware, we are able to decrypt the infected files. How- ever, to do so we need to implement the reverse operation than the one performed by the ransomware (see Algorithm 4). To decrypt any given file, we first parse the signature at the end of the file. There, we obtain the original size of the encrypted file. Then, we truncate the file to eliminate both the signature and the block of 512 bytes appended at the end of the file by the ransomware (536 bytes in total, since the signature is 24 bytes in length). Once we have the truncated file, we proceed to decrypt the first 0x100000 bytes in blocks of 8192 (0x2000) bytes. Notice that, as we showed in Algorithm 4, the Final parameter in the Cryp- tEncrypt calls was never set to True. According to the documentation, this parameter should be True when the last block is encrypted. Although we do not know if this nonstandard behavior is intentional or not, we are forced to do the same in the decryption routine. Therefore, we always 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, we truncate it once again, now to the original size recovered earlier from the signature appended at the end, to remove the padding bytes. 11 Obtaining a memory dump of a process can be done by standard forensic tools. Therefore, we open source the tool to recover the symmetric key from memory and decrypt the infected files: https://github.com/JavierYuste/AvaddonDecryptor. 5. Experimentation We test our proposal in a virtual environment running a Windows 7 x64 OS. In particular, we build this virtual machine on top of a virtualization solution named Virtu- alBox in a 1.60 GHz Intel Core i5-8250U CPU with 16 GB RAM computer. From the available hardware, we assign 2 cores and 4 GB of RAM to the aforementioned guest system. Then, we execute Avaddon on the virtual machine and let it encrypt the whole system. When Avaddon has not utilized more than 0.5% of the CPU time in the last 60 seconds, we understand that it has finished encrypting files and confirm the infection due to the presence of ransom notes 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 ransomware process with Process Explorer, a tool from the SysInter- nals suite 9. Note that we can freely drop executable files in the system before stopping Avaddon, since the exe ex- tension is excluded. Once the process is suspended, we can safely operate in the infected system. Next, we dump the 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) obtains the AES256 symmetric key from the dumped memory of the ransomware process iii) and decrypts the whole file system. We show the results in Table 1. From 209,186 files that were present in the whole system, we found that 9,135 (4.3%) were encrypted, making a total of 607 MB. Our proposed tool successfully decrypted all the affected files in 10 minutes and 35 seconds. Additionally, we have tested our tool with the most recent version of Avaddon, which was observed from a wild URL on mid-January 2021, when this paper was written. We confirm that the decryptor still works, 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 the proposed approach needs the encryption key to be present in memory. Otherwise, this would be destroyed and could only 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 one encrypted file to find the correct symmetric key. This, however, can be easily achieved, e.g. by obtaining known 9https://docs.microsoft.com/en-us/sysinternals/ Files in the system 209,186 Files encrypted by Avaddon 9,135 Total size of files in the system 46.85 GB Total size of encrypted files 607 MB Time spent decrypting files 558.54 s Total time 635.63 s Table 1: Results of the experimentation in a virtual environment. files present by default in theWindows OS version installed in the affected system. 6. Conclusions Current approaches of cybercrime specialization, in- cluding new malware techniques, increase the threat of modern ransomware campaigns. In this work, we have an- alyzed a new ransomware, Avaddon, operated as a RaaS in a shared profit scheme, first seen on June 2020. Avaddon incorporates 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 to leak 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 attribution is difficult, our analysis suggests that the threat actor be- hind Avaddon is from a CIS country. Indeed the initial announcement of the ransomware was made in a Russian underground forum, and it implements a policy to prevent infection of CIS-based victims. Moreover, a typographic error 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 also present. Indeed, the modus operandi of Avaddon, that we detailed in this work, is similar to that of MedusaLocker [52] and the list of services to stop is almost identical in both cases. By examining a sample obtained from the first cam- paign of Avaddon and describing its behaviors, we took a grasp on the general “Cyber Kill Chain” of ransomware threats (land, escalate privileges, deactivate defenses, ac- quire persistence, delete backups and encrypt files) and a detailed analysis of this ransomware in particular. Using an hybrid scheme, Avaddon attempts to hide the session key from defenders. However, due to the way in which cryptography keys are managed in this ransomware, we have developed a tool to recover the session key from the memory of the infected systems and decrypt all the af- fected files. The decryption tool also works with newer variants of the ransomware. The only requirement for this method to work is that the victim’s computer is not pow- ered off after the infection. Due to novelty of the ransomware, the business model in terms of an affiliate program, and the ability to extortion and blackmail victims (by means of exfiltration and DDoS 12 https://github.com/JavierYuste/AvaddonDecryptor https://docs.microsoft.com/en-us/sysinternals/ attacks), it is likely to expect new variants of Avaddon and similar ransomware samples improving their mechanisms and expanding in the future. Thus, we believe that the analysis and tools provided in this paper can contribute to guide future analyses of such variants and to improve existing mitigation mechanisms. Acknowledgements This work was supported by the Comunidad de Madrid (P2018/TCS-4566, co-financed by European Structural Funds ESF and FEDER). References [1] T. C. of Economic Advisers, The Cost of Malicious Cyber Ac- tivity to the U.S. Economy, https://www.whitehouse.gov/wp- content/uploads/2018/02/The-Cost-of-Malicious-Cyber- Activity-to-the-U.S.-Economy.pdf, [Online; accessed 28- September-2020] (2 2018). [2] B. Collier, R. Clayton, A. Hutchings, D. Thomas, Cybercrime is (often) boring: maintaining the infrastructure of cybercrime economies, 2020, workshop on the Economics of Information Security, WEIS ; Conference date: 14-12-2020 Through 15-12- 2020. [3] National Intelligence Officer, A Guide to Cyber Attri- bution, https://www.dni.gov/files/CTIIC/documents/ODNI_ A_Guide_to_Cyber_Attribution.pdf, [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 understanding the 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 underground forum, 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, https://www.pandasecurity.com/ mediacenter/pandalabs/annual-report-cybersecurity- predictions-2018/, [Online; accessed 28-September-2020] (11 2017). [8] R. Van Wegberg, S. Tajalizadehkhoob, K. Soska, U. Akyazi, C. H. Ganan, B. Klievink, N. Christin, M. Van Eeten, Plug and prey? measuring the commoditization of cybercrime via online anonymous markets, in: 27th {USENIX} security symposium ({USENIX} security 18), 2018, pp. 1009–1026. [9] Auld, Andy, What’s behind the increase in ransomware attacks this year?, https://www.pwc.co.uk/issues/cyber-security- services/insights/what-is-behind-ransomware-attacks- increase.html, [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, https: //www.crowdstrike.com/blog/double-trouble-ransomware- data-leak-extortion-part-1/, [Online; accessed 28- September-2020] (9 2020). [12] Panda security, Ransomware has a new trick: pay up or suffer a data breach, https://www.pandasecurity.com/mediacenter/ security/ransomware-data-breach-blackmail/, [Online; ac- cessed 28-September-2020] (3 2020). [13] C. Cimpanu, Conti (Ryuk) joins the ranks of ran- somware gangs operating data leak sites, https: //www.zdnet.com/article/conti-ryuk-joins-the-ranks- of-ransomware-gangs-operating-data-leak-sites/, [Online; accessed 28-September-2020] (8 2020). [14] M. J. Schwartz, Ransomware + Exfiltration + Leaks = Data Breach, https://www.bankinfosecurity.com/blogs/ ransomware-exfiltration-leaks-data-breach-p-2913, [On- line; accessed 28-September-2020] (7 2020). [15] Intel471, Ransomware-as-a-service: The pandemic within a pandemic, 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, New York, NY, USA, 2017, p. 445–462. doi:10.1145/3131365. 3131389. URL https://doi.org/10.1145/3131365.3131389 [17] S. Tripathi, Avaddon Ransomware, https://www.subexsecure. com/pdf/malware-reports/June-2020/Avaddon_Ransomware. pdf, [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-wild in 2 days, https://www.hornetsecurity.com/en/security- information/avaddon-from-seeking-affiliates-to-in-the- wild-in-2-days/, [Online; accessed 23-August-2020] (6 2020). [20] M. Malubay, Ransom.Win32.AVADDON.YJAF-A, https: //www.trendmicro.com/vinfo/us/threat-encyclopedia/ malware/Ransom.Win32.AVADDON.YJAF-A, [Online; accessed 22-September-2020] (6 2020). [21] R. Brewer, Ransomware attacks: detection, prevention and cure, Network Security 2016. [22] K. Zetter, What Is Ransomware? A Guide to the Global Cyberattack’s Scary Method, https://www.wired.com/2017/ 05/hacker-lexicon-guide-ransomware-scary-hack-thats- rise/, [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: 2018 IEEE Symposium on Security and Privacy (SP), 2018, pp. 618– 631. [24] S. Pastrana, G. Suarez-Tangil, A first look at the crypto-mining malware 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, mitigation and prevention, International Management Review 13 (2017) 10. [26] G. Hull, H. John, B. Arief, Ransomware deployment methods and 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 detecting ransomware, in: 25th USENIX Security Symposium (USENIX Security 16), USENIX Association, 2016, pp. 757–772. URL https://www.usenix.org/conference/ usenixsecurity16/technical-sessions/presentation/ kharaz [28] E. Kolodenker, W. Koch, G. Stringhini, M. Egele, Paybreak: Defense against cryptographic ransomware, in: Proceedings of the 2017 ACM on Asia Conference on Computer and Commu- nications Security, ASIA CCS ’17, Association for Computing Machinery, 2017, p. 599–611. [29] D. Sgandurra, L. Muñoz-González, R. Mohsen, E. Lupu, Au- tomated dynamic analysis of ransomware: Benefits, limitations and use for detection, ArXiv abs/1609.03020. 13 https://www.whitehouse.gov/wp-content/uploads/2018/02/The-Cost-of-Malicious-Cyber-Activity-to-the-U.S.-Economy.pdf https://www.whitehouse.gov/wp-content/uploads/2018/02/The-Cost-of-Malicious-Cyber-Activity-to-the-U.S.-Economy.pdf https://www.whitehouse.gov/wp-content/uploads/2018/02/The-Cost-of-Malicious-Cyber-Activity-to-the-U.S.-Economy.pdf https://www.dni.gov/files/CTIIC/documents/ODNI_A_Guide_to_Cyber_Attribution.pdf https://www.dni.gov/files/CTIIC/documents/ODNI_A_Guide_to_Cyber_Attribution.pdf https://resources.infosecinstitute.com/attribution-problem-in-cyber-attacks/ https://resources.infosecinstitute.com/attribution-problem-in-cyber-attacks/ https://www.pandasecurity.com/mediacenter/pandalabs/annual-report-cybersecurity-predictions-2018/ https://www.pandasecurity.com/mediacenter/pandalabs/annual-report-cybersecurity-predictions-2018/ https://www.pandasecurity.com/mediacenter/pandalabs/annual-report-cybersecurity-predictions-2018/ https://www.pwc.co.uk/issues/cyber-security-services/insights/what-is-behind-ransomware-attacks-increase.html https://www.pwc.co.uk/issues/cyber-security-services/insights/what-is-behind-ransomware-attacks-increase.html https://www.pwc.co.uk/issues/cyber-security-services/insights/what-is-behind-ransomware-attacks-increase.html https://www.crowdstrike.com/blog/double-trouble-ransomware-data-leak-extortion-part-1/ https://www.crowdstrike.com/blog/double-trouble-ransomware-data-leak-extortion-part-1/ https://www.crowdstrike.com/blog/double-trouble-ransomware-data-leak-extortion-part-1/ https://www.pandasecurity.com/mediacenter/security/ransomware-data-breach-blackmail/ https://www.pandasecurity.com/mediacenter/security/ransomware-data-breach-blackmail/ https://www.zdnet.com/article/conti-ryuk-joins-the-ranks-of-ransomware-gangs-operating-data-leak-sites/ https://www.zdnet.com/article/conti-ryuk-joins-the-ranks-of-ransomware-gangs-operating-data-leak-sites/ https://www.zdnet.com/article/conti-ryuk-joins-the-ranks-of-ransomware-gangs-operating-data-leak-sites/ https://www.bankinfosecurity.com/blogs/ransomware-exfiltration-leaks-data-breach-p-2913 https://www.bankinfosecurity.com/blogs/ransomware-exfiltration-leaks-data-breach-p-2913 https://intel471.com/blog/ransomware-as-a-service-2020-ryuk-maze-revil-egregor-doppelpaymer/ https://intel471.com/blog/ransomware-as-a-service-2020-ryuk-maze-revil-egregor-doppelpaymer/ https://doi.org/10.1145/3131365.3131389 https://doi.org/10.1145/3131365.3131389 http://dx.doi.org/10.1145/3131365.3131389 http://dx.doi.org/10.1145/3131365.3131389 https://doi.org/10.1145/3131365.3131389 https://www.subexsecure.com/pdf/malware-reports/June-2020/Avaddon_Ransomware.pdf https://www.subexsecure.com/pdf/malware-reports/June-2020/Avaddon_Ransomware.pdf https://www.subexsecure.com/pdf/malware-reports/June-2020/Avaddon_Ransomware.pdf https://id-ransomware.blogspot.com/2020/06/avaddon-ransomware.html https://id-ransomware.blogspot.com/2020/06/avaddon-ransomware.html https://www.hornetsecurity.com/en/security-information/avaddon-from-seeking-affiliates-to-in-the-wild-in-2-days/ https://www.hornetsecurity.com/en/security-information/avaddon-from-seeking-affiliates-to-in-the-wild-in-2-days/ https://www.hornetsecurity.com/en/security-information/avaddon-from-seeking-affiliates-to-in-the-wild-in-2-days/ https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/Ransom.Win32.AVADDON.YJAF-A https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/Ransom.Win32.AVADDON.YJAF-A https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/Ransom.Win32.AVADDON.YJAF-A https://www.wired.com/2017/05/hacker-lexicon-guide-ransomware-scary-hack-thats-rise/ https://www.wired.com/2017/05/hacker-lexicon-guide-ransomware-scary-hack-thats-rise/ https://www.wired.com/2017/05/hacker-lexicon-guide-ransomware-scary-hack-thats-rise/ https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kharaz https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kharaz https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kharaz https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kharaz https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kharaz [30] R. Vinayakumar, K. P. Soman, K. K. Senthil Velan, S. Ganorkar, Evaluating shallow and deep networks for ran- somware detection and classification, in: 2017 International Conference on Advances in Computing, Communications and Informatics (ICACCI), 2017, pp. 259–265. [31] K. Lee, S. Lee, K. Yim, Machine learning based file entropy analysis for ransomware detection in backup systems, IEEE Ac- cess 7 (2019) 110205–110215. [32] J. Caballero, C. Grier, C. Kreibich, V. Paxson, Measuring pay- per-install: the commoditization of malware distribution., in: Usenix security symposium, Vol. 13, 2011. [33] Kaspersky, xDedic – the shady world of hacked servers for sale, https://securelist.com/xdedic-the-shady-world- of-hacked-servers-for-sale/75027/, [Online; accessed 04- February-2021] (6 2016). [34] R. Bhalerao, M. Aliapoulios, I. Shumailov, S. Afroz, D. McCoy, Mapping the underground: supervised discovery of cybercrime supply chains, in: 2019 APWG Symposium on Electronic Crime Research (eCrime), IEEE, 2019, pp. 1–16. [35] PintSizeNore, AVADDON Ransomware (.avdn; [id]- readme.html) Support Topic, https://www.bleepingcomputer. com/forums/t/724607/avaddon-ransomware-avdn;-id- readmehtml-support-topic/page-2#entry5061940, [Online; accessed 14-October-2020] (09 2020). [36] M. De Jesus, M. Malubay, A. Christelle Ramos, Ran- somware Report: Avaddon and New Techniques Emerge, Industrial Sector Targeted, https://www.trendmicro. com/vinfo/us/security/news/cybercrime-and-digital- threats/ransomware-report-avaddon-and-new-techniques- emerge-industrial-sector-targeted, [Online; accessed 22-September-2020] (7 2020). [37] M. J. Schwartz, Avaddon Ransomware Joins Data-Leaking Club, https://www.bankinfosecurity.com/avaddon- ransomware-joins-data-leaking-club-a-14809, [Online; accessed 22-September-2020] (8 2020). [38] L. Abrams, Avaddon ransomware launches data leak site to extort victims, https://www.bleepingcomputer.com/news/ security/avaddon-ransomware-launches-data-leak-site- to-extort-victims/, [Online; accessed 22-September-2020] (8 2020). [39] L. Abrams, Avaddon ransomware launches data leak site to extort victims, https://www.bleepingcomputer.com/news/ security/another-ransomware-now-uses-ddos-attacks-to- force-victims-to-pay/, [Online; accessed 03-February-2021] (1 2021). [40] Emsisoft, Urgently Needed! Avaddon ransomware (.avdn), https://support.emsisoft.com/topic/33623-urgently- needed-avaddon-ransomware-avdn/, [Online; accessed 21- October-2020] (2020). [41] B. Computer, AVADDON Ransomware (.avdn; [id]- readme.html) Support Topic, https://www.bleepingcomputer. com/forums/t/724607/avaddon-ransomware-avdn;-id- readmehtml-support-topic/page-2, [Online; accessed 21- October-2020] (2020). [42] Microsoft, PE Format, https://docs.microsoft.com/en- us/windows/win32/debug/pe-format, [Online; accessed 01- October-2020] (2020). [43] R. Lyda, J. Hamrock, Using entropy analysis to find encrypted and packed malware, IEEE Security and Privacy 5 (2) (2007) 40–45. [44] P. V. Sabanal, M. V. Yason, Reversing c++, Black Hat DC. [45] hfiref0x2017, UAC bypass using CMSTPLUA COM interface, https://gist.github.com/api0cradle/ d4aaef39db0d845627d819b2b6b30512, [Online; accessed 31- August-2020] (2017). [46] A. Osipov, Trickbot Trojan leveraging a new Windows 10 UAC bypass, https://blog.morphisec.com/trickbot-uses-a-new- windows-10-uac-bypass, [Online; accessed 31-August-2020] (2020). [47] S. in bits, UAC bypass analysis (Stage 1) Ataware Ransomware – Part 0x2, https://www.securityinbits.com/malware- analysis/uac-bypass-analysis-stage-1-ataware- ransomware-part-2/, [Online; accessed 31-August-2020] (2019). [48] Microsoft, EnableLUA, https://docs.microsoft.com/en- us/openspecs/windows_protocols/ms-gpsb/958053ae-5397- 4f96-977f-b7700ee461ec, [Online; accessed 21-July-2020] (2019). [49] Microsoft, ConsentPromptBehaviorAdmin, https://docs. microsoft.com/en-us/openspecs/windows_protocols/ms- gpsb/341747f5-6b5d-4d30-85fc-fa1cc04038d4, [Online; accessed 21-July-2020] (2019). [50] Microsoft, Mapped drives are not available from an elevated prompt when UAC is configured to "Prompt for creden- tials" in Windows, https://support.microsoft.com/en- us/help/3035277/mapped-drives-are-not-available-from- an-elevated-prompt-when-uac-is-co, [Online; accessed 21-July-2020] (2015). [51] Lockheed Martin, The Cyber Kill Chain, https://www. lockheedmartin.com/en-us/capabilities/cyber/cyber- kill-chain.html, [Online; accessed 08-October-2020]. [52] B. Baskin, TAU Threat Analysis: Medusa Locker Ran- somware, https://www.carbonblack.com/blog/tau-threat- analysis-medusa-locker-ransomware/, [Online; accessed 19-October-2020] (June 2020). [53] A. Zsigovits, Ransomware-LockBit, https://github.com/ sophoslabs/IoCs/blob/master/Ransomware-LockBit, [Online; accessed 19-October-2020] (2020). [54] Microsoft, CryptImportKey function, https://docs. microsoft.com/en-us/windows/win32/api/wincrypt/nf- wincrypt-cryptimportkey, [Online; accessed 27-August-2020] (2018). [55] Sasza, Structure of HCRYPTKEY Data, https: //forums.codeguru.com/showthread.php?79163-Structure- of-HCRYPTKEY-Data, [Online; accessed 26-September-2020] (2020). [56] Microsoft, ALG_ID, https://docs.microsoft.com/en- us/windows/win32/seccrypto/alg-id, [Online; accessed 26-September-2020] (2018). 14 https://securelist.com/xdedic-the-shady-world-of-hacked-servers-for-sale/75027/ https://securelist.com/xdedic-the-shady-world-of-hacked-servers-for-sale/75027/ https://www.bleepingcomputer.com/forums/t/724607/avaddon-ransomware-avdn;-id-readmehtml-support-topic/page-2#entry5061940 https://www.bleepingcomputer.com/forums/t/724607/avaddon-ransomware-avdn;-id-readmehtml-support-topic/page-2#entry5061940 https://www.bleepingcomputer.com/forums/t/724607/avaddon-ransomware-avdn;-id-readmehtml-support-topic/page-2#entry5061940 https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/ransomware-report-avaddon-and-new-techniques-emerge-industrial-sector-targeted https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/ransomware-report-avaddon-and-new-techniques-emerge-industrial-sector-targeted https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/ransomware-report-avaddon-and-new-techniques-emerge-industrial-sector-targeted https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/ransomware-report-avaddon-and-new-techniques-emerge-industrial-sector-targeted https://www.bankinfosecurity.com/avaddon-ransomware-joins-data-leaking-club-a-14809 https://www.bankinfosecurity.com/avaddon-ransomware-joins-data-leaking-club-a-14809 https://www.bleepingcomputer.com/news/security/avaddon-ransomware-launches-data-leak-site-to-extort-victims/ https://www.bleepingcomputer.com/news/security/avaddon-ransomware-launches-data-leak-site-to-extort-victims/ https://www.bleepingcomputer.com/news/security/avaddon-ransomware-launches-data-leak-site-to-extort-victims/ https://www.bleepingcomputer.com/news/security/another-ransomware-now-uses-ddos-attacks-to-force-victims-to-pay/ https://www.bleepingcomputer.com/news/security/another-ransomware-now-uses-ddos-attacks-to-force-victims-to-pay/ https://www.bleepingcomputer.com/news/security/another-ransomware-now-uses-ddos-attacks-to-force-victims-to-pay/ https://support.emsisoft.com/topic/33623-urgently-needed-avaddon-ransomware-avdn/ https://support.emsisoft.com/topic/33623-urgently-needed-avaddon-ransomware-avdn/ https://www.bleepingcomputer.com/forums/t/724607/avaddon-ransomware-avdn;-id-readmehtml-support-topic/page-2 https://www.bleepingcomputer.com/forums/t/724607/avaddon-ransomware-avdn;-id-readmehtml-support-topic/page-2 https://www.bleepingcomputer.com/forums/t/724607/avaddon-ransomware-avdn;-id-readmehtml-support-topic/page-2 https://docs.microsoft.com/en-us/windows/win32/debug/pe-format https://docs.microsoft.com/en-us/windows/win32/debug/pe-format https://gist.github.com/api0cradle/d4aaef39db0d845627d819b2b6b30512 https://gist.github.com/api0cradle/d4aaef39db0d845627d819b2b6b30512 https://blog.morphisec.com/trickbot-uses-a-new-windows-10-uac-bypass https://blog.morphisec.com/trickbot-uses-a-new-windows-10-uac-bypass https://www.securityinbits.com/malware-analysis/uac-bypass-analysis-stage-1-ataware-ransomware-part-2/ https://www.securityinbits.com/malware-analysis/uac-bypass-analysis-stage-1-ataware-ransomware-part-2/ https://www.securityinbits.com/malware-analysis/uac-bypass-analysis-stage-1-ataware-ransomware-part-2/ https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpsb/958053ae-5397-4f96-977f-b7700ee461ec https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpsb/958053ae-5397-4f96-977f-b7700ee461ec https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpsb/958053ae-5397-4f96-977f-b7700ee461ec https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpsb/341747f5-6b5d-4d30-85fc-fa1cc04038d4 https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpsb/341747f5-6b5d-4d30-85fc-fa1cc04038d4 https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpsb/341747f5-6b5d-4d30-85fc-fa1cc04038d4 https://support.microsoft.com/en-us/help/3035277/mapped-drives-are-not-available-from-an-elevated-prompt-when-uac-is-co https://support.microsoft.com/en-us/help/3035277/mapped-drives-are-not-available-from-an-elevated-prompt-when-uac-is-co https://support.microsoft.com/en-us/help/3035277/mapped-drives-are-not-available-from-an-elevated-prompt-when-uac-is-co https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html https://www.carbonblack.com/blog/tau-threat-analysis-medusa-locker-ransomware/ https://www.carbonblack.com/blog/tau-threat-analysis-medusa-locker-ransomware/ https://github.com/sophoslabs/IoCs/blob/master/Ransomware-LockBit https://github.com/sophoslabs/IoCs/blob/master/Ransomware-LockBit https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptimportkey https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptimportkey https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptimportkey https://forums.codeguru.com/showthread.php?79163-Structure-of-HCRYPTKEY-Data https://forums.codeguru.com/showthread.php?79163-Structure-of-HCRYPTKEY-Data https://forums.codeguru.com/showthread.php?79163-Structure-of-HCRYPTKEY-Data https://docs.microsoft.com/en-us/windows/win32/seccrypto/alg-id https://docs.microsoft.com/en-us/windows/win32/seccrypto/alg-id Appendix A “C:\Program Files\Microsoft\Exchange Server” “C:\Program Files (x86)\Microsoft\Exchange Server” “C:\Program Files\Microsoft SQL Server” “C:\Program Files (x86)\Microsoft SQL Server” “C:\Windows” “C:\Program Files” “C:\Users\All Users” “C:\Users\Public” “C:\Users\%User Profile%\AppData\Local\Temp” “C:\Program Files (x86)” “C:\Users\%User Profile%\AppData” “C:\ProgramData” “Tor Browser” “AppData” “ProgramData” “Program Files” “Windows” Name of the ransom note (e.g., “363053-readme.html”) “bckgrd.bmp” Table 2: List of whitelisted strings in the encryption process. 15 1 Introduction 2 Background and related work 2.1 The Ransomware threat 2.2 The ecosystem of Avaddon 3 Ransomware analysis 3.1 Packing protections 3.2 Imported functions 3.3 Strings 3.4 Anti-analysis techniques 3.5 Language checks 3.6 Privilege escalation 3.7 Persistence and infection tracking 3.8 Process and service manipulation 3.9 Key generation 3.10 File encryption 4 Decryption of infected systems 5 Experimentation 6 Conclusions