Bring Your Own Vulnerable Driver: The Trust Gap Attackers Operate Inside

Bring your own vulnerable driver (BYOVD) is having a moment in endpoint security. Some of the buzz is earned. Some of it is overblown. This series unpacks both and shows the evidence for each. This piece weighs the trust gap the technique exploits against what the data actually shows.

A long-revoked certificate still loads a driver into the Windows kernel today. Help Net Security traced a 2026 intrusion to a decade-old forensic driver whose signing certificate had expired and been revoked years earlier. The kernel loaded it anyway.

The reason is structural, and it explains why the defensive target most teams chase is the wrong one. Defenders track bad drivers. We pull the LOLDrivers catalog, sync the default driver blocklist, and watch the list grow. The list is not where attackers compete. They compete over signing trust. A signature is the scarce thing. A driver is just the disposable wrapper around it.

Trust Is the Scarce Resource and Drivers are Disposable

Think about a stolen credit card. The number keeps clearing for hours or days in the gap before merchant blocklists sync. The thief does not need a new card. They need the window where the old one still works. Card networks did not win by perfecting the blocklist. They won by scoring the transaction itself in real time, regardless of whether the number was flagged yet.

Signed drivers run on the same broken model. The blocklist is the merchant blocklist. The signature is the card. Attackers live in the propagation gap, and that gap is wide.

The defensive move that follows is to stop chasing the card numbers and instrument the transaction. This is the reframe no competitor owns. Defend the trust anchor, because the list will always trail it. The anchor is the signing trust itself: revocation, signature metadata, and the slow death of cross-signed-driver trust. A list of bad drivers grows forever. The set of trust mechanisms that let those drivers load is small and addressable.

The web learned this lesson the hard way already. Online Certificate Status Protocol (OCSP) soft-fail meant a browser that could not reach the revocation responder simply trusted the certificate anyway. The kernel driver model carries the same flaw in a harsher setting. There is no soft-fail to debate, because the kernel does not ask the question at all.

The Proof Is In the Certificates

The economics favor the attacker because trust concentrates. Public threat research found a single GitHub PFX file holding more than a dozen expired certificates, drawn from the 2015 Hacking Team leak and Chinese forums. That one file forged signatures on thousands of malicious drivers.

A small set of compromised keys signs an unbounded supply of drivers. A few stolen keys against thousands of drivers means the list defenders maintain can never catch up. Block a driver and the cost is one recompile. Edit unauthenticated bytes, the file hash changes, and the same key signs a new artifact. The blocklist entry you just earned is already stale, because the signing key did not move and the key is the asset. SentinelOne®'s latest Annual Threat Report documents loaders that reintroduce effectively the same payload under fresh hashes to outpace simple hash-based blocking.

The trust-pyramid framing from that research describes a real structure. At the base sit individual drivers, cheap and disposable. Above them sit the end-entity certificates that sign batches of drivers, and at the apex sit the cross-signed certificate authorities the kernel anchors to. An attacker who climbs one level multiplies their reach across everything below it, and defenders who fight at the base are fighting where the attacker has infinite supply.

The same research showed how attackers manufacture fresh trust on demand. Tools forge signature timestamps, exploiting the pre-July-29-2015 cross-signed certificate exception by backdating a signature so it appears to predate the cutoff. An expired or revoked certificate becomes a working signing key again. The forgery does not break the trust chain. It satisfies it.

The kernel makes this worse by refusing to check revocation. Windows loads drivers signed with revoked certificates even when a local revocation list is present, and the decade-old forensic driver case showed the same failure in 2026. The operating system's kernel-mode signing policy accepts end-entity certificates issued before July 29, 2015 if they chain to a cross-signed authority. The policy codifies the loophole rather than closing it.

The defensive consequence follows directly. Blocking expired and revoked certificate driver loads, paired with the blocklist, beats the blocklist alone. The blocklist enumerates known-bad files one at a time. Revocation enforcement attacks the reusable key behind all of them, scaling against the attacker instead of with them.

A certificate authority revokes a key when it learns the key is compromised, and in a working system every consumer checks the revocation list and refuses the key. A revoked certificate carries a clear instruction, do not trust anything this key signs, and the kernel loads the driver anyway. The attacker did not defeat the trust system. They used the part of it that was never enforced.

The Driver Persistence Half-Life

Now the data. Against the LOLDrivers catalog, roughly one-third of catalogued vulnerable driver samples are not covered by the default blocklist. The June 19, 2026 pull puts it at 36 percent. That is 782 of 2,190 samples, absent from the default list. About 22 percent, 479 samples, load even with Hypervisor-Protected Code Integrity (HVCI) enabled.

Call this the Driver Persistence Half-Life, the signature data point of this argument.

Be honest about what that number is. The 36 and 22 percent figures are point estimates from a single computed pull against one blocklist version. The method is published and reproducible: parse the enforced HVCI SiPolicy and the official block rules against the LOLDrivers JSON, match by file hash, then by authenticode metadata, and pin both to a commit and a version.

The caveats matter. The denominator is the LOLDrivers catalog, not every driver that exists. "Not covered" means absent from the default block rules, not exploitable on a given host. Hash coverage is brittle, because an edit to unauthenticated bytes changes the hash without changing the abuse.

The corroboration is real, and it is fewer voices than it looks. The catalog's own coverage metrics report that many LOLDrivers entries sit off the default blocklist, and public threat research corroborates the cadence qualitatively, confirming that systems can be attacked with a driver not yet listed. Two open tools reproduce the check itself, Trail of Bits' HVCI-loldrivers-check and a community block-rules checker, but no genuinely independent second count of the exact figures exists yet.

The lag underneath the number is the real exposure. The default blocklist updates only periodically through Windows Update, roughly once or twice a year, and deliberately holds back some blocks to avoid breaking legitimate software. The minimum disclosure-to-block window is a calendar quarter, and the historical window has run to six months or more. Most of these vulnerable signed drivers are reachable without admin rights, so the exposure is wide and the door is low.

The on-device reality runs worse than the stated cadence. Public reporting documented a Windows 10 driver blocklist frozen at a December 2019 version until an October 2022 fix. That is a roughly three-year gap between the published cadence and what shipped on the machine. A defender reading the cadence would assume quarterly freshness. The endpoint disagreed for three years.

Per case, persistence runs to years. SentinelLABS disclosed Dell's dbutil_2_3.sys flaws in 2021, and the signed-but-vulnerable driver was still disabling security tooling in 2024. SentinelLABS noted that the driver's certificate had not been revoked, leaving it abusable long after disclosure.

The half-life metaphor is precise. The catalog grows faster than the blocklist can absorb it, so the gap widens rather than closes, a long, slow decay that the attacker schedules around.

The method is reproducible against your own fleet. Run the same hash and authenticode match against the drivers that actually load, and the result is a number that describes your real exposure, a measurement you can repeat each quarter. The durable claim stays the honest one: roughly one-third of catalogued vulnerable drivers are not blocked by default. The precise 36 and 22 percent belong to one computed pull, a snapshot with a published method attached.

Blocking Everything Breaks the Business

The obvious fix is to block every old driver. That fix is impractical, and the platform's own documentation says so plainly: the blocklist "isn't guaranteed to block every driver," and blocks are held back precisely to avoid breaking functionality.

Vulnerable drivers are dual-use. Public threat research catalogued how most abused drivers ship as legitimate software components first. The same signed driver that disables an EDR this week was a working hardware utility last week. The blocklist maintainer weighs one confirmed abuse against tens of thousands of working installs. The hold-back is a rational choice under that math, and the exact gap the attacker schedules into.

The reboot gap makes the DIY approach worse. Independent analysis of the blocklist notes that a driver the policy would block keeps running until the next reboot, so an in-progress kill chain survives the moment you activate the policy. The attack surface reduction (ASR) rule that blocks vulnerable signed drivers only stops a driver from being written to disk. It does not block one already present from loading. Defenders who think they have closed the gap have often only narrowed the entry path.

The platform is moving the trust anchor. A Windows security update in April 2026 removes default trust for cross-signed kernel drivers, directly targeting the loophole the timestamp-forgery and pre-2015 exceptions opened. This is the industry bending toward the right target, attacking the reusable signing key itself, which is the correct altitude.

It helps. It does not close the gap. The April change applies to default trust going forward, so the 36 percent that sit off the blocklist today are not retroactively addressed by changing tomorrow's trust rules. The half-life keeps running on the inventory that already exists.

A separate chokepoint also remains in play. Public threat research documented one EDR killer used by multiple ransomware gangs whose coordination point was a shared packer-as-a-service, with no shared driver tying them together. The packer became the chokepoint when the driver did not. That is the pattern to internalize. Each fix narrows one path and exposes the next. Tighten cross-signed trust and the attacker leans harder on forged timestamps. Close the timestamp loophole and they lean on the unsynced backlog. The trust model has many anchors, and the attacker only needs the cheapest one still standing.

This persistence is not an accident of the technique. It is the product of an industry on the other side. SentinelOne's latest Annual Threat Report describes the industrialization of the modern cyber breach, with mature automation accelerating intrusions at scale. A trust gap that one researcher could exploit becomes one that a tooled-up criminal market exploits at volume, which is why the half-life persists across so many drivers at once.

This piece builds on prior work. Independent security research argued that admin-to-kernel is not a serviced security boundary and that blocklists are largely performative. That critique is correct and it stands. The contribution here is a measured persistence half-life, the certificate-concentration evidence behind it, and a trust-anchor reframe detection engineers can act on.

Stop Chasing the List. Instrument the Failure.

The card networks made the stolen number unprofitable by scoring the transaction. Defenders should do the same with signed drivers. Watch the trust event, because the catalog entry arrives too late to matter.

That means instrumenting the load itself. Sysmon Event ID 6 logs every driver load with its hash, signer, signature, and signature status, and any non-Valid status warrants investigation. This telemetry is low-volume and high-value, which makes it cheap to monitor and hard to flood. The Splunk detection content keys on exactly this event, with an explicit note that the alert needs triage rather than blind firing.

Signature-status detection and first-seen anomaly detection catch what blocklist matching misses. Alert on any driver load whose signature status is not Valid, including untrusted root, explicit distrust, and bad or invalid signatures, and on any driver whose hash, signer, or version has never been seen on the host before. Both approaches key on the trust attribute, so the known-bad list never enters the decision and the alert fires whether or not anyone has catalogued the driver yet.

The CodeIntegrity Operational log confirms whether your blocklist policy actually applied. Event ID 3099 confirms the policy is loaded, a blocked load logs Event ID 3077, an audited load logs Event ID 3076, and Event ID 3089 carries the signature detail. Pairing the block events with the audit events proves which drivers the policy stopped, which turns coverage from an assumption into a measurement. Given the three-year staleness the frozen-blocklist case showed, that proof is not optional.

The behavioral chain is observable end to end. A service is created via sc.exe, logged as Sysmon Event ID 1, and a System Event 7045 fires for the service install. A driver loads under Event ID 6, then a device control call (IOCTL) drives termination against protected processes. Public threat research watched one such loop run a repeating, fixed-interval termination cycle in kernel mode, stepping past protected-process defenses (PPL), and recent killers also unregister EDR kernel callbacks as a distinct observable before terminating processes. Picus mapped the same sequence across cases. Each step is a tripwire on the trust event, and none of it depends on prior knowledge of the specific driver.

The order of the chain is what makes it durable. The driver name changes every campaign, but the structure does not. SentinelOne's latest Annual Threat Report makes the same point about the kernel: activity at that layer can blind user-space instrumentation and leave a manual disk scan an unreliable assurance of cleanliness. Detection keyed to that shape survives a recompile, and detection keyed to a hash does not.

The mental shift is the point. A driver list is a finite answer to an infinite problem, and the trust anchor is small, addressable, and already moving. SentinelLABS research has lived at that anchor for years. The team co-discovered the POORTRY and STONESTOP WHQL-signed toolkit that drove the security advisory ADV220005, and proposed Authenticode-metadata blocklisting before that was standard practice.

Defenders are not behind because the list is incomplete. They are behind because they were grading the wrong exam. Score the trust event, and the half-life stops being the attacker's advantage.

Why This Is the Work SentinelOne Exists To Do

Scoring the trust event instead of chasing the list is the whole argument, and it is the argument SentinelOne was built to win. The platform watches the load itself, the untrusted signature, the first-seen driver, and the masquerading kernel service, from a vantage designed to keep reporting when the kernel turns hostile. Purple AI® carries that telemetry forward. Its Agentic Investigation capability reasons over the trust event the moment it fires, builds the timeline, and renders a verdict in minutes and seconds rather than hours and days. The propagation gap the attacker lives inside narrows when the verdict arrives at machine speed.

A control you have not confirmed is running is a control you are only hoping for, and most teams cannot staff that verification around the clock. Wayfinder, SentinelOne's managed detection and response practice, holds the line when your own team is asleep, fusing human threat hunting with the platform's autonomous investigation and Google threat intelligence. That is the reason the company exists. The trust anchor is small and addressable, and the advantage goes to the defender who instruments it.

Next in this series: The practical hunts themselves, the four distinct techniques hiding inside the phrase EDR killer, and the telemetry that catches each one.

External References

1. EDR killer abuses a vulnerable forensic driver, Help Net Security. February 5, 2026.
2. LOLDrivers security metrics. loldrivers.io (MagicSword), Pull cited as June 19, 2026.
3. HVCI-loldrivers-check, Trail of Bits (GitHub: trailofbits/HVCI-loldrivers-check).
4. loldrivers-database, Community project (GitHub: didntchooseaname/loldrivers-database).
5. New EDR killer tool used by eight different ransomware groups, BleepingComputer. August 6, 2025.
6. EDR Killer Threat Advisory (AD-2025-018), Cyber Security Agency of Singapore. 2025.
7. Sysmon driver-loading (Event ID 6), TrustedSec Sysmon Community Guide.
8. Windows Vulnerable Driver Loaded, Splunk Security Content. 2026.
9. Windows Drivers Loaded by Signature, Splunk Security Content. 2026.
10. Qilin EDR Killer infection chain, SOC Prime. April 7, 2026.

IP Disclaimer:

This blog may include discussion of unreleased services or features. Any unreleased services or features referenced here are still in development and subject to change. Customers should make their purchase decisions based upon features that are currently available.