The evolution of Brazilian Malware

Introduction

Brazilian malware continues to evolve day by day, making it increasingly sophisticated. If you want to know how the various malicious programs work nowadays, you can jump to the corresponding section here. Meanwhile, before that, we would like to show how the techniques used by Brazilian cybercriminals have changed, becoming more advanced and increasingly complex.

Taking a look at the wider picture we can see that the authors are improving their techniques in order to increase malware lifetime as well as their profits.

Some time ago, analyzing and detecting Brazilian malware was something that could be done pretty fast due to no obfuscation, no anti-debugging technique, no encryption, plain-text only communication, etc. The code itself used to be written in Delphi and Visual Basic 6, with a lot of big images inside making it a huge file, as well as poor exception handling where the process would regularly crash.

Nowadays, the scenario is not the same; the attackers are investing time and money to develop solutions where the malicious payload is completely hidden under a lot of obfuscation and code protection. They do still use Delphi and VB, but have also adopted other languages like .NET and the code quality is much better than before, making it clear to us that they have moved to a new level.

Let’s walk through some samples showing the difference between what we used to find a few years ago and the threats being delivered today.

What we used to find

Keylogger

In the beginning, the first samples used to steal banking information from customers were simple keyloggers, most of them using code publicly available with some minor customizations in order to log only specific situations. At the time it was sufficient since banking websites were not using any kind of protection against this threat.

Public keylogger source code

Code implemented on malicious binary

The code was pretty simple; it just used the function GetAsyncKeyState in order to check the state of each key and then logged it as necessary. Most of the keyloggers were not using any obfuscation to hide the targets, helping in the identification of such attacks.

Plaintext strings used to detect navigation

Phishing Trojan

After the banks introduced virtual keyboard to their systems, the use of keyloggers was no longer effective. To bypass these protections, the Brazilian bad guys started developing mouselogger malware and later Phishing Trojans.

This type of malware was using DDE (Dynamic Data Exchange) in order to get the current URL opened in the browser; this method still works nowadays, but most of these malicious programs have updated their code to use OLE Automation instead of DDE because it provides more advanced options.

Code using DDE to get URL information

After getting the current URL the malware just checks if the URL is in the target list. If found, the malware would show a phishing screen asking for banking information.

Phishing Trojan being shown inside Internet Explorer

At this time the malware was not using any kind of encryption or encoding – all strings were plaintext making the analysis easier.

Malware strings without any encryption/encoding

The stolen information is then sent to the attacker by email.

Email containing the stolen information

Hosts

In order to steal information without making it easy to identify a phishing Trojan they started redirecting users to malicious web pages by changing the hosts file to resolve the banking domain names to hardcoded servers. In this way, after infection it would be more transparent to the user increasing the chances of a successful attack.

Data written to the hosts file in order to redirect access

Code used to write data to host file

These types of attack were very effective at the time, while not all anti-malware vendors were able to identify and block them. We can still see some samples using host modifications, but they are not so effective anymore.

Anti-rootkit

At this stage they realized that anti-malware solutions and internet banking security plugins were making their work more difficult. They then started to focus their efforts on removing security solutions before running the malicious payload in order to increase the chances of a successful execution and to keep running on the infected machine for much longer.

Nothing could be better than using well known command line tools that already have this capability –and most of them are already allowlisted.

• RegRun Partizan

This tool is a Native Executable which runs on system startup before the Win32 subsystem starts up. It is able to delete files and registry keys even if they are protected by Kernel mode drivers, since it is executed before the drivers are loaded to the system. The commands to be executed are specified on the .RRI file as shown below.

Partizan RRI script containing the list of files to remove

• The Avenger

A Windows driver designed to remove persistent files and registry keys. The commands to be executed on the system are written to a script that will be read by the driver once it starts.

The Avenger GUI and script to delete security solutions

• Gmer

Gmer is a well-known rootkit detector and remover with lots of functions to detect rootkit activities on the system as well as delete files by using its own device driver. As it has a command-line interface, it is easy to remove protected files.

BAT file using GMER’s killfile function to remove security solution

More details about banking Trojans using GMER to uninstall security software can be found in a separate blogpost.

Malicious Bootloader

After using anti-rootkits Brazil’s cybercriminals went deeper and started to develop their own bootloaders, tailored exclusively to remove the security solutions from user’s machine. The downloader is in charge of installing the malicious files and then rebooting the machine. After reboot the malicious bootloader can remove the desired files from the system.

Basically, the malware replaces the original NTLDR, the bootloader for Windows NT-based systems up to Windows XP, to a modified version of GRUB.

Modified GRUB loader acting as NTLDR

This loader will read the menu.lst file that points to the malicious files already installed on the system xp-msantivirus and xp-msclean.

Menu.lst file containing the parameters to execute malicious commands

When executed the malware will remove files related to security solutions and then restore the original NTLDR files that were previously renamed to NTLDR.old.

Commands executed to remove security modules and restore the original NTLDR

What we have nowadays

Automation

Most banks were using machine identification to prevent unauthorized attempts to perform operations using the stolen information. To bypass this the bad guys started performing the malicious operations from the infected machine, by using Internet Explorer Automation (formerly OLE automation) to interact with the page content.

The first samples using this type of attack were Browser Helper Objects (BHOs) that could detect a transfer transaction and then change the destination account, sending the money to the attacker instead of the real destination.

Later, the same method was heavily used in Boleto attacks, where they were using automation to get the inputted barcode and then replace it with the fraudulent one.

Since this method only works for Internet Explorer, the malware needs to force the user to access internet banking via that browser. Therefore, it implements a timer which checks if Firefox or Chrome is being used and then kills the process.

Code to avoid use of Chrome and Firefox

When an instance of IE is found, the malware will search for a tab instance in order to be able to read the window text and then to know which URL is being accessed.

Finding the tab handle and obtaining the URL being accessed

Search for target’s specific titles

As the automation will process the page structure, it needs to know if the victim is on the page to input the Boleto information. It installs a handle to the event OnDocumentComplete in order to collect the full URL as soon as it is loaded and then checks if the user is on the target page.

Search for target’s specific pages

After confirming that the user is on the target page, the malware will process the page structure and install a handler to the submit button, then it can take control of the execution right after the user has submitted the page and then process the inputted content.

Search for a specific textbox and get the inputted data

After collecting the inputted data, it can be processed and then changed to the malicious content before submitting the page.

For those samples we could find, string obfuscation, debugger detection and virtual machine detection as well as this method mean they are not as easy to detect as other attacks involving phishing Trojans and hosts.

Code Obfuscation and RunPE

Looking for new ways to bypass detection, Brazilian criminals started using obfuscation in order to hide the parts of code that perform their main operations.

In the code below the coder has encrypted the original code of the function used to download the malicious payload; on a static analysis you cannot figure out what the purpose of this function is.

Encrypted downloader function

In runtime the malware will call the function to decrypt this code prior to executing it.

Decrypt code call

Decryption routine

As we can see in the code above, the decryption is a simple sub operation using the key 0x42 on the encrypted byte – a simple and fast way to hide parts of code.

Decrypted downloader function

In order to avoid detection by a network firewall, the downloaded file is encrypted using its own encryption function.

Encrypted file

Decrypted file

The encryption function is also hidden by using the same method used in the download function – after decrypting the code we can find a XOR-based encryption combined with a shift-right operation on the XOR key.

After decrypting the file, it will not be executed using the normal methods usually found in malicious code. To hide the process on the machine the malware uses a trick known as RunPE where the code will execute a clean process (like iexplorer.exe or explorer.exe) in a suspended state and then modify its memory content to the malicious code and execute.

Code launching clean process as suspended state

After creating the process in a suspended state the code will write the new code to the memory space, set the new EIP for execution and then resume the thread.

Writing malicious code and resuming the thread

Internet explorer process hosting the malicious file

Since the malicious code is running on the memory space allocated to Internet Explorer, using tools like Process Explorer to verify the publisher signature does not work because they check the signature of the process on the disk.

It was clear that they had moved on completely from using beginner’s code to a much more professional development and we realized it was time to update the analysis process for Brazilian malware. We are sure most of this evolution happened due to contact and the exchange of knowledge with other malware scenes, mostly those in Eastern Europe, which we described in this article.

AutoIt Crypto

AutoIt is now often used as a downloader and crypto for the final payload in order to bypass detection. After being compiled the AutoIt script is encrypted and embedded to the generated binary which makes it necessary to extract the original script before analyzing its code.

Looking for a better way to hide the final payload, the Brazilian cybercriminals have developed a new crypto using AutoIt language where the decrypted payload is executed by using a RunPE technique.

AutoIt Crypto execution flow

The crypto uses two different methods to store the encrypted file: the first one is by using the FileInstall function that already exists on AutoIt, and the other one is embedding the file at the end of the binary.

When using the second method the crypto writes a key which is used to mark where the encrypted payload content starts and is then able to find the content to decrypt. On the sample below, the key used is a short version of “Sei que ganharei 20K” which means “I know that I will win R$ 20,000”.

Key used to mark where the encrypted payload starts

AutoIt Crypto main code

After reading the encrypted payload it decrypts the content using the decryption key “VENCIVINICI” and then executes the malicious payload using RunPE.

The decryption function code is not written in AutoIt – it is written in C language. After being compiled the bytes are included in the code as a string and then mapped to memory and executed by using CallWindowProc API.

Decryption function implementation

We found the following algorithms being implemented as the encryption/compression method for this crypto:

• RC4
• XXTEA
• AES
• LZMA
• ZLIB

The use of AutoIt for malware development is not something new, but in the middle of 2014 we saw a wave of attacks using AutoIt in Brazil, as we can see on the graph below.

Trojan.Win32.Autoit: number of users attacked in Brazil

MSIL Database

Another type of malware that emerged recently was malware developed in .NET instead of Visual Basic 6.0 and Delphi, following a trend we saw worldwide. It is not hard to find a downloader written in .NET. Anyway, some samples of Trojan-Banker.MSIL.Lanima grabbed our attention when we found some of them were not using functions commonly used to download the payload.

Download function

As we can see in the picture above this samples does not use any download function because it uses SQL Server to host the binary content and then just uses an SQL command to retrieve the content and save to disk.

The strings are encoded with base64 and encrypted with Triple DES algorithm in order to hide the text related to the main actions of the malware.

Decrypt function

This family of malware is very prevalent in Brazil and China:

MSIL Crypto

Following the same method used by AutoIt Crypto the bad guys developed another crypto, this time using .NET language. The process to extract the real executable is almost the same as AutoIt Crypto but it has an intermediate module which is responsible for extracting the final payload.

Looking at the main module we have a .NET code and the main function of this main module is to extract and load the embedded DLL.

.NET Crypto execution flow

Crypto main function

As we can see, the function above will split the binary content by using the separator string “cdpapxalZZZsssAAA” and use the second block which contains the encrypted code of the Loader DLL.

Loader DLL encrypted content

Then it is time to decrypt it by calling the function named “fantasma” (or “ghost” in English), the official name used for this crypto in the forums is PolyRevDecrypt which is basically an XOR operation between the encrypted byte, the last byte of the encrypted buffer and one byte of the password provided to the function.

Decryption function

After being decrypted, the code will be loaded and executed by the function “docinho” (or “candy” in English).

Function to load and execute the DLL

The code of the library is almost the same as the main executable except that now it will use the second block of the split content.

Loader DLL main function

RAT

In a bid to reduce the losses related to cyber attacks, banks implemented two-factor authentication using a hardware token and SMS token for online banking transactions in addition to the solutions already in place like machine identification. To solve this problem the cybercriminals have created a remote administration tool specially developed to request the information required to process internet banking transactions.

RAT execution flow

The browser watcher will monitor the user browser and see if any of the target banks are accessed; if they are, it will decompress and execute the RAT Client and notify the C&C about the new infection.

Internet banking access monitoring

The strings used by this malware are encrypted using their own encryption routine. After decrypting it we are able to identify the targets as well as the important parts of the code.

Decrypted strings

For this type of infection it is common for the bad guys to create a way to manage the attacks. Here we can see the number of computers infected on the same day, keeping in mind that this number means the amount of users that have accessed internet banking while the malware was running on their computer.

C&C panel showing the list of infected users

The RAT Client will connect to the server to alert the attacker that a new victim is accessing the internet banking system. It is then possible to execute the attack in real time.

RAT Server showing a new victim is connected

At this stage the attacker just needs to wait for the user to login and then proceed with the attack. When the user is already logged in, the attacker can see the user screen, lock it and control the execution as well as ask for specific information that will help him to steal the account, like:

• Token
• Access card code
• Date of birth
• Account password
• Internet banking password
• Electronic signature

To prevent the user from seeing that the computer is being remotely controlled, this RAT has a function that simulates an update for the bank security plugin showing a progress bar and disabling all user interactions. Meanwhile, the attacker can perform the banking operations by using the active browser section because the overlay screen is not shown to the attacker.

Lock screen simulating an update

If some information is requested to confirm the transaction, e.g. SMS token, the attacker can ask the victim who will think the information is necessary in order to proceed with the update process.

Screen asking for token code

As soon as the user provides the information, the attacker can enter it on the internet banking screen, bypassing the 2FA used in the transaction.

Information received from the victim

Ransomware

Brazilian cybercriminals not only work with banking malware – they are also exploring other types of attacks involving ransomware. Some years ago, we found TorLocker which contains details inside the malware code suggesting that the developer is from Brazil.

Code containing some strings suggesting the author is from Brazil

As we can see in the image above, we found the sentence highlighted in blue: “Filho de Umbanda não cai!” (“Umbanda’s son never falls down”). Umbanda is an unorthodox religion in Brazil. The name marked in red is the nickname of the author and it also uses the extension .d74 for the encrypted files. This user is very active on underground forums looking for malicious services in Brazil.

We also found other references, like the use of a service in Brazil to get the victim IP in order to notify about an infection.

Request to a Brazilian service to obtain the victim IP

Some months ago, we found another ransomware program based on the Hidden Tear source code that was modified to target Brazilian users, differing from the initial program that was found targeting English- and Japanese-speaking users.

Victim’s machine showing messages in Portuguese, asking to pay in order to receive the files

Why they evolve

We have sufficient evidence that Brazilian criminals are cooperating with the Eastern European gangs involved with ZeuS, SpyEye and other malware created in the region. This collaboration directly affects the quality and threat level of local Brazilian malware, as its authors are adding new techniques to their creations and getting inspiration to copy some of the features used in the malware originating from Eastern Europe. Brazilian cybercriminals are not only developing the quality of their code but also using the cybercrime infrastructure from abroad.

We saw the first sign of this ‘partnership’ in the development of malware using malicious PAC scripts. This technique was heavily exploited by Brazilian malware starting in 2011 and was later adopted by Russian banking Trojan Capper. This cooperation continued as Brazilian criminals started to use the infrastructure of banking Trojans from Eastern Europe – the Trojan-Downloader.Win32.Crishi was the first to use DGA domains hosted at bulletproof companies from Ukraine. Also the Boleto malware adopted the massive usage of fast flux domains, aiming to avoid the takedown of C2s – we saw that with the “bagaça” (bagasse in Portuguese) domains, registered using anonymous services, which hosted crimeware and boleto stuff and was resolving different IPs for every request.

The “bagaça” domains: fast flux and bulletproof from Eastern Europe

Other strong signs of their cooperation are the constant presence of Brazilian cybercriminals on Russian or Eastern European underground forums. It’s not unusual to find Brazilian criminals on Russian underground forums looking for samples, buying new crimeware and ATM/PoS malware, or negotiating and offering their services. The results of this cooperation can be seen in the development of new techniques adopted in Brazilian malware.

The Brazilian malicious author of TorLocker negotiating in a Russian underground forum

These facts show how Brazilian cybercriminals are adopting new techniques as a result of collaboration with their European counterparts. We believe this is only the tip of the iceberg, as this kind of exchange tends to increase over the years as Brazilian crime develops and looks for new ways to attack businesses and regular people.

Conclusion

Cybercrime in Brazil has changed drastically in the last few years, as it shifted from simple keyloggers built from public source code to tailored remote administration tools that can run a complete attack by using the victim machine.

Malware that used to show a phishing screen as soon as it was executed is now completely reactive and waits for a valid session in order to start the job.

That means that the criminals are investing much more money and time in order to develop their malicious code, enhancing anti-debugging techniques and then running the malware undetected for much longer.

As we know, they are in touch with cybercriminals from Eastern Europe, mainly Russians, where they exchange information, malware source code and services that will be used in Brazilian attacks. We can see that many of the attacks used in Brazil were first seen in Russian malware as well as Brazilian techniques later being used in Russian attacks.

Based on that, we can expect to find Brazilian malware with enhanced code obfuscations, anti-debugging tricks, encryption algorithms and secure communications making our work much harder than now.