|Image credit Unsplash|
Specialists from PT Expert Security Center found an interesting specimen of malware distributed in the Chinese segment of the Internet. Among other things, this malware is used for MITM attacks. Its main peculiar feature is that it combines various techniques of evading detection. We analyzed those to demonstrate how malware creators hide malware activity.
How it all began
Network traffic analysis system alerted us to the fact that the malicious application regularly requests an image with added content. The image was downloaded from imgsa.baidu.com, a legitimate image storage resource. In addition, we found that the picture itself was super cute. So cute that using it to hide malicious payload was pure evil.
|Figure 1. The image used to hide payload delivery|
To get started, we needed to collect initial data and compare samples. Therefore, we searched for similar samples, and found a few. We could do that by using typical data in the network communication and using our large database of malicious traffic. The network traffic demonstrated an obvious pattern, a trend of the same actions repeated again and again by the malicious application.
|Figure 2. Network traffic with highlighted patterns|
We studied the first request. The server responded by returning encrypted configuration (see Figure 3) with addresses of images containing the payload. That data is stored at http://63634[.]top:8081/koded.
|Figure 3. Encrypted configuration|
The obtained data is decrypted using DES algorithm in electronic code book mode with key 0x6a 0x5f 0x6b 0x2a 0x61 0x2d 0x76 0x62 contained in the body of the malware. After decryption, plaintext is made of strings (see Figure 4). Each string contains a link to the image. Judging by equal MD5 hashes, the image is the same. The attackers probably placed the same data at different addresses to make their delivery process more robust.
|Figure 4. Sample of decrypted loader configuration|
Using the obtained data, the malicious loader then initiates image download. It cuts off the first 5120 bytes (the duckling and the puppy) and uses only the payload starting at 5121 byte.
|Figure 5. Payload sample|
After decryption, we obtained a new configuration in a format similar to that obtained at stage one. That was another set of links to images. This time, however, all the MD5 hashes were different, and each string had a two-symbol suffix at the end.
|Figure 6. Second set of links, and suspicious suffixes|
Malware operation algorithm
Now we see actual payload modules. We found that the two symbols at the end of each string are used to select a specific image and, therefore, a specific payload. The string with AD suffix is used first. That choice is preset during malware development. So the loading sequence is preset in the form of two-symbol suffixes.
|Figure 7. Selecting the link with AD suffix|
The downloaded image contains the malicious module. You can tell just by looking at the file size. The data is still masked as an image and is located at the same 5120-byte offset. The loader puts the extra bytes aside, extracts and checks the hash sum, and then decrypts the module named TkRep.dll into a PE file.
|Figure 8. Sample of encrypted module in the image body, and its hash sum|
This library is loaded into the malicious process, and first of all it checks the environment where the module is running:
|Figure 9. Checking virtualization environment|
It checks all running processes for processes named devenv.exe, OLLYDBG.EXE, Dbgview.exe, windbg.exe, MSDEV.exe, Delphi32.exe, E.exe, PCHunter32.exe, and PCHunter64.exe, and also checks for antivirus tools.
|Figure 10. Checking processes|
Then comes the standard debugging check.
|Figure 11. Checking process launch in debugging mode|
Checks whether open pipes include those listed in the table.
Next, it registers the infected host on the attackers’ server by sending encrypted information about the infected host in a POST request in HTTP protocol.
|Добавьте Figure 12. Request for registration on the attackers server|
An important thing to note is that the server response always contains the same data. Moreover, the client takes into account only the code of server response.
How malware covers its activity
In accordance with the payload sequence, we move on to studying the next one. Its suffix is AR. As per the current process, the client downloads another concatenation of the image with encrypted payload from Baidu Images image storage. Then it decrypts the module and launches it in a new process with a random mane. In our opinion, this functionality makes the malicious application look harmless. Often it is a client for an online game. This was another masking technique.
|Figure 13. Online game interface|
After this false maneuver, the malicious process starts gaining a foothold on the infected host. It uses a functionality similar to that of a rootkit program. For instance, introducing its own protected driver into the system.
This is how it happens. From the decrypted configuration, it selects the payload with AE suffix. That is TaskReportDLL.dll library. It has the same functions as TkRep.dll library from the previous stage: sending information on the system and checking for security tools.
Then it downloads RealWorkDll.dll library. An important function of RealWorkDll.dll is downloading a driver partially protected with VMPROTECT, and a PE file installed in the system by that driver.
|Figure 14. Path to the driver’s database|
Next, the PE files used for driver installation are deleted, and this stage is complete.
A search using a string from the driver database lead us to repository of rootkit[.]com mirror, where we found a sample of rootkit FUTo with respective name in the path — objfre_wxp_x86.
Let us now have a closer look at the work of driver SDriverBlogx86 installed by module RealWorkDll.dll. At the first stage, client’s registration data is sent to the network. POST is used as a request, but this time it is sent to port 8081. It looks like this port is used to receive data if the activity on the infected system reaches the stage of FU rootkit activation.
|Figure 15. Request to C2 from the driver installed in the system|
Communication with the attackers’ server is encrypted. Before encryption, the data contains information on the system. Data field delimiters, representation format, and the number of fields are identical for all modules (see Figure 16).
|Figure 16. Information on the system to identify the infected host|
The mechanism of the driver introduced into the system is identical to the initiating loader. The difference is that this time the links to the images are requested from the port for the rootkit, and the path for storing configuration changed from /koded to /qqwe. Possibly it has something to do with qq.com and wechat.com services.
The list of modules received by the process contains a list of PE files. But in this case, instead of a two-letter suffix for payload selection, there is a key in the form of a file name at the end of the string.
|Figure 17. Configuration received by the driver that got a foothold in the network|
After image download, the payload is also located at 5120 byte offset. The structure of the payload for the installed driver includes the key from the previous list as a filename, and the PE file itself. Unlike the previous stage, this time the payload is not encrypted.
|Figure 18. Payload received by the rootkit installed in the system|
Among all payloads received at this stage, we should point out the PE file for MITM attack. Its hash sum is b9fcf48376083c71db0f13c9e344c0383bafa5b116fbf751672d54940082b99a, and the image is stored here. In the traffic, execution of this PE file can be detected by a GET request:
The received module checks for processes named devenv.exe, OLLYDBG.EXE, Dbgview.exe, windbg.exe, MSDEV.exe, Delphi32.exe, E.exe, PCHunter32.exe, and PCHunter64.exe, and processes ZhuDongFangYu, 360Safe, 360Tray. Presence of this module in the system can be detected by the presence of file C:Windows\Temp5B7C84755D8041139A7AEBA6F4E5912F.dat:
In the course of work, a GET request is used to download certificates server.crt, server.key, server.der, and startcom.crt.
Names of module classes for MITM attack make the attackers’ intent quite clear.
|Figure 18. Names of module classes for MITM attack|
This malware contains of a loader, the decoy file, rootkit driver, and a module for man-in-the-middle attack. The malware covertly delivers its payload using a technique of merging the data with JPEG images. Attackers register names in domain zones top, bid, and on cloud platforms, for their command servers.
The malware developers used the following methods to hide their activities:
- Posing as a legal application
- Posing as an image in the traffic
- Gaining foothold as a rootkit
The discussed threat is identified by PT Network Attack Discovery as Spy.GmFUToMitm.
Authors: Dmitry Makarov, Evgeny Ustinov, Positive Technologies