Qakbot Analysis

In this analysis, I will show what I saw in my hands on analysis of the malware. I’m still a novice in malware analysis, but I’m hoping things I see in this analysis can help other fellow analysts who may be starting out just like me.

Qakbot

Qakbot first came to known as Banking Trojan, mostly for credential stealing. However in the recent campaign from 2020, the malware got utilized more for post-exploitation deliveries such as Cobalt Strike. The usage is very similar to what we saw with Emotet and other modular malwares.

Summary

Qakbot’s infection flow is summarized below.

1. Victim receives phishing email with an Excel attachment, which has Docusign image pasted on the excel sheet.
2. Victim opens the Excel attachment and ”enable edit”, which starts the download of Qakbot from the C2 servers.
3. If C2 server is still online and the download is successful, the execution of Qakbot starts.
4. Qakbot starts the infection process via process injection to one of the following processes
   - Explorer
   - Internet Explorer
   - Mobsync
5. For post exploitation malware downloads, it creates additional connections to C2 Servers
6. Creates persistence
7. Executes post exploitation malwares.

Figure 1: “Prompting” users to enable content/editing

From here, I will be sharing what I saw in my analysis and how I approached the analysis.

Hands on Analysis

In the analysis we will look into actual Qakbot execution, and not from the Excel execution. This is because some of the Excel document connects to C2 server that are already offline and it will not properly retrieve the dll file.

The analysis will be conducted in VMware Windows 10 guest box and the following tools are going to be used.

• IDA Freeware
• x64dbg: Plugin DbgChild
• Process Monitor (ProcMon)

Static Analysis

In this Analysis I will be using IDA Freeware.

Export Table

Figure 2: The DllRegisterServer function which rundll32.exe will be calling

The Qakbot is a DLL file and from researching in the web, it appears that the file gets executed via rundll32.exe with function DllRegisterServer.

Import Table

Figure 3: Too few…

As we can see from the Figure 3, the import table looks too few and this is likely due to malware dynamically resolving the libraries.

Strings

When looked at the Strings of this dll file, most were random/encrypted looking strings. However there were two information that were interesting.

Figure 4: stager_1.dll

In Figure4, the dll name and the function name can be seen. This may indicate this file’s actual name or unpacked dll’s name.

Disassembler

To gather more information regarding this malware’s functionality, I attempted to analyze the DllRegisterServer function, but it was mostly random data, which is likely obfuscation done by the author.

Figure 5: DllRegisterServer disassemble

From looking at Import table, Strings and disassembled code I was only able to understand that it was doing anti-analysis methods, which was obstructng this analysis.

Since analyzing further with this method takes more time to deobfuscate the malware, I decided to speed up our analysis by going right into Dynamic Analysis.

Dynamic Analysis

In this analysis, we are going to look into the following.

• Anti-analysis
• Process Injection
• C2 Connection
• Persistence

x64dbg Command Line setting

We are going to debug the malware via x64dbg. Since dll file cannot be executed by itself, we need to start it with the rundll32.exe. The execution command are going to be below.

rundll32.exe C:\<Directory>\ldfr.oocs,DllRegisterServer

To debug dll files with x64dbg, we would need to take following steps

1. Open x64dbg → select “file” tab → select “open” → open rundll32.exe
   (Make sure you select 32 bit version of rundll32.exe)
2. Once the rundll32.exe starts, select “file” tab and select “Change Command Line.” Refer to Figure 6.
3. Once selected, pop up window will show where we can place our rundll32.exe command to execute our module! Refer to Figure 7.
4. Once completed, restart debugging.

Figure 6: “Change Command Line”

Figure 7: Command entered

Now that we have a proper commandline setup, lets start debugging.

Anti-Analysis

Malware authors will have tricks up their sleeve to hider the analysis, just as we saw in Static Analysis. Although debugger appears to be an ultimate tool within our arsenal, there are anti debugging and other methods to hinder the dynamic analysis.

How I feel using debuggers

For this specific case I will not look into specific anti-debugging technique(TBH I didn’t check…).

Many of the malware will often look into what processes are running in that environment. To achieve this, it will utilize CreateToolhelp32Snapshot api, which will allow the malware to retrieve information of processes running in the system.

Figure 8: CreateToolhelp32Snapshot

Figure 9: Stack for CreateToolhelp32Snapshot

As shown in Figure 9, the flag being used for CreateToolhelp32Snapshot is 0x2, which is TH32CS_SNAPPROCESS and it allows the snapshot to include all the processes running on the system. The malware is also known to checks its own file name and path.

With lists of processes running on the system, filename, and file path, malware compares it with the following lists.

• frida-winjector-helper-32.exe
• frida-winjector-helper-64.exe
• artifact.exe
• cuckoo-
• sandbox
• mlwr_smpl
• sample
• virus

It appears if the list matches with any of the above, it would terminate the malware execution.

Process Injection

From researching online, it appears the process injection that this malware uses is similar to Process Hollowing technique. The general steps for this technique are as follows.

1. Create an injection target process in suspended mode
2. Unmap the sections within the created process and prepare the realignment of injected code.
3. Write malicious code into a memory and remap.
4. Resume the suspended thread and start the malicious execution.

In this malware, we are seeing the following APIs used to execute this technique.

• CreateProcessW

When debugging, we can see the “explorer.exe” being created in suspended mode as shown in Figure 10and 11.

Figure 10: Creating a process with suspended mode as suggested by the instruction on 0x10010E6C

Figure 11: The process created with CreateProcessW is explorer.exe

Once the process is created we should take a note of the Handle number for later usage.

Figure 12: Process getting created.

• NtProtectVirtualMemory

This api changes the protection on a selected memory region. In the Process Hollowing, it can be seen to utilized for changing the permission of code injected into the target process.

Figure 13: NtProtectVirtualMemory getting called

Figure 14: Setting the memory region to PAGE_EXECUTE_READWRITE permission

As we can see from Figure 14, the explorer.exe handle is selected and changed the memory region 0x2F0FCC4 to 0x2F0FCD0 to permission flag of 0x40, which is PAGE_EXECUTE_READWRITE.

• ResumeThread

After injection setup is complete, malware will “resume” the created process which is in suspended mode. As we can see from Figure 15 the stack is selecting the suspended thread that was created in CreateProcessW.

Figure 15: Stack

The thread id is different from Figure 12 because I had to restart the debugging process, a noob mistake.

• VirtualAllocEx

Before injecting actual code or executable, malware would need to allocate a memory within the process.

Figure 16: Calling VirtualAllocEx

Figure 17: Allocating memory within the suspended process

Again, since I have restarted few times within my debugging process, Figure 17 has a different handle number from Figure 12.

• ZWUnmapViewOfSection

Process Hollowing removes the part of code out of the target process and then remap to injecting code. In order to execute this, malware needs to first “unmap” the sections within the process.

• ZwWriteVirtualMemory

After the memory is allocated within the target process, malware will start writing the injection code by utilizing this API.

Once the suspended process resumes, our debugger will detects it via plugin DbgChild, which will start another debugger. Figure 19 will show how the process looks like when our second debugger starts after the ResumeThread.

Figure 18: Process Hacker result

While debugging injected process(explorer.exe in our case), we can see that we are running in an unknown mapped memory space. While taking a look at the memory dump, we can see that it is an executable.

Figure 19: Legitimate PE header.

While looking into the dump, it includes same “stager_1.dll” and “DllRegisterServer” string, which likely indicates this file is indeed the injected code.

Figure 20: Same strings from Figure 4.

Since this DLL was already injected into the memory, it is likely in deobfuscated state. This appears to be the case as we can see from the Figure 21.

Figure 21: Import Table from memory dumped file and this looks more legitimate

With this information we can probably conduct more static analysis to dig deeper into what this malware is capable of. However within this analysis, I will not go dig any deeper.

However it was interesting to see the following string within this dump file.

Figure 22: Strings

Searching on the web, the string “deflate 1.2.8 Copyright 1995–2013 Jean-loup Gaily and Mark Adler” appears to be related to data compression library zlib. This libray can be seen to be used for some of the obfuscation method and this may be the case for this malware as well.

C2 Connections

Within the import table, we can see inet_ntoa function. This function converts the given string address into Internet standard dot notation, which we can debug to see what addresses are being used within this malware.

Figure 23: inet_ntoa function.

As we can see in the Figure 24, we are able to retrieve the IP address that this malware utilizes.

Figure 24: inet_ntoa returns C2 Server address.

When we search the given IP address in VirusTotal or other Threat Intelligence, we can see that the detected IP address is already known to be related to Qakbot.

From looking at String reference in x64dbg, we can also see where certain Strings are getting called. In Figure 25, there are strings with “https://” and this is likely where our IP address gets concatenated to create a C2 connection string.

Figure 25: String reference

From debugging according to the above information, it appears the assumption was accurate. From Figure 26, we can see the Address which was translated in inet_ntoa getting concatenated with the string “https://.”

Figure 26: IP address concatenated

Looking at the memory dump where the connection strings are written, we can see it is ending with “obama07.” Now I know why Qakbot is sometimes labled as “obama07.”

Figure 27: List of connection strings

Below are some of the IP addresses seen in the malware.

95.77.223[.]148, 186.28.55[.]211, 119.153.43[.]235, 43.32.211[.]207, 71.74.12[.]34, 80.227.5[.]69, 149.28.101[.]90, 71.88.193[.]17, 98.192.185[.]86, 149.28.101[.]90, 207.246.116[.]237, 2.7.116[.]188, 195.12.154[.]8, 45.77.117[.]108, 68.186.192[.]69, 108.160.123[.]244, 96.37.113[.]36, 79.129.121[.]81, 24.55.112[.]61, 83.110.109[.]106, 142.117.191[.]18, 74.222.204[.]82, 89.137.211[.]239, 217.133.54[.]140, 47.22.148[.]6, 75.67.192[.]125, 173.184.119[.]153, 173.21.10[.]71, 108.31.15[.]10, 193.248.221[.]184, 50.244.112[.]106, 92.59.35[.]196, 207.246.77[.]75, 207.246.116[.]237, 45.77.115[.]208, 189.210.115[.]207, 219.76.148[.]200, 189.222.59[.]177, 176.181.247[.]197, 83.110.11[.]244, 86.236.77[.]68, 187.250.118[.]233, 144.139.166[.]18, 176.181.247[.]197, 89.137.211[.]239, 140.82.49[.]12, 24.139.72[.]117, 76.25.142[.]196, 45.77.115[.]208, 45.32.211[.]207, 125.239.152[.]76, 80.11.173[.]82, 108.46.145[.]30, 173.21.10[.]71, 24.43.22[.]218, 217.133.54[.]140, 187.250.39[.]162, 45.77.117[.]108, 172.78.30[.]215, 202.184.20[.]119, 38.92.225[.]121, 149.28.98[.]196, 71.199.192[.]62, 45.77.115[.]208, 189.211.177[.]183, 149.28.99[.]97, 67.6.12[.]4, 85.52.72[.]32, 73.153.211[.]227

Persistence

Persistence mechanism that this malware uses is interesting. From sources on the web, it appears this malware has a capability to create a registry entry at the time of system’s shutdown. However it will delete the registry entry right after system boot to evade detection by antivirus softwares.

Looking at the import table, we can see that the malware is importing Registry related APIs.

Figure 28: Import table

While executing explorer.exe, we also got a service creation notification.

Figure 29: service created for malware

When obeserved this service within Process Hacker, start type is selected as “System Start”, which we can assume this service will delete the malware’s registry entry at the time of the system boot.

Figure 30: Service stopped at the time of creation.

To get the actual logs of this persistence in action, we are going to use ProcMon for Boot Logging. This method would allow us to see all the process logs at the time of system boot. Figure 31 is again has a different service name because of the restart…

Figure 31: Registry Entry

From the Figure 32, the persistence will be kept by starting the following dll file via regsvr32.exe. Finally once the following command is executed, the Registry Entry is deleted as we can see in the Figure 33.

Figure 32: Registry Value.

Figure 33: Registry deleted

Conclusion

From above analysis, it is evident that Qakbot has 3 major steps to infect the system.

1. Process Injection to evade detection and execute malicious code.
2. Persistence, which can also evade detection and keep the system infected.
3. Create C2 connections strings, which is assumed to be utilized for post exploitation.

Overall this malware was really interesting and being able to observe various malware techniques was a great learning experiece. I also felt that even after this, there’s just so much more to learn…

References

URLhaus - Tag Qakbot

Qbot malware switched to stealthy new Windows autostart method

https://www.binarydefense.com/qakbot-upgrades-to-stealthier-persistence-method/

https://github.com/David-Reguera-Garcia-Dreg/DbgChild