Chafer backdoor analysis

Introduction

A few weeks ago we published a config decrypter[1] for a sample that we believe is related with the Chafer group. Chafer is a well-known group which has primarily been operating in the Middle East. Their arsenal includes several custom-made tools, variants of the Remexi malware and open-source/publically available tools such as ‘Mimikatz’ or ‘PsExec’ [2] [3]. In this blog post, we describe the functionality of the discovered sample.

Attributing the Chafer group to any nation state is out of the scope.

Technical analysis

The component is a 64-bit executable file which requires administrator privileges in order to properly execute. The table below provides an overview of the structure and functionality of the malware (Table 1).

Upon execution, the binary file will read and decrypt the encrypted config file (srv.dat) and then check if any of following parameters have been passed (Table 2).

If none of the parameters have been passed, it assumes that the service has executed the binary file and it proceeds with executing the ‘ServiceMain’ function.

Two folders with randomly generated names are created in the same directory that the binary runs from. One folder is being created to store the received data and the other folder to store the output data from the malware (Figure 1).

The following python script replicates the folders’ name generation functionality:

In both cases, the data is stored in .tmp files. These filenames are generated based on the system’s time. We can replicate the same functionality with the python script below:

Afterwards, two threads are created. The first thread will initially contact the C2 by sending 38 bytes. The first 4 bytes include the rand result value from the random byte generator function and the length of the dt3 and dt4 config string values. The last 34 bytes are randomly generated from the random byte generator function. The malware will check if the length of the response from the C2 server is equal to 28 bytes and if the config’s first DWORD value is not equal to 0x31B9D63 (Figure 2). If both of these conditions are met then the config file will be updated with a new key. The key can be updated only once. We can replicate the key update mechanism using the following python script:

Afterwards, the files that reside in the two folders, which were created by the malware, will be sent to the C2 along with 38 bytes (4 bytes for the rand result value and the length of dt3 and dt4 config values and 34 random generated bytes) to the beginning of each file. Each time the random byte generator function is called, a different string parameter is passed as a second parameter to the function. Table 3 lists all possible parameters. It is also worth noting that the ‘boundary’ parameter in the POST headers is generated based on the infected system’s time (Figure 3).

A python script, which generates random bytes using the same functionality of the aforementioned function, is available in our github repository [4].

The second thread will perform two tasks. Firstly, it will delete any files which are smaller than two bytes or their creation timestamp is equal to:

i) LowDateTime = 0xFEB0C000
ii) HighDateTime = 0x1D263C1

Then it will create a new thread with the path of the tmp file passed as a thread parameter. This thread is where most of the core functionality of the malware resides. When this thread is executed, it will check if the tmp file’s size is smaller than or equal to two bytes. If it does then it will delete it. Next, it will read the tmp file that contains the received data from the C2 in an encrypted format. As mentioned already, the malware stores the received data from the C2 in one of the created folders in a tmp file, the data is encrypted using the RC4 algorithm. An RC4 key is stored unencrypted in the config file but not all of its bytes are always used in the algorithm. Specifically, the RC4 key for each RC4 decryption/encryption operation is dependent on the size of the data that will be passed to the algorithm. We can replicate this with the following script:

Once the data has been decrypted, the malware will attempt to identify if any of the following two parameters appear in the decrypted data (Table 4). 

As seen in the ‘Command example’ column, the ‘cwt/’ parameter can also have an integer before the system command that will be executed. This integer indicates the delay that will take place before executing the system command. The delay is calculated by multiplying the integer with 5000 (milliseconds). If only the command is passed, without a specified timer or without the ‘/cwt’ parameter, then the timer is specified by the config value dt5. The received system commands are executed on the infected machine using the ‘CreateProcess’ API, and the results are stored in an anonymous pipe.

The ‘sii’ command accepts up to two parameters. As mentioned in the config structure section, the dt6 value is used for delaying the execution, this is achieved by passing it as a parameter in the Sleep() function. A second integer (renamed to dt6_watcher in the screenshot below) is being constantly checked if it is greater than zero, and if its value is smaller or equal after subtracting it with 5 (Figure 4). If these conditions are met then the dt6 is reset back to its original config value. The first parameter in the ‘sii’ command updates the dt6 value in memory and the second parameter sets a new value to the dt6_watcher.

Depending on the length of the executed system command’s result, bigger than or equal to 0x100 bytes, the result will be either stored in an encrypted CAB file or in an RC4 encrypted tmp file in the second created folder. It is important to note that the CAB files have the string ‘TREX’ in the first DWORD and not the typical ‘MSCF’. In addition, the encrypted tmp files have the prefix ‘TREK’ in the first DWORD (Figure 5).

The authors of the malware decided to use an open-source library [5] to create and encrypt the CAB files. Each CAB file is encrypted using the blowfish algorithm with the same key used in RC4.

Log functionality

Almost every operation and task that is conducted from the binary is logged. The log files are stored locally if the ‘Log’ value exists in the registry key ‘SOFTWARE\Microsoft\DRM’. Table 5 summarises the different log formats that each thread and function uses. The integer might represent either the current function being executed or the if statement condition that was executed. Error codes and the thread ID are also recorded and stored locally in the log files. Three log files are created in the same directory that the malware is running from:

I) file-2.log
II) file-3.log
III) file-4.log

Conclusion

In summary, the Chafer group remains active and keeps developing custom tools to use in its operations. In this blog post, we briefly described the internals of one of the binaries that belong to this group.

IoCs

Domains

C2 Domain	Path
sabre-css[.]com	/comm.aspx
nvidia-services[.]com	/comm.aspx

Suspicious files

Files with the prefix ‘TREK’ or ‘TREX’ as the first DWORD value.

Services

Service Name	Service Description
Network Connections Manager	Allows the system to be configured to manage automatically the connections activities
nvdsvc	NVIDIA Graphical Display Driver Service

Hashes

Hash (SHA-256)	Description
bc32bf55e841052a095c27cea558577fa947fdf8b7d95beca0c5725dbd00324d	Analysed sample
b30eb3173b7241e851bad230a472f05cb2313c24b89eade88a8cb19793d89f66	Similar sample
12f79030e73030e127ae3ec5ab16b51cd5f7812e786e6d23fc54b5820f5f3064	Config file
d3ecd0e5f6dd6b6fa1e8fdad7e0ec9b1020e5bb0b9e64f76d2148f1b24ca7779	Config file

References

1. https://github.com/nccgroup/Cyber-Defence/blob/master/Tools/chafer_config_decrypter/chafer_decrypter.cpp
2. https://securelist.com/chafer-used-remexi-malware/89538/
3. https://www.symantec.com/blogs/threat-intelligence/chafer-latest-attacks-reveal-heightened-ambitions
4. https://github.com/nccgroup/Cyber-Defence/blob/master/Scripts/chafer/chafer_generate_bytes.py
5. https://www.codeproject.com/Articles/15397/Cabinet-File-CAB-Compression-and-Extraction
6. https://github.com/nccgroup/Cyber-Defence/tree/master/Scripts/chafer

Published date:  21 March 2019

Written by:  Nikolaos Pantazopoulos