Ransomware crews and state actors converged on the same trick years ago, and it keeps working: instead of attacking the kernel, arrive with a driver the kernel already trusts. BYOVD — bring your own vulnerable driver — is not an exploit story. It is a trust-model story, and understanding it explains both why the technique is everywhere and why it dies to one well-enforced policy. We maintain an active research program on it; this note is the shape of that program, at category level. Candidate lists and working detail stay in the licensed material.
The trust model that breaks
Windows decides what may run in kernel mode primarily by signature, not by safety. A driver signed through the proper attestation pipeline is accepted as legitimate — because cryptographically, it is. The system has no built-in opinion about whether the signed code is good, only about whether it is authentic. Revocation exists, but it is slow, administratively painful, and historically it breaks real fleets of real hardware, so the ecosystem moves reluctantly.
Authentic is not safe. Signed is not trusted.
Now take a legitimately signed driver that exposes, through its normal device interface, a primitive it should never have given user mode: read or write of arbitrary kernel memory, mapping of physical memory, termination of arbitrary processes from ring 0. That driver is authentic. It loads. And whoever loads it inherits a vendor-signed kernel primitive — which is the entire trick. The classic use case is killing protected security processes from a level they cannot defend, but the primitive catalog is wider: credential store access, callback table edits, disabling the very telemetry layers from the previous note.
What our research program actually does
Four workstreams, continuously. This is the proprietary part of AXIS that customers ask about most, so here is the honest shape of it.
Harvesting. Signed drivers surface in predictable places: vendor update packages, OEM support bundles, old SDK samples that escaped into production, hardware utilities nobody has re-audited since release. We maintain a private corpus — 1,400+ signed drivers — and grow it mechanically: the supply of signed, under-audited kernel code has never once trended downward.
Static triage. Before any dynamic work, a candidate is classified by its dispatch surface: which request handlers are reachable from user mode, and whether any of them implement a dangerous primitive class — arbitrary virtual or physical memory access, model-specific register access, process or thread termination via kernel routines, handle or privilege manipulation, raw disk sector writes. Most drivers die here; the interesting minority moves on.
Exploitability rating. A primitive is not a capability. We rate survivors on three axes: reachability (who can open the device — device permissions decide whether the primitive needs admin or just luck), reliability (does the path hold across builds, or does it blue-screen every tenth machine), and detectability (is the hash already on public vulnerable-driver lists and the Microsoft blocklist — a known candidate is a burned candidate).
{
"candidate": "DRV-0847",
"signer": "OEM hardware utility, 2019",
"primitives": ["phys_mem_map", "proc_terminate"],
"reachability": "admin · device ACL: SYSTEM+Admins",
"reliability": "22H2–24H2 stable · 0/200 crashes",
"exposure": "public lists: absent · msft-blocklist: absent",
"score": "B+ — deployable, burns on first public use",
// rotting: vendor silently patched in 3.1.7 → pin the version
}
Lifecycle. Candidates rot. Signatures get revoked, blocklists get updated, vendors silently patch. The corpus is re-rated on a schedule, and a candidate's rating history matters as much as its current score: a driver that defenders just learned to catch is a liability wearing a costume.
Where this fits in the product
In licensed builds, BYOVD exists as an operator-selectable capability inside the builder: the operator picks from currently rated candidates, the artifact integrates the chosen driver, and the audit log records the selection like any other build decision — because in an authorized engagement, kernel-level action is a decision someone must be able to justify afterward. The same corpus powers our QA: every release is validated against current blocklist enforcement, so customers learn from us — not from a failed deployment — when the defensive landscape moves.
What actually stops it
The technique has a single point of failure, and it is policy, not signatures. The Microsoft vulnerable driver blocklist — enforced through Windows Defender Application Control and on by default where HVCI runs — refuses known-bad signed drivers regardless of their cryptographic validity. Ships of new hardware increasingly enforce this out of the box, and every enforcement event converts a "reliable" candidate into a detection. Attack Surface Reduction rules, driver-load auditing, and simple alerting on kernel service creation close most of what remains. Defenders have real leverage here; the uncomfortable truth for the offense side is that BYOVD's future is measured in how slowly enterprises turn these switches.
The honest limits
BYOVD requires the privileges to install and load a driver, which means the operator already holds administrator — it buys kernel primitives, not initial access. It is loud to any telemetry that watches driver loads, and every load is a forensic artifact with a hash. And it collapses entirely against enforced blocklists. It is a scalpel for engagements where kernel-level effect is worth a logged, justifiable decision — not an invisibility cloak, and we would be suspicious of any vendor who describes one that way.
Next in the queue: a field guide to common bypass techniques — what each one still costs you, and why single-trick implants age badly.