“If a driver is signed, can we trust it?” That question is now less rhetorical than it once was, after security researchers reported a kernel-mode driver with a valid signature being used to install a new variant of a backdoor in a mid‑2025 intrusion attributed to the Chinese threat group Mustang Panda. Kaspersky, which uncovered the campaign, says the attacker delivered TONESHELL via a previously undocumented signed rootkit targeting an unnamed organization in Asia.
The immediate dilemma is stark: code signing historically indicates provenance and a degree of trust, yet here that very signal was repurposed as a covert avenue into the deepest layers of Windows. Kernel-mode drivers run with the highest privileges on a system; once loaded, they can disable defenses, hide activity, and make forensic collection and remediation exponentially harder. Evidence gathered by defenders of earlier campaigns shows signed drivers are an attractive shortcut for adversaries seeking durable access and stealth, and the Mustang Panda episode fits that pattern .
Background first. Mustang Panda (also tracked under names such as Bronze Presidente and RedDelta in some reporting) has long been linked to espionage-style operations focused on Asia and beyond. The new campaign, disclosed in December 2025 by Kaspersky and covered by The Hacker News, combines an unsigned or novel backdoor family labeled TONESHELL with a signed kernel driver acting as a rootkit loader. That pairing is of particular concern because the signed driver can neutralize user‑mode protections and create a stealthy foothold for follow‑on tooling.
Technically, the risk arises from a simple but powerful property: a valid digital signature proves who published a binary, not that the binary is safe or cannot be abused. Attackers can exploit vulnerable or compromised signed drivers—either by repurposing legitimate vendor drivers with flaws or by using stolen signing certificates—to gain kernel access without developing a complex zero‑day exploit. Once in kernel space, they can manipulate process memory, intercept kernel APIs, and blind endpoint defenses, making detection and removal significantly more difficult .
What does this mean in practice? For defenders, the incident echoes playbooks seen in other campaigns where signed drivers precede full remote‑access tool deployment. In some historical intrusions, adversaries followed driver loading with RAT families that provided command execution, credential theft, lateral movement, and persistent control. The signed driver thus serves both as a scalpel that pares away defenses and as a staging ground for more damaging operations. Practical guidance developed from those incidents stresses that signatures alone are not a silver bullet: behavioral monitoring, kernel telemetry, and strict driver installation policies are essential complements to signature checks .
Policy implications are broad and politically fraught. Platform owners and certificate authorities face pressure to tighten driver attestation, improve provenance tracking, and accelerate revocation when signing keys are misused. Yet strengthening those controls involves trade‑offs: tighter restrictions can introduce compatibility headaches for vendors and enterprises and may slow the release of legitimate updates. Regulators and standards bodies will need to weigh security gains against operational friction, and international cooperation will be required to disrupt markets for stolen signing material and abuse channels .
From a technologist’s perspective, the takeaways are concrete: enforce whitelisting for drivers, extend monitoring into kernel space, prioritize incident playbooks that assume trusted components may be weaponized, and engage vendors proactively to reduce windows of exposure. For policymakers, the challenge is designing incentives and standards that improve vetting and disclosure without stifling innovation. For everyday users and many administrators, the message is one of awareness—kernel compromises are rare but consequential, so organizations should invest in layered defenses and readiness rather than relying solely on signature validation.
Adversaries, too, face strategic calculations. Abusing signed drivers lowers the bar for stealthy kernel access, but it also creates a reproducible pattern defenders can hunt for—anomalous driver loads, unusual kernel API usage, and post‑load behaviors consistent with privilege escalation and persistence. Making abuse costlier and noisier through improved telemetry, faster revocation of compromised keys, and coordinated vendor response complicates adversary operations and raises their operational cost .
So where does this leave us? The Mustang Panda use of a signed kernel rootkit to deliver TONESHELL is a reminder that trust markers—like signatures—are necessary but not sufficient. It underscores the need for layered detection, supply‑chain diligence, and policy measures that improve attestation and accountability without unduly disrupting legitimate software ecosystems. As defenders harden one vector, adversaries will shift to another; the enduring solution will be a mix of better engineering, smarter telemetry, and coordinated governance.
In the end, the question hangs in the air: when the mechanisms we built to tell truth from falsehood can be turned against us, how do we rebuild trust in a way that is both secure and sustainable?
Source: https://thehackernews.com/2025/12/mustang-panda-uses-signed-kernel-driver.html
