Analysis of an Evasive Backdoor

Analysis of an Evasive Backdoor

Authored by: Roman VasilenkoKyle Creyts

The Initial Infection Vector – Nuclear Pack

A number of other posts have covered the Nuclear Pack Exploit Kit . While this EK (exploit kit) may not be as popular as kits such as g01pack or BlackHole, and may not contain nearly as many exploits as CoolEK or Phoenix, it still sees use.

Among other things, Nuclear Pack is known for using layers of redirection, first checking for user activity before delivering malicious code.


Nuclear Pack is known to be used by a number of different criminals for distribution of a variety of malware families, mostly crimeware; in this post, we detail an unusual incident wherein a customer gets hit by the Nuclear Pack exploit kit.

Here you can see the detection in the Previct UI:


This is how the event detail looks:

This Java payload successfully exploited the victim, immediately downloading the malicious executable load2.exe (78cfa36112cd0797690327a9a07d5890) as seen here:

A Curious Executable, A Detailed Analysis 

When we first looked at the initial dropper, for a moment, we thought that it was a false positive. The sample didn’t look like malware at all. A quick check over at VirusTotal didn’t help us to make a decision; according to the VT result, the sample also looked like a probable false positive.


The Dropper

The initial dropper is a NullSoft Installer (78cfa36112cd0797690327a9a07d5890), which drops 6 files to temp directory:

As you can see, the dropped executable has an icon resembling a “Settings” or “Updates” symbol, and one of the dropped DLLs has a description of “Google Chrome Patches”

Then it starts the executable file, wobiqacaxa.exe

The Second Stage

The second stage executable does some math computations like:

imports functions from other DLLs:

and calls them in the main function:

it also calculates the remaining battery life, and that’s the extent of the capability present in the executable. There is nothing suspicious so far.

Let’s look at the DLLs. First of all, they have very small size, and each have  one export function. The exports don’t look very suspicious, and after examining a few of them, one is tempted to say “it is something, but not malware, this feels like just wasted time”, and you might consider stopping here… Then you remind yourself of the utter oddness of the behavior you have examined in this “installer” so far, and continue the analysis.

Have a look:

womajejunuc.dll exports Nalexavo

tapevacanop.dll exports Miqudigob

horikipusac.dll exports humolu

None of this seems even a little bit malicious!   

But something nags at you, and you don’t want to stop digging. Why?

The Juxtaposition

Because the code doesn’t make any sense. It doesn’t make sense for a legitimate binary to:

  1. solve a math function such as “y = 10x – cos (2x)”
  2. get the local currency format, and apply it to the string “-3.80” and then do nothing with it
  3. calculate the remaining battery life
  4. enumerate list of the  drives 

All of these are just common routines which a legitimate program might make use of, but probably not together and probably not in this order… In this case, these are fake functionality which seems to have only one aim:  to confuse an automated detection system, an anti-virus, or even an analyst who attempts to manually analyse the sample.

All doubts are gone when we examine the file we identified earlier as “binary data.”

It definitely bears a strong  resemblance to the pattern of data encrypted by stream cipher with a short key.


The Unpack

So, besides aforementioned fake logic, this malware

  1. calculates a decryption key (provided by function humolu from horikipusac.dll)

  1. reads the binary file to memory ( provided by function Nalexavo from womajejunuc.dll)
  2. decrypts the data in the memory (provided by function Miqudigob from tapevacanop.dll)

And now onto the last DLL:

Qotowokami.dll exports the function Siwusonivin which implements the quite standard pattern of injecting decrypted data to a new process:

  1. GetCommandLine and PathGetArgs to get the path of the original installer. This works because the installer starts the dropped executable with itself (the installer) as a parameter in command line
  2. CreateProcessA to create a new process of the installer, but with suspended status.
  3. ZwUnmapViewOfSection and VirtualAllocEx to free original process memory and to allocate memory for decrypted data inside the created process.
  4. WriteProcessMemory to copy decrypted data to the process space.
  5. GetThreadContext + SetThreadContext + ResumeThread to change the entry point and resume the thread in the process.

But the function gets all of its API functions dynamically by calling LoadLibrary and GetProcAddress , and Qotowokami.dll itself doesn’t contain any of the functions’ names. They are located in decrypted memory. Thus, it is impossible to see real payload of this DLL without decrypted data. 

Sandbox And AV Evasion

The malware is written  in such a way that if the components were analyzed separately, or if any of components is lost, it is very difficult to identify what the sample is supposed to do, and if it is malicious or not.

Since most antivirus products do not really analyze binary files (of unknown format) except by checking hashes of a whole file, it is becoming trendy among malware authors to keep malicious payloads encrypted in non-executable binary files, and extracting the encrypted contents using a separate file, a loader/decrypter which doesn’t look suspicious. We already wrote about a similar  technique in a previous blog post:

Our analysis platform detected an evasion attempt:  the sample tries to check if it is working in a sandbox environment by reading the registry key


and comparing the value data with the substrings:

  1. “vbox” – (would appear in a VirtualBox VM)
  1. “qemu” – (would appear in a QEMU VM)
  2. “vmwa” – (would appear in a VmWare VM) 

The decrypted data is not an extracted payload yet, but rather  another wrapper which first checks if it is running in a sandbox environment:

Such sandbox evasion attempts are becoming increasingly common.

After that, the wrapper resolves the API functions.

It should be noted that the wrapper is looking for addresses of DLLs and API functions by hashes. Malware authors definitely do not want the malware being detected simply by searching for suspicious strings, such as suspicious API function names!

The wrapper finally decrypts the malicious payload ,  then builds an import table for it in an interesting way:

  1. For each API function it checks the first instruction.
  2. If the instruction is jump (0xEB, 0xE9) the wrapper gets the target address and repeats the check recursively.
  3. When the first non-jump instruction is found, the wrapper copies the instruction to allocated memory and adds a jump after it to the second instruction of the real API function.  With this  technique, the malware evades hooks of security components (such as HIPS).

Below is an example of malware’s “imports”.

Note that it uses jumps (usual imports construction call [x] / jmp addr) : 

But instead of addresses of API functions the jumps lead to specifically generated code (described above)

Unwrapped At Last 

The malicious payload is position-independent code, and after reconstruction, it looks like this:

It is a typical “backdoor” or “bind shell” which listens to a port and executes received commands. And for all the work put into evasion and anti-AV, the connection is not encrypted and is not protected by any authentication methods.

The Conclusion 

A brief graphical summary of the incident:

Name of dropped file

apparent filetype




PE32 executable (DLL)


injector of the decrypted routines


PE32 executable (DLL)


decryption key calculator


binary data


encrypted binary data


PE32 executable (DLL)


decryptor of encrypted memory


PE32 executable


second stage executable


PE32 executable (DLL)


reader of encrypted file


Has all of this effort been to protect a simple TCP bind shell from detection?

Why would an attacker deploy this with an exploit kit hosted on the Internet, outside of the victim’s network, where an attacker cannot be sure they will be able to call in to the host they have compromised? The victim’s IP was in RFC1918 space, and would not be reachable by an attacker over the Internet.

One possible explanation could be that the attacker is coming from inside the house (network)! An attacker inside of the network would probably be less concerned about encrypting their connections to other local machines than they would about traffic they were moving through network edges. 

This appears to be a lateral movement technique used by an attacker who has already established a beachhead inside the victim’s network, and wants to get access to another host on the same network. Using information gathered from the first machine, they will craft a believable message (a spear-phish),  complete with a compelling reason for the intended victim to visit an included URL, taking the victim to an exploit pack, such as one described at the beginning of this article.