The HoneyMyte APT evolves with a kernel-mode rootkit and a ToneShell backdoor

Kaspersky discloses a 2025 HoneyMyte (aka Mustang Panda or Bronze President) APT campaign, which uses a kernel-mode rootkit to deliver and protect a ToneShell backdoor.

The HoneyMyte APT evolves with a kernel-mode rootkit and a ToneShell backdoor

29 Dec 2025

minute read

Table of Contents

• Overview of the attacks
• Compromised digital certificate
• Technical details of the malicious driver

• API resolution
• Protection of the driver file
• Protection of registry keys
• Protection of user-mode processes
• Payload injection

• ToneShell backdoor
• Conclusion
• Recommendations
• Indicators of Compromise

Overview of the attacks

In mid-2025, we identified a malicious driver file on computer systems in Asia. The driver file is signed with an old, stolen, or leaked digital certificate and registers as a mini-filter driver on infected machines. Its end-goal is to inject a backdoor Trojan into the system processes and provide protection for malicious files, user-mode processes, and registry keys.

Our analysis indicates that the final payload injected by the driver is a new sample of the ToneShell backdoor, which connects to the attacker’s servers and provides a reverse shell, along with other capabilities. The ToneShell backdoor is a tool known to be used exclusively by the HoneyMyte (aka Mustang Panda or Bronze President) APT actor and is often used in cyberespionage campaigns targeting government organizations, particularly in Southeast and East Asia.

The command-and-control servers for the ToneShell backdoor used in this campaign were registered in September 2024 via NameCheap services, and we suspect the attacks themselves to have begun in February 2025. We’ve observed through our telemetry that the new ToneShell backdoor is frequently employed in cyberespionage campaigns against government organizations in Southeast and East Asia, with Myanmar and Thailand being the most heavily targeted.

Notably, nearly all affected victims had previously been infected with other HoneyMyte tools, including the ToneDisk USB worm, PlugX, and older variants of ToneShell. Although the initial access vector remains unclear, it’s suspected that the threat actor leveraged previously compromised machines to deploy the malicious driver.

Compromised digital certificate

The driver file is signed with a digital certificate from Guangzhou Kingteller Technology Co., Ltd., with a serial number of 08 01 CC 11 EB 4D 1D 33 1E 3D 54 0C 55 A4 9F 7F. The certificate was valid from August 2012 until 2015.

We found multiple other malicious files signed with the same certificate which didn’t show any connections to the attacks described in this article. Therefore, we believe that other threat actors have been using it to sign their malicious tools as well. The following image shows the details of the certificate.

Technical details of the malicious driver

The filename used for the driver on the victim’s machine is ProjectConfiguration.sys. The registry key created for the driver’s service uses the same name, ProjectConfiguration.

The malicious driver contains two user-mode shellcodes, which are embedded into the .data section of the driver’s binary file. The shellcodes are executed as separate user-mode threads. The rootkit functionality protects both the driver’s own module and the user-mode processes into which the backdoor code is injected, preventing access by any process on the system.

API resolution

To obfuscate the actual behavior of the driver module, the attackers used dynamic resolution of the required API addresses from hash values.

The malicious driver first retrieves the base address of the ntoskrnl.exe and fltmgr.sys by calling ZwQuerySystemInformation with the SystemInformationClass set to SYSTEM_MODULE_INFORMATION. It then iterates through this system information and searches for the desired DLLs by name, noting the ImageBaseAddress of each.

Once the base addresses of the libraries are obtained, the driver uses a simple hashing algorithm to dynamically resolve the required API addresses from ntoskrnl.exe and fltmgr.sys.

The hashing algorithm is shown below. The two variants of the seed value provided in the comment are used in the shellcodes and the final payload of the attack.

Protection of the driver file

The malicious driver registers itself with the Filter Manager using FltRegisterFilter and sets up a pre-operation callback. This callback inspects I/O requests for IRP_MJ_SET_INFORMATION and triggers a malicious handler when certain FileInformationClass values are detected. The handler then checks whether the targeted file object is associated with the driver; if it is, it forces the operation to fail by setting IOStatus to STATUS_ACCESS_DENIED. The relevant FileInformationClass values include:

• FileRenameInformation

• FileDispositionInformation

• FileRenameInformationBypassAccessCheck

• FileDispositionInformationEx

• FileRenameInformationEx

• FileRenameInformationExBypassAccessCheck

These classes correspond to file-delete and file-rename operations. By monitoring them, the driver prevents itself from being removed or renamed – actions that security tools might attempt when trying to quarantine it.

Protection of registry keys

The driver also builds a global list of registry paths and parameter names that it intends to protect. This list contains the following entries:

• **ProjectConfiguration

• **ProjectConfiguration\Instances

• ProjectConfiguration Instance

To guard these keys, the malware sets up a RegistryCallback routine, registering it through CmRegisterCallbackEx. To do so, it must assign itself an altitude value. Microsoft governs altitude assignments for mini-filters, grouping them into Load Order categories with predefined altitude ranges. A filter driver with a low numerical altitude is loaded into the I/O stack below filters with higher altitudes. The malware uses a hardcoded starting point of 330024 and creates altitude strings in the format 330024.%l, where %l ranges from 0 to 10,000.

The malware then begins attempting to register the callback using the first generated altitude. If the registration fails with STATUS_FLT_INSTANCE_ALTITUDE_COLLISION, meaning the altitude is already taken, it increments the value and retries. It repeats this process until it successfully finds an unused altitude.

The callback monitors four specific registry operations. Whenever one of these operations targets a key from its protected list, it responds with 0xC0000022 (STATUS_ACCESS_DENIED), blocking the action. The monitored operations are:

• **RegNtPreCreateKey

• **RegNtPreOpenKey

• **RegNtPreCreateKeyEx

• RegNtPreOpenKeyEx

Microsoft designates the 320000–329999 altitude range for the FSFilter Anti-Virus Load Order Group. The malware’s chosen altitude exceeds this range. Since filters with lower altitudes sit deeper in the I/O stack, the malicious driver intercepts file operations before legitimate low-altitude filters like antivirus components, allowing it to circumvent security checks.

Finally, the malware tampers with the altitude assigned to WdFilter, a key Microsoft Defender driver. It locates the registry entry containing the driver’s altitude and changes it to 0, effectively preventing WdFilter from being loaded into the I/O stack.

Protection of user-mode processes

The malware sets up a list intended to hold protected process IDs (PIDs). It begins with 32 empty slots, which are filled as needed during execution. A status flag is also initialized and set to 1 to indicate that the list starts out empty.

Next, the malware uses ObRegisterCallbacks to register two callbacks that intercept process-related operations. These callbacks apply to both OB_OPERATION_HANDLE_CREATE and OB_OPERATION_HANDLE_DUPLICATE, and both use a malicious pre-operation routine.

[...]

Original source