Stabuniq Financial Infostealer Trojan Analysis

According to Symantec, Stabuniq is a financial infostealer trojan which has been found on servers belonging to financial institutions, including banking firms and credit unions. The Trojan also compromised home computer users and computers at security firms.

Targets sounds interesting, so here at UIC R.E.Academy we decided to take an in depth look to this trojan by adopting a classical Reverse Engineering approach.

Binary Geometry

The sample we are going to reverse could be downloaded from Contagiodump and presents the following basic characteristics:

First Inspection

First inspection is done, as you know, by observing the binary from a disassembler perspective in order to understand the structure of the code that we are going to analyse and successively getting our hands directly into the assembly.

Let’s take a first look to the Call Flow of Stabuinq:

The picture clearly shows that the points of major interest are:

WinMain (obvious)

sub_40F400 due to the presence of interesting API calls like CreateProcessW and SetThreadContext

Once we have a clear idea of what are the core points of our binary we can switch to a dynamic approach, by using a debugger, in order to understand how the code works.
Additionally it’s interesting to observe that there is a lack of indicative strings, this means that this executable is probably packed and/or containts a secondary executable that is decoded and dropped at runtime.

Debugging and carving the second Stabuniq executable

As previously observed WinMain is our starting point, in this case the call is located as follows:

A new process is created with CREATE_SUSPENDED flag, in this way our binary could drop in the suspended process blocks of decrypted code and once memory filling is completed, via ResumeThread API call, the malicous process will execute the new dropped code.

PAGE_EXECUTE_READWRITE flag is often a very interesting point because this is a typical element which clearly indicates that a block of executable code is placed in the selected memory area. The picture below show the content of the PAGE_EXECUTE_READWRITE memory block:

As you can see we have a PE structure in memory but a double MZ stub, we can now dump the buffer and resize the file in order to eliminate the first MZ stub by cutting from the buffer start to the second ‘M’.

Our original executable now will transfer this code into the newly created process via WriteProcessMemory and finally via ResumeThread the secondary process is executed.

Preliminary Analysis via Volatility

We can now proceed with the analysis: the next step will be to run the unpacked version of Stabuniq and analyze the memory through Volatility in order to get a better understanding of what’s happening behind the curtains.

We can clearly see a couple instances of Internet Explorer launched from a process that’s not in the list (PPID 3104) they most probably are shadow IE instances, invisible to the user. Let’s dig a bit deeper to find out if there’s any outgoing connection:

Our shadow instance of IE attempted a connection on port 80 to 75.102.25.76 which translates to ns2.mktdns.com.br. It appears to be a DNS with a webserver configured. It’s time to check for injected code into both the instances:

Next a mutex called “StabilityMutexString” is created to ensure that only a single instance of this malware is running. If the mutex is found the application stops calling ExitProcess(). After this check several strings are initialized and all the APIs required by the malware are resolved through GetProcAddress() from this routine:

What’s going on here? The first parameter is a NULL-terminated array containing all the functions that needs to be retrieved, the second parameter is the library that the malware wants to query. Each API is resolved and put back into an external buffer. This is the list of all APIs requested:

The APIs, together with the list of URLs to contact, installations paths and possible executable names are copied inside a big array of data that will later be accessed by the injected threads. Before spawning the shadow copy of IE, Stabuniq constructs a request that will be sent to the C&C server, composed like this (in my case):

at the same time every value is scrambled with a function called at 0x00408336of our uncompressed executable, the obfuscation can be easily reversed if needed. Finally the function in charge of injecting a thread into IE is called in a loop:

We can take a look into the thread code from the disassembler, the only problem we’ll face here will be the APIs because they’re all called indirectly so we’ll have to manually reconstruct each pointer. First of all LoadLibrary() is called for every DLL that will be used by the thread:

Following that all the required registry entries are created. Let’s take a brief look at them.

Startup Method

After running an instance of stabuniq.exe (or its dropper), the original executable is removed and copied in a location picked up from the following table:

\Java Quick Starter

\InstallShield Update Service Scheduler

\SoundMax service agent

\GrooveMonitor Utility

\ComPlus Applications

\AcroIE Helper Module

The middle directory being one of these:

\Update

\Bin

\Uninstall

\Helper

\Installer

and the executable name being one of these:

\jqs.exe

\issch.exe

\smagent.exe

\acroiehelper.exe

\groovemonitor.exe

This directory tree is created right into “Program Files” directory, using a path randomly generated from the previous list. To ensure survival after a reboot several registry entries are added, from the disassembly we see that the first created is:

Three more threads

The first thread takes care of the deletion of the main executable, moves it to the new path, creates any required registry entry, then it starts another instance of Internet Explorer and injects it with its own same code. Then three more thread are created.

First Thread

The first thread, located at: 0x00408008 uses the following routine to keep reinjecting Internet Explorer:

Then three more threads are created, each one performing a different function.

Second Thread

The second thread is located at this address: 0x00407643, its main function is to keep creating the registry entries used to survive a reboot. Also any modification to these registry entries is monitored:

Third Thread

The third thread is located at this address: 0x00407CE3, this thread monitors the path where the original executable was started for changes and then finds a suitable place into “Program Files” to drop a copy of the same binary.

Mailslots are normally used to setup a communication with a remote part. Mailslot’s name is the GUID created during the first stage of the infection, data on this slot is read just before the creation of the list of running processes:

Here the trojan is checking for the presence of a cookie whose name is response=, the content is parsed and it is used to control the trojan’s behavior. During our analysis the domains used were already sinkholed, for this reason we can not reliably confirm what type of interaction the malware has over the infected system. It’s interesting to note however, that after processing the cookie information, details on user’s activity are acquired and sent to the C&C:

then the process list is updated and sent again to the C&C server. In our sample there are a few more strings, unreferenced, that might be an indication of stripped-out code used for different purposes and that might be used from future or different versions of Stabuniq:

Store key in cache? (y/n)

sshtest123

You gonna die like a bitch in the wolfs house.

password:

PortForwardings=

-load muhaha -P

Removal Instructions

Removing this version of Stabuniq is quite easy:

Start your task manager and kill any iexplore.exe process

Open the windows registry, remove startup the entries mentioned above

Reboot

Remove the executable pointed by the startup strings in the registry

Usually running an updated AV is a good option too… Just in case.

Indicators of Compromise

SANS institute recently published a comprehensive analysis of Indicators of Compromise in Memory Forensics, the paper includes also a study of Stabuniq.

Conclusions

Stabuniq seems to be in a phase of information gathering, nevertheless it might become a real threat as soon as the author decides to change the behaviour of this trojan, if you have any update or just want to share something with us, please use the comment section below.