A look at recent Tinba Banking Trojan variant

Introduction 

Tinba is information stealing Trojan. The main purpose of the malware is to steal information that could be browsing data, login credentials, or even banking information. This is achieved through code injection into system process (Winver.exe and Explorer.exe) and installing hooks into various browsers like IExplorer, Chrome, Firefox and Opera.

Tinba has been known to arrive via spammed e-mail attachments and drive-by downloads.  Recently, Angler Exploit Kit instances were also found to be serving Tinba banking Trojan as seen here.

Detailed Analysis of Tinba

Tinba is packed with a custom packer and uses well known anti-debugging technique using the WinAPI function “IsDebuggerPresent” to hinder reverse engineering of the binary image. The execution flow of the infection cycle for Tinba is shown below.

Execution flow of Tinba

The image below shows the custom packer code being used by the Tinba sample we were looking at.

Tinba unpacking Routine

The unpacked binary image is shown below which upon execution will perform code injection into system processes like Winver.exe and Explorer.exe.

Unpacked Binary

It generates Mutex name using root volume information of the victim’s machine as shown below.

Mutex name generation

Remote Thread in System Process
 
A remote thread is created inside Explorer process that is responsible for creating a copy of Tinba Binary in %APPDATA% & auto start registry entry in Registry hive.

Explorer remote thread

The Tinba binary is stored in a hidden folder which is created under %APPDATA% directory:

 C:\Documents and setting \username \Application Data\mutexname\bin.exe

It also creates an auto-run registry entry to execute Tinba binary during every windows start-up as shown below:

Auto start registry entry

Another thread is also created in Explorer process which is responsible for generating DGA (Domain Generation Algorithm) domains and injecting code into browsers like IExplorer, Chrome, Firefox and Opera.

Explorer local thread

Domain Generation Algorithm

The following is the Domain Generation Algorithm (DGA) used by Tinba variant where every sample uses a hardcoded domain and seed to generate the DGA domains.

DGA routine

Hardcoded Domain and seed

These DGA domains are fast flux domains where single domain is frequently switched to different IPs by registering it as part of the DNS A record list for a single domain.

targetHost targetIP eudvwwwrmyqi.in 89.111.166.60 eudvwwwrmyqi.in 95.163.121.94 jrhijuuwgopx.com 176.31.62.78 jrhijuuwgopx.com 176.31.62.77 norubjjpsvfg.ru 210.1.226.15 norubjjpsvfg.ru 104.223.122.20 norubjjpsvfg.ru 104.223.15.16 scpxsbsjjqje.ru 5.178.64.90 scpxsbsjjqje.ru 192.198.90.228 scpxsbsjjqje.ru 5.178.64.90 wgwnmffclqvu.ru 192.198.90.228 wgwnmffclqvu.ru 192.3.95.140

Remote Thread in browsers

The Explorer thread searches for browser process either by checking path of the browser executable or by loaded application specific DLL (e.g. NSS3.dll for firefox.exe). If the targeted browser process is found, then the secondary thread is created in the process.

Browser thread

This thread is responsible to get updated Bot configuration details like Target URL list and strings (BOTUID ) from a remote C&C server. If there is no updated list of target URLs from C&C server, then it uses default targeted list of URLs which is stored in the injected code. The list of default target URLs after decryption is shown below.

Default Targeted URL list

The collected information form webmail, social media and the banking sites are stored in "log.dat" file.

Log file path

C&C communication & Cryptography:
 
The POST request to C&C server contains encrypted system information like system volume & version information.  The cryptography routine is a simple byte 'XOR' with an 8 bit 'ROR' of the key after each write. 

Send Data Encryption

A sample Tinba POST request to DGA domains with 157 bytes of encrypted data is shown below.

C&C POST Request

Geo distribution of C&C call back attempts that we blocked in past one month:

Geo Location

We have seen following C&C server IP addresses:

• 103.1.149[.]36
• 104.223.122[.]20
• 104.223.15[.]16
• 104.223.15[.]234
• 104.255.97[.]136
• 104.255.97[.]15
• 162.218.89[.]118
• 176.31.62[.]77
• 176.31.62[.]78
• 192.198.90[.]228
• 192.210.139[.]138
• 192.3.95[.]140
• 198.100.29[.]2
• 198.56.237[.]21
• 210.1.226[.]15      
• 5.178.64[.]90
• 5.2.189[.]251
• 82.165.37[.]127
• 89.111.166[.]60
• 95.163.121[.]94

Conclusion:

     Tinba also known as small banking Trojan continues to be prevalent in the wild.  The arrival method varies from e-mail spam, drive-by downloads and most recently Exploit Kit infection cycle. Zscaler ThreatlabZ is actively monitoring this malware family and ensuring coverage for our customers.

The Story of a Trojan Dropper III

Introduction:

In previous posts (story of Trojan dropper part I, II) we performed both static and dynamic analysis on the threat and also developed a broad idea of what the malware was doing in it’s initial stages. We now set out to investigate the reason behind the crash of the dropped file (“Adobe.exe”) and at the same time we want to retrieve the payload from this particular malware sample.

Analysis:

Let’s go ahead and debug the file. This file (“Adobe.exe”) was found to be packed (custom variant) and the unpacking routine is similar to the approach detailed in part II of this post, so let’s skip all the gory details and dive right into it.

After unpacking the entire binary in memory, control is transferred to a newly unpacked region at the address "0x401634". Now the action begins from here and we get our first decryption routine, which is a simple 1-byte XOR with a static key as seen in the image below which reveals more code

Figure 1: Decrypt code

If we carefully look at the new code below, we can observe that it is riddled with JMP instructions and occasionally we find a few garbage values. The code is crafted in such a way that it resists disassemble attempts which makes reverse engineering the sample more difficult and somewhat painful.

Hidden in between these JMP’s in plain sight is an instruction that is familiar to us by now(i.e the instruction to fetch the address of PEB (Process Environment Block)).

Figure 2: Fetch address of PEB

At this point we can only speculate on why the malware needs the PEB address. Moving further in the code, we encounter another decryption point that is exactly same as the first one, which decrypts more code. Now the control is transferred to the newly decrypted code.

Figure 3: NtGlobalFlag (anti-debug)

In the image above, we have an interesting bit of code. Recall that the malware already collected the address of PEB. At this point, using the instruction CMP DWORD PTR DS:[EDI+68], ECX (here EDI holds the address of PEB which is "0x7FFD4000" and ECX holds a constant 0x70 ) a comparison is performed, after which a JNZ instruction decides the fate of the control flow.

Here we get our first glimpse of the anti-debugging technique employed by this malware. The instruction CMP DWORD PTR DS:[EDI+68], ECX compares the value of the ECX register (i.e. 0x70) to the location in the PEB structure known as “NtGlobalFlag”. The field is set to a value of “0x70”, if the process is spawned under a debugger.

In our case, this is true since we are debugging the file. Finally, the JNZ instruction at "0x401511" is not taken, which lands us in an invalid region in memory, thus triggering the anti-debugging. Let’s jump here and continue with our analysis. We now have another layer of decryption, which reveals more code after which, as usual, control is transferred to this region.

We then reach another piece of code, which is revealed only if we keep up with the control flow.

Figure 4: File-path, name identification (anti-debug)

The above code uses “strstr” to look for a string named “sample” anywhere in file path of our currently debugged file. If found, “strstr” returns a pointer to first occurrence of search string(i.e "sample") in file-path, or else it returns zero. The malware then checks the return value in EAX and takes a conditional jump in the form of JE instruction at "0x401135". If the jump is not taken, the code lands in “ExitProcess”, a call which terminates the process.

This is the second anti-debugging technique the malware employs, although not-an effective one in my opinion considering the odds of a file-path or malware name containing the name “sample”.

Figure 5: GetVolumeinformation, Volumeserial (anti-debug)

Again, here we have another anti-debugging technique where the malware retrieves the Volumeserial number using the API GetVolumeinformation and compares it with  “0CD1A40” and “70144646”. If either comparison matches, the code jumps to the ExitProcess call.

Another anti-debugging technique follows immediately thereafter in the form of “EnumSystemLocalesA”. The first argument that "EnumSystemLocalesA" accepts is a pointer to the callback function. Here the malware does a neat trick. If we look at the code below, at address “0x401179” a constant “0x2” is pushed onto the stack, which is followed immediately by a CALL. 

When this CALL is executed, it pushes the return address onto the top of the stack (which is "0x401180") and the EIP (Instruction pointer) now lands at the "EnumSystemLocalesA" call. Now if we observe the stack, the value on top of the stack is the return address, which naturally becomes the callback function address for "EnumSystemLocalesA" . When the "EnumSystemLocalesA" API is executed, control falls to the callback function, which continues the execution of the code. 

Figure 6: EnumSystemLocalesA (anti-debug)

Let's now continue our debugging from the address “0x401180”. Not far from here, yet another anti- debugging technique is uncovered. This time the malware retrieves the ‘Diskname’ from the registry. 

Figure 7: Diskname (anti-debug)

"RegOpenKeyExA" (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Disk\Enum)  and  "RegQueryValueExA" then uses “strstr” and searches for signs of a virtual environment such as “Xen”, “Vmware”, “Qemu” and also looks for string “virtual”.

Figure 8: Search vm strings(anti-debug)

Once the malware detects a virtual environment, it changes the control flow and land us in an invalid memory region. If we play along, we can observe something interesting here.

Figure 9: Adobe.exe crash

There we go. We can finally reproduce the crash that happened during the first stage of our analysis.
Ok, so a through binary analysis is often not so straight forward after all !!!

Figure 10: sandbox identification(anti-debug)

Let’s move on and see what surprises the malware has this time. Below, we can see anotherpiece of code that checks for a DLL name called “sbiedll” . Here, the malware checks whether it is run in a popular sandbox called “sandboxie”. If found, as usual, the malware bails out.


Immediately afterward, the malware performs a decryption routine to reveal compressed data, which is again packed with aplib and below we can observe the aplib unpacking routine which decompresses the data to a PE file.

Figure 11: Aplib decompression routine

Soon after, control is passed to the newly decompressed file. Below, we can see the new file being executed.

Figure 12: New PE-file in memory

Debugging further, we can observe the malware revealing the final trick that it has up it’s sleeve ,which I will explain in the next post in this series.