The ‘AVE_MARIA’ Malware

Ave Maria Malware – Phishing attempts spreading in the last days of the past year against an Italian organization operating in the Oil&Gas sector

The  Cybaze-Yoroi ZLab researchers analyzed phishing attempts spreading in the last days of the past year against an Italian organization operating in the Oil&Gas sector. The malicious emails try to impersonate a supplier’s sales office sending invoices and shipping orders confirmations. As usual, the mail conveys malicious Excel files exploiting the popular CVE-2017-11882 vulnerability to run an executable retrieved from a malicious website, previously compromised by the attackers.

The domains used to vehicle the malicious messages remained active only for few days in the middle of December, just the time needed to spread phishing emails. 

The Cybaze-Yoroi ZLab analyzed and dissected the payload delivered during these days.

Technical analysis

The actual infection chain starts from the self-extracting archive (SFX) dropped by after the opening of the malicious Office document.  The sample contains the image of Kagamine Rin as icon, a character belonging to the singing voice synthesizer software dubbed VOCALOID. 

The file is a WinRAR self-extractor configured to unpack its contents into the temporary folder  “%TEMP%\04505187” and then silently run a specific setup routine:

The timestamp of the compressed files shows the attacker weaponized the archive at 22:56 of 13th December 2018, within the domain activation time-span.

All the files have misleading extension to confuse the analysis and most of them are text files containing junk data. But three of these files deserve further attention:

• xfi.exe: a legit AutoIt interpreter; it is able to execute a specified AutoIt script.
• hbx=lbl: the first AutoIt script; it is obfuscated hiding the instructions among an huge number of comments.
• uaf.icm: file containing all the malware settings such as the installation folder, the interpreter name and other parameters used in the next stages; it is structured according to the “INI file format”.

Similar packing of AutoIT code have been observed even by Juniper back in 2016, where SFX files were abused this way to deliver scripts used as first stage of the malware. As shown in the configuration in Figure 2, the sample able to run the first script using the command:

$> xfi.exe hbx=lbl

At this point, using the encoded data contained into “uaf.icm” between the string pattern “[sData]”and “[esData]”, the first script creates a second one, with a random name (es. “ZZQLZ”), and runs it using “xfi.exe” engine.

The second script is heavily obfuscated using binary-encoding. After deobfuscation, it reveals interesting capabilities. First of all, there are different evasion techniques, such as a check about the current running processes: if there is a process related to some virtualization software, like Virtualbox, the malware kills itself.  

The main purpose of the second script is to decrypt and execute the final payload hidden inside“[Data]” and “[eData]” delimiter strings of the  “uaf.icm” file. The data is decrypted using the “Advapi32.dll!CryptDecrypt” Microsoft function, which is dynamically invoked into the AutoIt script through the high-level API “DllCall”. The decryption key is retrieved from the usual settings file.

It is interesting the way used by the AutoIt script to run the just extracted payload. In the first instance, the malware creates a copy of legit Regsvcs.exe, the .NET Services Installation Tool, into %TEMP% folder and runs it. Then, it performs a process injection in order to start the malicious payload behind the Regsvcs process.

In the following figure, it is shown the routine to extract, decrypt and inject the malicious binary stored into “uaf.icm” settings file.

The malware uses the CallWindowProcW Windows function as process injection technique, through DllCall AutoIt API.

The malware author used a custom shellcode stored into $ASM variable to correctly inject the binary payload into the running regsvcs process. 

Finally, the second AutoIt script provides to set persistence onto the victim’s machine writing the registry key HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run.

The registry key’s name corresponds to the value extracted from “uaf.icm” settings file at the section “Key”.

The Payload: AVE_MARIA Stealer

The payload injected into legit .NET process shows a typical bot behavior: it contacts a C2  hosted on anglekeys.warzonedns[.]com and retrieves the next action to perform. The attacker’ server is currently down, so it is not possible to obtain further stages of the commands.

A static investigation shows the malware looks for the installed e-mail client, like Microsoft Exchange Client or Outlook, to exfiltrate victim’s credentials.

Moreover, the bot is able to decrypt all the credentials stored by Firefox browser. These sensitive data are protected using PK11 encryption from Mozilla Network Security Services, so the malware is weaponized with all the necessary functions decrypt them. 

The malware writer re-used publicly available code to implement this functionality. The following screen shows part of the execution flow (on the left) and a piece of code belonging to a KeePass plugin (on the right) published on github; these two flows are very similar.

In addition, the malware embeds an utility able to bypass the User Access Control within the resource section. It abuses a vulnerability of the “pkgmgr.exe” Windows tool; many resources related to this exploit are publicly available on the internet.

Despite the wide malware’s capabilities, the writer left some evidences referring to his environment into the malicious code.

Finally, another strange string is emerged from the executable: “AVE_MARIA”. Which is used as HELLO message when the malware correctly contacts the C2. This particular string has been elected as common malware name by many researchers of the InfoSec community.

Conclusion

The first stages of the malware, including the AutoIt scripts, are very similar to another malware waves analyzed few years ago by third party security researchers: the malware logic, based on an INI settings file, and some pieces of AutoIt code are the same but the final payload is different. 

It’s possible the author of these malware is the same, showing an increasing complexity of implant, or also the first stage of the malware may have been purchased in the dark markets and the author of the “AVE_MARIA” malware composed a new stealer using publicly available code, forgetting to wipe the information related to him.

Further details, including IoCs and Yara rules are included in the report published in the Yoroi blog:

Pierluigi Paganini

(SecurityAffairs – Ave_Maria malware, phishing)

[adrotate banner=”5″] [adrotate banner=”13″]