Core code and technical analysis of Bitcoin thief Dyreza

In this article, we will analyze two payloads that work together, one is called Upatre (which downloads other malware) and the other is called Dyreza (which steals user identity information). In the past period of time, we have analyzed the core code and the techniques used by Dyreza, so let's analyze it step by step.

What is Dyreza?

Dyreza is a malware that aims to steal bank accounts and bitcoins. The entire process begins with downloading Dyreza through Upatre. According to research, the servers that currently provide Dyreza downloads are all routers (mostly AirOS and MicroTik). The attackers use the invaded routers, which have a variety of encrypted resource packages. The infected machines will download the encrypted malicious code program stored in the router through Upatre, and then decrypt it in the user system to obtain the Dyreza Trojan.

The significance of our analysis is that there are many variants of the Dyreza family of malicious programs, but their main behavior trajectories still have commonalities. By analyzing their characteristics and commonalities, we can better defend against them.

0×00 Sample Analysis

－－－－－

Sample: ff3d706015b7b142ee0a8f0ad7ea2911

The executable file of Dyreza, a botnet client, is responsible for performing the main malicious operations.

－－－－－

－－－－－

sample:

5a0e393031eb2accc914c1c832993d0b   – Dyreza DLL (32bit)

91b62d1380b73baea53a50d02c88a5c6   – Dyreza DLL (64bit)

－－－－－

0×01Behavior Analysis

When Dyreza starts to infect computers, it has a fast spreading speed. We can see it in the process management, and the most intuitive point is that many new processes are created and then terminated, such as explorer, svchost, taskeng, etc. This stage is to confuse its execution process and interfere with the research and analysis of security personnel.

Next, it copies two malicious program files named with pseudo-random codes using the regular expression [a-zA-Z]{15}.exe , ie vfHNLkMCYaxBGFy.exe into the C:\Windows and %APPDATA% directories, and then adds a new task to the task scheduler to continuously execute the malicious program samples every minute to ensure the continuous execution of the malicious program.

Then, it injects malicious code into other processes (such as svchost, explorer) and communicates with external C&C servers.

From the above observations, we can find out on VirusTotal that the service addresses that communicate with svchost and explorer processes have already been marked as malicious addresses. The main results are as follows:

• 141.8.226.14 ->   virustotal/141.8.226.14/information

• 83.241.176.230 ->   virustotal/83.241.176.230/information

• 197.231.198.234 ->   virustotal/197.231.198.234/information/

When any web browser is installed, it will also inject malicious code directly into the browser process and then make illegal external connections. This is how the malicious program maintains a connection with the external C&C server, and also performs the function of monitoring user activities and stealing various identity credentials.

Through research, it can also be found that Dyreza will store the acquired information as a small database in a folder called TEMP before sending it to the C&C server.

0×02 Code Analysis

Environmental testing

1. Detection before execution - If Dyreza detects that the number of CPUs on the machine is less than 2, it will not run. This technology is for self-protection to ensure that the program itself is not running in a virtual machine environment. Because from the current market and device configuration, in addition to virtual machines often using single-core CPUs, physical machines generally have more than two cores, and Dyreza also uses this as a basis for judgment. Dyreza makes judgments by detecting the information in the FS:[0x30] area in the thread information block under the process environment block. Only after confirming that the number of CPUs is greater than 2 (including 2), the malicious program will continue to execute.

2. At the beginning of execution, the malware loads additional forms into a newly allocated memory page. During the execution, module names and functions begin to be decrypted.

3. Execution environment detection - Use the SeDebugPrivilege parameter in the LookupPrivilegeValue function to determine whether the installation is under a debugger. If the return value is non-zero, the execution of the malicious program will terminate.

4. Perform effective execution through the following detection methods. At the beginning, according to the initial environment, the path is tracked and detected, such as the executable path and parameters when the program is running. When it is installed for the first time, it will copy itself and put the copied files in the C:\Windows and %APPDATA% directories, and install the copied program as a new process. If it is deployed to a valid path and initial parameters and passes the verification, the next step is to check whether it is the first installation. This step is achieved by creating a specific global mutex (the name is the hash value of the computer name and system version, obtained through the GetComputerName, RtlGetVersion functions).

5. If this condition is met and the mutex already exists, it will then proceed to the most important step, executing the malicious code. At the beginning, the encrypted data and key will be loaded from the executable resource package.

As shown above, T1RY615NR is the encrypted 32-bit code, YS45H26GT is the encrypted 64-bit code, and UZGN53WMY is the key.

The next step is to unpack and take out the code:

The unpacking algorithm is also very simple. key_data contains the value and data - the index list of the value in key_data. We read the corresponding value through the corresponding index list. The corresponding code is as follows,

 def decode(data, key_data):
decoded = bytearray()
for i in range(0, len(data)):
val_index = data[i]
decoded.append(key_data[val_index])
return decoded

The decryption execution code is as follows:

 import argparse
import hashlib
from Crypto.Cipher import AES
BS = 16
pad = lambda s: s + (BS - len(s) % BS) * chr(BS - len(s) % BS)
unpad = lambda s : s[:-ord(s[len(s)-1:])]
def aes_decrypt(enc, iv, key):
cipher = AES.new(key, AES.MODE_CBC, iv)
return unpad(cipher.decrypt(enc))

For detailed execution code, please refer to dyrezadll_decoder.py

The decrypted file includes a shellcode for injection and a DLL (compatible with 32/64 bits) for calling malicious program functions.

0×03 Core Malicious DLL

At this stage, the malware’s functionality becomes very clear. The dll file does not contain much obfuscation – it has obvious strings and a typical import table.

We can see the strings used to communicate with the C&C server.

Both 32-bit and 64-bit DLLs have similar functionality. Only the architecture-related parts and strings are different. The client can identify the system and then send the information to the C&C server.

A similar program in a 64-bit version of the DLL, only with “_64bit” instead of “_32bit” in the hard-coded strings:

At the same time, the network settings are checked (confirming and informing whether a back-end connection with the C&C client can be established – command: autobackconn)

Inject malicious modules into the browser to execute code:

Next, try sending the stolen account information.

In addition to monitoring the browser, it also collects basic information about the computer (such as configuration, existing users, etc.)

The malware not only steals information and sniffs the user's browsing activity, but also attempts to take full control of the system in order to execute various shell commands, such as shutting down the system. Some examples are as follows:

Try creating a new user with administrator privileges:

The shutdown operation can be performed through the command AUTOKILLOS.

0×04 C&Cs

In order to prevent being detected, the communication between the server and the client of this botnet is encrypted and many strategies are adopted.

First, the address of the C&C server is randomly picked from a hardcoded pool. This pool of addresses is stored in the resource pack of the Dyreza DLL (encrypted with the AES encryption algorithm). Next, when executing the payload, we can see how it is decrypted.

The above is the analysis and research of this time. The specific Dyreza code can be obtained in dyreza.