Zscaler Blog

Get the latest Zscaler blog updates in your inbox

Dynamic Approaches seen in AveMaria's Distribution Strategy

STUTI CHATURVEDI, MEGHRAJ NANDANWAR

February 04, 2023 - 15 min read

Contents

Introduction
Key Takeaways
Analysis of AveMaria 2022 Case Studies
Conclusion
Zscaler Coverage
Indicators Of Compromise (IOCs)
More blogs

Introduction

Zscaler’s ThreatLabz research team diligently monitors and tracks active threat campaigns globally to rapidly detect new developments and proactively safeguard Zscaler customers. The seven case studies that follow provide an in-depth analysis of the AveMaria infostealer attack chain and how it has been shifting over the past six months.

Key Takeaways

AveMaria is a Remote Access Trojan (RAT) infostealer malware that targets sensitive data with added capabilities of remote camera control and privilege escalation. This stealer has been growing in popularity among threat actors since appearing in December of 2018.
Over the past six months, researchers have observed significant changes and additions to the execution stages and Tactics, Techniques, and Procedures that characterize an AveMaria attack.
AveMaria attacks are initiated via phishing emails, once the dropped payload infects the victim’s machine with the malware, it establishes communication with the attacker’s Command-and-Control (C2) server on non-HTTP protocol, after decrypting its C2 connection using RC4 algorithm.
The most recent variation in the AveMaria attack chain technique leverages a custom downloader that decrypts a disguised payload by converting the value data type to another, known as type casting.

Analysis of AveMaria 2022 Case Studies

This section details different variations of the AveMaria stealer attack chain analyzed across samples discovered between July and December of 2022. The case studies included below specifically focus on how different file formats and techniques are used to execute the AveMaria end payload on the victim’s machine, instead of directly dropping and executing the malware.

DECEMBER | .Vhd(x)_campaign

In December, ThreatLabz researchers identified the AveMaria .Vhd(x) campaign. This campaign is defined by the discovery of a new execution technique that uses the Virtual Hard Disk file format to drop the malicious downloader payload in one of the two formats onto the victim’s machine.

FIRST CASE STUDY

.Vhd(x) campaign Targeting Kazakhstan Officials

Fig. 1 - AveMaria .vhd(x)_campaign First Case Study attack chain

In this scenario, phishing emails impersonating the Russian government targeted Kazakhstan officials with a malicious .vhdx file disguised as a fake meeting notice.

Fig. 2 - Screenshot of a phishing email targeting Kazakhstan officials with malicious .vhdx file attachment designed to launch an AveMaria infostealer attack.

Upon executing the attached .vhdx file, researchers observed the creation of a new system drive (see Tag 1 in Fig. 3 below) containing a malicious .lnk file, a decoy file, and other system related files (see Tag 2 in Fig. 3 below). Triggering the malicious shortcut file downloads another payload via curl command (see Tag 3 & 4 in Fig. 3 below) and drops the malicious file in the impacted system’s temp directory. Finally, execution of the final payload infects the victim’s machine with the AveMaria malware and enables attackers to gain access and take control.

Fig. 3 - Behavioral analysis of the .vhdx file and shortcut file
SECOND CASE STUDY

Fig. 4 - AveMaria .vhd_campaign Second Case Study attack chain

Under the same campaign, researchers observed another variation of the attack chain with a custom downloader and other system related files, as shown in Fig. 5 below. Unfortunately the phishing email for this case study is unavailable, so researchers can not identify the target of these attacks or deduce exactly how the initial payload (.vhd file) was delivered.

Fig. 5 - Malicious payload file properties of custom downloader

Stage 1: Custom downloader

The custom downloader used in this AveMaria attack chain retrieves an encrypted file from a third party file sharing website and after downloading and decrypting in memory, it executes the decrypted version of the retrieved payload, which is in PE format. Because the downloaded payload comes as a data file it can successfully evade detections by AV engines.

Fig. 6 - Shows the decryption logic to get the second stage payload in PE format.

To build the downloaded file in PE format, the custom downloader makes use of type casting or type-conversion mechanism whereby different data types are used to manipulate the values at bit level.

Manipulation of Bits Via Type Casting

In C# programming, the byte data type is represented by an 8-bit unsigned integer, i.e. it only takes positive values and will ignore the signed bit associated with the value.

In the current decryption scenario, the custom downloader gets the handle and an offset of an array and via “for loop” gets a byte value at particular offset, thereafter convert it to an integer data type and subsequently subtract it with the hardcoded value (which in our case is “585” and can be different in other cases) resulting in negative integer value. Then, the negative integer value gets converted to a byte data type. And the hex value of the byte data type will get substituted at the particular offset of an array.

It is worth noting that the integer type holds 32-bits of data compared to a byte which holds only 8-bits of data. Converting any integer data type to a byte data type results in the computer only reading the last 8-bit value.

For example, converting a hex value 0xB8 from the encrypted array holding “This program” string to an integer data type results in “184”, and subtracting it with “585”, the final value is “-401”, which is represented in binary as:

“1111111111111111111111111111111111111111111111111111111001101111”

Going the other way and converting the integer data type to byte data type, the system will read only the last 8-bit value, which in binary is “01101111”. So the hexadecimal value of the mentioned binary value will be “0x6F”, as shown below, and the converted ASCII value of “0x6f” is “o”, which is a part of the “This program” string.

Fig. 7 - Calculation of bits manipulation

Stage 2: Second stage DLL

Dumping the decrypted file from memory, achieved in Stage 1, results in a .Net DLL binary without exports. The DLL binary consists of encrypted bytes under the resource section named “a”, passed as an argument to the decryption function to reveal the final AveMaria payload, as shown below.

Fig. 8 - Decryption Code In Second Stage DLL

This is the final stage of decryption, after which the AveMaria payload is executed and kicks-off C2 communications validating the successful execution of the malware on the victim’s machine.

October | AUloader_campaign

THIRD CASE STUDY

Fig. 9 - AveMaria AUloader_campaign Third Case Study attack chain

The third case study named AUloader was also observed by ThreatLabz researchers in October. It uses the same phishing email technique to distribute the main malicious binary. This campaign leverages a highly obfuscated Autoit script and Autoit interpreter to decrypt the AveMaria binary in memory and then execute the payload.

The Autoit script is bundled into a self-executing compressed file or executable package known as the parent payload, which consists of all the required components to facilitate the execution of the main malware. The main components are:

Vbscript: performs sandbox and AV emulator checks and provides the Autoit script to the interpreter.
Autoit Interpreter: runs the script.
Autoit Script: contains highly obfuscated payload decryption and malware execution logic.

Note: The bundled payload might include or consist of decoy and junk files, with no relevance to the malware or to the attack execution flow.

The related phishing email analyzed during this case study (shown below) invites the recipient to submit a competitive quotation offer for an unidentified tender. Requesting a quote is a common practice businesses use to procure fair goods and services. However in this case, the attached zip file sent with the email invitation is malicious and designed to result in an AveMaria infostealer attack.

Fig. 10 - Phishing email imitating to be a Tender Invitation

After extracting the payload from the attached zip file the bundled parent payload is revealed.

The file artifacts and its execution flow are as follows:

Tag1: File is compressed (bundled payload).
Tag2: Drops malicious and decoy files on execution.
Tag3: Parent file calls wscript.exe with an argument of dropped malicious vbscript file. The vbscript file then calls out the malicious Autoit script with the interpreter. The execution of Autoit script then leads to process injection of malware into a legitimate file.
Tag4: Payload loaded in RegSvcs.exe memory.
Tag5: Obfuscated Autoit script.

Fig. 11 - Behavior flow of the extracted file

September | Phishing Campaign Targeting Serbian Citizens and Vbs_campaign Purchase Order Scam

In September, researchers discovered two different AveMaria malware delivery phishing campaigns, first an e-identification portal login credential scam that targets Serbian citizens and second a purchase order scam requesting an invoice payment.

FOURTH CASE STUDY

Phishing Email campaign targeting Serbian Citizens

Fig. 12 - AveMaria Fourth Case Study attack chain

In this campaign, Serbian citizens were targeted with a phishing email impersonating the government of Serbia and prompting them to update and store new login credentials for access to the government e-identification portal.

Fig. 13 - Phishing email impersonating eID.gov.rs

Eligible citizens of Serbia and foreign nationals use an e-identification portal to register for eCitizenship which gives them single-sign on access to all related government portals from a single platform.

Fig. 14 - Legitimate Serbian eCitizen registration site

The attached zip file (see Fig. 13) contains the malicious AveMaria payload, which when executed creates a copy of itself at the %userprofile%\document location. To further evade detection by Windows defender at runtime, the malware author(s) added the functionality to exclude the whole drive prior to the initialization of the copied file for further infection, via powershell command as shown below.

Fig. 15 - Attackers evade detection by Windows defender by adding this drive exclusion powershell command

Once the malicious packed binary, named Adobe5151.exe, is executed, it decrypts the end payload, steals user sensitive information and establishes C2 communication for performing exfiltration of the stolen data.

FIFTH CASE STUDY

vbs_campaign or Purchase Order Scam

Fig. 16 - AveMaria vbs_campaign Fifth Case Study attack chain

In the same month, researchers discovered another phishing campaign imitating a generic purchase order payment request with a malicious payload disguised as a fake invoice attached to the email. A key differentiator in this particular attack chain is the various stages of obfuscation and execution.

Fig. 17 - Phishing email

Extracting the vbscript from the attached zip file what looks like a pdf filetype but appears with a script file icon, which serves as an indicator that the file is in fact a script disguised as a pdf.

Fig. 18 - Extracted vbscript file appears to have a .pdf filetype extension with a mismatched script file icon

Stage 1: VBscript

The vbscript (see Star 1 in the screenshot below) which is in an obfuscated format, on execution, calls out powershell.exe with commands consisting of two downloading urls (see Star 2 in the screenshot below).

Fig. 19 - Vbscript file artifacts and behavior

The interesting fact is that the vbscript provided only two downloading urls (as an input), but as can be seen above (see Star 3 in Fig. 19), three files were downloaded and all of them are obfuscated in some or the other manner.

The downloaded files were all base64 encoded, which after decoding turns out to be

an injector .Net binary dll (base64 encoded)
a supporting dll (base64 encoded filled with replaceable value)
AveMaria payload in reversed base64 encoded format

Stage 2 : Injector DLL

Decoding the dll2.txt file reveals a dotnet DLL binary that acts as a downloader and injector to execute the end payload.

Instead of directly downloading and executing the malware onto the system, threat actors use a custom binary to download supporting DLL and restore the same. Subsequently, it downloads the reversed base64 encoded AveMaria payload and puts it back to base64 format. Once all the required files are in place, the same will be used to perform process injection as shown below.

Fig. 20 - Code inside custom downloader

Stage 3: Actual AveMaria binary

The file named jfgfhhjhgjkj.txt is the actual AveMaria payload, downloaded in the reversed base64 encoded format. After restructuring and decoding, the main payload is revealed. The screenshot below shows the file properties and strings present inside the malicious payload.

Fig. 21 - File properties showing malicious AveMaria payload artifacts

August | Phishing Campaign Targeting Ukraine Officials

SIXTH CASE STUDY

Fig. 22 - AveMaria Sixth Case Study attack chain

In August, researchers observed a new phishing campaign targeting Ukrainian officials impersonating a representative from the Ukrainian Department of Economic Policy and Strategic Planning. The featured phishing emails included an ISO file attachment containing the malicious AveMaria payload along with three decoy documents and four shortcut files.

Fig. 23 - Phishing email impersonating a representative of the Ukrainian Department of Economic Policy and Strategic Planning

All the shortcut files examined from the attached ISO file in this campaign contain the same powershell command that searches for a hardcoded filename in each drive, as shown below.

Fig. 24 - PowerShell Commands in shortcut file

The file named gov12.exe is the actual Avemaria executable which on execution creates a copy of itself with the hardcoded filename images.exe at %userprofile%\documents folder location, adds run key in the registry to achieve persistence and then initiates the copy for further infection.

Fig. 25 - Persistence

JULY | mshta_campaign

SEVENTH CASE STUDY

Fig. 26 - AveMaria Seventh Case Study attack chain

In the seventh case study attack chain, researchers observed that the “System Binary Proxy Execution” detection evasion technique is used for executing the end payload. A malicious HTA file consisting of a vbscript code under <script> tag, is used to download the end payload. The phishing email file associated with this attack chain was unavailable, but we anticipate that the .iso file is being distributed as an attachment only.

Stage1: Shortcut files

The shortcut files extracted from the attached ISO file consist of a powershell command and some obfuscated code decrypted at runtime by the powershell binary. Executing shortcut files downloads malicious .hta extension file and thereafter executes the latter via mshta.exe.

Fig. 27 - Shortcut file artifacts and behavior

Stage 2: HTA file generating third stage powershell code

The .hta file consists of a vbscript under <script> tag generates an obfuscated third stage powershell code when executed and then the latter is passed as an argument to legitimate powershell binary for further execution.

Fig. 28 - Obfuscated third stage powershell script

Stage 3: Generated PowerShell code

After researchers decoded and beautified the obfuscated script a legible powershell script was revealed containing the following key functions:

1.) Main function: contains the logic to check for file at %appdata% folder (see blue bracket on the right in the screenshot below)

if true, then execute the same via “Invoke-item” command.
If false, then logic to download and execute the same.

2.) Decoding function: contains the logic to decode encoded data (see red box in the screenshot below)

3.) Downloading function: contains code related to initiating web connection object which downloads the files (see green box in the screenshot below)

Fig. 29 - Decrypted and beautified version of powershell script

The powershell script shown above downloads and executes the AveMaria stealer malware onto the target system in the last stage of the attack.

Note: In this attack, a website was compromised to host malicious payloads.

Conclusion

From the case studies detailed in this analysis, it is evident that the developers of the AveMaria infostealer are actively maintaining the malware and updating the phases and stages of execution with new techniques to ensure the stealer remains relevant by evading detection. While examining the various TTPs over a span of six months, ThreatLabz researchers observed a multitude of changes to the AveMaria malware distribution mechanisms typically updated monthly, so that even if one mechanism is flagged by security operators the others can still be applied effectively.

Zscaler Coverage

Zscaler Sandbox detected and analyzed the full behavior of the different files, showcasing threat scores and number of MITRE ATT&CK techniques triggered, as shown in the below screenshots.