HoneyMyte’s CoolClient Evolves Into a Stealthier Threat With a Kernel-Mode Rootkit + Video

Listen to this Post

Featured ImageA Familiar Espionage Tool Takes a Dangerous Turn

Cyber espionage rarely stands still. When defenders become familiar with a malware family, attackers have a strong incentive to change the rules rather than simply repeat the same playbook. That is exactly what appears to be happening with HoneyMyte, also known as Mustang Panda, whose CoolClient backdoor has evolved from a conventional user-mode espionage implant into something considerably harder to detect.

Recent activity described in the supplied research shows CoolClient being paired with a kernel-mode rootkit capable of hiding elements of the malware’s command-and-control infrastructure on compromised Windows systems. That change is important because kernel-level malware operates beneath many traditional security controls, potentially giving attackers a much deeper position inside an infected endpoint.

HoneyMyte has previously been associated with cyber-espionage operations against organizations in Asia and Russia. The latest activity reportedly includes targets in Myanmar, Mongolia, Pakistan, and Russia, including government-related organizations.

The campaign demonstrates an increasingly familiar pattern in modern intrusions: legitimate software is abused, malware is disguised as trusted Windows components, persistence is established in multiple ways, and finally a kernel driver is introduced to make the compromise more difficult to see.

CoolClient Was Already a Powerful Espionage Implant

CoolClient is not a lightweight piece of malware. Its capabilities reportedly include keylogging, clipboard collection, credential theft, file manipulation, system reconnaissance, and plugin-based expansion.

That combination makes the backdoor particularly valuable for long-term espionage. Instead of simply stealing one password or one document, an operator can maintain visibility into a compromised environment and selectively collect information over time.

The addition of a kernel-mode component therefore represents more than another feature. It changes the defensive challenge.

A conventional backdoor running in user mode can often be investigated through process listings, loaded modules, filesystem artifacts, registry entries, scheduled tasks, network connections, and endpoint telemetry. A rootkit operating inside the Windows kernel can attempt to interfere with exactly the kinds of visibility defenders depend upon.

PlugX Can Open the Door

The reported infection chain often begins with PlugX, another malware family historically associated with HoneyMyte activity.

According to the supplied research, PlugX can serve as an initial implant and help attackers deploy CoolClient and its supporting components after the initial compromise.

This layered approach is significant. Instead of placing the final espionage implant directly onto a machine, attackers divide the intrusion into stages.

One component establishes access.

Another prepares the environment.

A trusted application performs DLL sideloading.

A loader decrypts the next payload.

A second-stage component handles persistence and privilege operations.

Finally, the CoolClient implant is deployed and the kernel driver provides another layer of stealth.

This architecture makes attribution and detection more difficult because defenders may encounter only one piece of the overall infection chain during an investigation.

Fake Windows Defender Files Add a Layer of Deception

One of the most interesting aspects of the campaign is the abuse of familiar Windows security naming conventions.

Before deploying the malware, attackers reportedly create Microsoft Defender exclusions for a directory designed to resemble a legitimate Defender installation location.

The malicious files can then be copied into a path such as:

C:Program FilesMicrosoftWindows Defender

The directory name itself is not proof of legitimacy, but it creates an opportunity for attackers to blend malicious artifacts into an environment where investigators may initially expect security-related files.

The attackers reportedly also use an executable named defender.exe.

That name is particularly deceptive because filename-based investigations can easily become unreliable when adversaries deliberately select names associated with trusted operating-system components.

Legitimate Sangfor Software Becomes the Sideloading Vehicle

The campaign reportedly abuses a legitimate Sangfor application, commonly referenced as Sang.exe, by renaming it to defender.exe.

When the trusted executable is launched, it can load a malicious DLL named libngs.dll.

This is a classic example of DLL sideloading.

The attacker does not necessarily need to make the legitimate executable itself malicious. Instead, the trusted application becomes the mechanism through which an attacker-controlled library is loaded.

That distinction matters for defenders.

A security team that focuses only on whether an executable is digitally signed may miss the fact that a legitimate executable has been placed alongside a malicious library.

The stronger detection strategy is behavioral: examine which DLLs are loaded, where those DLLs originate, what processes load them, and whether the executable normally appears in that location.

The Loader Keeps the Next Stage Out of Sight

The reported CoolClient infection chain contains multiple files with deliberately misleading names.

The legitimate Sangfor program acts as the sideloader.

libngs.dll acts as the first-stage loader.

The loader decrypts another component, reportedly loadcert.ini, directly in memory.

This is an important defensive detail because traditional file-scanning approaches can become less effective when the next-stage payload is decrypted and loaded without being stored conventionally on disk.

The second-stage component reportedly handles several high-value tasks, including persistence, privilege checking, process injection, driver deployment, and loading the final CoolClient implant.

In other words, the attacker is not simply dropping one executable and waiting for it to run.

The malware is constructing an execution environment designed to survive, escalate, inject, and conceal.

Process Injection Adds Another Layer of Confusion

The malware reportedly injects itself into a process named synchost.exe.

The name is notable because it resembles the legitimate Windows process svchost.exe.

This is another example of how attackers exploit human expectations.

Security analysts often work under intense time pressure. During an incident, dozens or hundreds of processes may appear in telemetry. A process name that looks familiar can therefore receive less immediate scrutiny than an obviously suspicious executable.

This is why defenders should not rely on process names alone.

A suspicious synchost.exe should be evaluated according to its path, parent process, command line, digital signature, loaded modules, network behavior, privileges, creation time, and relationships with other suspicious artifacts.

Persistence Through Scheduled Tasks and Registry Entries

CoolClient reportedly establishes persistence through both a scheduled task and an AutoRun registry entry named goopdate.

Using multiple persistence mechanisms is strategically useful to an attacker.

If defenders remove one mechanism, another may restore the malware.

The scheduled task can reportedly launch the fake Defender executable as SYSTEM during startup, providing both persistence and a highly privileged execution context.

The registry-based persistence adds redundancy.

This is an important lesson for incident responders: deleting the obvious malicious executable is rarely enough.

A proper cleanup process should search for scheduled tasks, services, Run/RunOnce keys, startup folders, WMI persistence, drivers, and other mechanisms that could resurrect the infection.

CoolClient Can Also Become a Windows Service

The malware reportedly has another persistence path in which it installs itself as a Windows service named media_updaten.

The attackers appear to check whether security software from 360 Total Security is running before taking this route.

That conditional behavior suggests that the malware is capable of adapting its installation process according to the defensive environment it encounters.

This is another reason endpoint telemetry should be correlated rather than examined in isolation.

A newly created service is not necessarily malicious.

A newly created service appearing alongside a suspicious executable, unusual DLL sideloading, abnormal registry modifications, process injection, and an unsigned or suspicious driver is a very different situation.

Privilege Escalation Makes the Attack More Dangerous

The supplied research also describes the use of an RPC-based UAC bypass technique combined with parent process ID spoofing.

The objective is to make an elevated CoolClient process appear to have originated from a trusted Windows process.

Parent-process relationships are valuable forensic evidence. Manipulating them can therefore make an investigation more complicated.

For defenders, this reinforces an important principle: process ancestry should be treated as evidence rather than unquestionable truth.

Security telemetry should ideally correlate process creation with token information, integrity levels, executable paths, signatures, command lines, user context, and kernel telemetry.

The Kernel Driver Changes the Game

The most significant development is the deployment of a signed kernel driver identified as msagent.sys.

After obtaining sufficient privileges, CoolClient reportedly extracts and installs the driver, registers it as a service, and loads it into the Windows kernel.

The malware then communicates with the driver using DeviceIoControl, commonly abbreviated as IOCTL.

This is the point where the campaign moves beyond conventional user-mode malware.

A kernel driver has substantially greater access to the operating system than an ordinary application. If abused, that access can be used to manipulate or conceal information from security tools and investigators.

The presence of a suspicious kernel driver should therefore be treated as a high-priority incident-response signal.

Three IOCTL Operations Provide the Rootkit With Its Instructions

The reported rootkit uses three particularly important IOCTL operations.

One reportedly registers the CoolClient process as trusted.

Another provides the driver with the configured C2 IPv4 address.

A third sends filesystem paths and registry locations that the driver should protect or hide.

That final capability is especially concerning because it connects the kernel component directly to the malware’s concealment strategy.

Instead of simply hiding a process, the rootkit can reportedly receive specific information about what the attacker wants concealed.

This creates the possibility of a highly targeted stealth mechanism rather than a generic rootkit.

Why Hiding C2 Infrastructure Matters

Command-and-control infrastructure is one of the most valuable pieces of evidence available to defenders.

If an infected machine repeatedly communicates with an unusual IP address or domain, defenders can block the destination, identify other infected systems, pivot through network telemetry, and potentially uncover the broader campaign.

A rootkit designed to hide C2-related artifacts attacks that investigative advantage directly.

The result is a frustrating defensive scenario: the network may still contain malicious communications, but the endpoint may provide fewer obvious artifacts explaining why those communications exist.

This makes network-level visibility increasingly important.

Signed Does Not Automatically Mean Safe

The use of a signed kernel driver deserves particular attention.

Digital signatures are an important security mechanism, but defenders should never interpret “signed” as synonymous with “trusted.”

Attackers have repeatedly attempted to abuse legitimate drivers, vulnerable signed drivers, stolen certificates, and other mechanisms that allow code to operate with elevated trust.

A mature security program therefore evaluates kernel drivers according to provenance, installation context, expected software relationships, hashes, certificates, loading behavior, and endpoint prevalence.

An unexpected driver appearing shortly before suspicious process activity deserves investigation regardless of whether Windows accepts its signature.

The Infection Chain Is Built Around Trust

One of the strongest themes in this campaign is trust abuse.

The attackers reportedly abuse a legitimate application.

They use names resembling Microsoft Defender components.

They create a path that looks security-related.

They use a process name resembling svchost.exe.

They establish a scheduled task capable of running as SYSTEM.

They use a signed kernel driver.

None of these techniques depends entirely on exploiting a single software vulnerability.

Instead, the attackers manipulate assumptions.

That is what makes the campaign particularly instructive for defenders.

Deep Analysis

What Defenders Should Investigate First

Incident responders should begin by identifying unusual kernel drivers, suspicious services, scheduled tasks, and recently created executables.

Useful defensive commands include:

Get-CimInstance Win32_SystemDriver |
Select-Object Name, State, StartMode, PathName

This can provide an initial inventory of installed system drivers.

Security teams can also inspect Windows services:

Get-CimInstance Win32_Service |
Select-Object Name, State, StartMode, StartName, PathName

Scheduled tasks deserve attention as well:

Get-ScheduledTask |
Select-Object TaskName, TaskPath, State

For registry-based persistence, defenders can review common AutoRun locations:

Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run"
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run"

These commands are defensive discovery examples. They should be used as part of an authorized investigation rather than as a substitute for a full endpoint-security platform.

Hunting for Suspicious Driver Installation

Security teams should specifically investigate unexpected references to:

msagent.sys

media_updaten

goopdate

defender.exe

libngs.dll

loadcert.ini

cert.ini

synchost.exe

A filename alone should never be treated as conclusive evidence.

Instead, investigators should correlate each artifact with:

File path

SHA-256 hash

Digital signature

Signer certificate

Creation timestamp

Parent process

Process command line

Loaded modules

Network connections

Service registration

Registry persistence

Scheduled-task creation

Examining File Hashes

The supplied indicators include the following MD5 values associated with msagent.sys:

2d7c8780e97409770a9d4f31c66c9d63

9460E150E1981D5C165043520C5C12FE

Because MD5 is cryptographically weak, defenders should not rely on MD5 alone.

Where possible, calculate and hunt for stronger hashes such as SHA-256:

Get-FileHash "C:\Path\To\msagent.sys" -Algorithm SHA256

The resulting hash can then be compared against trusted internal inventories and authorized threat-intelligence platforms.

Hunting for DLL Sideloading

A useful detection strategy is to identify trusted executables launching from unexpected directories.

For example, defenders can investigate:

Get-Process |
Select-Object Id, ProcessName, Path

For deeper investigations, endpoint telemetry should be used to identify processes that load DLLs from unusual locations.

The key question is not simply:

Is Sang.exe legitimate?

The better question is:

“Why is this legitimate executable running from this directory, and why did it load this particular DLL?”

That distinction can expose sophisticated sideloading attacks.

Investigating Network Behavior

Even when endpoint artifacts are hidden, network activity can reveal the compromise.

Security teams should hunt for:

Unexpected outbound IPv4 connections

Rare external destinations

Long-lived connections from unusual processes

New C2 destinations

Connections originating from SYSTEM processes

Network activity associated with suspicious services

Defenders should correlate network events with process IDs whenever their telemetry supports it.

If an unusual connection is associated with a process that also loaded an unexpected DLL or recently installed a driver, the confidence of the investigation increases dramatically.

Why Kernel-Level Visibility Matters

Traditional user-mode monitoring has limits when an attacker operates from kernel space.

Organizations with high-value Windows environments should therefore consider telemetry capable of identifying:

Driver loading

Kernel callbacks

Driver-service creation

Code-integrity events

Unexpected kernel modules

Process injection

Credential-access behavior

Tampering with security controls

Windows event logs, Microsoft Defender telemetry, EDR platforms, Sysmon, and SIEM correlation can all contribute to this picture.

No single telemetry source should be expected to catch a sophisticated rootkit by itself.

What Makes This Campaign Particularly Concerning

HoneyMyte’s reported approach combines several mature techniques into one infection chain.

It begins with an established espionage framework.

It uses legitimate software for execution.

It disguises malicious files using trusted security-product naming.

It creates redundant persistence.

It performs privilege escalation.

It injects into a process with a deceptive name.

It deploys a kernel driver.

And it provides the driver with information needed to conceal selected artifacts.

Each individual technique has defensive countermeasures.

Together, however, they create a much more difficult investigation.

What Organizations Should Do Now

Organizations should begin by auditing unexpected kernel drivers across Windows endpoints.

Security teams should compare installed drivers against approved software inventories and investigate anomalies in both filename and installation context.

They should also review Defender exclusions, particularly newly created exclusions involving directories that resemble Microsoft security-product locations.

Unexpected exclusions should receive immediate attention.

Scheduled tasks and services created around the same time as suspicious binaries should also be investigated.

Organizations should strengthen DLL sideloading detections by monitoring trusted executables launched from unusual directories.

Finally, network monitoring should remain a critical line of defense because endpoint concealment does not necessarily eliminate the underlying C2 traffic.

Incident Response Priorities

If msagent.sys or closely associated artifacts are discovered, organizations should avoid immediately assuming that deleting the file constitutes remediation.

Kernel-level malware can alter the reliability of information obtained from the compromised operating system.

The affected machine should therefore be isolated according to the organization’s incident-response procedures.

Investigators should preserve relevant forensic evidence before destructive remediation where appropriate.

Credentials potentially exposed by the malware should be assessed for rotation.

Other systems should be searched for the same artifacts and behavioral indicators.

Most importantly, defenders should investigate the initial access vector, because removing the rootkit without closing the original intrusion path can simply create an opportunity for reinfection.

What Undercode Say:

HoneyMyte’s CoolClient evolution is a reminder that advanced espionage malware does not need to reinvent every component to become significantly more dangerous.

The important change here is the move toward kernel-level concealment.

CoolClient already had a substantial collection of surveillance capabilities.

The rootkit gives those capabilities a deeper defensive challenge.

The campaign also demonstrates why trusted software can become an attacker’s greatest weapon.

The legitimate Sangfor executable is reportedly turned into a delivery mechanism rather than being directly modified into obvious malware.

That approach can bypass simplistic application-based assumptions.

The fake Defender directory is another example of psychological deception applied to filesystem analysis.

A directory containing “Windows Defender” in its name should never automatically be considered trustworthy.

Security teams need to verify provenance, signatures, hashes, and execution relationships.

The use of defender.exe demonstrates how attackers exploit familiar naming conventions.

Human analysts are susceptible to visual familiarity, especially during high-pressure incident response.

The synchost.exe naming technique reinforces the same lesson.

Small differences in filenames can matter enormously.

This is why process-path analysis should be standard practice.

Persistence redundancy is another major concern.

A scheduled task and a Run key can provide overlapping survival mechanisms.

A Windows service provides yet another route.

Attackers are effectively building a recovery system for their malware.

Removing one component may therefore accomplish very little.

The kernel driver is the centerpiece of the evolution.

Once malicious functionality reaches kernel space, defenders face a fundamentally different visibility problem.

The ability to communicate through IOCTLs gives the user-mode malware a structured interface to the driver.

More importantly, the driver reportedly receives C2 and hiding instructions.

That suggests the rootkit is not merely present for prestige.

It serves an operational purpose.

The capability to hide selected registry and filesystem locations could interfere with traditional forensic workflows.

That makes offline or trusted-environment analysis particularly important during serious investigations.

The campaign also reinforces the importance of network telemetry.

If endpoint visibility becomes unreliable, network evidence becomes even more valuable.

C2 destinations, DNS activity, connection timing, TLS metadata, proxy logs, and firewall records can help reconstruct activity from outside the compromised host.

Another lesson concerns digital signatures.

A signed driver should inspire investigation of its provenance rather than immediate trust.

Security teams need to know why a driver exists, what installed it, what software depends on it, and whether the driver belongs on that particular machine.

The broader trend is unmistakable.

Attackers increasingly combine legitimate software, living-off-the-land techniques, process injection, persistence, and privileged components rather than relying on one obviously malicious executable.

Defenders should respond in kind.

Detection must become behavioral and contextual.

A suspicious file is useful evidence.

A suspicious file combined with an unexpected service, a new scheduled task, a Defender exclusion, unusual DLL loading, and outbound C2 traffic is far stronger evidence.

The campaign also highlights the value of endpoint baselines.

If an organization knows which drivers, services, scheduled tasks, and security exclusions normally exist, deviations become much easier to identify.

Rootkits remain especially dangerous because they attack visibility itself.

The defender is not merely trying to remove malware.

The defender is trying to determine whether the evidence being presented by the operating system can still be trusted.

That is why kernel-level incidents deserve a higher level of forensic caution.

Organizations protecting government systems, critical infrastructure, research environments, and sensitive corporate data should treat unexpected kernel-driver installation as a serious security event.

HoneyMyte’s reported evolution of CoolClient ultimately sends a simple message:

The next generation of espionage malware will increasingly compete not just for access to systems, but for control over what defenders are allowed to see.

✅ HoneyMyte Is Also Known as Mustang Panda

The supplied article identifies HoneyMyte and Mustang Panda as names associated with the same threat actor.

This attribution is consistent with widely used cybersecurity reporting terminology.

However, threat-actor naming can vary between security vendors, so analysts should preserve the source and confidence level of any attribution.

✅ CoolClient Has Espionage Capabilities

The described functionality includes keylogging, clipboard collection, credential harvesting, file operations, reconnaissance, and extensibility.

These capabilities are consistent with the role of a remote-access espionage implant.

The precise capabilities available in a particular campaign can vary depending on the malware build and plugins deployed.

✅ The Campaign Uses DLL Sideloading

The supplied research describes a legitimate Sangfor executable being used to load a malicious libngs.dll.

That is a classic DLL-sideloading pattern in which a trusted executable becomes the execution vehicle for an attacker-controlled library.

Defenders should therefore investigate DLL loading behavior rather than relying solely on executable signatures.

✅ The Reported Attack Uses a Kernel Driver

The article identifies msagent.sys as the kernel-mode component.

The reported use of IOCTL communication between CoolClient and the driver is technically consistent with how Windows applications communicate with kernel drivers.

The exact rootkit capabilities should nevertheless be validated against the original threat-research evidence before being treated as universally present in every CoolClient sample.

❌ A Signed Driver Should Not Automatically Be Considered Safe

A digital signature does not prove that a driver is appropriate for a particular endpoint.

A legitimate certificate can be abused, compromised, or attached to software being used maliciously.

Context, provenance, behavior, and cryptographic identification remain essential.

⚠️ Filenames Alone Are Not Indicators of Compromise

Names such as defender.exe, synchost.exe, and media_updaten can be suspicious in the context described here.

They should not, however, be treated as definitive proof of compromise.

Legitimate software can occasionally use similar names, which is why path, hash, signer, parent process, timestamps, and behavior should be correlated.

Prediction

(+1) Kernel-Level Evasion Will Become a Bigger Enterprise Security Priority

The most likely direction is greater investment in kernel-level telemetry, driver-control policies, application control, and behavioral detection.

As attackers increasingly attempt to hide inside trusted Windows processes and privileged components, security products will have to observe deeper layers of the operating system.

Organizations that continue relying primarily on traditional antivirus signatures may struggle against highly customized espionage implants.

The strongest defensive posture will combine endpoint telemetry, kernel-driver monitoring, network analytics, identity protection, application allowlisting, and disciplined incident-response procedures.

The evolution of CoolClient illustrates why cybersecurity is becoming less about recognizing a single malicious file and more about understanding an entire chain of suspicious behavior.

For defenders, the goal is not simply to find the malware.

It is to detect the attacker before the attacker can control what the defender sees.

▶️ Related Video (86% Match):

🕵️‍📝Let’s dive deep and fact‑check.

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

References:

Reported By: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.linkedin.com
Wikipedia
OpenAi & Undercode AI

Image Source:

Unsplash
Undercode AI DI v2

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeNews & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube