December 4, 2019

Malware creators trying to avoid detection. Spy.GmFUToMitm as an example

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

Data decryption

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\\Temp\5B7C84755D8041139A7AEBA6F4E5912F.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

Conclusion

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.
IOC:

1953db709a96bc70d86f7dfd04527d3d0cb7c94da276ddf8f0ef6c51630a2915
1ab1b2fe3ce0fd37a0bb0814a2cac7e974f20963800f43d2f5478fc88c83a3da
1c8dbaf0a5045e2b4a6787635ded8f51d8e89a18e398c0dd79b1b82a968df1a0
9b7082ac4165b25a3b22f2aafdd41ea5f3512a76693f6a6b3101873a9cded961
9cee3f6d6e39adfa0d4712541c070b9c2423275698be0c6cd6cd8239d8793250
b9fcf48376083c71db0f13c9e344c0383bafa5b116fbf751672d54940082b99a
df3e7b04d988cf5634ec886321cb1ac364a46181e7a63f41f0788753e52dcf34
eb67c1d69eb09e195b8333e12c41a0749e7e186c9439f1e2c30f369712ce2c12
http://63634.top/ 
http://anli.bid/
http://shangdai.bid/
http://b-blog.oss-cn-beijing.aliyuncs.com

Authors: Dmitry Makarov, Evgeny Ustinov, Positive Technologies

No comments:

Post a Comment