Inkasso Trojaner – Part 2

Date: 2013-07-01 08:01:32

In Part 1 of the analysis we have seen a first description of the dropper and how to extract the executeable placed in the file. To move forward with work we dumped the memory with the decrypted virus body and continued the analysis.

Description

This part is packed using standard the UPX executable packer (http://upx.sourceforge.net). It’s main purpose is to connect to one of the C&C servers to receive commands. Besides it also masks itself behind PDF document (the icon in resources was changed to the appropriate one).

Technical Details

The executable contains new sections named UPX0 and UPX1 (which belongs to UPX):

After unpacking it is possible to find C&C addresses within the binary by searching for strings:

Below is the list of the supported commands, without description ;) also found by string:

Places in Autostart the Dropper tries to inject itself:

We loaded the binary into IDA Pro to start the static analysis.

The code starts with some sanity checks to actually find out a certain enviroment is used. For this a string named: ‘sand-box’ is located within the pathname:

If the string is not found then the code goes to the next function which first tries to select a process name between:

and then starts the application using CreateProcessA API with a CREATE_SUSPENDED flag:

Later we can see the subsequent call to another function sub_40E9D2 which allocates a memory within the process selected process using VirtualAllocEx, copies the new code there and creates a new thread using CreateRemoteThread API:

This anti-debugging method works because it is impossible to attach a debugger to the suspended process. There are several options how to bypass such protection. We choose to overwrite first 2 bytes of copied buffer with a EB FE bytes (JMP 00h – jump to self) and continued the execution. After that the debugger can be attached to the running process and the memory context can be restored to its original value (55 89).

After attaching:

After restoring original values:

From here we continued the analysis using dynamic (live) approach.

The code starts with another portion of sanity checks. It checks for a proper executable name, proper parent directory, etc. If there are some problems it tries to copy itself into the %TEMP%\randomname.exe and deletes the original file. After that it executes itself once again.

After sanity check section the code loads wininet.dll, advapi32.dll, user32.dll and cryptdll.dll libraries and tries to resolve all the necessary API calls:

When the previous operation is done the code tries to gather necessary information about the running environment. It resolves computer name and current username to calculate the checksum (which is later used in Crypt* stuff), operating system name and version and the underlaying architecture (x32 / x64). After that the program creates a Mutex called LDRBCCE0. If it exists the code terminates:

Next the code jumps to the cryptographic routine. First it performs string concatenation using previously computed value from GetUsernameA() and GetComputerNameA() together with a hardcoded value QQasd123zxc. The resulting string is later used as the key for cryptographic functions. The code creates a new hash object using MD5 algorithm derived and RC4 stream cipher to encrypt/decrypt data to/from C&C server. The screenshot on next page describes the whole process:

Right after previous operations the code creates a thread which shows a fake Adobe Acrobat Reader error message with an information that the file is corrupted and cannot be recovered:

After another chunk of code the thread is killed and the code tries to create another one to establish the connection to C&C. By setting a breakpoint at address pointed by ESI register it is possible to continue with the analysis:

The thread starts with a code which constructs parameters passed to the /inbox.php PHP script. This process is divided into two separate routines. The first one constructs a string which contains information about OS name, the dropper version, system default language id (codepage) and the status code (NULL means it’s the new instance):

The second routine construct the prefix string which contains selected C&C address and some hardcoded values (ltype=ldr and ccr=1) and ID of the current system (calculated previously):

The dropper uses hardcoded HTTP headers which are sent during the HTTP requests:

Next the code tries to connect to HTTP service on one of the C&C servers and pass the HTTP request to it. After connection the command parsing routines is called:

At the beginning of the blogpost we had the list of commands without description, even if some commands are quite obvious, with this part of code we can see what every command is doing:

IP addresses information

The dropper uses several C&C domain names, during the analysis they resolved to those IP Adresses:

• 202.31.139.173
• 159.253.18.253
• 62.152.59.248
• 217.174.211.1
• 67.202.109.141

Summary

This time we stepped a bit forward, published more of the innerworkings of the dropper. Showed the used domains, that HTTP is used for communication and that the dropper already has some interesting commands. In Part 3 we will show how the trojan itself is working. Curesec Research Team is part of curesec GmbH find us here: curesec.com