2012-07-01
Abstract
Researchers have found a small piece of malware capable of doing just as much as its bigger brothers. Raul Alvarez looks at the structure of the malware, its code injections and modular execution and describes how the tiny ‘Tinba’is capable of doing so much.
Copyright © 2012 Virus Bulletin
Researchers have found a small piece of malware capable of doing just as much as its bigger brothers. Dubbed ‘Tinba’ (Tiny Banker) [1], the malware is approximately 20KB in size. The size of the malware itself is nothing unusual – we have already seen malware of around the same size and even smaller. But, generally, smaller-sized malware tends only to perform very specific tasks, such as downloading components, creating backdoors, and other trivial things. What sets this one apart from the pack is its ability to do much more.
Using behavioural analysis, we can describe Tinba’s main functionality. Using static analysis, we can predict and confirm what the code is doing. But it is only by following its footsteps that we can observe the modularity of Tinba’s execution.
This article will look at the internal structure of the malware, its code injections, and its modular execution. We will describe how such a small piece of malware is capable of doing so much.
The particular sample that we will look at is 19,968 bytes in size. It is small, but it has a simple encryption/decryption routine.
When the sample is executed, its initial routine starts with a simple decryption algorithm. After setting up the destination memory and the starting location of the encrypted bytes, it XORs each byte with 0xBF. A total of 13,312 bytes will be decrypted to the memory.
After decryption, the strings, texts and code that Tinba uses are visible, including the domain names it tries to connect to. After the decryption routine, the malware resolves the APIs that it needs to execute its other tasks.
The APIs used by the malware are taken from five main DLLs: kernel32, ntdll, advapi, ws2_32 and user32. With the exception of kernel32, all of these names can be seen in the decrypted strings.
The image bases of the DLL names are used to resolve the APIs that Tinba needs for its malicious actions. These are acquired as follows:
First, the image base of kernel32.dll is acquired by parsing the Process Environment Block (PEB). The malware simply looks for a match for ‘32’, which is part of the name of kernel32.dll. No other checking is done to make sure the full name is ‘kernel32’. Fortunately for Tinba, the first DLL with ‘32’ in its name is kernel32.dll. Once it obtains the image base of kernel32.dll, it parses its header to look for the export table. Once the export table is located, the malware will get the hash value of each API in kernel32.dll and compare it with its own list of hash values (see Figure 1). This is the malware’s method of resolving the API addresses without a regular call to the GetProcAddress API. After resolving the APIs that it needs, it moves on to get the image base of the next DLL.
The image base for ntdll.dll is acquired next, using a call to the GetModuleHandleA API using the string ‘ntdll’ as a parameter.
The image bases of advapi32.dll, ws2_32.dll and user32.dll are then acquired using the LoadLibraryA API with the string names of the DLLs as parameters.
The APIs the malware needs from these DLLs are resolved using the same method as for kernel32.dll.
After the exhaustive resolution of APIs, Tinba creates a new process named ‘winver’ in suspended mode. It copies its 12,744 bytes of decrypted code to the winver process, and executes it remotely by calling the ResumeThread API. Afterwards, the original Tinba process is terminated. It is interesting to note that the malware hasn’t done anything beyond decrypting its code and injecting it into the winver process.
Once Tinba has transferred execution to the winver.exe process, it starts the API resolution again in the same manner as it did during the execution of the original malware. This is to make sure that it gets the right DLL and the right addresses for the APIs. The code for API resolution is the first set of routines from the decrypted code.
Once the malware has determined that it is running in the context of the winver process, it looks for explorer.exe from the list of processes and injects its code in the same way as it did with the winver.exe process. This time, however, the CreateRemoteThread API is called to trigger the code in the explorer.exe process. This is the second code injection performed by Tinba.
This time the malware doesn’t terminate the execution of the winver.exe process after the code injection into explorer.exe.
Tinba proceeds by initiating Internet connectivity for its communication with the C&C server. The routine to connect to the C&C servers is executed within the winver.exe process. The domain names are hard-coded and can be seen in the decrypted code of the malware (see Figure 2).
Once the code injected into explorer.exe executes, Tinba performs the API resolution again, and checks to see which process it is running in. Once the malware has determined that it is running inside the explore.exe process, it performs the following familiar malware routines:
It checks whether the original sample is running as %APPDATA%\default\bin.exe. If it isn’t, it creates the %APPDATA%\default directory, then moves the original executable to %APPDATA%\default as ‘bin.exe’. This, eventually, will look like it has deleted the original file and dropped a copy of itself.
It makes start-up registry keys with %APPDATA%\default\bin.exe, to make sure that Tinba will survive after a system reboot. Details of the registry keys are as follows:
Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run Value: default Data: “%APPDATA%\default\bin.exe” Key: HKEY_USERS\[SID]\Software\Microsoft\Windows\CurrentVersion\Run Value: default Data: “%APPDATA%\default\bin.exe”
The malware also modifies HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3 with a value of 1609, also known as DisplayMixedContentInternet.
It reads %APPDATA%\Mozilla\Firefox\profiles.ini, to get the default profile location. This is also one way to check whether Firefox is installed in the system. It looks for the ‘Path=’ from within the file, takes the ‘[profile code].default’ value, and creates a folder path: %APPDATA%\Mozilla\Firefox\Profiles\[profile code].default.
Afterwards, Tinba creates the file %APPDATA%\Mozilla\Firefox\Profiles\fzdq808c.default\user.js, which contains:
user_pref(“security.warn_submit_insecure”,false); user_pref(“security.warn_viewing_mixed”,false);
Effectively, this disables the security warning that appears when the user tries to send data through an insecure site, and disables the warning that appears when the user opens a page containing both encrypted and unencrypted data.
Then, it creates and runs a thread that does the following:
It checks the list of processes for iexplore.exe, firefox.exe and chrome.exe. Once any of the three processes is found, it injects the 12,744 decrypted bytes again (giving us the third code injection), and executes the code by calling the CreateRemoteThread API. The code will only be injected into the browser process if the browser is not yet infected.
After injecting its code into the available browsers, it goes back and lists the processes again, and checks whether any new ones have been added since the last time it checked the list. The thread keeps running to check for new browser processes to inject its code into.
The code injected into the running browser is the same as that injected into the explorer.exe and winver.exe processes. This is the third and final code injection performed by Tinba. If any of the iexplore.exe, firefox.exe and chrome.exe processes are found on the list of running processes, Tinba will inject its code to any or all of them. It has a thread running within the explorer.exe process that monitors for the execution of the browsers. Even if the user terminates the browser, Tinba will be able to inject its code again once the browser application is executed, thanks to the persistent thread running inside the explorer.exe process.
Once Tinba determines that it is running within the browser, it executes the code used to intercept the user’s online activities. Tinba now acts as a man-in-the-browser.
On initial execution, Tinba’s only goal is to decrypt the malware code and inject the decrypted code into the newly created winver.exe process. It transfers the malware execution to the winver.exe process and terminates itself. There are two main tasks that Tinba performs while in the context of the winver.exe process: it injects its code into explorer.exe, and connects to the C&C servers. Once execution has been transferred to the explorer.exe process, the familiar malware routines are performed, including dropping and creating files, adding registry keys, and injecting code into browsers. Tinba injects its code into running browser processes, but it leaves a thread running inside explorer.exe to monitor and make sure that it infects new browser processes. Finally, modular execution inside the browser monitors the user’s Internet activities.
One trivial feature of Tinba is its ability to know which running process it has been injected into and perform the relevant necessary tasks. Tinba may be small, but its code has been optimized ingeniously. If a larger sized piece of malware had this kind of coding structure, we would expect it to be a considerable challenge. But, ingenious or not, security experts will always find a way to catch up with the malware.
[1] Tinba. http://www.csis.dk/en/csis/news/3566.
