QakBot Hooking Analysis

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()

When we first open the sample in Pestudio, we see that there are 2 executables embedded in it

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

“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

We open the 32 bit DLL in IDA for static analysis

Since we know that it uses API hooking and trampolines, we want to find occurrences of 0xE9 which represents the jmp instruction

We see that 3 lines of code in 2 functions are writing or comparing to 0xE9

We go into procedure 10009DDF and we see a long complicated function

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.

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.

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.

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