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.
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.
Nothing could be better than using well known command line tools that already have this capability –and most of them are already whitelisted.
Basically, the malware replaces the original NTLDR, the bootloader for Windows NT-based systems up to Windows XP, to a modified version of GRUB.
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.
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.
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.
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.
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.
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.
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”.
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.
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.
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.
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.
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.
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.
securelist
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 whitelisted.
- RegRun Partizan
Partizan RRI script containing the list of files to remove
- The Avenger
The Avenger GUI and script to delete security solutions
- Gmer
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
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
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.
securelist