How the creators of malicious software try to avoid its detection: we analyze Spy.GmFUToMitm as an example

Image: Unsplash



Experts at the Positive Technologies Security Center (PT Expert Security Center) discovered an interesting sample of malware spreading in the Chinese Internet segment. This software is used, among other things, to carry out MITM attacks, and its main feature is the combination of various techniques for avoiding detection. We decided to parse them to show how developers of malicious software hide its activity.

How it all started

The network traffic analysis system has drawn our attention to the fact that a malicious application regularly requests an image with additional content included in it. The download took place from a legitimate resource for storing images - imgsa.baidu.com. In addition, as it turned out, it was a picture with an overwhelming level of cuteness :) And how blasphemous after that the attempt by attackers to use it to hide various malicious loads looked blasphemous!







Fig. 1. Image used to hide the fact of delivery of the payload



To begin with, to collect the initial data and compare the samples, we organized a search for similar samples - and found a few. This was made possible thanks to the characteristic data in the network interaction and our extensive database of malicious traffic. In particular, a clear pattern can be seen in network traffic, a pattern consisting in the repetition of the same actions by a malicious application.







Fig. 2. Network traffic with marked patterns



We examined the first request, in response to it, the server returned an encrypted configuration (Fig. 3) containing the addresses of the images that contained the payload. This data is stored at hxxp://63634[.]top:8081/koded



.







Fig. 3. Encrypted configuration

Data decryption

The received data is decrypted by the DES algorithm in the electronic codebook mode with the key 0x6a 0x5f 0x6b 0x2a 0x61 0x2d 0x76 0x62 contained in the body of the malicious program. After decryption, the plaintext is a string (Fig. 4), each of which contains a link to the image. Based on the equality of MD5 hashes, this is the same image. Apparently, for the stability of the delivery scheme, the attackers located the same data at different addresses.







Fig. 4. Example of decrypted bootloader configuration



Using the obtained data, the next step is the malicious downloader initiates the download of the image. It cuts off the first 5120 bytes (duckling and puppy) from it and uses only the payload (Fig. 5), which follows immediately starting from the 5121st byte.







Fig. 5. Payload example.



After decrypting the data, we received the next format configuration, similar to what was obtained in the first step. That is one more portion of image links, but this time all the MD5 hashes are different and there are two character suffixes at the end of each line:







Fig. 6. Second set of links and suspicious suffixes

Malicious algorithm

Now these are real payload modules. As it turned out, the two characters at the end of each line are used to select a specific image, that is, a specific payload. First, a line with the suffix “AD” is used (Fig. 7). This choice is already predetermined at the stage of creating the malicious program. That is, the load sequence is predefined in the form of two-digit suffixes.







Fig. 7. Selecting a link with the suffix "AD"



The downloaded image already contains a malicious module, this can be said at least based on its size. The data is still disguised as images and located at the same offset of 5120 bytes. Having discarded the extra bytes, the loader extracts, checks the hash amount and then decrypts a module called TkRep.dll into the PE file.







Fig. 8. An example of an encrypted module in the image body and its hash sum



This library is loaded into a malicious process and, first of all, checks the environment in which the module is running:







Fig. 9. Checking the virtualization environment



Checks among running processes the presence of processes with the names devenv.exe, OLLYDBG.EXE, Dbgview.exe, windbg.exe, MSDEV.exe, Delphi32.exe, E.exe, PCHunter32.exe, PCHunter64.exe - as well as the presence of anti-virus tools.







Fig. 10. Process Verification



Makes a standard debug check.







Fig. 11. Checking the start of the process in the context of the debugger



Checks for open pipes that are listed in the table.



The next step is to register the infected node on the malicious server, sending encrypted information about the infected node with a POST request to the HTTP protocol (Fig. 12).







Fig. 12. Request for registration on the server of cybercriminals



It is noteworthy that the response from the server always contains the same data, and moreover, only the server response code is taken into account by the client.

How malware hides its activity

In accordance with a given sequence of payloads, we proceed to the study of the following. Its suffix is ​​“AR”. The client, in accordance with the existing scheme, downloads the next concatenation of the image with the encrypted load from the Baidu Images image storage service, decrypts the module and starts it in a new process with a random name. In our opinion, this functionality serves to make a malicious application look harmless. Often this is an online game client (Fig. 13). And this was another disguise technique.







Fig. 13. Online game interface



After carrying out this distracting maneuver, the malicious process proceeds to the stage of fixing on the infected node. To do this, it uses functionality similar to the functionality of rootkit programs. In particular, the introduction of its own secure driver into the system.



And this is how it happens. From the decrypted configuration, the load with the suffix "AE" is selected. This is the TaskReportDLL.dll library. It has the same functions as the TkRep.dll library from the previous step - send information about the system and check for the availability of protective equipment.



Then the RealWorkDll.dll library is downloaded. Among the functions of RealWorkDll.dll, it is important to download the driver, which is partially protected by VMPROTECT, and the PE file that this driver will install on the system.







Fig. 14. Path to the driver database



Then, the PE files used to install the driver are deleted, and this stage of fixing is completed.



A search in the driver database row led us to the rootkit [.] Com resource mirror repository, in which an instance of the FUTo rootkit with the corresponding name in the path “objfre_wxp_x86” was found (Fig. 14). In our company’s blog, this rootkit was considered back in 2006 .



Let us consider in more detail the work in the system of the SDriverBlogx86 driver installed by the RealWorkDll.dll module. At the first stage, the client’s registration data goes to the network. POST is used as a request, but now on port number 8081 (Fig. 15). Apparently, this port is used to receive data if activity on the infected system has reached the activation stage of the rootkit “FUTo”.







Fig. 15. Request for C2 from the driver installed in the system



Access to the server of cybercriminals occurs in encrypted form, data before encryption is information about the system. Separators of data fields, presentation format and number of fields are the same for all modules (Fig. 16).







Fig. 16. System information for identifying an infected node



Further, the mechanism of operation of the driver embedded in the system coincides with the initiating bootloader - the only difference being that links to images this time were requested from the rootkit port and the configuration storage path changed from / koded to / qqwe. Perhaps this is somehow related to the services qq.com and wechat.com.



The list of modules that the process receives contains a list of PE files. But in this case, instead of the two-letter suffix for selecting the load, at the end of the line contains a key in the form of a file name:







Fig. 17. Configuration received by the driver fixed in the system



After loading the images, the payload is also located at an offset of 5120 bytes. The payload structure for the installed driver includes the key from the previous list in the form of a file name, and then the PE file itself. Unlike the previous steps, the payload is not encrypted here.







Fig. 18. Payload received by the rootkit installed in the system



Among all the payloads received at this stage, it is worth noting the module for conducting MITM attacks. Its hash is equal to b9fcf48376083c71db0f13c9e344c0383bafa5b116fbf751672d54940082b99a



, the image with it is stored at this address .



The resulting module checks for processes with the names devenv.exe, OLLYDBG.EXE, Dbgview.exe, windbg.exe, MSDEV.exe, Delphi32.exe, E.exe, PCHunter32.exe, PCHunter64.exe, as well as the processes ZhuDongFangYu, 360Safe, 360Tray.



In the process of working with the help of a GET request, the server.crt, server.key, server.der, startcom.crt certificates are downloaded.







Fig. 19. Request for certificates



The class names of the module for conducting a MITM attack leave no doubt about the intentions of the attackers (Fig. 18).







Fig. 20. Class names of the module for conducting a MITM attack

Conclusion

This malware consists of a bootloader, a disguise file, a rootkit driver, and a module for conducting a man in the middle attack. For covert payload delivery, the software uses a technique for splicing data with JPEG images. For command servers, attackers register names in the domain zones top, bid, as well as on the basis of cloud platforms.



Here are some methods of masking the activity used by the developers of malicious software:

• disguise as a legal application,
• masking traffic for images,
• docking as a rootkit.

The considered threat is detected by the network traffic analysis system PT Network Attack Discovery as Spy.GmFUToMitm.





Authors : Dmitry Makarov, Evgeny Ustinov, Positive Technologies