“Brazil has a lot of banking Trojans” – is a sentence folks working the AV industry might have said/heard quite a few times.
Well, here’s a quick analysis on a random Brazilian banking Trojan. Spoiler alert: it’s a mess.
- VT Report – (0/58)
Taking a look into the dropper’s source code, one of its function already shares a lot of information.
So: download a malware, hosted at that URL, unpack it with “unzip.exe” (a resource within the JAR), using the password in this.senhaZ. Reproduce the steps, and we get access to the “main” malware.
- VT Report (8/58)
Small detail about speak.exe:
Themida is, definitely, not the easiest exe protector to get around. Fortunatelly, LCF-AT created an incredibly useful script for situations like these. Thank you! 🙂
After removing Themida, we have a 20mb sized malware. Analyzing the new executable, we’re informed (with 99% certainty) that this file was compiled in Delphi. Before we get into the code, let’s take a look if it has any interesting resources.
We can see some Delphi forms there, and within the forms, some PNG references. I’m showcasing only 8 images up there, but inside the executable there’s more than 80. All of the images are related to brazilian banks.
OK, what about the code? Let’s open it on IDA, put some breakpoints and run.
Anti-VM. We’re going to study it deeper on another post, but, basically, all the protection could be bypassed through a little patch, and that’s what i did. Let’s continue.
Multiple Delphi timers started executing. Let’s analyze each one, and understand the malware.
ClampTimer repeats the execution of function sub_6b8e80. Let’s take a look into that function.
After initializing some variables with 0, this function calls a Windows API function – GetCurrentProcessID. With its return value, and a flag (0x8), it calls a another function – sub_5e11c0.
(Just as a sidenote, notice that parameters are passed through EDX / EAX registers – that’s because Delphi uses the FASTCALL calling convention, where the parameters are passed to the function from right to left, from EDX to EAX – if there’s more parameters, they’ll be passed through the stack. STDCALL – the one used on Win32 API – passes all the parameters through the stack)
The sub_5e11c0 function searches for a pointer to CreateToolhelp32Snapshot. If the pointer exists, it gets called using the parameters we saw earlier. If not, it searches for the function’s pointer in kernel32.dll. Checking Microsoft’s reference for this function, we can assume that the idea here is to list all the modules loaded by speak.exe. After that, with the handle returned from CreateToolhelp32Snapshot, another API is called in sub_5e1220, Module32First, in order to get the first module on the list.
In this block, it verifies if the name of the current module on the list contains the “GBIE” substring. If it doesn’t, it goes to the next block. If it does, it goes to the 5th block.
Same thing as the 2nd block, but with the substring “GBP”.
Same thing as the 2nd block, but with the string “GBIEH.DLL”. Only here, if it doesn’t contain the string, it goes straight to the 7th block.
If some of the modules contain the strings “GBP”, “GBIEH.DLL” or “GBIE”, this block gets executed. Here, it basically gets the handle of the current module on the loop, through GetModuleHandle, and goes to block 6.
It loops FreeLibrary using the it got on block 5, until the library get’s freed. That is, remove any module which the name contains any of the strings we saw.
If the current module on the loop doest not contain any of these strings, it goes back to block 2 with the next module on the list. If there’s no module next, it goes to the other blocks, and the function ends.
Summing up, TLonder_ClampTimer loops through the process’ modules searching for DLLs that matches those strings. GBIEH.dll is part of GbPlugin, a security plugin used by many brazilian banks. This plugin injects a DLL in every running process – probably to hook some API calls.
This timer is a little bit bigger than the function we saw previously. I’ll focus on more important details from now on.
This is a very common behavior on this kind of malware: encrypt strings to hinder automatically analysis. sub_6ba234 is the function responsible to decrypt these strings. That string, in specific, is the name of a file. @UStrCat will concatenate that filename with the %temp% directory, in order to later check if the file exists. If it does, it takes a specific action. All of the blocks, until the the one indicated by the second red line, do that repeatedly. File exists? Take an action. If it doesn’t, go to the next file check.
After those checks, the form TSamptX is created. Apparently, this malware’s developer decided to put all the “helper functions” inside this form. TSamptX_SetUAC, for example, disables Windows’ UAC. TSamptX_CompName gets the computers name, and so on, the name of the functions are self-explanatory. Eventually, it checks if a checkbox is marked, and an important function gets executed: TSamptX_Infect.
TSamptX_Infect is also a very big function, so i’ll sum it up the best i can. This function concatenates a lot of information about the users computer into one big string, sends it to a server, adds itself to currentversionrun, and a couple of other things. For example:
- TSamptX_JukeBox: Checks for the brazilian bank’s security plugins, such as GbPlugin, Scpad and Rapport.
- TSamptX_GetBoX: Checks installed anti-virus softwares.
- TSamptX_AddRun: Installs the malware in WindowsCurrentVersionRun, in order to get executed every time the computer starts.
- TSamptX_post_inf: Sends all the information gathered (which anti-virus / security plugin it found, the computer’s name, the user’s name, etc) to a server.
- TSamptX_Lib32: Installs a driver to help spying on keyboard activity.
And then, a new timer is enabled.
I’d say that this is one of the main timers of this malware. He’s responsible for the “Trojan.Spy.Banker” activity. Also, the code is 3x bigger than the previous timer.
That function graph is a little intimidating, but this big sequence of blocks are nothing more than if statements, one after the other.
It uses some Windows APIs to get the title of the currently focused window. Then, it tries to find a substring, “Google Chrome”, in that title, later it tries to find “Internet Explorer”, “Firefox”, and so on.
Once it’s able to determine if a browser is in focus, it starts to find out if the user is navigating through a brazilian bank website, checking for strings such as “Bradesco”, “Banco do Brasil”, “Santander” in the title. If the user is, it executes a function called TLonder_Start, passing a string of which bank it detected as a parameter.
There are a couple of checks before the block i highlighted, but i want to focus on the important part. What TLonder_Start is doing is stablishing communication with a server. At this point, the malware already determined that the victim is navigating in a bank’s website. Now it’s going to connect to a server to, probably, receive some commands about what it should do next.
TLoader_BancoAtual is the string that identifies which bank it detected: “BB” (Banco do Brasil), “ITAU”, etc. It concatenates this information in a command named “Tapa”.
It later sends another command: “Navi”. We do not know what is happening on the server’s side. At least not for now. But, obviously, the malware will receive some commands.
Alright, taking a look at the code it’s easy to see that the controller it’s using to establish this communication is named TCustomWinSocket. The function that sends information, more especifically, is named SendText. So, there should probably exist one named GetText, or something like that, right? If we find that function, we could cross-reference which functions calls it, and then see if we can understand what happens when the malware receives a command. After a little bit of search, there really is such function. Its name is ReceiveText.
If we map out all the references to TCustomWinSocket_ReceiveText, this is what we get:
Great! Let’s take a look at DezembroRead.
So you thought that there was too much code in TLonder_MoniqueTimer? Take a look at this:
Now that’s a big function. It’d be impractical to analyze every single block here. Instead, let’s sum up this gigantic function’s goal.
The first block identifies which command was received. If the strings match, the second block executes. Each block in the upper line has a corresponding block below, that is, a different action for every single command (obviously). In the example above, the second block is managing the “ITNASCU” command. That string is then passed to the TSamptX_mostra_form function, and that function is equally immense as DezembroRead. TSamptX_mostra_form will show up the form corresponding to the received command. Pretty much all the commands are related to different form combinations, each one to persuade the user to send some sensitive information.
Let’s try to emulate a command being received, and see if we’re assuming correctly:
Exactly what we expected. That infinite number of commands just make slight changes in these panels. If the fraudster needs any specific information, like the victims birthday, he sends a command, and the malware changes the panel.
There are other types of commands. There are commands to get some more information about the infected computer. There are commands to get keyboard activity, and so on. But the idea here is not to catalog every single possibility, but understand the malware’s main functionality and reliably define its intention.
Summing all up
There’s a lot of code in this malware, other Forms to study, other timers to understand. But I believe we have enough information for now:
- Verifies the existence of security softwares, and tries to protect itself from them. It also installs itself on Windows RUN registry key to re-executed every time the computer powers on;
- Monitors user activity by checking the title of the currently focused window. If it finds anything interesting, it connects to a c/c server, and gets ready to start receiving commands;
- Most of the possible commands are to show up brazilian banks forms, in order to persuade the victim to provide sensitive information.
On the victims perspective, everything is very convincing: it browses the bank’s website to pay some bill, logs in, and suddenly mouse and keyboard stops working, and then a bank screen comes up asking for some information. Some, more experienced, would question it, but most are clueless.
Hope you had fun seeing a bit of one of the many (many!) different RATs Brazilians have to deal with on a daily basis. Albeit being different, they mostly perform the same sort of nastiness.