Reviewing Qakbot loader sequences: Part 4

Posted:
10/25/2023
| By:
Blake Eakin

So far, in our Qakbot review blog series, we’ve focused on weak signals that emerge after reviewing the historic procedure-level behaviors wholly to understand atypical activities and trends that can detect similar techniques used by other threat actors or the same actors returning to old techniques. For convenience, you can reference the first three parts of the series below.

In this fourth installment and conclusion to our series, we review everything in between—which includes techniques chosen to evade defenses that require minimal user interaction in a manner that maintains a low level of suspicion.

Office document macro execution

Office macros were once one of the most common phishing payloads, not just for Qakbot delivery but throughout the landscape of malware delivered via phishing. They’re not as popular as they once were before Microsoft disabled them by default in Office documents with the mark of the web (MOTW), so we won’t dive as deep into macros as some of the other paths—but to ignore them would expose a blind spot.

Our approach for detecting malicious macro execution depends on two signals. The first is suspicious child processes of Office application parents. In the case of Qakbot, these were mostly regsvr32.exe child processes, usually from Excel. The second is a registry value being set that indicates a user clicked the banner to trust the downloaded document, which is shown below.

HKCU\Software\Microsoft\Office\[version]\[application]\Security\Trusted Documents\TrustRecords\[document path]

LNK files

LNK files, commonly known as shortcuts, were used in malicious contexts before Microsoft disabled macros, but afterward, they became very popular for many of the advantages they offered. For one, they offer a built-in, one-click execution of anything set in the shortcut’s target. They also provide a trustworthy appearance. Any icon can be set for the shortcut, and the LNK file extension is hidden by default in the file explorer, so anything named with two extensions, eg. .pdf.lnk, will appear as if it had the first file extension. The only visual tell might be the small arrow icon in the lower-left corner, but that can easily be overlooked or quickly considered a curiosity.

On top of that, aside from file creation records, there’s no log-based indicator that an LNK file was involved in any activity. Given this, our attempts here will be to consider what we do know about running LNK files and combine this with what can be known about the contexts they’re expected to be opened in to develop possible detections.

From our research, we can tell several things about LNK file execution. For one, the LNK file’s target will be observed as a child process to explorer.exe unless the shortcut was opened from archive software, in which case that specific software will be its parent process. Also, the working directory for the process creation event will be the directory it was opened from.

Outside of that, there’s not much to help us out. SentinelLABS has previously done valuable frequency analysis on LNK samples from VirusTotal that can be combined with these other facts to try and dig out potential LNK executions from directories where malicious LNK payloads could land.

With Qakbot delivery, the context was always either in a disc image file or a ZIP file. Also, execution from an LNK file generally fell into one of three categories: directly executing a DLL using rundll32.exe or regsvr32.exe, running a script file (.cmd, .bat, .js, .vbs, .wsf), or enacting a DLL hijack.

Disc image files

Another delivery method that saw an upswing post-macro disabling was the use of disc image files such as .iso, .img, and .vhd. In some cases, they could be used to bypass MOTW. They also provided some illusion of trust since, by default, when they are opened by a user, Windows will go ahead and mount the image and then present its contents to the user in the explorer window without them needing to put much thought into what they just opened.

Mounting a disc image file can be identified in event logs in a couple of different ways, which may provide a good detection on its own if their usage is unexpected in your environment or by particular users. A variety of registry activities will occur when they are mounted, but one value will indicate for certain that a virtual drive has been mounted.

For ISO and IMG files:

Key:HKLM\System\CurrentControlSet\Enum\SCSI\CdRom&Ven_Msft&Prod_Virtual_DVD-ROM\2&1f4adffe&0&[number]

Value:FriendlyName

Data:@cdrom.inf,%%ISO_Generic_FriendlyName%%;Microsoft Virtual DVD-ROM

For VHD files:

Key:HKLM\System\CurrentControlSet\Enum\SCSI\Disk&Ven_Msft&Prod_Virtual_Disk\2&1f4adffe&0&[number]

Value:FriendlyName

Data:@disk.inf,%%VHD_Generic_FriendlyName%%;Microsoft Virtual Disk

Depending on how file system auditing is configured, you can also observe the files that are in a disc image using event ID 4663 for removable storage, which will show important details around an attempt to access an object.

Notably, the ObjectName will show the path of the file in the image, which will start with “\Device\CdRom[#],” and ProcessName, which will show the processes attempting to access it. Using this, you can hunt for disc images mounted with LNK files, script files, and other suspicious files. It won’t be certain that the removable storage device will be from a disc image, but this can be correlated with other records. VHD images will not generate these records since they will be mounted as local discs instead of removable discs.

The fact that most Qakbot LNK activity came from disc images presents us with some detection opportunities for potential execution from a LNK file in a mounted image. Knowing what was previously established about LNK files, we can look for process creation events where the working directory is in a lettered drive other than “C” with an explorer.exe parent process.

From here, we can cover most of the LNK execution cases by looking for the process being cmd.exe with the “/c” switch on the command line, or for cases where the target was a script file, we can look for wscript.exe process names.

To cover the final case of DLL hijacking, we could also have a detection for Sysmon Image Loaded events where the image path is in a lettered drive other than “C” as well. Again, none of these activities indicate with certainty that LNK files were opened from mounted disc images or that DLL hijacking occurred, just that several signs that would be present in those cases aligned to indicate its possibility. All these events are atypical enough to warrant further investigation and potential tuning for expected activity.

It would also be effective to create detections for particularly small disc image files, but this would depend on the proper telemetry.

Curl

Most of the time, the malicious DLL for injecting Qakbot was delivered with the phishing payload, whether in a disc image or otherwise embedded in delivered files. But it wasn’t infrequent for it to be downloaded after the phishing payload was executed. In these cases, curl was mostly used to download the next stage payload. Curl was made native to Windows in 2018 but could potentially be used in a wider variety of ways than just the native binary.

Curl offers a Windows installer that will likely be more up-to-date than the native version. Many software installs will package a curl binary with them. PowerShell uses curl as an alias for Invoke-WebRequest. You may see it evoked via Windows Subsystem for Linux (WSL), and malware could even drop its own curl binary to ensure its availability.

There are many ways curl may be used in normal settings, but the effectiveness of detections based on it will heavily depend on your own environment. In some cases, it may be enough to look for users running curl, as this could be unusual enough in your environment to warrant concern. However, you may need to narrow it down to certain types of users if curl is frequently used by developers or IT-based users.

For our purposes of monitoring many different environments, we’ve found an effective detection in Qakbot’s cases to detect file creation events by the native curl binary, which we target with system32 or SYSWOW64 in the image path. This could be further refined by looking for file creations in suspicious directories if necessary for your purposes.

Less frequently observed behaviors

In at least 19 instances, scheduled tasks were used for privilege escalation using schtasks.exe. All those task creation events involved using the arguments “/Z” for deleting the task after it runs, “/RU “NT AUTHORITY\SYSTEM”” to run as the SYSTEM user, and “/SC ONCE” to specify that it should only run once.

Depending on your environment, these options may be suspicious enough to warrant detections. However, we also see many common, benign scheduled tasks using all these arguments, so we’ve been able to make stronger detections around the content of the task itself. For Qakbot distribution, this included tasks running powershell.exe, rundll32.exe, and regsvr32.exe.

A few times, they used other living-off-the-land binaries (LOLBins) such as mshta.exe and hh.exe for proxying execution of scripts. The resulting behavior is typically suspicious enough to warrant detection and can capture a variety of other threat actors’ activities. With Qakbot, they were seen as parent processes to curl, PowerShell, and rundll32.

MSI installers were used a handful of times, leading directly to rundll32 execution. They were either opened from ZIP or ISO files, or they were executed by wscript. Most of the MSI files were dropped in the user’s %temp% directory, which can be observed after the “/i” switch on the command line executions. These occurrences can be observed in Sysmon Process Creation events, but there are also MsiInstaller events that can potentially provide more structured data around these activities.

Conclusion

The botnet infrastructure supporting Qakbot has been dismantled, but with the actors behind it still free, we expect to see them reemerge. Attackers will never stop coming up with new techniques to evade defenses, but they frequently revisit and tune them.

Following the detection guidance we’ve outlined throughout the series will help give you an advantage for the next wave of their attacks. Since the recommendations are based on behaviors for the delivery of Qakbot, it will allow you to detect on their known techniques broadly, giving them fewer opportunities to sneak through defenses with old behaviors.

Recommended