And again, Qbot – a new strain of banking Trojan

We discovered and reverse engineered another new strain of Qbot – complex, widely known malware that collects data that allows you to commit financial fraud. Here are examples of data that Qbot collects: browser cookies, certificate information, keystrokes, login-password pairs and other credentials, as well as data from open sessions in web applications.
The Varonis security research team responded to several cases of Qbot infections in 2019, mainly in the United States. It seems that the Qbot developers were not idle: they created new strains with new functionality, simultaneously improving the ability to prevent detection by teams responsible for information security.

We described an earlier strain of Qbot and discussed its TTP (tactics, techniques, and procedures). The new strain differs from the previous one in two main details:

  • instead of trying to guess the domain user’s passwords, this strain uses an already compromised user to build a map of available network folders;
  • it sends the victim data to the FTP server, instead of using HTTP POST requests.


One of our customers asked for help after being notified by cyber security platforms Varonis that the user account behaves atypically and accesses an unusual number of network nodes. Then the customer drew attention to the logs of the anti-virus solution on the device from which this access was made, and noticed unprocessed notifications about the infected file that appeared at about the same time.
The raw files were in the temp folder of the user profile and had extensions .vbs and .zip.
The Varonis forensics team helped the user retrieve samples of infected files, and the security research team analyzed and found that it new variation of Qbot .

How does he work

We launched the infected file in our laboratory and found similar indicators that it was malicious with those that were in our previous study — the introduction of the “explorer.exe” process, connection to the same URL, the same mechanisms to ensure constant presence in the registry and on disk, and the same replacement copy of the file with “calc.exe”.
This strain contained an encrypted configuration file, with the incorrect extension “.dll”. Using a dynamic analysis of the explorer.exe process, we found that the key to decrypt the encrypted RC4 configuration file is the SHA1 hash of the unique string that the malware creates for each device (we know that this is not a random character set, as the previous Qbot variation created same line for the same device).
Here are the configuration data decrypted by us for our device:

This configuration contains the following data:

  • installation time;
  • time of the last call from C2;
  • external IP of the victim;
  • list of network folders surrounded by the victim.

Phase I: Bootloader

File Names: JVC_82633.vbs

SHA1: f38ed9fec9fe4e6451645724852aa2da9fce1be9

Like the previous version, this variation of Qbot used the VBS file to load the main malicious modules.

Phase II: ensuring a consistent presence in the system and implementation in processes

Just like the previous sample, the bootloader launches the kernel modules of the malware and ensures the constancy of their presence in the OS. This version copies itself to
% Appdata% Roaming Microsoft {Arbitrary line} instead of% Appdata% Roaming {Arbitrary line}, but the values ​​of the registry keys and scheduled tasks remained identical.
The main payload is embedded in all active processes running on behalf of the user.

Phase III: Data Theft – Path to Hacker Server

After ensuring the presence in the system, the malware tries to connect to its C2 server using the URI This version collects data that is important for its purposes from the victim’s computer and sends it via FTP using hard-coded login and password.
This server contained encrypted data collected from victims, with the following naming principle: “artic1e- * 6 characters and after them 6 more digits * – * POSIX-time * .zip”.
We opened the specified FTP server and found this folder with the following contents:

We have not yet been able to decrypt the zip files to determine what data has been stolen.

Remediation and recovery

Since we found only one infected device, our recommendations were:

  1. Disconnect the infected device from the network and erase the data on the disk, and then configure the environment in accordance with what it was before the infection;
  2. Add the monitoring of network connections to the functionality of the used IB tools to ensure that other devices will not connect to IP addresses detected in malicious activity;
  3. Pay close attention to alerts from Varonis, especially those related to behavioral abnormalities.

Similar Posts

Leave a Reply