Astaroth unleashed

Authors: Norbert Biro, Jozsef Gegeny, Prakas Thevendaran

·       Astaroth, also known as Guildma, is a sophisticated piece of malware that first emerged in 2018 and has since undergone significant evolution, adapting to new security measures and refining its attack methodologies.

·       Believed to have originated in Brazil, Astaroth predominantly targets Latin American (LATAM) regions. Based on Acronis telemetry, 91% of the affected systems are in Brazil, followed by 4% in Mexico and 2% in Argentina. About 27% of compromises affected organizations involved in manufacturing. IT is the second most impacted industry (18%) followed by financial services (13%) and health care (7%).

·       Astaroth employs advanced techniques to hinder reverse engineering and evade sandbox analysis. These include multistage infection processes, anti-debugging mechanisms and precise geolocation checks to ensure it operates exclusively within its intended targets.

·       This analysis identifies several differences compared to previously documented cases for this malware family. The initial infection uses MSHTA to execute malicious JavaScript directly. The JavaScript downloader has also evolved by randomly selecting compromised domains. This version introduces an additional check at a single location (C:\ProgramData\Public\fu) to detect prior compromise, causing the downloader to terminate if an infection is identified.

·       It uses PowerShell instead of Bitsadmin for downloads and modifies the payload filename to evade detection better. The Astaroth payload targets Brazilian victims through precise geolocation checks, and it shuts down the computer if the language settings indicate English (U.S.). These changes reflect ongoing adaptations by attackers to evade detection.

The infection campaigns often begin with phishing or spear-phishing emails crafted to appear legitimate and lure users into action. Recent campaigns have used email attachments disguised as innocuous documents, such as curriculum vitae (resumes), orçamento (budgets), contábil (accounting files), tesoreria (treasury files), or IRPF (personal income tax declarations). These themes resonate with the targeted audience, increasing the likelihood of engagement.

The infection process is anything but straightforward, relying on a complex chain of events that unfolds from a malicious .lnk embedded in the email. Opening the file triggers a convoluted series of steps, including the execution of JavaScript and AutoIt scripts, ultimately leading to process injection techniques.

In the following sections, we will delve into one of the latest campaigns, examining its progression from the initial stage to its ultimate execution.

Astaroth’s phishing campaign has been observed leveraging spoofed DocuSign emails to deceive recipients into believing they are receiving legitimate documents for review or signature. These emails closely mimic the official branding and formatting of genuine DocuSign notifications, increasing their credibility. Once the users click on the embedded link, they are redirected to deliver a malicious payload.

This link leads to a malicious ZIP file, which, when extracted, contains a shortcut (LNK) file. While the filenames of the ZIP archives can vary significantly, some examples gathered from our telemetry include:

Malicious LNK files often serve as an entry point for sophisticated attacks. In the following case, as shown in the screenshot below, we inspect a file named QL_035.zip, which contains an LNK file from an Astaroth campaign:

By examining the properties of the LNK file through a simple right click in Windows Explorer, we can observe the command it executes in the Target field. In this instance, as seen, it runs mshta.exe through cmd.exe. Note that the mshta command and subsequent strings are deliberately mixed with uppercase and lowercase letters, a technique aimed at evading detection:

The full content of the target command is:

One quick and effective method to decode these obfuscated strings is by using NodeJS. NodeJS is an open-source, cross-platform, JavaScript runtime environment that allows developers to execute JavaScript code outside the constraints of a browser, such as in a command prompt:

The JavaScript command executed by mshta essentially retrieves and runs a script from a remote URL. In the second stage, we will proceed by delving into the details of this JavaScript file.

The initial stage executed a very tiny JavaScript code, typically only a single line in length. While it is concise and efficient, it does not provide significant insight into the malware's functionality. Its primary purpose is to download a more substantial and complex script that follows. The actors behind Astaroth designed their infrastructure with geofencing in mind, which impacted our analysis. As a result, we were only able to download the second stage by using a Brazilian VPN.

The JavaScript is mildly obfuscated, with most of the obfuscation affecting only the variable names, while other programming structures such as loops and conditionals remain intact. This made the code relatively easy to deobfuscate manually. For clarity, we provide an example of the obfuscated code snippet here, but in subsequent examples, we will present the deobfuscated version for improved readability.

A JavaScript file executes a PowerShell command whenever it attempts to download a file from the internet. The PowerShell command uses the irm option (Invoke-RestMethod) for the download operation:    

Additionally, the script contains a list of domains addresses. When performing a download, it randomly selects one of these domains from the list and uses it as the target for the download process:

An interesting use case of .sbs domains. Originally, SBS stands for 'side by side' and was marketed toward nonprofits, activist groups, startups and creators aiming to emphasize inclusion or social impact. However, it can also be abused by threat actors, as demonstrated by the Astaroth gang. These domains are ideal for malicious purposes because they're cheap and easy to register, they can evade basic domain filters and they're less recognizable, making them useful for impersonation or deception.

The malware uses the directory C:\ProgramData\Boot\QNAPVive.QNAP.03864.4664.666\ as its installation path. The directory names are crafted to resemble legitimate software, helping it avoid detection. Before initiating any downloads, it verifies whether the system has already been compromised. This verification is performed by checking for the existence of the directory C:\ProgramData\Public\fu, which acts as a semaphore.

In summary, the JavaScript downloader is responsible for creating the destination folder for Astaroth. It then connects to a randomly selected server from a predefined list of command-and-control (C2) domains to download the files necessary for executing the next stage. The files created during this stage include:

Our telemetry has revealed highly variable naming patterns, suggesting that the server dynamically generates the JavaScript downloader. This is likely done using a pool of words related to vendor names and software or hardware terms. For instance, the table below highlights the 20 most frequently occurring vendors and words:

On the server side, the backend script appears to combine a random selection of these words — such as Huawei and HDMI — with a random number, producing filenames like Huawei.HDMI.04353.5219.132.exe.

The JavaScript downloader prepared everything required for the execution of the third stage, particularly the following files:

·       Vive.QNAP.03864.4664.666.exe

·       Vive.QNAP.03864.4664.666.log

It is important to note that Vive.QNAP.03864.4664.666.exe is a legitimate AutoIt executable file and is not inherently malicious. However, the malicious content resides in the Vive.QNAP.03864.4664.666.log file, which is passed via the command line by the previous stage:

To decompile the script, we utilized myAut2Exe, successfully employing version 2.12. While the decompiled script remains obfuscated, we identified an embedded PE DLL within its code:

The script appears to leverage code from MemoryDll.au3 to load the embedded DLL directly into memory, bypassing the need to write it to disk. The DLL, represented in hexadecimal format, can be readily extracted and reconstructed into its original binary form. Further analysis of this DLL is conducted in Stage 4.

The primary function of this smaller executable is to decrypt the contents of stack.tmp, a file downloaded during Stage 2. This file contains the final payload — Astaroth malware — in an encrypted form:

After loading stack.tmp into a buffer, the executable attempts to inject it into a Microsoft process named RegSvcs.exe:

The Astaroth binary is compiled with Embarcadero Delphi for Win32 compiler. Delphi is known to generate large executables, which explains the large file size of this Astaroth payload, which is a little bit more than 3MB in size.

During analysis, strings are one of the most valuable artifacts, as they provide crucial clues and quick insights into the behavior of disassembled code. However, Astaroth significantly complicates this process by encoding almost all its strings, as illustrated in the disassembled screenshot:

Astaroth employs a custom three-layer string encryption algorithm. We have reverse engineered the algorithm and implemented it in Python:

For example, the encoded string 70706B616F64696710960194189915847E6B deciphers to "ASTAROTH," hinting at the origin of the malware's name.

To emphasize the scale of Astaroth’s obfuscation, extracting all hexadecimal patterns from its binary reveals nearly 1,000 encoded strings, underscoring the complexity of analyzing this executable.

Astaroth enumerates running processes to detect the presence of well-known analysis tools

The full list of blacklisted processes includes:

·       Sysmon.exe

·       splunkd.exe

·       splunk-winevtlog

·       x32dbg.exe

·       Wireshark

·       OLLYDB

·       DbgX.Shell

·       SbieSvc

·       QEMU-GA

·       VBoxService

·       DLLoader32

Astaroth also verifies the hard drive’s volume serial number as part of its anti-analysis measures. The volume serial number can be retrieved manually using the `dir` command:

However, the malware does not rely on this command. Instead, it programmatically retrieves the volume serial number by invoking the GetVolumeInformationW Windows API. If the resulting buffer matches any of the following IDs, the system is flagged as a sandbox:

·       9E7BF525

·       AC7D7D62

·       CE4B511D

·       AE58521C

·       5CAFFAB4

Additionally, if the computer’s language settings indicate English (U.S.), Astaroth flags the system as sandboxed, too:

If sandboxing or debugging is detected, Astaroth responds by immediately shutting down the system:

Astaroth ensures persistence by configuring itself to start automatically upon user logon. It achieves this by creating an LNK file in the current user's Startup folder, such as:

In the latest campaigns, we observed the following filename prefixes:

·       clearclean.rest

·       syncup.setup

·       sysupdate.setup

·       SysClean.out

·       SystemInUpdate.out

These prefixes are hardcoded within the malware, with a random number and the .LNK extension appended to complete the filename. The created LNK file is designed to execute the malicious AutoIt loader via PowerShell:

Astaroth’s configuration file, named dump.log, is located in the same directory as the main executable. This file is encrypted and employs multiple layers of obfuscation. The outermost layer uses Base64 encoding, while the inner layer is encrypted with a custom algorithm. Upon analysis, we observed that the format of dump.log closely resembles that of another log file, auid.log, used by the malware:

By reversing the encryption algorithm applied to auid.log, we successfully decrypted dump.log. Notably, the decryption process requires the use of the value 3F2h, which serves as a seed or key.

The decoded configuration file is shown below:

By reversing the encryption algorithm applied to auid.log, we successfully decrypted dump.log. Notably, the decryption process requires the use of the value 3F2h, which serves as a seed or key.

The decoded configuration file is shown below:

While the purpose of all values in the configuration file is not fully understood, it does contain a list of command-and-control (C2) server addresses, separated by the | character. In this particular instance, however, the configuration file contained only a single C2 URL, which was repeated multiple times.

Another notable observation was the presence of links pointing to a remote image file, which we downloaded. The image depicted green apples, destacada-paisagens2.jpg:

Upon examining the binary format of the image file, we identified extra data that did not align with standard image content:

Further analysis and decoding of this embedded data revealed it to be a backup malware configuration. This backup contained the same command-and-control (C2) server addresses as those found in the initial malware configuration file.

From Astaroth binaries, we extracted the top-level domains (TLDs) associated with financial institutions, allowing us to quantify the number of affected entities by country. The data is summarized below:

The most impacted countries include Brazil, Paraguay, Argentina, Colombia, Panama, and Venezuela, with Brazil having the highest number of affected institutions. This highlights a predominant focus on financial institutions within the LATAM region. However, the malware's scope is not geographically confined to Latin America. European countries such as Italy, Spain and Portugal have also been targeted, indicating a broader operational reach. Notably, a single reference to a Japanese entity was also identified, underscoring the malware's ability to target diverse geographical regions and financial ecosystems.

Comparing the targets list with previous campaigns, we can observe that they are constantly refreshing and adding new targets. New Brazilian targets appear more frequently than any other, which also suggests that the authors most likely operate within Brazil. Newly added targets since the last campaign:

Based on Acronis telemetry, most of the victims are in Latin America. 91% of the affected systems are in Brazil, followed by 4% in Mexico and 2% in Argentina. The distribution reflects the malware authors' selected targets based on their language and regional configuration.

Manufacturing is the most impacted industry in this Astaroth campaign. About 27% of compromises affected organizations involved in manufacturing. IT is the second most impacted industry (18%) followed by financial services (12%) and health care (6%).

Acronis Advanced Security + Extended Detection and Response (XDR) successfully detects components used in the attack chain.

Zip with LNK file

·       62acdb0765cf0a73bd4fedf7f11c3512

·       86517ea3d3ae9767f654bd417e990b1f

·       dece8b727fab19363beb8624a98b4c98

JS downloaders

·       f12081c4e22fdada874685141b181e3d

·       8c8a0a86fefa9747635108b7cd72a3b6

AutoIt scripts

·       94c1f53880724609abe811b9b41f9807

·       ba50eba9acac42db84718197dd10e0fd

·       0179f0ad93a73819880d20845cd527a3

·       8894b28ebcd13b1b3a61fe6047eb6882

DLL loaders

·       73c0b62eb4474724b7294c8a08fa67b9

·       c790bc62e9d08c675b37f986b306ac7f

Astaroth binaries

·       c153aee19f6c0f029611300752f6c0eb

·       f14583e23da88954836852cbf7c1d0f4

·       52d7108a5c366d589fbb3ab319ee78a3

·       7338e4bb33360147ebbf92af29adf52d

Astaroth C2

·       tcp.sa.ngrok.io:20262

·       tcp.sa.ngrok.io:22754

·       tcp.us-cal-1.ngrok.io:24521

·       5.tcp.ngrok.io:22934

·       7.tcp.ngrok.io:22426

·       9.tcp.ngrok.io:23955

·       9.tcp.ngrok.io:24080

Backup malware configs

·       hxxps://i.postimg.cc/fRnxLLCy/destacada-paisagens2.jpg

·       hxxps://bit.ly/3QhP2oI

·       hxxps://cli.re/kwbaDX

·       hxxps://rebrand.ly/sthpo7e

·       hxxps://bit.ly/49mKne9

·       hxxps://bit.ly/4gf4E7H