|Image credit Unsplash|
How it all beganNetwork 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|
|Figure 2. Network traffic with highlighted patterns|
|Figure 3. Encrypted configuration|
Data decryptionThe 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|
|Figure 5. Payload sample|
|Figure 6. Second set of links, and suspicious suffixes|
Malware operation algorithmNow 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|
|Figure 8. Sample of encrypted module in the image body, and its hash sum|
|Figure 9. Checking virtualization environment|
|Figure 10. Checking processes|
|Figure 11. Checking process launch in debugging mode|
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|
How malware covers its activityIn 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|
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|
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|
|Figure 16. Information on the system to identify the infected host|
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|
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|
ConclusionThis 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