Tracking 15 Years of Qakbot Development

Introduction

Qakbot (aka QBot or Pinkslipbot) is a malware trojan that has been used to operate one of the oldest and longest running cybercriminal enterprises. Qakbot has evolved from a banking trojan to a malware implant that can be used for lateral movement and the eventual deployment of ransomware. In August 2023, the Qakbot infrastructure was dismantled by law enforcement. However, just several months later in December 2023, the fifth (and latest) version of Qakbot was released, marking more than 15 years of development. In this blog, we will analyze Qakbot from the first version dating back to 2008 through the most recent version that continues to be updated as of January 2024. Our analysis demonstrates the threat actor behind Qakbot is resilient, persistent, and innovative.

Key Takeaways

• Qakbot originated in 2008 as a banking trojan designed to steal credentials and conduct ACH, wire, and credit card fraud.
• In recent years, Qakbot has become an initial access broker delivering Cobalt Strike for lateral movement and ultimately resulting in second-stage infections including ransomware like BlackBasta.
• Over the years, Qakbot’s anti-analysis techniques have improved to evade malware sandboxes, antivirus software, and other security products.
• The malware is modular and can download plugins that enable it to dynamically add new functionality.
• The threat group behind Qakbot has now released five distinct versions of the malware with the latest release in December 2023.

A Brief History of Qakbot

ThreatLabz researchers have been tracking Qakbot for more than a decade and our analysis started with samples that date back to 2008. These early versions of Qakbot contained a date timestamp rather than a version number. However, we will refer to these samples as version 1.0.0 for clarity and consistency with subsequent versions. At that time, Qakbot leveraged a dropper with two embedded components in the resource section that consisted of a malicious DLL and a tool to inject the DLL into running processes. The Qakbot DLL implemented a wide variety of features including: a SOCKS5 server, stealing passwords, harvesting web browser cookies, and spreading via SMB. These early versions were heavily developed and even had a feature to report crash dumps. In 2011, Qakbot introduced a versioning system that started with 2.0.0 that has signified major developmental milestones over time. The Qakbot major version number is a three-digit hexadecimal value with 0x500 (or 5.0.0) being the most recent. 

Qakbot was largely used for banking fraud until 2019, when the threat actor pivoted to serving as an initial access broker for ransomware including Conti, ProLock, Egregor, REvil, MegaCortex, and BlackBasta.

The following timeline illustrates the key developments for each version of Qakbot.

Each version of Qakbot represents a snapshot in time and is indicative of the threat landscape during that period. For instance, early versions contained hardcoded command-and-control (C2) servers. As time progressed, law enforcement and malware researchers worked successfully with domain registrars to suspend malicious domains. In response, the Qakbot threat actor added network encryption and implemented a solution to remove the C2 server’s single point of failure by adding a domain generation algorithm (DGA). While a DGA addressed the single point of failure issue, it also created significant noise when querying for a large number of domains. As a result, the Qakbot developer devised a new multi-tiered architecture that leveraged compromised systems to act as proxy servers that relay network traffic between other infected systems and the backend C2 infrastructure. This design update addressed the single point of failure problem, reduced network traffic, and effectively hid the subsequent C2 tiers.

In the following sections, we will analyze key areas where Qakbot has evolved significantly including anti-analysis techniques, network communication, and the implementation of a modular design.

Anti-Analysis Techniques

Qakbot has implemented anti-analysis techniques from the beginning of its development including string obfuscation, API obfuscation, and malware sandbox evasion. 

String obfuscation

Every version of Qakbot since its inception has obfuscated the malware’s important strings with a simple XOR algorithm. The XOR key (and most recently, the derivation of an XOR key) is used to decrypt strings. Moreover, the reference structure to the strings has also evolved across versions.

In the first two versions (1.0 and 2.0), the malware decrypted a block of strings from the data section, overwriting the original encrypted block, and the unencrypted strings remained in memory as shown in Figure 1. This simple design was likely an attempt to evade static antivirus signatures.

Figure 1. Early versions of Qakbot string obfuscation

In later versions of Qakbot, the XOR key length was significantly increased, and strings were decrypted and copied to a newly allocated buffer. Qakbot version 5.0 made perhaps the most significant change to the string encryption algorithm. The strings are still encrypted with a simple XOR key. However, the XOR key is no longer hardcoded in the data section. Instead the XOR key is encrypted with AES, where the AES key is derived by performing a SHA256 hash of a buffer. A second buffer contains the AES initialization vector (IV) as the first 16 bytes, followed by the AES-encrypted XOR key. Once the XOR key has been decrypted, the block of encrypted strings can then be decrypted as shown in Figure 2.

Figure 2. Qakbot 5.0 string decryption

API obfuscation

In versions 1 and 2, Qakbot carried a list of Windows API names used by the malware in the encrypted strings table. After the strings table was decrypted, the code would dynamically resolve the address of each API at runtime and then initialize a table of pointers that could then be used by Qakbot to invoke the corresponding function when required. This implementation made it harder for malware researchers and antivirus software to statically determine the APIs used at runtime.

In more modern versions, the Qakbot developer further obfuscated the use of APIs by resolving the imports using a CRC32 hash rather than a string. At first, Qakbot used the CRC hashes of the API name directly, and subsequent versions performed an XOR with a hardcoded value and the CRC hash. Figure 3 shows an example of this dynamic API import hashing algorithm.

Figure 3. Example Qakbot API obfuscation

Junk code

Over time, Qakbot has introduced blocks of code that are deliberately non-functional to defeat static antivirus signatures as shown in Figure 4. In the example below, a block of junk code was added prior to an RC4 initialization routine.

Figure 4. Example of Qakbot junk code block in an RC4 initialization function

Anti-sandbox techniques

Qakbot has implemented numerous detection mechanisms to identify researcher environments and malware sandboxes since the earliest versions. In particular, Qakbot has attempted to identify processes, system artifacts, and the underlying virtual machines associated with an analysis environment. Figure 5 shows an example of Qakbot’s implementation to identify whether an infected system is running on a VMWare virtual machine from a sample dating back to September 2009.

Figure 5. Qakbot implementation to identify VMWare

Qakbot has continuously added code to identify analysis environments by checking system information such as the name of BIOS vendors, processes, drivers, etc. for strings as shown in Table 1.

Network Communication

Qakbot has leveraged HTTP for C2 communication from the beginning. However, the network protocol on top of HTTP has changed significantly over the years with encryption, RSA signature verification, and the addition of a JSON-based message format.

Network protocol and encryption

Qakbot has continuously updated its message protocol with version 19 being the latest. The protocol specifies the format of the message. In version 3, Qakbot sent requests in a format similar to the following:

protoversion=9&r=1&n=kvtjmq970452&os=6.1.1.7601.1.0.0100&bg=b&it=3&qv=0300.288&ec=1453922906&av=0&salt=qrTMyfvpr

However, this protocol format was later replaced with a JSON-based protocol with integer key values that denote specific fields as shown below:

{
   "8":1,
   "5":1035,
   "1":19, // protocol version
   "59":0,
   "3":"obama259",
   "4":1028,
   "10":1683022694,
   "2":"kqsvfc505763",
   "6":59661,
   "14":"Xgd1KxZQKTHGB6IxwtIy2e0RAq4iFNE6w6",
   "7":16759,
   "101":1,
   "26":"WORKGROUP",
   "73":0
}

This encoding adds a layer of obfuscation for each of the message fields.

Qakbot’s network encryption has used RC4 with the key consisting of 16 random bytes concatenated with a hardcoded salt and hashed using SHA1. The most recent version of Qakbot now uses AES encryption with the key consisting of 16 random bytes concatenated with a hardcoded salt and hashed using SHA256. After encryption, the data is Base64 encoded and prepended to a variable in the body of an HTTP POST request.

Domain generation algorithm

The first versions of Qakbot only used hardcoded C2s as shown in Figure 7.

Figure 7. Example of hardcoded Qakbot C2s

However, in version 2.0.1 a DGA was added as a backup C2 channel in the event that the hardcoded C2s were unreachable. Qakbot used a time-based DGA to generate up to 5,000 C2 domains for a specific date interval as shown in Figure 8.

Figure 8. Qakbot DGA code

Interestingly, some versions of Qakbot would generate fake domains if an analysis environment was detected in an effort to mislead researchers, as shown in Figure 9.

Figure 9. Example of Qakbot generating fake domains if network monitoring tools were detected

Data exfiltration to compromised FTP servers

Qakbot versions 3.0.0 and earlier used compromised FTP servers to exfiltrate data rather than sending the data directly to their C2 server. The FTP credentials were stored in Qakbot’s configuration files as shown below:

22=<ip address 1>:[email protected]:<credspassword1>:
23=<ip address 2>:[email protected]:<credspassword2>:
24=<ip address 3>:[email protected]:<credspassword3>:
25=<ip address 4>:[email protected]:<credspassword4>:
26=
3=1581496845

This design had an inherent weakness since anyone with the FTP credentials could potentially have accessed and recovered the stolen information. To address this weakness, Qakbot was later updated to send the stolen data directly to Qakbot’s C2 infrastructure.

Using compromised systems as relays

After version 3.2.4.8, Qakbot ceased using the DGA. Instead, Qakbot started using compromised systems themselves as C2 servers, and embedded a list of IP addresses and port numbers in the malware configuration. Before version 4.0.3.2, the configuration file (stored as an encrypted resource) contained the list of IP addresses in a text-based format:

45.45.105.94;0;443
86.107.20.14;0;443
99.228.5.106;0;443
184.191.62.24;0;995
47.153.115.154;0;995
206.169.163.147;0;995
96.35.170.82;0;2222
73.210.114.187;0;443
75.70.218.193;0;443
…

However, after version 4.0.3.2, the Qakbot C2 list evolved into a binary format as shown in Figure 10.

Figure 10. Qakbot C2 list binary format

Commands

In the first versions of Qakbot, the server sent commands in a descriptive text-based format. The following commands were supported in Qakbot versions 1.0 and 2.0:

• certssave
• ckkill
• cksave
• clearvars
• cron
• cronload
• cronsave
• forceexec
• ftpwork
• getip
• install3
• instwd
• kill
• killall
• loadconf
• nbscan
• psdump
• reload
• rm
• saveconf
• sleep
• socks
• sxordec
• sxorenc
• sysinfo
• thkill
• thkillall
• uninstall
• update
• update_finish
• uploaddata
• var
• wget

In order to obfuscate these commands, the Qakbot author replaced these string commands with integer values starting in the later builds of version 3.

Addition of RSA signature verification

Qakbot version 3.0.0.443 introduced RSA digital signatures (initially using the MatrixSSL library) to prevent tampering. This was especially important when the DGA and compromised systems were used as C2 servers.

Modular Structure

The design of Qakbot has changed significantly from versions 1 through 5. In particular, the malware has become more modular with the ability to dynamically add new features without releasing a new version of Qakbot. Modern versions use a lightweight stager responsible for initializing, maintaining persistence, and establishing C2 communication to request commands and modules.

Embedded resources

Prior to version 4.0.2.19, Qakbot frequently used the resource section to store configuration information (such as web injects and application parameters) as well as DLLs that performed malicious behavior. Initially, in version 1.0, these resources were not encrypted. However, Qakbot’s code evolved with various encryption algorithms to protect these resources.

Qakbot version 2.0 implemented a custom XOR-based algorithm as shown in Figure 11.

Figure 11. Custom encryption algorithm used by Qakbot 2.0 to protect resources

In this example, the offset 0x7 in the encrypted resource contained a WORD that was the size of the XOR key. The XOR key was located at offset 0x9 in the resource. Encrypted data was then concatenated after the XOR key. Python code that replicates this algorithm is shown below:

import struct

def custom_xor(data, key):
    out = b""
    for i, eb in enumerate(data):
        v6 = eb ^ key[i % len(key)]
        v1 = (v6 & (0xff&(255 >> (8 - (i & 7))))) << (8 - (i & 7))
        v2 = (v6 >> (i & 7)) 
        v3 = v1 | v2
        out += struct.pack("B", v3)
    return out

s = open('res.bin', 'rb').read()
key_sz = struct.unpack('H', s[7:9])[0]
s = custom_xor(s[9+key_sz:], s[9:9+key_sz])
print(s)

Qakbot version 3.0 and later used an RC4-based algorithm to decrypt the resources. 

The initial 0x14 bytes in the resource served as the RC4 key for decrypting the remaining data.  A slightly modified version of the BriefLZ library was later added to compress specific resources to reduce the overall file size.

In version 4.0.2.1, the resource encryption algorithm changed slightly. The first 0x14 bytes of the resource were no longer used as an RC4 key. Instead, the code contained a salt value in the encrypted strings table that was then hashed using SHA1 to derive the RC4 key used to decrypt the resource. In version 4.0.3.902 this was improved again, which added two layers of RC4 to decrypt the resource. The first RC4 layer was decrypted using the SHA1 hash of the salt string. The second layer used the first 0x14 bytes of the result as the key to decrypt the following data. Example Python code for this algorithm is shown below:

seed = b"Muhcu#YgcdXubYBu2@2ub4fbUhuiNhyVtcd"
key = SHA1(seed).digest()
dec_data = RC4(resource_data, key)[0x14:]
data = RC4(dec_data[0x14:], dec_data[0:0x14])[0x14:]

Plugins

In version 4.0.1, Qakbot was modified to split various functionality into separate modules. This allowed Qakbot to use a stager to download additional modules from Qabkot’s C2 servers to add functionality on-demand. Qakbot has built modules to hook web browsers, steal email addresses (and email), harvest stored credentials, deploy Cobalt Strike, and act as a C2 server that relays traffic between other infected systems and the backend infrastructure.

Conclusion

Qakbot is a sophisticated trojan that has evolved significantly over the past 15 years, and remains remarkably persistent and resilient. Despite the significant disruption to Qakbot in August 2023, the threat group remains active and recently updated their codebase to support 64-bit versions of Windows, improved the encryption algorithms, and added more obfuscation. This demonstrates that Qakbot will likely remain a threat for the foreseeable future and ThreatLabz will continue to add detections to protect customers.

Zscaler Cloud Sandbox

Zscaler’s multilayered cloud security platform detects payloads with the following threat names:

Win32.Banker.Qakbot

Indicators Of Compromise (IOCs)