Back 
Summary
Ousaban (a.k.a. Javali) is a banking malware that emerged between 2017 and 2018, with the primary goal of stealing sensitive data from financial institutions in Brazil. This malware is developed in Delphi and it comes from a stream of LATAM banking trojans sourced from Brazil, sharing similarities with other families like Guildma, Casbaneiro, and Grandoreiro. Furthermore, the threat often abuses cloud services, such as Amazon S3 to download second stage payloads, and Google Docs to retrieve the C2 configuration.
Netskope Threat Labs came across recent Ousaban samples that are abusing multiple cloud services throughout the attack flow, such as Amazon or Azure to download its payloads and log the victim’s IP, and Pastebin to retrieve the C2 configuration. The malware is downloaded through MSI files either by a JavaScript or a Delphi DLL, and is targeting more than 50 financial institutions in Brazil. Furthermore, we also found Telegram abuse in the malware code, likely used for C2 communication via Webhooks.
In this blog post, we will analyze Ousaban, showing its delivery methods, obfuscation techniques, and C2 communication.
Delivery methods
Ousaban is delivered through malicious MSI files spread in phishing emails. In this campaign, we found that the MSI file downloads and executes the second stage either through JavaScript or a PE file.
Delivery by JavaScript
In the first scenario, the JavaScript is executed via CustomAction.
The JavaScript code is obfuscated, likely in an attempt to slow down analysis.
Looking at the deobfuscated code, these are the steps executed by the malware:
- Creates an empty file to be used as a flag in case the MSI is executed twice (similar concept as Mutex usage);
- Downloads the second stage from the cloud, either from Amazon or Azure;
- Decompress the ZIP file downloaded from the cloud and renames the main executable;
- Sends a simple GET request to another URL (Azure or another attacker-controlled server), alerting the attacker and logging the victim’s IP;
- Executes the main file via WMIC.
Delivery by File
We also found Ousaban being delivered without JavaScript. In this case, we can see a file named “avisoProtesto.exe” being executed via MSI CustomAction.
“avisoProtesto.exe” is a signed and non-malicious binary exploited to execute the malicious DLL via DLL search order hijacking.
This is possible because the non-malicious binary loads a DLL named “crashreport.dll” without specifying the real path of the library. Therefore, the attacker places a DLL with the same name in the same folder of the executable, making it load the malicious DLL instead.
In this case, both next-stage and tracker URL are loaded from a text file, named “FileLinks”.
All the files we analyzed were downloading the next stage from the cloud, either Amazon or Azure. In some cases, the URL used to log the victim’s IP address was also from Azure. All the URLs can be found in our GitHub repository.
Loading the second stage
The binary downloaded from the cloud is a ZIP file containing the next stage payload, which is a Delphi DLL executed by a non-malicious binary.
The file executed by the malware is a non-malicious executable with a valid signature (“Securityo6Z3.exe”).
The malicious DLL is then loaded by the non-malicious binary through a DLL search order hijacking vulnerability, the same technique that is used by some of the downloaders.
Second stage
The second stage is a Delphi malware responsible for decrypting and loading Ousaban’s payload in the following flow:
- Loads the encrypted bytes of Ousaban from disk;
- Decrypts Ousaban payload using a key stored in the “.data” section;
- Decrypts the code that runs Ousaban using the same key, stored in the “.data” section.
The encrypted payload of Ousaban is located among the files downloaded from the cloud, named “ZapfDingbats.pdf”.
Once running, the second stage loads Ousaban’s encrypted bytes, which will be decrypted using the key stored in the PE “.data” section.
