The immediate defensive priority is not to treat this as another commodity signed-driver alert. According to Neowin’s account of Kaspersky’s latest research, CoolClient uses the driver as part of a targeted intrusion chain seen in Pakistan, Mongolia, and Myanmar, including government victims. Organizations with users, infrastructure, suppliers, or diplomatic operations connected to those regions should hunt for the specified service and persistence artifacts now, then preserve affected systems for offline investigation rather than assuming a visible process kill has removed the intrusion.
There is also an important reporting gap. Kaspersky’s January 2026 research on CoolClient explicitly said it had observed a newer Pakistan-and-Myanmar variant that deployed an unseen rootkit and that a separate technical report would follow. At publication time, that follow-up report was not readily available in Kaspersky’s public research archive. The new CoolClient-specific driver details therefore remain attributable to Neowin’s reporting, while Kaspersky’s earlier work independently establishes that the group had begun pairing CoolClient with an as-yet-undocumented rootkit variant.
A signed driver changes the cleanup problem
Neowin reports that the newer CoolClient installs a signed kernel-mode driver as a Windows service, then communicates with it through IOCTL requests. IOCTLs, or input/output control calls, are the normal Windows mechanism through which applications request operations from drivers. In malicious hands, they provide a direct channel from user-mode malware to code running in the kernel.
The reported driver functions go beyond maintaining persistence. It allegedly hides CoolClient processes, protects files and Registry entries, and blocks tampering. That means an endpoint tool operating only in normal user mode may see an incomplete picture of the machine: the malicious service can remain registered while its supporting process, payload files, or configuration data become harder to enumerate or open.
This is the practical consequence for incident response teams: do not use the apparent absence of a file, process, or Registry key as proof that the host is clean. A rootkit designed to restrict handles to protected processes can make Task Manager, Process Explorer, EDR live-response sessions, and ordinary removal scripts less reliable precisely when responders need them most.
Kaspersky’s December 2025 HoneyMyte report documented a related pattern in a separate ToneShell campaign. There, a signed driver registered as a mini-filter driver protected malicious files, Registry keys, and injected user-mode payloads. The payload in that campaign was ToneShell, rather than CoolClient, and it used a different certificate and service name. But the operational lesson carries over: HoneyMyte has already demonstrated a move toward drivers that make its post-compromise implants harder to inspect and eradicate.
CoolClient had already become a broader espionage platform
The rootkit report lands after a substantial CoolClient expansion documented by Kaspersky in January. In that analysis, CoolClient was no longer just a basic remote-access implant: it could collect detailed host and user data, upload or delete files, log keystrokes, create reverse tunnels, establish proxies, and load additional modules directly into memory.
Kaspersky also documented newer monitoring of the clipboard and active window titles, plus collection of credentials passed in HTTP proxy-authorization headers. Separate plugins added remote shell access, full file-management functions, and service management. In other HoneyMyte activity, Kaspersky observed browser credential stealers targeting Chrome and Microsoft Edge, alongside scripts for document collection and system reconnaissance.
The rootkit therefore protects an implant that has enough functionality to support a prolonged intelligence operation. An attacker does not need to deploy a new tool for every task if the existing CoolClient installation can take files, stage in-memory plugins, tunnel traffic, monitor user activity, and execute commands. The kernel driver’s value is extending the time attackers can retain that access without being discovered.
Neowin further reports that HoneyMyte used PlugX as an earlier implant in at least one Myanmar intrusion before CoolClient components arrived. That sequencing fits Kaspersky’s prior observations that CoolClient often appeared alongside PlugX, ToneShell, and LuminousMoth-related activity rather than as an isolated infection. For defenders, finding PlugX or historic HoneyMyte artifacts should trigger a wider review for newer persistence mechanisms, not a narrowly scoped cleanup of the first backdoor discovered.
The certificate is an investigative lead, not proof of safety
According to Neowin, the CoolClient driver was signed with a certificate issued to “Nanjing Ranyi Technology Co., Ltd.” with serial number 3E 62 DC 5D 8D 61 2A 26 33 E7 6B DF D6 07 19 DD. The certificate was reportedly valid from August 2013 through September 2014. Its presence on a current malware driver would be an immediate anomaly: a valid code-signing signature tells Windows that a file has not changed since signing, but it does not establish that the signer or its certificate was trustworthy at the time a threat actor acquired it.
Security teams should avoid the common mistake of building a detection rule that trusts a driver simply because Windows accepts its signature. Microsoft’s vulnerable driver blocklist is specifically designed to block drivers associated with known vulnerabilities, malicious behavior, or certificates used to sign malware. But Microsoft also cautions that the blocklist is not guaranteed to block every risky driver, partly because broad blocks can create compatibility failures.
That limitation matters here. A driver signed with an old or compromised certificate can operate in the interval before an applicable block rule reaches endpoints, assuming the Windows configuration permits it to load. The correct control is defense in depth: current Windows servicing, the vulnerable driver blocklist, memory integrity where compatible, and tightly managed App Control policies rather than reliance on signature reputation alone.
For Windows 11, Microsoft says the vulnerable driver blocklist has been enabled by default since the 2022 Update, though it can be disabled. It is also enforced when memory integrity, Smart App Control, or S mode is active. Administrators should verify configuration rather than infer it from the operating-system version, especially on devices upgraded across several Windows releases or managed with older baselines.
What defenders should check first
The reported indicators are useful, but they should be used as pivots rather than as a complete detection strategy. Neowin names msagent and media_updaten as service artifacts worth investigating. Kaspersky’s January CoolClient analysis independently documented media_updaten as a service name used by an earlier CoolClient variant, which makes it a credible starting point even though service names alone are easy for an actor to change.
A first-pass hunt should include the following actions:
- Review newly created or recently modified kernel-driver services, especially services whose binary paths point outside established vendor directories or whose driver signatures chain to unexpected, expired, or unapproved publishers.
- Investigate any
media_updatenormsagentservice immediately, recording its service configuration, binary path, file hash, signer information, creation time, dependent services, and associated Registry keys before attempting removal. - Compare endpoint process, driver, service, and Registry inventories from EDR with offline or boot-time inspection results. A discrepancy is more meaningful than either view alone when rootkit behavior is suspected.
- Audit Microsoft Defender Antivirus exclusions, particularly additions affecting user-writable directories, temporary locations, or unusual executables. Microsoft warns that scan exclusions reduce protection and specifically advises against excluding common malware staging locations such as user profile temporary folders and Windows temporary directories.
- Confirm that Microsoft’s vulnerable driver blocklist is enabled and that devices are receiving current Windows security updates. For more restrictive environments, validate Microsoft’s recommended driver block rules in audit mode before enforcement to identify legitimate software that could be affected.
Defender exclusions deserve special attention because they can outlive the initial payload. Microsoft documents that exclusions can be configured through local settings, Group Policy, Configuration Manager, WMI, PowerShell, and mobile-device-management policy. A local cleanup that deletes one suspicious exclusion without identifying the policy source can fail when the setting is reapplied by a compromised administrative channel or an unauthorized Group Policy Object.
Response should begin outside the compromised Windows session
If the reported rootkit behavior is confirmed on a host, responders should assume that the live operating system may be unable to provide trustworthy evidence or successfully remove the driver. Isolate the device from the network, collect volatile data where policy and tooling permit, and preserve the driver file, service configuration, event logs, and endpoint telemetry. Then perform deeper examination from trusted media, a known-good recovery environment, or a forensic workflow that does not depend on the potentially subverted Windows session.
Rebuilding may be safer than trying to disinfect a sensitive government or enterprise endpoint when a kernel driver has protected malware and interfered with process or file access. That decision should be based on the system’s role, the attacker’s demonstrated access, whether credential theft or lateral movement occurred, and whether the organization can establish a reliable chain of trust from firmware through the operating system.
HoneyMyte’s CoolClient upgrade is a warning that the group’s tooling is becoming more durable after initial compromise. The indicator names and certificate details may change in later campaigns, but the defensive requirement will not: Windows fleets need a verified kernel-driver policy, monitored Defender configuration, and an incident process built for the possibility that the infected machine is lying about what is running on it.