Introduction

One of the most active botnets of 2015, Dridex steals bank account information and is believed responsible for over $35 millions in losses worldwide. Dridex is a descendant of Bugat/Feodo/Cridex and is part of the infamous Zeus family.

In a concerted effort of the FBI and security vendors, the botnet was partly shut down at the end of 2015. Multiple command-and-control nodes were taken down and the botnet kingpin was arrested, thus considerably crippling his capabilities. When the botnet started in July 2015, it was not significant as when a new phishing campaign was launched this fall. The actors behind Dridex are still active. The present article takes a closer look into Dridex attack vector, the packer used to protect against AV solutions and the recon stage.

Dridex is using Microsoft Office documents with macros as attack vector to infect the victims. In an effort to hide the malicious macros from security scanners, the file attached to the emails sent by the botnet are MIME HTML(.MHTML), which is a web page archive format used to incorporate HTML code with all the external dependencies like images, Flash animations and/or audio files. The OLE document(.doc/.docx) with the actual macros is embedded inside the .MHTML file as an ActiveMIME objects.

Below is the base64 encoded object embedded inside the MHTML file. Being compressed as an ActiveMIME object allows the payload to escape network scanners that are not opening those objects to scan them.

Stripping the base64 reveals the actual ActiveMime object.

Finally, inside the ActiveMime container is the OLE document (.doc, .docx).

The document doesn’t make use of vulnerabilities, only macros are present. Taking a look at them is easy enough with the help of a dumping tool like OLEDump.

The first observation is that they are heavily obfuscated, but also that they are set to execute when the document is open.

To make sense of those macros, simply replace the random variable names with meaningful names and decode the strings which are split into multiple parts and encoded by a Caesar cipher of +1. The string decoding function is inside module 5.

Two actions are performed by the macros, download an executable from the C2 and then executes it on the spot with the VBA shell() function. The downloaded file is the actual Dridex Trojan.

See below the HTTP GET query and the command line used in this sample.

The packer used to protect Dridex is in pair with what we would expect from a last generation banker. It contains various AV evasion techniques like exception handling, code rewriting and an original polymorphic engine. The later is taking advantage of something well known in the exploitation world, return oriented programming (ROP). The following is an overview of this AV defence.

Exception Handling

Loaded inside IDA, Dridex doesn’t reveal much other than endless operations with no clear goals. This code is randomized for each
compilation, thus making a unique signature each time. Static reversing being of no help in this type of situation, executing the Trojan inside a debugger is the way to go. Running first without breakpoints leads to an exception inside the rpcrt4.dll module.

The exception is provoked deliberately for anti-reversing in an attempt to hide the code logic. Somewhere before the exception is provoked, the malware registers his own handler. When the exception is thrown, the execution is passed to the malware exception handler, thus the malware is back in control.

In order to resume debugging, the malware exception handler must be located. There are various ways to achieve this, but walking the
exception handlers chain like the OS does when an exception is thrown is a quick and easy way.

The chain starts inside the Task Information Block(TIB) segment.

The first DWORD inside the TIB points to the start of the exception handler chain.

The handlers chain is constituted of EXCEPTION_REGISTRATION structures where the first member is a pointer referring to the previous  registered handler and the second member is a DWORD containing the address to the handling procedure.

If the malware has registered an error handler, walking each registered handler inside the chain eventually leads to an handler that is coming from the application .text section. The following is the exception handler to whom the execution is passed when the exception is provoked.

Return Oriented Reversing

Inside the handler, the code is still very messy with enough useless and random instructions to make your eyes bleed. On top of that, Dridex is making good usage of return oriented programming(ROP). Well known in vulnerability exploitation for DEP evasion, ROP usage is not common in Trojans. Though, the situation is likely going to change in the near future, because ROP for polymorphic engine is actual a very good idea and it’s already public.

The technique is also easy to implement and hard to detect for AV solutions. A simple push instruction is needed to choose wherever the execution returns.

When the function returns, it doesn’t return where it was called like it should, but inside the chosen widget.

Self Rewriting

Rewriting the code section is a well known trick for Trojans. It avoids being caught executing outside the .text section and also hides the code logic. Dridex follows the same known pattern for self rewriting, but with the help of ROP.

First, a space is allocated with Kernel32!VirtualAlloc, but the function is never “called” like the usual way. Instead, a pointer to
Kernel32!VirtualAlloc is pushed onto the stack before a return instruction, thus executing inside the function after the return.

A shellcode is then decrypted and copied inside the new allocated space. ROP is yet again used to execute the shellcode.

Inside the shellcode, the library pointers are found using the list of already loaded modules inside the process, InLoadOrderModuleList, which is inside the PEB (Process Environment Block) structure. From each of these libraries, the function pointers are retrieved from the PE exports list.

The shellcode starts by detaching the console window using kernel32!FreeConsole, that way the trojan runs in the background without any GUI.

The next action is to rewrite the code section (.text) by first calling kernel32!VirtualProtect to allows himself write access, then copying the actual Trojan code to the new section. A last ROP sequence starts a new thread with a start address within the new code. The later is not obfuscated and written in C++.

Recon Stage

From this point, the Trojan is unpacked and wants to communicate with his C2 with even installing himself. It starts by building a footprint of the box. It do so by querying various registry keys unique to specific Windows versions, thus allowing to correctly guess the version without raising suspicion by calling the usual kernel32!GetVersionEx. Below is the XML footprint that is collected. It contains the hostname with an unique ID, the botnet ID to whom the Trojan is related, a system ID and the architecture. The list of installed packets is also included into the exfiltrated footprint.

The footprint is then encrypted using RC4, a table of 0x100 bytes and the following key.

The encrypted data is sent to one of the C2 found in the following hard coded IP list.

If the Trojan successfully communicates with a C2, it proceeds with infecting the box, if not, it keeps retrying with a longer timeout between each retry.

Introduction

We report here on a reverse engineering effort to better understand how z13.exe infests a system. From our analysis, this malware bears the signature of a banker trojan. Although we have not yet confirmed its insertion in a web browser to steal banking credentials, we can see that it leverages methods and algorithms seen in Zeus and the most recent version of Tinba (Tiny Banker). In addition, it it is reported by most antivirus software as miscellaneous banker variations. Since the leak of the Zeus source code in 2011, forks of well-known versions of banker trojans have become commonplace.

We first look at the dropper program, which unwraps the malware behaviour from encrypted modules. Second, we show how it transfers its attack code to a hollowed-out child process. Third, we follow its injection into Windows Explorer, using the so-called Heaven’s Gate technique.

Fourth, we examine the various tricks the malware does to cloak itself, as well as to persist on the infected system.

Entry Point

At first glance, the malware doesn’t reveal much with static and dynamic analysis. Only with careful tracing does it reveal all its tricks. It starts as a common MFC program. It sets up a dialog named chat tool from a loaded resource segment. It’s from the initialization of this dialog that the code Link starts to act like a malware.

It loads in memory a copy of the file on disk and then seeks a value into this memory that indicates the start of an encrypted block. The block is decrypted on the heap as follows:

Once decrypted, the execution jumps into this new code segment, which executes various recon tasks to determine whether the host is already infected. At the end of this code segment, another memory block is decrypted using the same procedure. This second blockcontains antiVM behaviour and an interesting forking process detailed in the next section. This type of architecture shows modularity in the conception of the malware. The developers make independent block with different features and those blocks, revealed for execution one at a time, determine the malware behaviour.

The imports for each code segment are found by first pushing the names of all routines it needs on the stack. Then, the string kernel32.dll is retrieved from the process environment block (PEB). The module is found among those loaded, so the code fetches LoadLibrary and GetProcAddress from its the export table. Those two functions are then used to resolve all other function names that were previously pushed on the stack.

Malicious behaviour transfer

The malware is using a wellknown but interesting technique called process hollowing, which consists in rewriting the memory of another process without touching the PEB. This technique is usually used to cloak a malicious process into a legitimate process. For example, “C:\malware.exe” could hide into “C:\windows\notepad.exe”, but in this case, the hollowed process is the same as the original one. It is therefore not used for cloaking but as a way to slow down the reversing.

The implementation of process hollowing starts by creating a suspended target process. The original memory sections of the target process are first unmapped with NtUnmapViewOfSection . The new sections are then written into the hollowedout process. The suspended process is now ready to resume except for one detail: the thread EP (entry point) is not valid anymore. Hence the parent process gets the main thread context with GetThreadContext , corrects the EP at offset 0xB0 and sets back the thread context with SetThreadContext . The hollowedout
process is then resumed with new program code.

At this point, the malicious computation has transferred into the child process. In order to continue our trace study, we must attach to the child process. This can be done by manually placing a breakpoint on the new EP with a memory patching tool like ProcessHacker. The EP address is found at offset 0xB0 in the thread context structure just before the SetThreadContext function.

With the breakpoint set in the child process, we set our debugger up as JIT and resume execution of the parent process. The latter will resume the hollowed out process, so the JIT debugger will break on the EP. The main task of the child process is to inject a remote thread into the Windows Explorer. To prepare for this, it simply asserts debugging privileges, so it may attach as a debugger to all application running as the same user.

Injection in Windows Explorer

The malware finds its injection target by listing the system processes with the function NtQuerySystemInformation, called with the enum SYSTEM_INFORMATION_CLASS set to 0x5 (SystemProcessInformation) . It then performs the same hash comparison procedure used to resolve the imports in order to find the SYSTEM_PROCESS_INFORMATION structure related to explorer.exe. It gets from that structure the PID of explorer.exe, of which it retrieves the handle using OpenProcess.

When ready to inject, the malware tests the remote process architecture with isWow64Process. The injection occurs either ways, but with the difference that it passes through the Heaven’s gate for a 64bits process.

The Heaven’s gate is a simple far jump with the code selector register (CS) set to 0x33, indicating x64 instructions. Its a simple CPU switch between 32bit and 64bit mode. In sysWoW64, this switch is implemented in the function wow64cpu!X86SwitchTo64BitMode FS:[0xC0]. In order
to keep control over the return address, the injector implemented a widget with a call to offset 0x0 and setting up the return address 0x5 higher on the stack, yielding a return following immediately this fake procedure, into the rest of the injected code.

Once in 64bits mode, the injection is completed with CreateRemoteThread. The inverse mechanism is used to return to x86 mode, setting the CS to 0x23.

The use of this hybrid type of malware is increasingly used by malware authors to adapt to the dual architecture Windows ecosystem. The main thread injected into explorer.exe is behaving as we would expect from any banker trojan. It starts by hooking ZwResumeThread, which is called each time a new process is created by explorer.exe.

The added hook is straightforward. It injects code into each new process if the access rights allow it. Note that the injection still supports both 32bits and 64bits architectures. The main thread injects also into every currently running process. The injected thread in explorer.exe also tries to beacon its C&C using the new popular thing in the banker world, DGA (domain generator algorithm), with the difference that it generates IP addresses instead of domain names. The malware owners set up a large range of possible IP addresses for their C&C. The DGA queries thousands of IPs until it receives a valid answer from an active C&C. This method of communication is now very popular, as it is very effective against C&C takedowns.

Persistence and cloaking

The malware is using common sandbox evasion behaviours. It searches indicators specific to virtual environments like vmtoolsd.exe (VMWare), VBoxService.exe (VirtualBox) or SbieDll.dll (Sandboxie). It does so by iterating over the module and process list using CreateToolhelp32Snapshot . This is easily worked around with memory patching or a VM setup without virtualisation tools.
Before infecting the host, the mutex “qazwsx” is tested to avoid reinfection. It also attempts to open the file “C:\myapp.exe” with C reateFile. If the returned handle is valid, the process is terminated without infecting the host. This could be a way for the authors to easily avoid infecting the host in the development process. It tests the string “C:\windows\explorer.exe.\” similarly. Persistence is achieved by dropping a copy of the malware in the AppData folder. The name of this new file is an obfuscated value that terminates in wnisxpeo.exe . Here is the deobfuscation algorithm:

The file time of the dropped file wnisxpeo.exe is copied from svchost.exe. This is a common approach to lower the file suspicion.

An autorun registry key is created by the injected explorer.exe process to secure persistence after reboot.

Finally, the dropper is deleted from disk once its task is done. It does so by creating a simple batch file starting by “ms” and followed by a random numerical value. The script is placed in the path “C:\%UserDir%\AppData\Roaming” and executed.