The digital signature which authenticates this rootkit has expired as of September 2014. It had been obtained the previous year, by an unknown company which has never been heard of by the defenders. And yet Windows still loads the driver.
It is no bug in the digital signature verification process. The latter takes place, gives a proper result to the improper query.
What is the CoolClient kernel rootkit? A kernel mode driver on the Microsoft Windows platform, msagent.sys, which is loaded into the CoolClient backdoor belonging to the Mustang Panda group with ties to China. It obscures processes, files, registry keys and kernel drivers, filters the connections of the attacker from the system monitoring tools, and prevents security software from accessing the obscured data.
The Chain Starts With A Renamed Security Binary
Access happens first via PlugX, a backdoor the group has been using for years now. The subsequent phase operates stealthily.
A legitimate signed executable file, obtained from a commercial security application, is renamed to defender.exe. Everyone who checks a process list will see a convincing file doing convincing things.
That file then executes a malicious DLL file called libngs.dll, which will decrypt and execute the second stage in loadcert.ini. The payload will finally reside in cert.ini with its configuration in time.ini. A scheduled task executes this entire chain at boot, with SYSTEM-level privileges.
All files in this chain have either innocuous filenames or .ini extensions. None of the files look suspicious in any way when listed in a directory.
How Windows Decides Which Drivers It Trusts
What The Driver Does Once It Loads
The rootkit works as a Windows service and receives its commands from the user-mode backdoor using the IOCTL requests. It uses 33 IOCTL commands, although, the examined sample used only three of them.
The rootkit has nothing else in mind except hiding. Processes are removed from the list of processes. Files, registry entries, and kernel drivers are removed from enumeration. Network traffic is processed through Nsiproxy hooks removing command-and-control IP addresses from being viewed by any process up the stack.
Protected processes are stripped of their access rights preventing termination and injection attacks. Anti-malware software cannot terminate something it does not have access to.
Victims included governmental organizations in Myanmar, Mongolia, Pakistan, and Russia.
Why A Certificate From 2013 Still Works
This is the part that is worth noting about outside the scope of this single campaign.
Windows performs driver signing at the kernel boundary. There is also an exception for backward compatibility, in which the driver will load if signed with an un-revoked certificate before July 29, 2015 that chains back to one of the cross-signing authorities Windows supports.
The exception is well justified, because without it, drivers for hardware deployed in hospital equipment, factory machinery and utility systems will fail to load, as these are machines that can’t simply be replaced.
If the attacker holds one of the revoked certificates and its private key, he is granted the same exception. The certificate doesn’t need to be up-to-date. The important thing is that the certificate be old enough, and not revoked and correctly chained.
The attribution here does not depend on the certificate. The connection with Mustang Panda is established by way of malware families and deployment mechanisms, although malicious drivers signed using this certificate were seen around 2013.
Microsoft Is Closing This, On Recent Builds
Cross-signing for drivers was made obsolete in 2021, and its certificates expired.
Windows update in April 2026 brought along a new kernel trust policy that would apply to Windows 11 24H2, 25H2, 26H1 and Windows Server 2025. The risk in those estates would be quite different from the risks in any earlier version of Windows.
Which means that the key issue isn’t whether Microsoft has fixed this. It’s whether a particular fleet is using a Windows version that gets the fix and how many in that fleet aren’t.
Signature Checks Answer The Wrong Question
When a campaign installed a genuine, correctly signed ScreenConnect agent that no administrator had approved. Same logic, different level. There it resides in the user space, here it works its magic in the kernel space.
The signature confirms that some entity has signed the software at some point in time. It does not confirm that the one with such a signature is currently in possession of that signature or that such signing even exists any more. These are two entirely different facts and no certificate includes them.
The execution governance asks the question which the certificate cannot give you an answer to. Not if your code is signed but if your code is allowed to execute at that moment in time. Kernel driver with no sign of an approval record does not matter how old the signature of it is and from whom it originated.
The rootkit described above was designed to prevent any post-execution checks. By the time when the check would happen, the driver had destroyed any evidence.
Conclusion: The Signature Was Valid. The Execution Was Not.
The defining lesson from this campaign is not that Windows failed to verify a digital signature. The deeper problem is that a historical trust decision could still help unauthorized kernel execution appear legitimate years later.
The attack chain compounds that trust problem at multiple levels. A legitimate signed executable is renamed and used to side-load a malicious DLL. Additional stages are decrypted from files with innocuous extensions. A scheduled task restores the chain at boot with SYSTEM privileges. Finally, a signed kernel driver becomes a rootkit capable of hiding processes, files, registry entries, drivers, and attacker network activity while restricting security software’s ability to inspect or terminate protected processes.
That makes trust before execution decisive. Once the rootkit reaches the kernel and begins suppressing the evidence defenders depend on, post-execution visibility is already operating at a disadvantage. The important question is therefore not simply whether a component carries a technically acceptable signature. It is whether that execution is trusted and authorized in the environment where it is occurring.
Why This Threat Matters
- A valid signature is not authorization. Cryptographic verification can establish signing provenance without establishing that a driver belongs in the current environment.
- Legitimate software can become part of the execution chain. The signed executable is not itself the malicious component, but its trusted execution context is used to load one.
- Persistence restores the entire chain. The scheduled task brings the sequence back at boot with SYSTEM-level privileges.
- Kernel access changes the defensive balance. Once active, the rootkit can manipulate the visibility that security tooling relies on for investigation and response.
- Innocuous filenames provide little assurance. DLLs, encrypted stages, configuration data, and payloads can sit behind names and extensions that reveal nothing about their purpose.
- Legacy compatibility can preserve legacy trust. Organizations need to know which systems are actually operating under Microsoft’s newer kernel trust policy and which remain exposed to older assumptions.
Where Defensive Control Must Operate
Defensive control must operate before an untrusted execution chain inherits the privileges of legitimate software and reaches the kernel.
Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform applies Execution Governance to unknown execution before trust exists. In this attack shape, that control point matters around the malicious DLL and subsequent payload stages, where untrusted code should not receive unrestricted access simply because execution began through a legitimate signed binary.
Xcitium Vulnerability Assessment supports the fleet-level problem by helping identify outdated systems, patch gaps, and configuration weaknesses that leave endpoints outside the intended security baseline. Microsoft is raising the kernel trust boundary on newer Windows estates, but defenders still need to know where older or insufficiently remediated systems remain.
Trust the Authorization, Not Just the Signature
Driver signing should be one input into trust, not the final permission to execute. Security teams should inventory systems outside the newer Windows kernel trust baseline, validate boot persistence and driver authorization, and investigate unexpected DLL loading from otherwise legitimate applications.
The rootkit’s objective is to make post-execution evidence disappear. The stronger defensive position is to challenge the execution chain before it gains the authority to decide what defenders are allowed to see.
