AzzaSec emerged as an Italian hacktivist group leveraging ransomware to further their political and ideological objectives. In recent days a lot of media attention has been dedicated to this group, especially in conjunction with the announcement of a R-a-a-S (Ransomware-as-a-Service) program adopted by the group in question. Since AzzaSec sells the affiliation to this R-a-a-S at a not very low price (850$ for 1 Month of Subscription, 2400$ for 3 Month of Subscription, 4500$ for 6 Month of Subscription, 8000$ for Fully Undetectable Ransomware Source Code) I decided to give a take a closer look at this locker. I warn you that if you feel like spending 8k for a source code of this type you may be able to enjoy the thrill of paying premium prices for bargain bin software ;D
AZZASEC RANSOMWARE
The VB.Net payload I obtained effectively appears to be part of a ransomware program, specifically designed by the AzzaSec hacktivist group. It shares some internal strings and functions with the NoCry ransomware family. The code contains multiple anti-analysis techniques, encryption mechanisms, and malicious payloads aimed at disrupting and damaging victim systems. Generally speaking, this ransomware employs the following main features:
Anti-analysis techniques to detect if it is running in an emulator, debugger, sandbox environment, or virtual machine. If any of these conditions are met, the program terminates immediately.
The use of Mutex ensures that only one instance of the malware runs at any given time.
The core functionality involves encrypting files on the victim’s machine. It uses AES encryption and stores the key and initialization vector (IV).The encryption process targets specific directories while excluding critical system directories like “Windows” “System Volume Information” etc.
The malware reads various settings and configurations via the Class1.Settings to determine its behavior, such as which anti-analysis checks to perform, which extensions to target, and specific actions to execute.
For the anti-analysis features, we can observe a collection of anti-analysis functions embedded within the AzzaSec namespace, explicitly crafted to detect and evade various virtualized and debugging environments. These techniques are employed to thwart the efforts of security researchers and analysts who often utilize such environments for malware analysis.
The Emulator function includes a rudimentary technique for detecting emulated environments. By measuring the system’s time progression through the use of DateTime.Now.Ticks and a subsequent Thread.Sleep of 10 milliseconds, the function assesses the difference in ticks. In a non-emulated environment, the difference should approximate the sleep duration of 10 milliseconds. However, if the difference is significantly less, this indicates the presence of an emulator, as these environments often struggle to accurately simulate real-time passage, thereby causing the function to return true.
Moving on to DetectVirtualMachine, this function utilizes Windows Management Instrumentation (WMI) to query the system’s manufacturer and model. Through the ManagementObjectSearcher, it retrieves information about the Win32_ComputerSystem. The function examines the manufacturer and model to identify signatures of common virtual machine environments. For instance, it looks for manufacturers like Microsoft Corporation” and checks if the model contains VIRTUAL or if it matches known VM identifiers such as VMware or VirtualBox. If these conditions are met, the function conclusively identifies the environment as virtualized and returns false, indicating it is not suitable for the malware to operate. The DetectDebugger function employs the CheckRemoteDebuggerPresent API from kernel32.dll to ascertain if the current process is under the scrutiny of a debugger. By passing the handle of the current process and a reference boolean, this API call populates the boolean with the result. If a debugger is indeed present, the function returns true. This technique is crucial for evading dynamic analysis, where debuggers are commonly used to step through code execution. For detecting Sandboxie, the DetectSandboxie function leverages the GetModuleHandle API to check for the presence of SbieDll.dll a DLL specifically associated with the Sandboxie environment. If this DLL is loaded, which it typically would be in a Sandboxie environment, the function interprets this as a positive detection and returns true. The anyrun function adopts a different approach by querying an external web service. It sends a request to ip-api.com to determine if the current IP address is associated with hosting services. This is a clever method to detect environments like Any.Run, a popular online sandboxing service that often utilizes hosting IPs. If the response from the web service includes “true” it signifies that the environment is likely an Any.Run sandbox, prompting the function to return true.
The external functions GetModuleHandle and CheckRemoteDebuggerPresent are pivotal in the functionality of the aforementioned detection techniques. GetModuleHandle is used to retrieve a handle to a specified module loaded into the address space of the calling process, which is integral to detecting Sandboxie’s DLL. CheckRemoteDebuggerPresent checks if the calling process is being debugged by another process, aiding in the detection of debugging attempts. In summary by combining time-based checks, WMI queries, API calls, and external web service queries, the malware aims to detect and evade a wide array of virtualized and debugging environments. A mutex is then created (Module1.MT) to ensure that only one instance of the malware runs at a time. If the mutex already exists (!flag), the application terminates by calling ProjectData.EndApp(). The “vYtzIm0SDgeCYX5eq8g7″ is the Mutex value for the analyzed sample.
Assuming the environment passes these checks, the ransomware proceeds to establish persistence by potentially adding itself to the system startup, a behavior governed by the startup setting. This ensures that the ransomware executes every time the system boots, enhancing its persistence on the infected machine. The ransomware then proceeds to its primary function: file encryption. It begins by generating a random encryption key, using characters defined in validchars and a length specified by maxrandom. This key generation process is critical as it ensures that the encryption keys are unique and robust, complicating any decryption attempts without the proper key. The generated key is subsequently encrypted using a combination of AES encryption and hardware-based identifiers (HWID), ensuring that even if the key is discovered, it remains protected. The encrypted key is stored in system settings, providing a stealthy and persistent method for key management. With the encryption key secured, the ransomware enumerates files across logical drives and user directories. It targets an extensive list of file types, as defined in the mExtesiones setting. This list includes various file formats such as documents, images, databases, scripts, and more, ensuring a broad impact on the victim’s data. Following the complete list of extensions targeted by the AzzaSec ransomware:
".js", ".sln", ".suo", ".cs", ".c", ".cpp", ".pas", ".h", ".asm", ".sqlite3",
".sqlitedb", ".sql", ".accdb", ".mdb", ".db", ".cmd", ".bat", ".lnk", ".url",
".mat", ".kys", ".pif", ".scf", ".shs", ".shb", ".xnx", ".ps1", ".vbs", ".vb",
".pl", ".jsp", ".php", ".asp", ".rb", ".java", ".jar", ".class", ".sh", ".mp3",
".swf", ".fla", ".wmv", ".mpg", ".vob", ".mpeg", ".asf", ".avi", ".mov", ".mp4",
".3gp", ".mkv", ".3g2", ".flv", ".raw", ".gif", ".png", ".bmp", ".jpg", ".jpeg",
".vcd", ".iso", ".backup", ".zip", ".rar", ".7z", ".gz", ".tgz", ".ta", ".pdf",
".pptx", ".ppt", ".xltm", ".xltx", ".xlc", ".xlm", ".xlt", ".xlw", ".xlsb",
".xlsm", ".xlsx", ".xls", ".docx", ".doc", ".htm", ".html", ".php5", ".php",
".phtml", ".fla", ".cmd", ".ink", ".exe", ".txt", ".gif", ".csv", ".raw",
".lua", ".dat", ".vbs", ".vb6", ".apk", ".config", ".c", ".resx", ".vbproj",
".myapp", ".cache", ".pdb", ".manifest", ".png", ".bmp", ".eps", ".hdr",
".exr", ".ico", ".svg", ".tga", ".tiff", ".wbmp", ".webp"The ransomware avoids encrypting critical system directories to maintain system stability, focusing instead on valuable user data. Files collected during this process are then encrypted using the previously generated key, with the ransomware appending the .AzzaSec extension to signify their encrypted status. Additionally, the ransomware prepares ransom instructions for the victim. It drops an HTML file on the desktop, which includes recovery instructions and demands for ransom payments. The instructions typically provide a BTC (BitCoin) address (bc1q463s23vlpuu36n8k9nlxmqt6tw4dqkggvr2cac for the analyzed sample) for payments and an email address for communication ([email protected] for the analyzed sample), facilitating the ransom transaction. The ransomware is also able to send log activities to a specified remote server. The remote server (C2) is reported under the Class1.Settings.logg string and is reached via HTTPS requests through the sends() function. The sends() function is called by Form1.BackgroundWorker1_DoWork; it’s designed to construct a request for the remote C2 by combining a hash value from the settings with a decrypted string. The decryption process uses a specific method and a key generated from the hardware ID (HWID) of the system, ensuring that the data being sent is uniquely tied to the current machine. The constructed message is then sent to the server using the sends function from Module1. The loop continues to run until the sends function returns true, indicating that the information was successfully sent. Next, it’s indeed this function that generates the HTML “ransom note” file. It retrieves the HTML template from the program’s resources and replaces placeholders within this template with specific values from the settings. These values include the amount of money for ransom, a Bitcoin address, and an email address. The ransomware’s operational workflow also includes mechanisms to hinder recovery efforts. If enabled, it deletes system restore points, a common recovery method, thereby complicating the victim’s ability to restore encrypted files.
Furthermore, it changes the desktop wallpaper to an image containing the ransom note or a warning message, making the victim immediately aware of the ransomware’s presence. Notably, the code incorporates extensive exception handling, allowing it to recover from errors and continue its execution without crashing. This resilience appears to be one of the aspects to which the malware author paid most attentionis and indeed it’s critical in maintaining the presence on the system and avoiding detection due to unexpected terminations.
CRYPTOGRAPHIC SCHEME
The ransomware’s approach to encryption involves multiple stages, including key generation, encryption key storage, file enumeration, and the actual encryption process. The ransomware begins by generating an unique encryption key. This key generation process utilizes a combination of random character selection from a predefined set of valid characters (validchars) and hardware-based identifiers. The set of valid characters includes lowercase and uppercase letters as well as digits, providing a broad entropy pool for the key generation process. The ransomware constructs the key using a StringBuilder and a Random object to select characters at random, iterating up to a length defined by the maxrandom setting, which is typically 20 characters. As already stated, the ransomware employs a hardware-based identifier (HWID) as part of its key management strategy. The key is encrypted using an AES encryption algorithm, with the HWID incorporated as part of the encryption process. This dual-layered encryption could help to protect the confidentiality of the key even if intercepted because it remains protected by the hardware-specific encryption layer, tying the decryption process to the specific infected machine. The encrypted key is then stored in the system settings, utilizing the Interaction.SaveSetting method. This method writes the encrypted key to a specified location in the system’s registry. The key is stored in two parts: the encrypted random string and an additional encrypted setting derived from the original, further obfuscating the decryption process. Once the encryption key is securely generated and stored, the ransomware proceeds with file enumeration. It systematically scans the victim’s filesystem, targeting a wide range of file types. The enumeration process is thorough, covering all logical drives and user directories while excluding critical system directories to maintain system stability. The actual encryption process is executed using a AES encryption algorithm. For each file identified during enumeration, the ransomware reads the file’s contents into memory, encrypts the data using the AES algorithm and the previously generated key, and writes the encrypted data back to the file. The ransomware appends a specific extension (.AzzaSec) to each encrypted file clearly marking them inaccessible to the user without the correct decryption key. Finally, the ransomware deletes system restore points if configured to do so, hindering recovery efforts that rely on these points. Additionally, it changes the desktop wallpaper to an image containing the ransom note (image below) ensuring that the victim is immediately aware of the ransomware’s presence and the severity of the situation.
CONCLUSIONS
The analysis of the AzzaSec ransomware reveals an unsophisticated but still effective piece of malware. The ransomware’s multi-layered approach begins with the generation of strong, unique encryption keys, leveraging both random character selection and hardware-based identifiers. This ensures that each instance of encryption is uniquely tied to the infected machine, complicating any decryption efforts. The use of robust AES encryption further solidifies the ransomware’s ability to effectively lock victim data, making it practically inaccessible without the correct key. Furthermore this locker employs fairly basic anti-analysis controls, including checks for emulators, debuggers, sandboxes and virtual machines. It’s interesting the operational resilience of the malware author, with extensive exception handling ensuring that the ransomware can recover from errors and continue its execution. This resilience reduces the likelihood of crashes that could alert the victim or security software to its presence, maintaining the ransomware’s operational integrity. In conclusion, the AzzaSec ransomware is a malware with a decent set of features but based on a malware families already present in the threat landscape of this category (NoCry / .Cry), not sophisticated and with basic internal controls / routines but to be considered still effective in its intended purposes .