APT group HoneyMyte upgrades CoolClient: the backdoor gets a kernel-level Windows rootkit

Introduction CoolClient is a backdoor family attributed to the HoneyMyte APT group (also known as Mustang Panda) that has been used in their cyber-espionage campaigns targeting organizations across Asia and Russia. It supports such capabilities as keylogging, clipboard theft, credential harvesting, file management, system reconnaissance, and plugin-based extensions. Since its first public disclosure by Sophos in 2022 and subsequent analysis by Trend Micro in 2023, CoolClient has continued to evolve. In 2025, we analyzed a newer variant that introduced clipboard theft and HTTP traffic interception for credential harvesting. In late 2025 and 2026, our latest investigation reveal another major evolution. The newest CoolClient variant can deploy a signed kernel-mode driver as a Windows service and communicate with it through IOCTL requests. The driver enhances the malware’s stealth by hiding the CoolClient process, protecting related files and registry entries, and preventing them from being inspected or modified. The overall design is comparable to the kernel-mode enhancements previously observed in ToneShell, but the CoolClient driver exposes dedicated IOCTL handlers that allow the user-mode backdoor to communicate directly with the driver. We have observed this updated CoolClient variant and its accompanying driver in intrusions across multiple countries in Asia, including Pakistan, Mongolia, and Myanmar. Technical analysis In the observed campaign targeting Myanmar, HoneyMyte used PlugX as the initial post-compromise implant to deploy the CoolClient components. Before deploying the malware, the actor added both a folder exclusion and a file exclusion to Microsoft Defender for the fake Windows Defender installation directory and the renamed sideloader executable (defender.exe ). | 1 2 | wmic /Node:localhost /Namespace:\Root\Microsoft\Windows\Defender Path MSFT_MpPreference call Add ExclusionPath="$programfiles\Microsoft\Windows Defender" wmic /Node:localhost /Namespace:\Root\Microsoft\Windows\Defender Path MSFT_MpPreference call Add ExclusionPath="$programfiles\Microsoft\Windows Defender\defender.exe" | The actor then created a fake Windows Defender installation directory, copied the CoolClient components into it, and renamed a legitimate Sangfor executable, usually named Sang.exe , to defender.exe to serve as the DLL sideloader. | 1 | xcopy "$programfiles\Windows Defender*" "$programfiles\Microsoft\Windows Defender" /a /s /v /e /f | Persistence was established through a scheduled task that launched defender.exe with SYSTEM privileges during system startup. | 1 | schtasks /create /sc onstart /tn "\Microsoft\Windows\Windows Defender Advanced Threat Protection Service" /tr ""$programfiles\Microsoft\Windows Defender\defender.exe"" /ru "system" /F | When executed, defender.exe sideloads the malicious libngs.dll , initiating the CoolClient execution chain described in the following sections. CoolClient components Similar to previous variants, the latest CoolClient user-mode component follows a multi-stage execution chain, with each component performing a distinct role during execution. | Component | Description | | defender.exe / Sang.exe | Legitimate Sangfor application abused for DLL sideloading | | libsrapc.dll | Benign dependency required for the Sangfor application to execute normally | | libngs.dll | First-stage loader that decrypts and loads the next stage into memory (First stage) | | loadcert.ini | Encrypted DLL implementing the core CoolClient functionality, including command handling, process injection, driver deployment, and persistence (Second stage) | | cert.ini | Final-stage implant responsible for C2 communication and backdoor functionality (Final stage) | | time.ini | CoolCleint configuration file | Our previous CoolClient analysis focused primarily on the final-stage implant (main.dat ), including its backdoor commands and plugin framework, while the first-stage loader (libngs.dll ) and second-stage component (loader.dat ) received only a brief overview. In the latest variant CoolClient, loader.dat and main.dat have been renamed to loadcert.ini and cert.ini , respectively. This article revisits those earlier stages, focusing on the second-stage component and the newly introduced kernel-mode driver that extends CoolClient with rootkit capabilities. First stage: libngs.dll Execution begins when the legitimate Sangfor application (defender.exe or Sang.exe ) loads the malicious libngs.dll through DLL sideloading. As in previous CoolClient variants, the malware continues to abuse the same Sangfor application to execute its first-stage loader. To make the DLL appear legitimate, libngs.dll exports numerous dummy functions. Each export simply calls OutputDebugStringA with its corresponding function name before immediately invoking ExitProcess , serving no functional purpose other than mimicking the expected export table of the legitimate DLL. The actual malicious logic is executed from DllMain (DllEntryPoint ). Although heavily obfuscated through control flow flattening and numerous unconditional jumps, the routine ultimately performs a straightforward task: loading, decrypting, and executing the encrypted second-stage DLL, loadcert.ini . The loader resolves the required Windows APIs, reads loadcert.ini into memory, and decrypts it using a 0x32-byte repeating XOR keystream derived from a transformed seed value of 0xA4 . After decryption, the DLL is loaded directly into memory, and execution is transferred to loadcert.ini. Second stage: loadcert.ini (before synchost.exe injection) The second-stage DLL, loadcert.ini , is responsible for preparing the execution environment before the malware transitions into its injected process. It first determines its execution context by checking whether the current module is synchost.exe . If the DLL is running under the original sideloaded process (for example, Sang.exe ), it performs the initial setup, including persistence, UAC bypass, registry modifications, and process injection. If the DLL is already executing inside synchost.exe , it follows a different execution path that decrypts time.ini , deploys the kernel-mode driver, and loads the final-stage implant (cert.ini ). Command handler The command handler remains largely unchanged from previous CoolClient variants, with one notable difference: the malware now injects into synchost.exe instead of write.exe . Execution is controlled through three command-line parameters: | Parameter | Purpose | | install | Performs the initial setup, including persistence, privilege checks, and preparation for the injected execution path. | | work | Executes the primary second-stage functionality from the injected synchost.exe process, including driver deployment and third-stage loading. | | passuac | Continues execution after privilege elevation. | If no parameter is supplied, the malware creates a new Sang.exe process with the install parameter using CreateProcessW . Establishing AutoRun persistence When executed with the install parameter, CoolClient creates an AutoRun entry under: | 1 | HKCU\Software\Microsoft\Windows\CurrentVersion\Run | The registry value, named goopdate , launches Sang.exe (or defender.exe , depending on the deployment) with the work parameter whenever the user logs on. Process injection into synchost.exe Upon establishing the AutoRun registry entry, CoolClient decrypts loadcert.ini using a 0x32-byte repeating XOR keystream derived from the hardcoded base key 0x4D . The decrypted DLL is then injected into a newly created suspended instance of synchost.exe . The malware allocates memory in the target process, writes the decrypted payload, redirects the thread context to the injected code, resumes execution, and finally terminates the original process with ExitProcess . From this point onward, execution continues entirely within synchost.exe , where the malware proceeds with kernel-mode driver deployment before loading the final-stage implant (cert.ini ). Service installation When executed with the install parameter, CoolClient establishes an additional persistence mechanism by installing itself as a Windows service. Before doing so, it verifies that it has sufficient access to the Service Control Manager and that no 360 Total Security software processes (360sd.exe , zhudongfangyu.exe , or 360desktopservice64.exe ) are running. If both checks succeed, the malware decrypts time.ini to retrieve the service configuration, including the service name and description. It then checks whether the service media_updaten already exists. If found, the existing service is stopped and deleted before a new one is created. The new service is configured to execute Sang.exe with the work parameter using CreateServiceA . The malware then starts the service by executing "sc start media_updaten" via WinExec . Administrator privilege check If the service installation path is not taken, CoolClient checks whether the current process is running with administrator privileges by verifying membership in the local Administrators group. When administrative privileges are available, the malware relaunches itself with the passuac parameter before continuing with the remaining execution flow. Elevated relaunch and UAC bypass To continue execution with elevated privileges while concealing its true parent process, CoolClient implements an RPC-based process creation technique similar to the method described by Google Project Zero. The technique combines RPC process creation with parent process ID (PPID) spoofing to launch a new elevated instance of itself. The malware first checks for the presence of escanmon.exe . If the process is running, it constructs the path to C:\Windows\System32\winver.exe and establishes a connection to the local ncalrpc endpoint (201ef99a-7fa0-444c-9399-19ba84f12a1a ). It then invokes NdrAsyncClientCall to launch winver.exe through the RPC interface. After winver.exe is created, CoolClient retrieves its debug objec