Blog.

Summary

Qbot or Qakbot is a sophisticated worm with banking capabilities. This malware family has been infecting computers since 2009, utilizing a number of techniques (some of them quite advanced) which make it difficult to detect. It has a packing layer, anti-VM techniques, anti-debug techniques, and anti-sandbox techniques which make the analysis of this threat difficult. Qakbot is capable of updating itself and this also makes this threat more complex to detect since it is constantly changing on disk.

Using Triage we analyzed the most recent variant of this malware, and we added a new module to support the detection and configuration extraction of Qakbot samples as shown in the image below. A tool to deobfuscate the Qakbot payload is also included qakbuscator.py.

Unpacking process

Qakbot has a custom packer. There are probably other versions of Qakbot in the wild with different packers, but this section is based on analysis of the packer for the sample: e736cf964b998e582fd2c191a0c9865814b632a315435f80798dd2a239a5e5f5.

In summary, the unpacking process is as follows:

The packer allocates memory and then drops an encrypted buffer there (Step 1-2).

The dropped buffer is decrypted and the decrypted data contains a PE file (Step 3). This PE file is not at the beginning of the buffer but starts at offset 0x427. From the beginning to the PE file offset is filled with 0x00 bytes.

This could be a trick to make analysts think that this function is “freeing memory” or that it’s a memset-like function.

The PE header is modified - this can also confuse analysts or memory dumping tools that look for PE file signatures since they can’t find the “MZ” magic number. This is shown in the image below.

The decrypted PE file image size is calculated to allocate memory for it. The PE file is copied (mapped as a windows loader would do) from the decrypted buffer to the newly allocated memory (Step 3-4).

Once the file is mapped to the newly allocated memory, the header is fixed as shown in the following image. Once the PE file is mapped its entry point is called. (Step 4)

This PE is going to read the rest of the previous decrypted buffer since there is still some encrypted data. Once the data is decrypted a new PE file can be found. (Step 4-5)

This time the header is also modified and is fixed before mapping it. (Step 5-6)

The decrypted PE is Qakbot itself. In this case the PE header doesn’t have the well-known string “This program cannot be run in DOS mode”, because the DOS-Stub was deleted.

This PE file is the final payload of Qakbot so finally the PE file is mapped to the ImageBaseAddress of the original file (Step 6).

The original image loaded at address 0x400000 is wiped.

The newly unpacked PE (Qakbot) is copied to the original image base address 0x400000.

So, after mapping the Qakbot binary the execution flow goes to the EntryPoint of this file. (Step 7).

The unpacked sample hash of the file we ran in Triage: 850ff92b7f3badda4bd4eca0a54fbdea410667db1ea27db8069337bf451078d1

Obfuscation

Once the sample is unpacked, Qakbot itself also implements an obfuscation layer in its code. This obfuscation makes the analysis a bit harder. The flow graph of the main function is the following:

The obfuscation basically consists of adding unused loops with an empty body. Like the following:

As is shown in the image above, it does a “XOR EAX, EAX” operation and then decides to loop or not depending on the Z flag which is set with the previous instruction (so the loop will never happen). The goal of these small loops is to make a less comprehensive flow graph and to make the analysis harder. There are more than 600 loops like this throughout the code.

At Hatching, we implemented a tool qakbuscator.py to deobfuscate the code and make the analysis much easier. This tool is provided with this analysis to allow all researchers to use it.

The DLLs that are in the Qakbot resources also have this obfuscation layer - you can use the script to deobfuscate them.

Behavioral analysis

The sample used to perform the behavioral analysis is the deobfuscated sample using our deobfuscator tool explained in the previous section.

SAMPLE: 3bd468d29868bb3f198530ef2426668efe30a8330bf3835a4f3a941d534ef2df

This is how a process tree of a Qakbot infection looks like:

Regardless of the input vector, the first time Qakbot runs it tries to install itself.

Anti-VM/Anti-analysis tricks

First of all, it checks if it is running in a virtualized environment or not. Qakbot executes itself with the option "/C". Qakbot admits parameters, in this case the parameter "/C" is to make anti-VM and anti-sandbox checks like the following ones:

Reading from the virtual port in order to detect VMWare

Check the CPUID

There are also other techniques used by Qakbot to know if it is running in an emulated environment like checking the sample name - in order to see if it is set to some default name like “sample.exe” or “malware.exe”; or checking running processes in order to detect any related to a virtual environments, anti-virus, debuggers etc.

Among the different options that Qakbot accepts we can find the following:

Installation

If a VM is detected it exits. Otherwise, it copies itself into %APPDATA% under a randomly generated folder with a randomly generated name. Those names are unique for each infected machine since they are created using some characteristics from infected host.

It also creates the following registry key in order to be run when the system reboots “HKCU\Software\Microsoft\Windows\CurrentVersion\Run”.

Also, it drops a .dat file that has configuration information, like botnet name, timestamp, etc. This file contains encrypted data which is decrypted in memory during run time. Once this file is decrypted it looks like is shown in the image below.

The following table, from a blog post by the security researcher Vitaly Kremez (link) , shows the meanings of some of these config values:

Finally, the copied file is executed and the original file is overwritten with calc.exe. Some malware deletes the file directly, but Qakbot has decided to overwrite it with a legitimate binary. This way it doesn’t leave traces.

When Qakbot is installed, its behavior is different. In this case, it is going to create an instance of the explorer.exe process in order to inject itself into it.

Once injected into explorer, the main .dll is loaded. At this point, different things could happen since the communication with the control panel begins. As shown in the process tree above, the explorer process executes an update of Qakbot directly downloaded from the C&C. Also, it can exfiltrate data, or infect browsers in order to get banking information from the victim system.

Qakbot update sample: https://tria.ge/reports/191104-athqk1tjxn/task2

Triage

In Triage we’ve just added support for this family, meaning you can detect Qakbot as well as get its configuration directly after the analysis.

Samples

The Triage report for the sample that was used for this blog can be found (here).

Here is a list of related samples and their corresponding Triage reports.

References

• https://www.symantec.com/content/dam/symantec/docs/security-center/white-papers/w32-qakbot-in-detail-11-en.pdf
• https://www.vkremez.com/2018/07/lets-learn-in-depth-reversing-of-qakbot.html
• https://cofense.com/closer-look-qakbot-malware-dangerous/
• https://blog.talosintelligence.com/2016/04/qbot-on-the-rise.html