1. Introduction

With the vast amount of communication traffic in the internet environment, it is inevitable for security researchers to encounter non-clear-text data when conducting traffic analysis. We can easily analyze the communication content based on the traffic characteristics of our own data, but there are so many malicious traffic communications. When you see such traffic, can you analyze what kind of content the traffic data is transmitting?

The overall content of communication traffic has poor readability, and it is completely impossible to see what content the malicious traffic needs to transmit.

And for such content, if the corresponding detection rules are extracted, it is impossible to extract them solely through traffic layer analysis.

Next, let's restore the significance of data transmission from the perspective of reverse engineering.

2. Behavior Analysis

2.1 Overall Flow Chart

The overall execution process of the sample is as follows:

2.2 Release Lure Document

Firstly, run the sample, release and run the lure document to confuse the victim.

Subsequently, through the second file release and dll calls, the final malicious DLL is loaded to achieve service startup and malicious communication purposes.

2.3 Locate the Final Payload

The behavior of the Trojan is as follows, detecting suspicious behavior

And locate the corresponding service in the service list through this file

3. Reverse Engineering

3.1 Key Function Location

Locate the target dll and perform reverse engineering analysis, and the corresponding export function is as follows:

Enter the Servicemain function for analysis and locate the main malicious code function.

3.2 Service Registration and Startup

Firstly, create the service name, which is as follows: Net1Service, which is identical to the service name located by FireEye剑.

3.3 Thread Creation

The main function of malicious code creates a thread, and all operations are performed in the thread callback function.

3.4 Backtracking Function Call

The thread callback function uses memory address addressing to call the target function, which has poor readability and increases the difficulty of reverse analysis.

Cross-reference back to the function assignment position

3.5 Mutex Creation

Before running malicious code, it checks if the target mutex exists. If it exists, it will no longer continue to infect the current host; otherwise, it will create a mutex to execute the subsequent malicious code.

Through dynamic debugging analysis, it is confirmed that the 'v3+16' function is the online package processing function.

3.6 C2 Resolution

Enter the function internally, and the function first performs DNS resolution on the target c2, and after successful resolution, it acquires the target IP.

3.7 Online Package Data Acquisition

The address is then used for acquiring information in the online package data.

Firstly, the MAC address of the victim's host is obtained, and then it is formatted according to 02x%.

The formatted MAC address information is then appended to the specified offset 0x04 of the online package data.

The GetUserInfo function is then responsible for acquiring the remaining data of all online packages.

The data after acquisition is concatenated as shown in the figure below:

It includes the MAC address of the victim's host, CPU frequency, CPU core number, physical memory size, country language region, computer name, system version, and so on. It is noteworthy that this Trojan uses encoding page numbers to indirectly judge the language region when obtaining the country language region of the victim.

3.8 Encryption function analysis

After obtaining the data, use the encryption function to encrypt all plaintext going online packet information. Here, the XOR encryption is used, with the key being 0xf7.

The encrypted data is as follows, which is the same as the communication traffic data in the original pcap capture.

After encryption is completed, the information for going online is sent, with the size of the going online packet being 474 bytes.

This is exactly consistent with the packet size captured in wireshark.

4. Decrypted and restored original data

Through the above detailed reverse operation, all communication traffic data has been restored and decrypted. The following table shows the specific data structure of the communication data and its corresponding explanation.

Overall data structure restoration.

5. Summary

The author of this article restores the real communication data in malicious traffic from a reverse perspective, with the key idea being how to locate the corresponding PID of the target traffic communication data and reverse and debug to locate and restore the data structure.