Bad news from malware-land after security researchers from IBM reported today they'd discovered the first samples of version 4.0 of the infamous and highly-active Dridex banking trojan.
One of the lesser known things about computer viruses is the fact that malware is very similar to normal software, often going through the same development cycles and receiving constant updates.
While most malware operators strive to keep as much of their source code and operational details hidden, the Dridex crew has always embedded the malware’s version number in its source, which, in turn, has permitted researchers to easily track its evolution.
This version number included in Dridex binaries and configuration files has allowed researchers to create a timeline of major Dridex versions. For example, based on the version numbers, Dridex v1 launched in late 2014 and only lasted up until the first days of 2015.
Dridex v2 was as short-lived as v1, and only survived until April 2015, when it was replaced by Dridex v3.
The v3 version was a far more stable version, which the Dridex crew updated incrementally in small chunks during the past two years.
According to experts, the trojan’s source code received so many updates that it went from a banking trojan that relied on webinjects to using redirection attacks, two very different techniques.
Nonetheless, despite this major updates, the rest of Dridex’s operations remained the same, often relying on hVNC (Hidden VNC – Virtual Network Computing) to establish hidden connections to hosts, which they used to control infected computers via unseen virtual desktops.
According to IBM experts, for Dridex v4, the malware's creators kept most of the same technologies from recent v3 versions, relying on redirection attacks to intercept user traffic, and redirect users to a clone of the real banking portal using a locally installed proxy server. hVNC came into play later on, but only if the attackers stumbled upon victims with precious data and needed RAT-like access to infected hosts.
Experts say that what changed in Dridex v4 is how the banking trojan loads its malicious code into the host's memory.
This might seem something trivial to casual observers, but this is a big deal for security researchers since this is one of the ways vendors detect the trojan's activity.
In older Dridex versions, attackers relied on various Windows API calls to load snippets of their malicious code into the user's memory and then into the user's browser processes.
Security products knew that by watching a few Windows API calls, often used by a multitude of malware families, they could detect a wide range of malicious behavior and stop it or contain it.
Dridex v4 has dropped this process injection mechanism that relied on a few intensily-watched Windows API calls. According to IBM, Dridex v4 now uses a technique discovered by enSilo researchers in late October 2016.
This new and somewhat ground-breaking code injection technique is called AtomBombing. In a very simple explanation, the technique relies on storing malicious snippets of code inside atom tables.
Atom tables are specific to the Windows OS and allow applications to store the name of a string and an associated value. Atom tables work as caches for commonly used strings and entries can be accessed by all applications, not just the ones that created the data.
enSilo researchers discovered that attackers could store malicious code in these atom tables and then invoke them without using the same ol' Windows API calls.
When enSilo published its research on AtomBombing last year, they said they were revealing this attack vector because Microsoft couldn't patch the issue as it would have implied rewriting large chunks of the entire Windows operating system, something that was impractical.
enSilo researchers wanted antivirus vendors to take note of how the attack worked and deploy detection and mitigation solutions.
According to IBM, the Dridex crew seemed to be aware of enSilo's reasons, as they only used the first half of the enSilo proof-of-concept exploit, while for the second half they wrote their own code.
The resulted technique still uses atom tables to load malicious code into an RWX (read-write-execute) portion of the victim's computer memory, but because it doesn't use the same API and function calls, it bypasses AtomBombing detection mechanisms built around enSilo's findings.
Besides AtomBombing, security researchers also noted other updates. Probably the second most important is an update to the configuration file's encryption.
On all infected hosts, the Dridex trojan creates a configuration file that it fills with data from its command and control server.
This file is very important to researchers because it holds both the malware version number, but also the banking portals and online websites for which Dridex will attempt to collect user credentials via phishing pages.
This file's importance is also why the Dridex gang encrypts it. According to IBM, Dridex v4 uses a new encryption scheme, still relying on RC4 ciphers as used in previous versions, but using different encryption routines.
This change in the encryption routine is not specific to major Dridex versions, as the encryption changes regularly even in minor versions to keep researchers and targeted financial institutions in the dark as much as possible.
The good news is that this encryption didn't keep researchers in the dark for too long. According to IBM, recent Dridex v4 samples targeted only customers of UK banks, but v4 is expected to spread to other countries.
With IBM's findings available for all, security products can now implement systems to track and prevent Dridex v4 attacks.