Break down the business value of Binary Defense services into dollars and cents

Qakbot Upgrades to Stealthier Persistence Method

James Quinn

James Quinn

James Quinn is a Threat Researcher and Malware Analyst at Binary Defense. He also works as a freelance malware analyst and participates in security intelligence sharing groups. James is a major contributor to research of the Emotet botnet with the Cryptolaemus security researcher group. Quinn has previously written about Emocrash, a killswitch he wrote for Emotet after discovering a vulnerability from reverse engineering the malware.
Share on facebook
Share on twitter
Share on linkedin

Qakbot is a versatile banking trojan that until recently, focused primarily on theft of personal information and passwords.  However, following the trend toward ransomware set by Trickbot and other botnet malware families, Qakbot has recently shifted its goals to deliver post compromise attack platforms such as Cobalt Strike Beacon, with the final objective of loading ransomware, including ProLock and most recently, Egregor ransomware. On November 24, Binary Defense’s analysts detected a major version update to Qakbot’s loader and bot, combining the loader and bot into one file. Additionally, it changed several of Qakbot’s persistence mechanisms to make them more stealthy, while moving a lot of its logging to the registry. 

Arrival on System

In recent campaigns. Qakbot typically arrives on the system after a victim opens and enables macros on a malicious Excel workbook file.  Currently, there are 2 active distribution affiliates or “botgroups” as they are identified in Qakbot’s core configuration: abcXXX and tr02.  For the purpose of this analysis, Binary Defense will be focusing on tr02’s Excel files and distribution techniques.

The tr02 distribution affiliate for Qakbot uses two different approaches, with examples shown below. Some distributions are malicious spam messages with malicious file attachments, using topical lures with key phrases related to the pandemic. For other distributions, their approach uses spam messages with generic lure text, containing a link to download the malicious files, which the targeted person has to click to download. The lure text is not well written, but it has been effective enough to convince people to open the attachment.

Good afternoon!
In line with the pandemic warning, we have signed a sanity rules.
Check out the table to learn more #
Thanks.
Fig 1.1, example of attachment-only email lure

Stealthy Sheets

The Excel file that is used to deliver the malware has been successful at avoiding detection by most anti-virus programs, at least for the first day or two after each wave of malicious spam emails are sent. Most of the malicious files are detected by only three to five out of the 70 or so anti-virus products on VirusTotal at the time they are sent. More anti-virus products usually catch up to start detecting the files as malware over the next few days, but by that time it is too late for all the victims whose computers have already been infected.

Once the victim has downloaded and opened the Excel sheet, obtained either in attachment or through a compromised distribution server, they are greeted with a sheet masquerading itself as a DocuSign-encrypted document, which contains macros in the older Excel 4 macro format. The name of the first sheet in the Excel file is usually “DocuSign” and there are other attributes of the Excel files which make them unique. A search of VirusTotal for XLS files with these unique attributes results in over 42,400 malicious files, most of which have five or fewer detections by anti-virus products, and about 300 of which are not detected by any anti-virus at all, even though they contain the malicious Excel 4 macros. This very low detection rate means that the payloads are more likely to make it through email threat scanning systems and into employees’ inboxes.

The malicious sheet informs the victim that they need to enable macros to proceed. 

A DocuSign masquerading lure, with step-by-step guides instructing the user to first click "Enable Editing" followed by "Enable Content
Figure 1.2, example of a malicious Excel sheet

As seen in Figure 1.2, the sheet actually includes a step-by-step guide for the victim to enable macros.  This is a very common technique for macro-based document malware.

The Excel sheet macro is basic in its operation and simply downloads the Qakbot bot DLL from a distribution server, which is typically a compromised web server. The downloaded bot DLL is then loaded with regsvr32.exe, using a seemingly random drop path, as seen in figure 1.3.

A process execution tree shows that Excel.exe executed regsvr32.exe with the "-s" switch.
Figure 1.3, regsvr32.exe used with -s to load a DLL

As these sheets have fairly low detection rates, one of the key detections we’ve found for this behavior is using Endpoint Detection and Response (EDR) telemetry to detect when regsvr32 is used to register DLLs (-s switch), after spawning from Excel.exe.

New call-to-action

Qakbot Installation

The usage of regsvr32.exe by the macros in the Excel sheets is not just for defense evasion. The unpacked Qakbot loader/bot DLL has two exports: the entry point, and DllRegisterServer.  DllRegisterServer contains the main code for the loader/bot and is only called if the DLL is executed with regsvr32.exe -s, or executed with rundll32.exe using the “DllRegisterServer” command line argument. If it had been executed without these command line arguments, as is typically done by automated malware sandbox systems when analyzing a DLL file, only the entry point function would have been called. Because the entry point function doesn’t perform any malicious actions, a sandbox system likely would mark the DLL as benign.

Inside the new combined loader and bot DLL, the loader portion of Qakbot has been vastly simplified. Removing the command line switches and analysis checks through new process creation (while still keeping many of the anti-analysis/anti-sandbox checks), the new loader’s installation mechanism only occurs after the bot has been injected into explorer.exe. The new installation mechanism also creates the new in-registry encrypted config generated by the bot during runtime, which will be discussed in a later section.

The first actionable persistence mechanism is the installation of a scheduled task, using the command line in figure 2.1. The xml for the installed scheduled task is also included in Appendix A.

%s\system32\schtasks.exe" /Create /RU "NT Authority\SYSTEM" /tn %s /tr "%s" /SC ONCE /Z /ST %02u:%02u /ET %02u:%02u
Figure 2.1 Command executed to install the scheduled task

Run Key Persistence

While initial reports by other researchers had stated that the Run key persistence mechanism was removed in the new version of Qakbot, it has instead been added to a more stealthy and interesting persistence mechanism that listens for System Shutdown Messages, along with PowerBroadcast Suspend/Resume messages. If it detects a shutdown or a system suspend (sleep) as demonstrated in Figure 3.1, Qakbot will install itself to the run key just before the computer goes to sleep or shuts down, so that Qakbot will be executed when the system wakes up or restarts, but waiting so close to system shutdown that security products don’t have a chance to detect and report on the new run key. If it detects a “Resume” message (which is sent when sleep is ended), it deletes the run key in an effort to evade detection by defenders. 

IDA Assembly graph view of the Windows Message Listener function.  WM_QUERYENDSESSION is highlighted, and a green path shows it leading to the PersistenceInstall function, along with PBT_APMSUSPEND.

PBT_APMRESUMESUSPEND and PBT_APMRRESUMEAUTOMATIC events result in the DeletePersistence function's execution.
Figure 3.1, Window Message Listener

This particular type of persistence mechanism is not unheard of and has been used Gozi and Dridex in the past. Qakbot attempts to delete this run key several times throughout its execution, just to be sure that it is gone. Because the run key value name is entirely random, Qakbot’s code doesn’t know exactly what the key will be named, and attempts to delete any run keys with value data matching Qakbot’s path.

As seen in Figure 3.2, the run key uses regsvr32.exe to execute the bot DLL.

View of Registry Editor for the HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows
CurrentVersion\Run key.

Value Name: whsibbxtd
Value Data: regsvr32.exe -s "<Censored>"
Figure 3.2, Run key install using a randomized key name (“whsibbxtd” in this example)

Encrypted Config In Registry

One of the most noticeable changes to Qakbot was the removal of the configuration and log file ending in “.dat” that was created by the previous version of the loader and bot and updated during run time.  While the encrypted config file is no longer stored as a .dat file on victim systems, the same configuration data has instead been moved to the registry and encrypted. 

During startup, the bot creates a key in HKCU\\Software\\Microsoft\\<predictably random string>. Inside this key are eight-character long hex strings (using the characters a-f, 0-9) representing a hashed config entry. Each of the values contain encrypted config entries, using an RC4 key made up of a salted SHA1 hash of the victim’s computer info along with the config value as a DWORD in little endian byte order. The key is then padded with random data to further obfuscate the true content.

Conclusion

In this analysis, we discussed the lures used by the Qakbot distribution affiliate, tr02, along with the recent updates to the Qakbot binary (effective for all bots, regardless of botgroup). 

Appendix A: Scheduled Task Details

Scheduled Task
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2020-12-03T18:06:51</Date>
    <Author>Censored</Author>
    <URI>\gmyqoeobly</URI>
  </RegistrationInfo>
  <Triggers>
    <TimeTrigger>
      <Repetition>
        <Interval>PT10M</Interval>
        <StopAtDurationEnd>false</StopAtDurationEnd>
      </Repetition>
      <StartBoundary>2020-12-03T18:08:00</StartBoundary>
      <EndBoundary>2020-12-03T18:20:00</EndBoundary>
      <Enabled>true</Enabled>
    </TimeTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-18</UserId>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <Duration>PT10M</Duration>
      <WaitTimeout>PT1H</WaitTimeout>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <DeleteExpiredTaskAfter>PT1S</DeleteExpiredTaskAfter>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>regsvr32.exe</Command>
      <Arguments>-s "C:\Users\<pathToBot>"</Arguments>
    </Exec>
  </Actions>
</Task>

Appendix B: Indicators of Compromise (IoCs)

HKCU\\Software\\Microsoft\\<predictably random keys> - Config log directory
%Appdata%\Microsoft\\<predictably random keys> - Bot install directory
Run key saved during computer reboot, and deleted on computer login.

Reference: https://www.cybereason.com/blog/new-ursnif-variant-targets-japan-packed-with-new-features


Don’t miss the latest updates on current threats and industry trends! Sign up for Threat Watch, a free news digest from Binary Defense.

More Articles