Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 959
- Points
- 113
Specialists from the Positive Technologies Expert Security Center (PT Expert Security Center) have discovered an interesting example of malware spreading in the Chinese segment of the Internet. This software is used, among other things, to carry out MITM attacks, and its main feature is the combination of various techniques for evading detection. We decided to analyze them to show how malware developers hide its activity.
And how blasphemous after that the attackers’ attempt to use it to hide various malicious loads looked!
Rice. 1. Image used to hide the fact of payload delivery
To begin with, in order to collect initial data and compare samples, we searched for similar samples - and found several. This became possible due to the characteristic data in network interaction and the presence of an extensive database of malicious traffic. In particular, in network traffic you can see a clear pattern, a pattern consisting in repetition of the same actions on the part of the malicious application.
Rice. Fig. 2. Network traffic with marked patterns
We studied 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.
Rice. 3. Encrypted configuration
Rice. 4. An example of a decrypted bootloader configuration
Using the received data, the malicious bootloader initiates the download of the image in the next step. It cuts off the first 5120 bytes (duckling and puppy) and uses only the payload (Fig. 5), which immediately follows starting from the 5121st byte.
Fig.5. Payload example.
After decrypting the data, we received another configuration of a format similar to that obtained in the first step. That is, another portion of links to images, but this time all MD5 hashes are different and at the end of each line there are suffixes of two characters:
Fig. 6. Second set of links and suspicious suffixes
Rice. 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. After discarding the extra bytes, the bootloader extracts, checks the hash, and then decrypts a module called TkRep.dll into a PE file.
Rice. Fig . 8. An example of an encrypted module in the body of an image and its hash sum.
This library is loaded into a malicious process and first 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 - and also the presence of antivirus agents.
Rice. 10. Process check
Performs a standard debugging check.
Rice. 11. Checking the launch of a process in the context of a debugger
Checks the presence of those listed in the table among the open pipes.
The next step is to register the infected node on the attackers’ server by sending an HTTP POST request with information about the infected node in encrypted form (Fig. 12).
Rice. 12. Request for registration on the attackers’ server
It is noteworthy that the response from the server always contains the same data, and moreover, the client only takes into account the server’s response code.
Rice. 13. Online game interface
After this distracting maneuver, the malicious process proceeds to the stage of securing itself on the infected node. To do this, it uses functionality similar to that of rootkit programs. In particular, the introduction of its own secure driver into the system.
And this is how it happens. The load with the suffix “AE” is selected from the decrypted configuration. This is the TaskReportDLL.dll library. It has the same functions as the TkRep.dll library from the previous stage - send information about the system and check for the presence of security measures.
Then the RealWorkDll.dll library is downloaded. Among the functions of RealWorkDll.dll, an important one is the download of the driver, partially protected by VMPROTECT, and the PE file that this driver will install on the system.
Rice. 14. Driver Database Path
The PE files used to install the driver are then deleted and this pinning step is complete.
A search for the driver database string led us to the rootkit[.]com resource mirror repository, where an instance of the FUTo rootkit was found with the corresponding name in the path - “objfre_wxp_x86” (Fig. 14). This rootkit was discussed on our company's blog back in 2006.
Let's take a closer look at the operation of the SDriverBlogx86 driver installed by the RealWorkDll.dll module in the system. At the first stage, the client’s registration data is sent to the network. POST is used as a request, but now to port number 8081 (Fig. 15). Apparently, this port is used to receive data if activity on the infected system has reached the “FUTo” rootkit activation stage.
Rice. 15. Request for C2 from a driver installed on the system.
The attacker's server is contacted in encrypted form; the data before encryption is information about the system. Data field separators, presentation format and number of fields are the same for all modules (Fig. 16).
Rice. 16. Information about the system to identify the infected node
Further, the mechanism of operation of the driver embedded in the system coincides with the initiating bootloader - with the only difference that this time links to images were requested from the rootkit port and the configuration storage path changed from /koded to /qqwe. Perhaps this has something to do with the services qq.com and wechat.com.
The list of modules that a process receives contains a list of PE files. But in this case, instead of a two-letter suffix for selecting a load, the end of the line contains a key in the form of a file name:
Fig. 17. Configuration received by the driver attached to the system
After loading images, the payload is also located at offset 5120 bytes. The payload structure for an installed driver includes the key from the previous list as a file name, and then the PE file itself. Unlike previous steps, the payload here is not encrypted.
Rice. 18. Payload received by the rootkit installed on the system
Among all the payloads received at this stage, it is worth noting the module for carrying out a MITM attack. Its hash sum is b9fcf48376083c71db0f13c9e344c0383bafa5b116fbf751672d54940082b99a, the image with it is stored at this address.
The resulting module checks for 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 processes ZhuDongFangYu, 360Safe, 360Tray.
During operation, the server.crt, server.key, server.der, startcom.crt certificates are downloaded using a GET request.
Rice. Fig. 19. Request for certificates
The class names of the module for carrying out a MITM attack leave no doubt about the attackers’ intentions (Fig. 20).
Rice. 20. Names of module classes for carrying out a MITM attack
Here are the activity masking methods used by malware developers:
The threat in question is detected by the PT Network Attack Discovery network traffic analysis system as Spy.GmFUToMitm.
IOC
1953db709a96bc70d86f7dfd04527d3d0cb7c94da276ddf8f0ef6c51630a2915
1ab1b2fe3ce0fd37a0bb0814a2cac7e974f20963800f43d2f5478fc88c83a3da
1c8dbaf0a5045e2b4a6787635ded8f51d8e89a18e398c0dd79b1b82a968df1a0
9b7082ac4165b25a3b22f2aafdd41ea5f3512a76693f6a6b3101873a9cded961
9cee3f6d6e39adfa0d4712541c070b9c2423275698be0c6cd6cd8239d8793250
b9fcf48376083c71db0f13c9e344c0383bafa5b116fbf751672d54940082b99a
df3e7b04d988cf5634ec886321cb1ac364a46181e7a63f41f0788753e52dcf34
eb67c1d69eb09e195b8333e12c41a0749e7e186c9439f1e2c30f369712ce2c12
63634.top
anli.bid
shangdai.bid
b-blog.oss-cn-beijing.aliyuncs.com
Authors: Dmitry Makarov, Evgeny Ustinov, Positive Technologies
Where it all started
The network traffic analysis system brought to our attention that the 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. Moreover, as it turned out, it was a picture with an off-scale level of cuteness And how blasphemous after that the attackers’ attempt to use it to hide various malicious loads looked!
Rice. 1. Image used to hide the fact of payload delivery
To begin with, in order to collect initial data and compare samples, we searched for similar samples - and found several. This became possible due to the characteristic data in network interaction and the presence of an extensive database of malicious traffic. In particular, in network traffic you can see a clear pattern, a pattern consisting in repetition of the same actions on the part of the malicious application.
Rice. Fig. 2. Network traffic with marked patterns
We studied 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.
Rice. 3. Encrypted configuration
Data decryption
The received data is decrypted using the DES algorithm in 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 consists of lines (Fig. 4), each of which contains a link to an image. Based on the equality of MD5 hashes, this is the same image. Apparently, to ensure the stability of the delivery scheme, the attackers placed the same data at different addresses.
Rice. 4. An example of a decrypted bootloader configuration
Using the received data, the malicious bootloader initiates the download of the image in the next step. It cuts off the first 5120 bytes (duckling and puppy) and uses only the payload (Fig. 5), which immediately follows starting from the 5121st byte.
Fig.5. Payload example.
After decrypting the data, we received another configuration of a format similar to that obtained in the first step. That is, another portion of links to images, but this time all MD5 hashes are different and at the end of each line there are suffixes of two characters:
Fig. 6. Second set of links and suspicious suffixes
How the malware works
Now these are real payload modules. As it turns out, the two characters at the end of each line are used to select a specific image, that is, a specific payload. First, the 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 sequence of loads is predetermined in the form of two-digit suffixes.
Rice. 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. After discarding the extra bytes, the bootloader extracts, checks the hash, and then decrypts a module called TkRep.dll into a PE file.
Rice. Fig . 8. An example of an encrypted module in the body of an image and its hash sum.
This library is loaded into a malicious process and first 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 - and also the presence of antivirus agents.
Rice. 10. Process check
Performs a standard debugging check.
Rice. 11. Checking the launch of a process in the context of a debugger
Checks the presence of those listed in the table among the open pipes.
| \\.\FltMouseKb | \\.\GameGuard | \\.\GxWfpFlt |
| \\.\XxGamesFilter | \\.\GpeNetSafe | \\.\TeSafe |
| \\.\Sdriver | \\.\PowerChange | \\.\xspeed |
| \\.\gmMemProt | \\.\diafahbb |
The next step is to register the infected node on the attackers’ server by sending an HTTP POST request with information about the infected node in encrypted form (Fig. 12).
Rice. 12. Request for registration on the attackers’ server
It is noteworthy that the response from the server always contains the same data, and moreover, the client only takes into account the server’s response code.
How malicious software hides its activity
In accordance with the given sequence of payloads, we move on to studying the next one. Its suffix is "AR". The client, in accordance with the existing scheme, downloads the next concatenation of an image with an encrypted load from the Baidu Images image storage service, decrypts the module and launches it in a new process with a random name. In our opinion, this functionality serves to make a malicious application appear harmless. Often this is an online game client (Fig. 13). And this was another camouflage technique.
Rice. 13. Online game interface
After this distracting maneuver, the malicious process proceeds to the stage of securing itself on the infected node. To do this, it uses functionality similar to that of rootkit programs. In particular, the introduction of its own secure driver into the system.
And this is how it happens. The load with the suffix “AE” is selected from the decrypted configuration. This is the TaskReportDLL.dll library. It has the same functions as the TkRep.dll library from the previous stage - send information about the system and check for the presence of security measures.
Then the RealWorkDll.dll library is downloaded. Among the functions of RealWorkDll.dll, an important one is the download of the driver, partially protected by VMPROTECT, and the PE file that this driver will install on the system.
Rice. 14. Driver Database Path
The PE files used to install the driver are then deleted and this pinning step is complete.
A search for the driver database string led us to the rootkit[.]com resource mirror repository, where an instance of the FUTo rootkit was found with the corresponding name in the path - “objfre_wxp_x86” (Fig. 14). This rootkit was discussed on our company's blog back in 2006.
Let's take a closer look at the operation of the SDriverBlogx86 driver installed by the RealWorkDll.dll module in the system. At the first stage, the client’s registration data is sent to the network. POST is used as a request, but now to port number 8081 (Fig. 15). Apparently, this port is used to receive data if activity on the infected system has reached the “FUTo” rootkit activation stage.
Rice. 15. Request for C2 from a driver installed on the system.
The attacker's server is contacted in encrypted form; the data before encryption is information about the system. Data field separators, presentation format and number of fields are the same for all modules (Fig. 16).
Rice. 16. Information about the system to identify the infected node
Further, the mechanism of operation of the driver embedded in the system coincides with the initiating bootloader - with the only difference that this time links to images were requested from the rootkit port and the configuration storage path changed from /koded to /qqwe. Perhaps this has something to do with the services qq.com and wechat.com.
The list of modules that a process receives contains a list of PE files. But in this case, instead of a two-letter suffix for selecting a load, the end of the line contains a key in the form of a file name:
Fig. 17. Configuration received by the driver attached to the system
After loading images, the payload is also located at offset 5120 bytes. The payload structure for an installed driver includes the key from the previous list as a file name, and then the PE file itself. Unlike previous steps, the payload here is not encrypted.
Rice. 18. Payload received by the rootkit installed on the system
Among all the payloads received at this stage, it is worth noting the module for carrying out a MITM attack. Its hash sum is b9fcf48376083c71db0f13c9e344c0383bafa5b116fbf751672d54940082b99a, the image with it is stored at this address.
The resulting module checks for 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 processes ZhuDongFangYu, 360Safe, 360Tray.
During operation, the server.crt, server.key, server.der, startcom.crt certificates are downloaded using a GET request.
Rice. Fig. 19. Request for certificates
The class names of the module for carrying out a MITM attack leave no doubt about the attackers’ intentions (Fig. 20).
Rice. 20. Names of module classes for carrying out a MITM attack
Conclusion
This malware consists of a downloader, a disguise file, a rootkit driver and a module for carrying out a man-in-the-middle attack. To covertly deliver the payload, the software uses the technique of splicing data with JPEG images. For command and control servers, attackers register names in the top, bid domain zones, as well as on cloud platforms.Here are the activity masking methods used by malware developers:
- disguised as a legitimate application,
- disguise in traffic as images,
- pinning as a rootkit.
The threat in question is detected by the PT Network Attack Discovery network traffic analysis system as Spy.GmFUToMitm.
IOC
1953db709a96bc70d86f7dfd04527d3d0cb7c94da276ddf8f0ef6c51630a2915
1ab1b2fe3ce0fd37a0bb0814a2cac7e974f20963800f43d2f5478fc88c83a3da
1c8dbaf0a5045e2b4a6787635ded8f51d8e89a18e398c0dd79b1b82a968df1a0
9b7082ac4165b25a3b22f2aafdd41ea5f3512a76693f6a6b3101873a9cded961
9cee3f6d6e39adfa0d4712541c070b9c2423275698be0c6cd6cd8239d8793250
b9fcf48376083c71db0f13c9e344c0383bafa5b116fbf751672d54940082b99a
df3e7b04d988cf5634ec886321cb1ac364a46181e7a63f41f0788753e52dcf34
eb67c1d69eb09e195b8333e12c41a0749e7e186c9439f1e2c30f369712ce2c12
63634.top
anli.bid
shangdai.bid
b-blog.oss-cn-beijing.aliyuncs.com
Authors: Dmitry Makarov, Evgeny Ustinov, Positive Technologies
