Malware Analysis Spotlight: Qbot’s Delivery Method

Sep 15th 2020

The Re-Emergence of Qbot

After more than a decade in operation, the Qbot Trojan is back in the news. A modified version of the malware which now extracts email threads from Outlook to use in phishing attacks was used in a prominent campaign that ran from March to the end of June. Then this same modified version was used, in some cases, as the payload for the Emotet Trojan campaign in July that may have affected up to 5% of organizations worldwideNow, Qbot is taking on a life of its own with its malspam campaign launched in August.

First discovered in 2008, Qbot has evolved from a banking Trojan which steals online banking credentials to becoming a “Swiss Army knife” of malware, capable of not only stealing credentials but also distributing ransomware and performing other malicious activity.

This Malware Analysis Spotlight focuses on one of the methods used to deliver Qbot and highlights some interesting features of the delivery process leading to the execution of Qbot. In contrast to commonly used delivery techniques through documents with embedded VBA macros, the payload used in this sample is disguised as properties of different objects. This can bypass static analysis because the referenced properties have to be taken into account to see the full behavior of the macro.

View the VMRay Analyzer Report for Qbot


Analysis of a Qbot Delivery Method

The initial delivery method is using a Word document with an embedded VBA macro. The macro is referencing data hidden inside a forms object also embedded inside the document. From the label embedded in the form, it extracts a Visual Basic script, drops it into a file and executes it by starting explorer.exe with the script as an argument (Figure 1). The tool oledump by Didier Stevens is also capable of extracting information from user forms as has been demonstrated in Maldoc: Payloads in User Forms.


Malicious Document

Figure 1: Malicious document with “hidden” data.


The VBS contains a lot of noise including a variable declaration for errors and messages, and a header claiming the original name of the file is winrm.vbs.

The actual purpose it serves is to write a set of commands into a .cmd file which it then executes. This functionality is located near the middle of the file, surrounded by the previously mentioned noise.

The written cmd script invokes Powershell with commands as arguments, which then downloads the payload from one of the hard-coded domains to “C:\BlotRoots\Loterious.exe and executes it with the standard alias saps (Figure 2).


VMRay Analyzer

Figure 2: VMRay Analyzer Behavior – Powershell downloads next stage.


The final payload is Qbot. It contains multiple evasion techniques and at this stage, it enumerates over existing processes and compares them against a hard-coded list (Figure 3). Next, it sets a mutex, drops a copy of itself with a random name together with a configuration file into the %AppData% directory and starts 3 new processes. The first one is using current process’s base image but this time uses the parameter “/C”, the second one has the image located in %AppData% as base and takes no parameters, the third one is executing a command which overwrites the Loterios.exe image with calc.exe (Figure 4).


Function Log

Figure 3: VMRay function log – Enumerate processes and compare against an internal list


VMRay Analyzer Behavior

Figure 4: VMRay Analyzer Behavior – Creation of new processes.


The new process that was started with the “/C” parameter is responsible for the anti-analysis techniques. Just as before it enumerates running processes and compares them to an internal list, it also uses the SetupAPI to enumerate devices and compare them against a hard-coded list. The next check it performs is to verify that none of the currently loaded DLLs is one on his list (Figure 5).


Function Log

Figure 5: VMRay function log – Device enumeration (left) and DLL enumeration (right)


Finally, it verifies that the name of the sample doesn’t contain one of the following strings (Figure 6):

  • sample
  • mlwr_smpl
  • artifact.exe


Function Log

Figure 6: VMRay function log – Verify the sample’s name


After the attempts to identify an artificial environment, the final stage is injected into explorer.exe at address 0x28e0000 (Figure 7).


VMRay Analyzer Behavior

Figure 7: VMray Analyzer Behavior – Injection into process.exe at address 0x028e0000


This payload then decrypts one of its resources with the name “307” and loads it at address 0x02AC0000 (Figure 8). This resource is one of the core modules of Qbot. A more detailed analysis of Qbot can be found in Deep Analysis of Qbot Banking Trojan.


Figure 8: VMRay function log and Behavior – Find resource and allocate memory for it (left) and a dump of that memory region (right).



In this analysis, we can see that the delivery can be split up into multiple stages, whereby each stage has its own purpose.

However, we can easily follow the path of delivery and observe Qbot’s detection mechanism and its further behavior. The memory dumping ability of VMRay’s Analyzer eases the access to Qbots core modules loaded in memory.

One day after we collected the sample, the payload was either deleted or replaced by putty. This means that opening the document now can result in downloading and executing putty instead of Qbot.









IP Addresses