Nov 13, 2021
0 0

Ousaban: Private photo collection hidden in a CABinet

Written by

Another in our occasional series demystifying Latin American banking trojans
Ousaban is a Latin American banking trojan active exclusively in Brazil. ESET has been tracking this malware family since 2018. In common with most other LATAM banking trojans, Ousaban uses overlay windows to steal credentials and more from financial institutions. However, unlike most other LATAM banking trojans, Ousaban’s developers have extended the use of overlay windows to steal credentials from popular regional email services. In this installment of our series, we examine its main features and many connections to other Latin American banking trojan families.
Ousaban is written in Delphi, as are the vast majority of the other Latin American banking trojans ESET is tracking. And, as do many of them, Ousaban shows signs of active and continuous development.
The name ESET assigned to this family is a portmanteau of two words – “ousadia”, which means “boldness” in Portuguese, and “banking trojan”. The reason for such a name is that for a very long time, Ousaban was distributed alongside the images (some of them obscene) shown in Figure 1. In the most recent campaigns distributing Ousaban, this is no longer the case.
Figure 1. Various images distributed alongside the Ousaban banking trojan
Ousaban is also known as Javali, a name assigned by Kaspersky. A recent article about Ousaban can be found here. ESET has also been able to attribute Ousaban to the campaigns described in this blogpost from 2018. Even though some sources claim Ousaban is active in Europe, ESET has never observed any campaign spreading this banking trojan outside of Brazil.
Ousaban protects its executables with either Themida or Enigma binary obfuscators. Additionally, most EXEs are enlarged, using binary padding, to approximately 400 MB, likely in order to evade detection and automated processing.
Most recent Ousaban variants contain a string table to hold their strings, storing this table in their .rsrc sections. One of the resources contains a zlib-compressed list of strings delimited by newline characters.
Its backdoor capabilities are very similar to a typical Latin American banking trojan – simulating mouse and keyboard actions and logging keystrokes. The latest variants communicate with C&C servers using RealThinClient – a protocol also used by Grandoreiro.
The typical Latin American banking trojan attacks users of financial institutions using overlay windows crafted specifically for its targets and Ousaban is no exception. Interestingly though, its targets include several email services that it has overlay windows ready for as well, as illustrated in Figure 2.
Figure 2. Overlay window design for the UOL email service
To achieve persistence, Ousaban either creates a LNK file or a simple VBS loader in the startup folder, or it modifies the Windows registry Run key.
Ousaban is distributed mainly through phishing emails (such as the one in Figure 3). The threat actor behind Ousaban cycles through multiple distribution chains. These chains share some common characteristics, mainly:
Figure 3. Recent spam email distributing Ousaban (a rough translation is provided on the right)
This distribution chain, illustrated in Figure 4, is quite straightforward. The victim is misled into executing an MSI attached to the phishing email. When executed, the MSI launches an embedded JavaScript downloader that downloads a ZIP archive and extracts its contents. It then executes the legitimate application, which side-loads the Ousaban banking trojan.
Figure 4. Simple Ousaban distribution chain
Recently, ESET has observed a new distribution chain spreading Ousaban massively. It is much more complicated than the one described above. The whole process is illustrated in Figure 5.
The first two stages are almost identical. In both, the core of the stage is contained in an archive (ZIP or CAB) and contains:
The legitimate application, when executed, side-loads the injector. The injector locates, decrypts and executes the downloader. The downloader decrypts the configuration file to obtain a URL leading to a remote configuration. The remote configuration contains a URL leading to the next stage archive. The downloader downloads the next stage archive, extracts its contents and executes the legitimate application.
The final stage is slightly different, as it decrypts and executes the actual Ousaban banking trojan instead of a downloader. The third configuration file leads to a remote configuration with C&C server IP address and port. The archive with the last stage contains one more malware-related file – a support module that alters various settings of the victim’s machine. Finally, the archives for all three stages include additional files – a single legitimate executable in the first-stage archive, 14 legitimate files in the second-stage archive, and 13 legitimate files in the third-stage archive plus an embedded archive containing a further 102 legitimate files.
Figure 5. Ousaban’s complex distribution chain
Ousaban loads this module to make it easier for the threat actor to connect to the victim’s machine. It mainly:
The module contains the RDPWrap binaries stored in its .rsrc section. It then changes the RDP settings directly in the Windows registry at:
The module then uses netsh.exe to modify the Windows firewall to allow all TCP and UDP traffic directed to port 3389, the standard port for RDP. Finally, it creates a new account Administrat0r with administrative privileges. We hypothesize that the threat actor wants to have a second way to access the victim’s machine; the threat actor is then not limited by the capabilities of the Ousaban banking trojan and can perform any malicious activity.
Ousaban utilizes three cryptographic schemes overall. Its strings are encrypted with an algorithm used by the vast majority of Latin American banking trojans we have analyzed (we have previously described it in detail here). All communications between Ousaban and its C&C server are encrypted using the standard AES cipher with a hardcoded key.
The final algorithm is used in the previously mentioned injector specific to this family. We provide a Python implementation in Figure 6.
Figure 6. Algorithm used by Ousaban’s injector to decrypt its payloads
Ousaban relies on remote configuration to obtain its next stage URLs and the C&C address and port to use. Ousaban used to store its remote configuration on YouTube, similar to Casbaneiro, but lately it has started using Google Docs instead.
The remote configuration is in JSON format with the values being encrypted by the same algorithm used for strings, but with a different key. The fields have the following meaning:
Examples of the remote configuration are provided in Figure 7 and Figure 8.
Figure 7. Ousaban remote configuration on YouTube
Figure 8. Ousaban remote configuration on Google Docs
We have already mentioned some similarities between Ousaban and other Latin American banking trojans previously analyzed in this series (like the same string decryption algorithm). During our analysis, we discovered additional links to the other families, mainly:
We analyzed the interestingly close cooperation between these malware families in depth in our white paper presented at the Virus Bulletin 2020 conference.
In this installment of our series, we looked at Ousaban, a Latin American banking trojan targeting only Brazil. This malware family has been active since at least 2018 and shares typical characteristics of this type of threat – it is written in Delphi, contains backdoor functionality and attacks using overlay windows.
We have covered its most typical features, distribution and execution methods and the structure of its remote configuration. We also discovered several leads that suggest Ousaban is linked to some other Latin American banking trojans.
For any inquiries, contact us at Indicators of Compromise can also be found in our GitHub repository.[.]com/document/d/1o9MlOhxIJq9tMOuUHJiw2eprQ-BGCA_ERnbF54dZ25w/edit[.]com/document/d/1nQqifeYFsCcI7m-L1Y1oErkp50c-y670nfk7NTKOztg/edit[.]com/document/d/13A6EBLMOOdvSL3u6IfyrPWbYREXNRVdDTiKzC6ZQx7U/edit[.]com/document/d/1UiuqrzI_rrtsJQHqeSkp0sexhwU_VSje8AwS-U6KBPk/edit[.]com/document/d/1VKxF3yKbwQZive-ZPCA4dAU1zOnZutJxY2XZA0YHa3M/edit[.]com/document/d/19bXTaiFdY5iUqUWXl92Js7i9RoZSLJqcECgpp_4Kda4/edit[.]com/document/d/1DDDmJzBVcNWhuj8JMRUVb7JlrVZ5kYBugR_INSS96No/edit[.]com/document/d/1UbfOcHm-T9GCPiitqDRh5TNwZRNJ8_miEpLW-2ypU-I/edit[.]com/document/d/1d1903AvDBYgOo0Pt9xBBnpCHwSerOpIi4l1b6M4mbT4/edit[.]com/document/d/1JLuJKoxcd0vRqut8UeBjFJXzMDQ9OiY2ItoVIRq6Gw8/edit[.]com/document/d/1EOwVDlYPV3gE7PSnLZvuTgUQXvOSN9alyN5aMw7bGeI/edit[.]com/document/d/18sc6rZjk529iYF2iBTsmuNXvqDqTBSH45DhSZpuLv_U/edit
Note: This table was built using version 8 of the MITRE ATT&CK framework.


Article Categories:

Comments are closed.