There are a number of papers on how Tinba-DGA (Tiny Banker with Domain Generation Algorithm) works once it infects a system, how the web injects are used, and what type of hooks are performed on the system. But what about examining and taking a look at how Tinba can be stealth enough to infect the Explorer process without being detected? A lot of work has been done in order to achieve this objective; in fact, the unpacking stage seems to be customized and in close relation with Tinba malware.

Let’s first take a look at a manual approach to such binary in a series of posts with deep analysis on the Tinba infection process. We will see some of its internals in order to understand how it works and how we can detect it before we are completely compromised by the malware. All the behavior described in this post, and the ones that will follow, is based on the following samples of Tinba found in VirusTotal:
Before going into details, let’s summarize some behaviors described in this post:

• How Tinba starts execution and jumps between different execution layers
• "Sophisticated" strategy to resolve windows API functions and get loaded modules
• Override tricks that modify its own memory
• Override tricks that modify its own header

There are more layers, but they will be described in the coming posts. Let’s make a deep dive into Tinba now!

Layer 1

When double-clicking the main binary, malware starts to prepare the next execution layer. In order to achieve that the first thing that the malware does is to override the current binary header to add a new header where a ‘.flat’ section is specified. In order to do that, as already said, first of all it needs to prepare such payload by calling some internal subroutines and an RtlDecompressBuffer API function.

See the resulting payload below:
Once the payload is correctly prepared as shown in the above picture, Tinba packer unprotects the memory related to the EntryPoint in order to be allowed to override it with such new payload. All this process is performed by an intermediate layer executed just before the JMP to the new layer located at 0x20000.

The following picture shows a call to VirtualProtect function with the specified memory section as target:
In the figure, you can see the arguments being passed through the stack. In effect, it’s setting 0x14000 bytes starting at 0x40000 as PAGE_READWRITE memory. Once it has performed such operation, it starts copying new MZ and PE headers with initial code to be executed in the next layer as well.

It’s important to say that no internal function is called in order to copy the payload to the targeted memory section. It uses its own copy mechanism, the starting point of the copy loop is shown at the end of the top window in the above picture.

Finally, in order to move the execution flow into another memory section the malware executes a JMP EAX instruction, which is the last opcode once the loop is finished:
When it’s done, EAX points to the entry point of the new copied payload. In the picture below there is the new code to be executed in order to continue with the infection:

Layer 2

The execution flow starts with the new layer of code. After analyzing it, we can see how it first tried to find the ‘kernel32.dll’ loaded in the binary by iterating the loaded modules list.

It’s interesting how it does this.It checks for the substring “\x32\x00\x33″ (“23″ in unicode) in a specific offset in every loaded module’s name field. After that, applying the same “sophisticated” technique it tries to find the VirtualAlloc function address.

The objective of this layer is to uncompress and copy the actual malicious payload into a new allocated memory. The following picture shows the whole code after being analyzed (it is the same one shown at the end of layer1):
The last called function is to APLib_dec, which is the decompression process provided by APLib, a compression library. The overall schema of such function is as follows:
Once everything has been executed, the last JMP moves the execution flow to the new payload copied into the new allocated memory in the binary. The EDI value at this point was: 0x1870000, and its content is shown in the following image:
As you may notice, there is a list of different API functions from the Windows Libraries (kernel32 in this case). But before looking at the list, there are some binary opcodes at the beginning of the section:
The actual Tinba payload starts after those binary instructions at the beginning. This very first code block is used as a loader for the actual malicious payload to stealthily inject it into another process. We will describe this however in the next post.

To this point, we have identified the following tricks in Tinba:

• Overriding its own entry point.
• Making use of relative calls in order to put the current EIP into the stack and use it in further functions.
• Managing loaded modules list to get kernel32.dll base address by comparing the substring.
• Iterating functions in kernel32.dll and comparing a substring of the targeted function to find it.
• Resolving only the required functions.

In the coming posts we are going to see how the infection continues from the current point. There is no persistence or any malicious action performed by the malware… – for now.

At Blueliv, we believe that sharing expertise and intelligence is the key to getting the upper hand in an ever-changing cyber landscape so we invite you to join Blueliv Threat Exchange Network, a collaborative community that enables you to defend yourself and help everyone fight cyber crime.

Blueliv Labs