threat

Qbot

Qbot is a banking trojan with the ability to quickly spread to other hosts within an environment. In 2020 Qbot was observed as a delivery agent for ransomware, most notably ProLock and Egregor.

Pairs with this song

#3

OVERALL RANK

8.7%

CUSTOMERS AFFECTED
 

Analysis

Qbot, also known as “Qakbot” or “Pinkslipbot,” is a banking trojan that has been active since at least 2007, focusing on stealing user data and banking credentials. Over time, the malware has evolved to include new delivery mechanisms, command and control (C2) techniques, and anti-analysis features. Qbot infections typically stem from phishing campaigns. While some campaigns deliver Qbot directly, throughout 2020 we observed Qbot delivered as a secondary payload to other prominent malware such as Emotet.

In addition to data and credential theft, Qbot has the ability to move laterally within an environment. Left unchecked, widespread Qbot infections throughout an enterprise eventually lead to ransomware. Different ransomware families have been observed alongside Qbot, with ProLock being a common occurrence in early 2020, followed by a much more prolific outbreak of Egregor ransomware as a Qbot follow-on later in the year. For these reasons, it is imperative to respond quickly when Qbot gains a foothold in your environment.

Evolving TTPs

Qbot presents several opportunities for detection, and while it is actively developed and TTPs have changed over the years, some things remain the same. One of these consistent patterns is the staging folder for the malware. Historically, Qbot installed itself as a randomly named EXE into a randomly named subdirectory of AppData\Microsoft. However, during the latter half of 2020, Qbot switched to using a DLL instead of an EXE. The use of a DLL provides more flexibility for defense evasion through Signed Binary Proxy Execution using Regsvr32 or Rundll32.

Along with the change to using a DLL, Qbot also changed where it stores configuration information on the infected host. Earlier versions of Qbot stored this data within a DAT file in the same randomly named folder as the malicious binary. As of late 2020, this data is now stored in the registry, under a randomly named subkey under HKCU\Software\Microsoft. While this move to the registry keeps things a bit more hidden from prying eyes, in both cases the presence of a randomly named value under the Microsoft folder/key should be cause to investigate. Baselining the normal values in these locations and alerting on anomalies can be a fruitful way to identify Qbot, as well as other Microsoft-masquerading malware attempting to hide out in these places.

Over a decade of development and in-the-wild observation, many researchers have studied and reported on Qbot’s evolving TTPs, including Binary Defense and Fortinet.

Detection opportunities

Detection opportunity 1

Microsoft Office spawning Rundll32 or Regsvr32
ATT&CK technique(s): T1218.011 Signed Binary Proxy Execution: Rundll32, T1218.010 Signed Binary Proxy Execution: Regsvr32
ATT&CK tactic(s): Defense Evasion

Details: Since October 2020, we have observed Qbot delivered as a DLL and subsequently executed using the signed binaries Rundll32 or Regsvr32, which adversaries commonly use to evade defensive controls. Looking for instances of either of these processes executed as a child of winword.exe or excel.exe is a quick win to detect Qbot’s initial access as well as other threats spawning from initial access via Microsoft Office. Additionally, we’ve found success with the rundll32.exe command-line flag DLLRegisterServer. While this is a legitimate function for rundll32.exe, with some baselining you can tune this to identify anomalous behavior.

Detection opportunity 2

Execution of esentutl to extract browser data
ATT&CK technique(s): T1005 Data from Local System
ATT&CK tactic(s): Collection

Details: One way Qbot steals sensitive information is by extracting browser data from Internet Explorer and Microsoft Edge by using the built-in utility esentutl.exe. As we examined normal esentutl command lines, we determined it’s fairly rare to see references to Windows\WebCache in the command line for this tool. Writing an analytic looking for a process of esentutl.exe with Windows\WebCache in the command line may help you catch this behavior.

Detection opportunity 3

Scheduled task names and execution
ATT&CK technique(s): T1053.005 Scheduled Task/Job: Scheduled Task,T1218.010 Signed Binary Proxy Execution: Regsvr32
ATT&CK tactic(s): Persistence, Defense Evasion

Details: The more things change, the more they stay the same. One of the most consistent ways we have detected Qbot over the years is through its use of scheduled tasks for persistence. While Qbot has consistently relied on this method of persisting, its implementation has varied over time. These variations have triggered several different detection analytics.

One area to focus on is the name of the scheduled task. We often observe this in the /tn (task name) parameter on the command line of schtasks.exe. Much like the subfolders containing the malware, some versions of Qbot have used a random string for the scheduled task name. This is a bit more challenging to detect, but using trigram analysis, we have been able to identify likely random task names that unearth a variety of pernicious persistence. In addition to the scheduled task name, the process it executes can also be useful for detection. In the below example (showing the more recent DLL variation of Qbot), you can see that the process executed by the task is regsvr32.exe. It is unusual to see a scheduled task executing regsvr32.exe at all, let alone for a binary in a user’s profile folder, so looking for that execution presents another detection opportunity.

In other cases, instead of a random string of characters, Qbot uses a GUID for the scheduled task name. Since GUIDs use a similar pattern, you can create a detection analytic looking for schtasks.exe along with create and a regular expression for the GUID pattern. You may still encounter some legitimate software doing this, but it should be fairly straightforward to tune out the noise based on the parent process of schtasks or by the specific GUID itself.

In addition to the scheduled task name, you can also look for what is being executed, similar to the above example. In the below example, the GUID task name executes JavaScript stored in a file with a .npl file extension. You could create a detection analytic looking for scheduled task execution of a .npl file, or even take it a step further to look for cscript.exe or wscript.exe execution from scheduled tasks (though that may take some tuning).

Kyle Rainey
INTELLIGENCE ANALYST
Kyle has been providing proactive and reactive incident response and forensics services to Fortune 500 companies for over five years. As an intelligence analyst at Red Canary, he leverages his years of experience conducting investigations and building detections in order to engineer impactful, scalable intelligence products. Kyle is passionate about solving hard problems and constantly learning.
Kyle has been providing proactive and reactive incident response and forensics services to Fortune 500 companies for over five years. As an intelligence analyst at Red Canary, he leverages his years of experience conducting investigations and building detections in order to engineer impactful, scalable intelligence products. Kyle is passionate about solving hard problems and constantly learning.