SURIQ
For the past year the trend in endpoint evasion has been loud: attackers ship a signed but flawed driver whose only job is to switch the security agent off. HoneyMyte, the China-nexus espionage group more widely tracked as Mustang Panda, has gone the other direction. Its CoolClient backdoor now loads a signed kernel driver that never touches your agent. It leaves the tool running and feeds it an edited version of reality, so the malicious process, its files, its registry keys, and its live network connections stop appearing in anything that asks Windows what is running. Researchers at Kaspersky documented the upgrade on August 16.
That distinction is the whole story, and it changes where you look.
Kill the agent, or blind it: two different problems
We have written about the kill approach more than once. Ransomware crews and access brokers load a trusted-but-flawed driver to reach into the kernel and terminate protection, a technique the industry calls bring your own vulnerable driver, or BYOVD. When it works, the console goes quiet and the agent stops reporting. That silence is ugly, but it is also a signal: a managed endpoint that suddenly stops checking in is an alarm most teams already watch. We covered exactly that pattern with a signed-driver kill used by ransomware and with an evasion kit sold as a finished product.
A rootkit is the quieter cousin. HoneyMyte's driver does not stop the agent or trigger a missed check-in. The agent keeps running and keeps reporting, but the answers it gets from the operating system have been rewritten underneath it. There is no silence to detect. Nothing looks wrong, because the thing that would look wrong has been removed from view before your tool ever sees it. Kill trips an alarm. Hide trips nothing. That is why the two need different detections, and why treating a rootkit like a louder BYOVD case will miss it.
What the driver actually hides
Kaspersky identified the kernel component as msagent.sys, installed as a Windows service named media_updaten. Once loaded it does four things, and each one targets a different way a defender might notice the backdoor. It unlinks the CoolClient process from the kernel list that tools walk to enumerate what is running, so the process is live but absent from a normal process listing. It registers a file-system filter that denies access to the backdoor's own files and folders. It installs a registry callback that hides the keys holding its persistence. And it hooks the Nsiproxy driver to strip its command-and-control addresses out of the connection tables the host reports.
The driver exposes 33 command handlers, but the analyzed sample used only three: one to register a process to hide, one to register an address to filter, and one to protect a path. One more detail is worth keeping. An active install writes a marker value, Wid_H1deF5Dirs, under HKLM\SYSTEM\RNG, which is a clean thing to hunt for because it is present whether or not the runtime is hidden.
The activity is hidden on the host, not everywhere
Here is the opening. A kernel rootkit can only edit what the host reports about itself. It cannot reach back in time to delete the events your systems already recorded before the driver loaded, and it cannot touch the record your network kept off the box. The process is gone from the local list, but the process-create event fired at launch, before the driver was ever installed. The C2 connection is scrubbed from the host's own tables, but the flow still crossed your network and your collector saw it. The hiding is real, and it is also local.
| Malicious activity | Hidden on the host after the driver loads | Still visible to you |
|---|---|---|
| CoolClient backdoor process | Unlinked from the live process list | The process-create event logged before the driver loaded |
| Backdoor files and folders | Access denied by a kernel file filter | The signed vendor binary sideloaded to drop them |
| Persistence registry keys | Filtered by a registry callback | The registry write and the service that installed the driver |
| Command-and-control traffic | Scrubbed from on-host connection tables | Flow records collected from your network, not the host |
Read that table as a hunting plan. Every entry in the middle column is a runtime query you can no longer trust on a compromised host. Every entry on the right is a place the same activity survives, because it lives in telemetry the driver has no reach into: events shipped to your log pipeline as they happened, and flow data recorded by your network rather than the endpoint.
The install chain is loud. Watch it.
The rootkit is the quiet end of a noisy sequence, and the noise is your detection window. HoneyMyte's chain starts with the older PlugX backdoor, then sideloads its payload through a legitimate, signed Sangfor executable renamed to defender.exe, decrypts several staged loaders, bypasses User Account Control through a remote-procedure-call technique, and injects into synchost.exe before the driver is ever installed as a service. Along the way it adds Microsoft Defender exclusions and creates a decoy C:\Program Files\microsoft\windows defender\ folder to blend into the namespace defenders trust.
None of that is hidden, because the rootkit is not loaded yet. The events worth alerting on are concrete: a signed third-party binary loading an unexpected DLL from its own directory, a new kernel-mode service being created, a driver load whose signing certificate is years old, writes that add Defender exclusions, and the creation of files or services that borrow Microsoft's own product names. A managed detection service watching service-creation and driver-load telemetry, rather than periodically listing processes, catches this class of intrusion at install time, which is the only time it is reliably visible. We made the same point about a Linux backdoor that moved into the Windows kernel: the detection window closes the moment the driver loads.
Treat an old signature as a warning, not a pass
The most quietly instructive detail is the driver's certificate. Kaspersky reports it was issued to Nanjing Ranyi Technology Co., Ltd. and was valid only from August 2013 to September 2014. It is expired, and Kaspersky did not establish how the attackers obtained it. Windows loaded it anyway, because kernel-mode signing checks honor a signature that was valid when it was made. That is the gap. A decade-old certificate is not a mark of trust, it is a mark of something that should not be loading a fresh driver today. Microsoft's vulnerable-driver blocklist covers known-bad drivers, but the durable habit is to treat the age of a driver's signature as a signal in its own right and to question any kernel module signed years before it appeared on the host.
Attribution here is careful, and worth repeating as such. Kaspersky links the campaign to HoneyMyte based on the consistent PlugX-led chain and prior tradecraft, while noting that Chinese-language debug strings alone do not settle it. The victims it names, government entities among targets in Myanmar, Mongolia, Pakistan, and Russia, fit an espionage operation, and reporting on the research frames it the same way. We have watched this same shift, from tools that disable defenses to tools that hide beneath them, in a modular kit that hot-swaps drivers. The kernel is where both fights now end, and the side that owns the driver-load moment owns the outcome.