A Technical Look At Dyreza

In a previous post we presented unpacking 2 payloads delivered in a spam campaign. A malicious duet – Upatre (malware downloader) and Dyreza (credential stealer). In this post we will take a look at the core of Dyreza – and techniques that it uses.

Note, that Dyreza is a complex piece of malware and various samples come with various techniques – however, the main features remain common.

Behavioral analysis

When Dyreza starts to infect the computer – it spreads like fire. Observing it in Process Explorer, we can see many new processes appearing and disappearing. As we can notice, it deploys explorer, svchost, taskeng… All this is done in order to obfuscate the flow of execution, in hopes of confusing analyst.

When we deploy any web browser, it directly injects the code into its process and deploys illegitimate connections.It is the way to keep in touch with the C&C, monitor user’s activity and steal credentials.

We can also see files created in a TEMP folder that are serving as a small database, where Dyreza stores information, before they are sent to the C&C.

Inside the code

Main executable

Dyreza doesn’t start on a machine that has less than 2 processors. This technique is used as a defense, preventing file from running on VM. It is based on the observation that VM usually have only one processor – in contrast to most physical machines used nowadays. It is implemented by checking appropriate field in PEB (Process Environment Block), that is pointed by FS:[30]. Infection continues only if the condition is satisfied.

At the beginning of execution, malware loads additional import table into a newly allocated memory page. Names of modules and functions are decrypted at runtime.

It checks, if it is deployed under debugger – using function LookupPrivilegeValue with argument SeDebugPrivilege – if it returns non-zero value, execution is terminated.

Valid execution follows few alternative paths. Decision, by which path of to follow is made based on the initial conditions – like, executable path and arguments with which the program was run. When it is deployed for the first time (from a random location), it make its own copy into C:\Windows and %APPDATA% and deploy the copy as a new process. As an argument to a deployed copy (from C:\Windows) it passes a path to the other copy.

If it is deployed from the valid path and the initial argument passed validation, it performs another check – verifying if it is deployed for the first time. It is achieved by creating a specific Global mutex (it’s name is a hash of Computer name and OS Version – fetched by functions: GetComputerName, RtlGetVersion).

If this condition is also satisfied and mutex already exist, then it follows the main path, deploying the malicious code. First, the encrypted data and the key are loaded from the executable’s resources.

The revealed content contains a shellcode to be injected and a a DLL with malicious functions (32 or 64 bit appropriately). The main sample chooses which one to unpack and deploy, by checking if it is running via WOW64 (emulation for 32 bit on 64 bit machine) – calling function IsWow64Process.

Malicious DLL (core)

At this stage, functionality of the malware becomes pretty clear. The DLL does not contain much obfuscation – it has clear strings and a typical import table.

We can see the strings that are used for communication with the C&C:

Both – 32 and 64 bit DLLs have analogical functionality. Only architecture-related elements and strings are different.

The agent identifies the system:

and then – include this data in information sent to the C&C:

Similar procedure is present in the 64 bit version of the DLL, only the hardcoded string “_32bit” is substituted by “_64bit”:

In addition to monitoring browsers, it also collects general information about the computer (it’s hardware, users, programs and services) – in form of a report:

The malware not only steal information and sniff user’s browsing, but also tries to take a full control over the system – executes various shell commands – system shutdown,etc. Some examples below:

Trying to add a user with administrative privileges

Shutdown system on command (AUTOKILLOS)

C&Cs

This botnet is prepared with great care. Not only communication is encrypted, but also many countermeasures have been taken in order to prevent detection.

First of all, the address of the C&C is randomly picked from a hard-coded pool.This pool is stored in one of the resources of Dyreza DLL (AES encrypted). Below, we can see how it gets decrypted, during execution of the payload:

January 31, 2017 - The developers of Locky Bart already had very successful ransomware campaigns running called “Locky” and “Locky v2”. After some users reported being infected with Locky Bart, we investigated it to find the differences as to gain greater knowledge and understanding of this new version.