🦆

QakBot Hooking Analysis

QakBot

QakBot is a banking trojan that infects the victim by hooking web browser DLLs, and redirecting them to malicious functions when functions like HttpSendRequest() or HttpOpenUrl() are called from the browser.
Even if TLS or HTTPS is enabled, the malware is still able to get the information as encryption of the data is done during the call to HttpSendRequest() and not before. Therefore when QakBot hooks this function, it’s able to access all unencrypted data and send it to it’s own servers, before executing the normal procedure of HttpSendRequest()

Dumping the files

When we first open the sample in Pestudio, we see that there are 2 executables embedded in it
notion image
We dump these two files out for analysis. One of the files is a 64 bit DLL, while the other is a 32 bit DLL, both written in Visual Studio
notion image

Trampoline Refresher

“Cheating” a little, we already know that this malware sample does API hooking via trampolines. As a refresher, trampolines redirect the original function to a malicious one, and after executing the malicious actions, within the malicious function it jumps back to the original intended function.
In this example, on the left shows the original function of InternetReadFile. On the right is after we have hooked it, and upon calling InternetReadFile, there is a jump to LoadLibraryA (or our malicious function). After executing LoadLibraryA or our malicious function, it jumps back to the InternetReadFile procedure at sub esp 38
notion image
 

32 bit DLL analysis

We open the 32 bit DLL in IDA for static analysis
notion image
Since we know that it uses API hooking and trampolines, we want to find occurrences of 0xE9 which represents the jmp instruction
notion image
notion image
We see that 3 lines of code in 2 functions are writing or comparing to 0xE9
notion image
We go into procedure 10009DDF and we see a long complicated function
notion image
If we find references to this function and references to those, we eventually end up in this function.
It first get a variable from sub_100147C5(*a2) and returns it to v4
Then it calls GetModuleHandleA(v4) to the get the handle on v4, before calling GetProcAddress to get the procedure address of v4
This is likely the pre-hooking setup, where it’s finding the address of the function to hook, and sub_10002D2E does the actual hooking.
 
notion image
If we find references to this function, we see 5 of them. They each pass in data from different memory regions, and these eventually get passed to the pre-hooking function.
notion image
notion image
notion image
notion image
notion image
notion image
If we inspect one of the memory regions, we get a hex value. This will be passed to sub_100147C5 in the pre-hooking function.
sub_100147C5 looks to be doing some form of decryption or de-obfuscation due to the presence of a XOR operation, and iterating through an object at line 44.
notion image
notion image
We can thus guess that the malware decrypts a string, gets the module handle and procedure address, and then performs hooking on those functions.
When we rename the pre-hooking function to it’s functionality, it will look something like this
notion image