QBot is a banking trojan that steals victims’ credentials and is usually spread via phishing campaigns. QBot aka QakBot malware has been there for a decade as it frequently evolves new techniques to attack victims.
Recently, several articles have been making rounds regarding the new variant of QakBot leverages DLL Side Loading technique to spread its malicious binary and evade detections.
Today, I’ll analyze one such sample, and we’ll see how easy it is for the threat actors to evade detections by using Windows’ legitimate apps.
QakBot Leverages DLL Side Loading Technique
The sample was first reported by Security Researcher @ProxyLive
#Qakbot – obama200 – html > .zip > .iso > .lnk > calc.exe > .dll > .dll
— proxylife (@pr0xylife) July 11, 2022
T1574 – DLL Search Order Hijacking
cmd.exe /q /c calc.exe
regsvr32 /s C:UsersUserAppDataLocalTempWindowsCodecs.dll
regsvr32.exe 102755.dllhttps://t.co/2Vgg6cuRFh
IOC’shttps://t.co/e7hkNW8eQu pic.twitter.com/sCH1xagkyR
MD5: 2881945bdf1db34216cc565fef4501d4
SHA-1: 274104b6503e7b94336fe44df94dc8356855c8fa
SHA-256: 54688153cd5a861b26da6a8c191aabe01bb5bfd31d1ab1dd848788b40cc3a38c
Dropper – Html file
To better understand the sample file, it is important to know what is the file format of the sample file. If we simply open it in any code editor like Notepad or Visual Studio Code, we can see that the sample is actually an HTML file. Other cases would be a PE file, ELF file or any other file format.
Opening up a sample file in the browser automatically downloads a zip file named “Report Jul 14 71645.zip“. The password provided for the zip file is abc444.
As we now already know that the sample is an HTML file and begins with the Html and CSS codes that it needs to render a page… however, if we scroll towards the bottom of the page, we could see some interesting JavaScript code that we can start to dig in to understand better what’s happening behind the scene.
Around line 972 starts a javascript code that contains a huge blob of Base64 code (highlighted in yellow) and is assigned to a variable text.
If we take that data and decode it in CyberChef, we can see that it identified it as a PK file, which basically denotes that it is an archive.
Also, if you notice the decoded data in the Output window, you can see some text at the beginning saying “3590/Report Jul 14 71645.iso“. From this, we can guess that this relates to the zip file downloaded earlier. The below code also gives some strong indication.
var content_type = ‘application/zip’;
var target_file_name = ‘Report Jul 14 71645.zip’;
Now, if we extract the contents of the archive “Report Jul 14 71645.zip” with the specified password abc444, we can see extracted folder named 3590, and within that, there’s an iso file named Report Jul 14 71645.iso.
Now, this is clear that it is related to the above data, which we saw while decoding a Base64 encoded code in CyberChef.
The ISO file contains four different files: an LNK file, a legitimate calculator app (calc.exe) from windows 7, and two DLL files, 7533.dll and WindowsCodes.dll. If the victim has not enabled the option to show hidden items, then he will see only LNK (shortcut) file.
Now, the actual game begins here. And we’ll try to understand what’s calc.exe doing here. We can guess that those DLLs probably would be malicious. But calc.exe….?
Here Comes DLL Side Loading
DLL side loading is a technique where threat actors take advantage of the DLL search order where application and malicious DLL are placed side by side. Side loading takes advantage of hijacking, which DLL a program loads when executed.
In the same way, in this case, if the victim executes an LNK file, it runs a calc.exe which loads the WindowsCodec.dll DLL file and does the malicious stuff in the background.
But the question arises why it loads WindowsCodec.dll first and not the other DLL file. And what happens if we change the name of the DLLs? Will that still execute the malware?
Well, this is something that we’ll see going forward. To make it understand better, let’s jump to our VM and test out the samples actually with different use cases.
Case 1: If we take our calc.exe application and execute it from some other folder other than the one where the malicious files reside, we can see in the Process Monitor that calc.exe is trying to load the DLL file named WindowsCodecs.dll, but since it wasn’t found at the folder from where the calc.exe was launched, Process Monitor says NAME NOT FOUND, but later it was found in the SysWOW64 or System32 folder and loads it from there.
Wondering Why?
The answer lies in the DLL search order; how the Windows app loads any particular DLL.
The DLL search order says that the application should first search and load the DLL from the directory from which the application is loaded. And if not found, then it searches for the specified DLL in the System directory.
This is what has happened in this case.
Case 2: Now, let’s see what happens when you launch an app calc.exe from within a folder that contains malicious DLLs.
Calc.exe found the WindowsCodecs.dll file, and once it side-loads it on runtime, it spawns a process regsvr32.exe with command line “C:WindowsSysWOW64regsvr32.exe 7533.dll” that executes the malicious 7533.dll file.
This is how the attacker makes use of Windows legitimate binaries to carry out the attack and evades detections as well.
