Live Cyber Attack Lab 🎯 Watch our IR team detect & respond to a rogue insider trying to steal data! Choose a Session

X

Varonis Uncovers Another New Strain of the Qbot Banking Malware

Cybersecurity News, Threat Research

We have discovered and reverse engineered another new strain of Qbot, a sophisticated, well-known type of malware that collects sensitive data, such as browser cookies, digital certificate information, keystrokes, credentials, and session data from its victims to commit financial fraud.

Varonis Security Research and Forensics teams responded to several Qbot infections in 2019, mostly in the US. The threat actors appear to have been busy: they’ve been creating new strains with new functionality as well as improving their SecOps capabilities.

We detailed an earlier strain of Qbot and discussed its TTP (tactics, techniques & procedures); this strain differs in two main aspects:

  • Instead of brute-forcing domain user passwords, the strain uses the compromised user to map available network shares.
  • This strain sends victim data to an FTP server instead of using HTTP POST requests.

Discovery

One of our customers reached out after receiving an alert from the Varonis Data Security Platform that a user’s account had deviated from its behavioral baseline and accessed an atypical number of network devices. The customer then looked at AV logs from the suspected device and noticed unhandled infected file alerts from around the same time.

The unhandled files were in the user’s temp folder and had .vbs and .zip extensions. Varonis Forensics team helped the customer extract the malicious file samples; our research team analyzed them and discovered the new Qbot variant.

How It Works

We ran the infected file in our lab environment and found similar indicators to those in our prior Qbot investigation – injection to the “explorer.exe” process, connection to the same remote URLs, same registry and disk persistence methods and same replacement of disk evidence with “calc.exe” file.

This strain contained an encrypted configuration file, misleadingly labeled with a “.dll” file extension. Using dynamic analysis of the explorer.exe process, we determined that the key for the RC4-encrypted configuration file is the SHA1 hash of a unique string the malware creates for each device (we know it is not random because the previous Qbot variant chose the same string for the same device).

This is the configuration data we decrypted for our device:

Qbot II Configuration Data

The configuration data contains:

  • Time of installation
  • Last call time from C2
  • The external victim IP address
  • List of network shares on the victim environment

Phase I – Dropper

File names:  JVC_82633.vbs

SHA1: f38ed9fec9fe4e6451645724852aa2da9fce1be9

Much like the previous version, this version of Qbot also used a VBS file to download the main modules of the malware.

Phase II – Persistency and process injection

Like our previous sample, the loader executes the core malware modules and gains persistence. This version copies itself to %Appdata%\Roaming\Microsoft\{Randomized String} instead of %Appdata%\Roaming\{Randomized String}, but the registry values and task scheduler routines were the same.

The main payload is injected into all the active processes under the user.

Phase III – Data exfiltration: into the attacker’s server

After establishing persistence, the malware tries to connect to its C2 server in the URI content.bigflimz.com. This version collects sensitive data from the victim’s machine, encrypts it and sends it over FTP to a server using hard-coded credentials.

This server contains encrypted files collected from victims, with a naming convention that follows “artic1e-*6 characters followed by 6 numbers*-*time in epoch standard*.zip”.

We logged into the FTP server, revealing this directory:

Qbot II FTP Server

Qbot II FTP Server

We have not yet managed to decrypt the zip files to determine what information the attacker exfiltrated.

Remediation & Recovery

As we found that only one device was infected, our remediation recommendations were:

  • Disconnect the infected device from the network and wipe the drive.
  • Add the IOCs to other security solutions to make sure no other device has any infected files or creates connections with the malicious IP addresses etc.
  • Pay close attention to future Varonis alerts, especially those related to abnormal amounts of device access.
 

Does your cybersecurity start at the heart?

Get a highly customized data risk assessment run by engineers who are obsessed with data security.