A Technical Look At Dyreza

Nytro · November 5, 2015

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.

Analyzed samples

ff3d706015b7b142ee0a8f0ad7ea2911 – Dyreza executable- a persistent botnet agent, carring DLLs with the core malicious activities
- 5a0e393031eb2accc914c1c832993d0b – Dyreza DLL (32bit)
- 91b62d1380b73baea53a50d02c88a5c6 – Dyreza DLL (64 bit)

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, loads some DLL via dllhost… All this is done in order to obfuscate the flow of execution, in hopes of confusing analyst.

2 copies of the malicious file are dropped – in C:\Windows and %APPDATA% – under pseudo-random names, matching the regex: [a-zA-Z]{15}.exe , i.e vfHNLkMCYaxBGFy.exe

That persistence is achieved by adding a new task in the task scheduler – it deploys the malicious sample after every minute, to ensure that it keeps running.

Code injected into other processes (svchost, explorer) communicates with the C&C:

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 SQLite files (etilqs_*) created in a TEMP folder that are serving as a small database, where Dyreza stores information.

Collected data are stored in a dedicated folder 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 (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.

T1RY615NR – encrypted 32 bit code, UZGN53WMY – the key, YS45H26GT – encrypted 64bit code

Unpacking:

The unpacking algorithm is pretty simple – key_data contains values and data – list of indexes of the values inkey_data. We process the list of indexes and read the corresponding values:

def decode(data, key_data):

decoded = bytearray()

for i in range(0, len(data)):

val_index = data

decoded.append(key_data[val_index])

return decoded

This script decrypts dumped resources:

https://github.com/hasherezade/malware_analysis/blob/master/dyreza/dyreza_decoder.py

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 sends the information 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”:

Also, network settings are examined (to verify and inform the C&C whether the client can establish back connection – command : AUTOBACKCONN)

It injects its modules in following browsers:

Below – attempt to send stolen account credentials:

In addition to monitoring browsers, it also collects general information about the computer (it’s configuration, existing users) – 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:

(A script for decrypting list of C&Cs from dumped resources is available here:https://github.com/hasherezade/malware_analysis/blob/master/dyreza/dyrezadll_decoder.py)

Also, the certificate served by a particular C&C changes on each connection. The infrastructure is built on the network of compromised WiFi routers (most often: AirOS, MicroTik).

The server receives encrypted connection on port 443 (standard HTTPS) or 4443 (in case if standard HTTPS port of a particular router is occupied by a legitimate service).

Conclusion

Dyreza is an eclectic malware, developed by professionals. It is clear that they are constantly working on a quality – each new version carries some new ideas and improvements, making analysis harder.

Appendix