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.
Two columns: what a kernel signature checks (vendor identity, binary integrity) versus what it does not check (security vulnerabilities, future exploitability). What a kernel signature certifies ✓ What it checks Vendor identity The driver came from a named vendor who passed Microsoft's certification Binary integrity The file hasn't been tampered with since it was signed ≠ ✗ What it doesn't check Security vulnerabilities Whether the code contains flaws that can be exploited Future exploitability Whether someone finds a way to weaponize it years later
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.
Four legitimate vendors whose signed drivers were used as BYOVD weapons: Tower of Fantasy (gaming), Topaz Antifraud (security), K7 Security (security), and Huawei audio (hardware). All had valid Microsoft signatures. Three had documented CVEs that hadn't made the blocklist; the fourth had no CVE at time of attack. Four signed drivers. Four legitimate vendors. All valid Microsoft signatures. All used as weapons. GAMING Tower of Fantasy Gamedriverx64.sys CVE-2025-61155 ✓ Valid signature ✗ On blocklist in time SECURITY SOFTWARE Topaz Antifraud wsftprm.sys CVE-2023-52271 ✓ Valid signature ✗ On blocklist in time SECURITY SOFTWARE K7 Security K7RKScan.sys CVE-2025-1055 ✓ Valid signature ✗ On blocklist in time HARDWARE Huawei (audio) HWAuidoOs2Ec.sys No CVE at time of attack ✓ Valid signature ✗ CVE at attack time
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.
Timeline: vulnerability exists, CVE is assigned before the attack, attack happens while the driver is not yet on the blocklist, then the blocklist is finally updated. For three of four drivers in this campaign the CVE predated the attack; the real gap was between CVE and blocklist update. The blocklist can only block what's already been found Vulnerability exists CVE assigned Attack happens Blocklist updated CVE exists. Driver not yet on blocklist.
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.
Two-stage diagram: Event ID 7045 fires when the driver loads while security tools are still running. After the kill sequence those tools are gone and the detection window closes. The detection window in a BYOVD attack Stage 1: Driver loads Event ID 7045 fires here Security tools still running Defender, EDR, SIEM all active Detection window open kill sequence Stage 2: Security tools killed Defender, EDR, SIEM no longer running Logs still exist, but nothing acts on them Detection window closed
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.