In June 2026, Symantec Carbon Black's Threat Hunter Team published a breakdown of how Hackledorb, the cluster behind DragonForce ransomware, spent one to two months inside a major U.S. services firm. Before deploying ransomware, before killing a single security process, the operators loaded four kernel-mode drivers in sequence. Three had documented CVEs. The fourth, a Huawei audio driver the operators named "Havoc Process Terminator," had no known vulnerability at all when they deployed it.
A note on tracking names. Symantec Carbon Black tracks this operator as Hackledorb; Trend Micro calls the same group Water Tambanakua. "DragonForce" refers to the broader ransomware cartel; multiple operators run attacks under that brand. Origin remains unconfirmed: Intel 471 notes the main operator posts in Russian on cybercrime forums; a suggested Malaysia connection traces to a separate hacktivist group that denied any link in early 2024.
What a Microsoft driver certificate actually checks
Every driver that loads on modern Windows must carry a valid Microsoft signature. That requirement is real.
What it checks: that the driver came from a vendor who went through Microsoft's certification process and that the binary hasn't been tampered with. What it does not check: whether the driver contains security vulnerabilities. That was never the purpose of the gate.
A kernel signature is provenance trust: it tells you who shipped the code. It is not a guarantee that the driver cannot be exploited.
Bring Your Own Vulnerable Driver (BYOVD) is what happens when an attacker exploits that gap. They load a legitimate, signed driver with a known security flaw, use that flaw to disable security software, then proceed with the attack. Windows sees a valid signature and loads the driver normally. The event log records a routine installation. Nothing looks wrong.
The same library, two campaigns
This campaign is not an outlier.
In June 2026, ESET published research on GentleKiller, a BYOVD framework that a second ransomware group distributes to affiliates as standard pre-attack tooling. It uses signed drivers from multiple legitimate vendors to kill security tools from 48 vendors, including Defender, CrowdStrike, SentinelOne, and Sophos. ESET confirmed 478 victims across more than 70 countries.
Both campaigns used a Huawei audio driver. In the December 2025 campaign, that driver had no documented vulnerability when the operators deployed it. Huntress published their analysis three months later, after the attack.
The driver library spans a game studio, a security product vendor, an audio hardware manufacturer, and a fraud prevention company. These are legitimate businesses that shipped signed code and had no involvement in what happened next. The signing pipeline validated each driver at release and kept validating them after vulnerabilities were found.
The blocklist can't block what hasn't been found yet
Microsoft maintains a vulnerable driver blocklist. Enforced and up to date, it works.
The problem is timing. A driver gets added after it appears in an attack, after a CVE is filed, after the campaign generates enough visibility. In the December 2025 attack, three drivers had documented CVEs that hadn't made the blocklist. The Huawei driver had no CVE at all.
This is not a process failure. It is a structural constraint. The blocklist is reactive. Attackers work in the gap between when a vulnerability can be exploited and when the defense catches up.
The one detection window
There is one moment a defender can catch a BYOVD attack before the security tools are killed.
When a driver loads as a Windows service, Windows logs Event ID 7045. This event fires while security tools are still running, before the kill sequence begins. Monitoring those logs for driver installations outside your normal baseline gives you a window to act.
Once the kill sequence runs, that window closes.
A structural fix also exists: enabling Memory Integrity (also called HVCI) enforces a stricter driver policy that blocks this technique before it starts. Most enterprise environments haven't enabled it. It requires hardware support and compatibility testing that many organizations haven't completed. The fix exists. Deployment lags.
What the certificate doesn't cover
Code signing tells you who shipped the driver. It does not tell you whether someone else can exploit it years later.
The two campaigns together draw from a library spanning gaming, cybersecurity, hardware, and enterprise software. Legitimate vendors with valid signatures, all available to any attacker who finds the right flaw.
BYOVD does not break the Windows kernel signing system. It uses it.
Blocklisting after weaponization is the reactive approach. Memory Integrity (HVCI) is the structural fix. Until it is deployed more widely, hunting Event ID 7045 for anomalous driver loads is where the practical detection work sits.
Detection isn't broken. It's incomplete.
Vectra AI operates at the network layer, not the endpoint, so the kill sequence described here doesn't affect it. If you want to go deeper on how network-based detection fits alongside endpoint and identity controls across all three gaps, the Mind Your Attack Gaps ebook covers the full architecture.