Follow the Access · 16 — The Vulnerable Driver: Bringing a Signed Key to the Kernel

Follow the Access — Case 16. This register follows the intruder from the login prompt to the foothold's fate, and closes each case on what the access becomes: RANSOMED · MINED · PROXIED · HARVESTED · WIPED · RESOLD.

Most of this register has followed the way in — the doors, the credentials, the trusted channels an attacker uses to gain a foothold. This case follows the way down. Because once an attacker is inside, there is a hierarchy of depth to the access he can hold, and at the very bottom sits the deepest access a computer has: the kernel, the innermost core of the operating system that controls the hardware, governs every process, and — crucially — is the level at which the security software itself runs. An attacker who reaches the kernel does not merely have more privilege than the defender's tools; he operates at the same level as them, or below, which means he can turn them off. This case is about the technique that gets him there, and it is one of the more elegant in the register, because the attacker does not break the kernel's defenses. He walks through them carrying a key they were built to accept.

Windows protects the kernel with a strict rule: because drivers run in the kernel, they must be signed by a trusted vendor before Windows will load them. This is a good rule, and it stops an attacker from simply loading his own malicious driver. Bring Your Own Vulnerable Driver — BYOVD — defeats it not by forging a signature but by finding a driver that is genuinely, legitimately signed by a real hardware vendor, and that also happens to contain a serious vulnerability. The attacker brings this signed-but-vulnerable driver to the machine he has compromised, loads it — Windows accepts it, because the signature is real — and then exploits the flaw inside it to run his own code in the kernel. The signature that was supposed to guarantee the driver's safety instead guarantees the attacker's entry. He brought a legitimate key to a lock that only checks whether the key is real, not whether the door should open.

So the disposition is RANSOMED, because BYOVD's dominant purpose in criminal hands is to clear the last defense from the ransomware's path. From the kernel, the attacker can disable the endpoint-detection tools that are the defender's final hope of catching a hands-on intruder before he strikes. The crew kills the security software across the estate, and then — blind now, the defender — the crew encrypts everything, unopposed. This is the case about access to the kernel, bought with a signed key the attacker brought himself, and used to blind the watcher before the theft.

1. The Deepest Access, and Why It Matters

Begin with why the kernel is the prize, because the whole significance of BYOVD rests on what kernel access confers. A computer's software runs in layers of privilege. At the top, with the least privilege, are ordinary user programs. Below them, with more privilege, are administrative processes. And at the very bottom, with total control, is the kernel — the core of the operating system, which manages memory, hardware, and every process, and which everything else runs on top of. Code running in the kernel can do essentially anything: read and write any memory, start and stop any process, hide files, intercept operations, and — the point that matters for this case — control or disable the software that runs above it. The kernel is not just more powerful than user programs; it is the ground they stand on, and code in the kernel can move that ground.

This is why kernel access is the deepest and most valuable access an attacker can hold, and why it changes the entire contest with the defender. The defender's security tools — antivirus, and especially the behavioral endpoint-detection-and-response (EDR) tooling that Case 11 named the last real hope against a hands-on intruder — run with high privilege, and they are hardened against ordinary tampering: an attacker with mere administrator rights usually cannot simply kill them, because they are protected. But that protection assumes the attacker is above or beside the security tool in the privilege hierarchy. An attacker in the kernel is beneath it. From the kernel, he is operating at a level the EDR's protections cannot defend against, because those protections themselves run at a level he now controls. Reaching the kernel is therefore not an incremental gain in privilege; it is a categorical one — the move from being watched to being able to blind the watcher.

The register frames this as an access case because that is precisely what it is: the acquisition of the deepest tier of access on the machine, sought not for its own sake but for what it enables. The attacker does not want the kernel because the kernel is interesting; he wants it because from the kernel he can turn off the defenses that stand between his foothold and his goal. Every earlier case was about getting access to a machine or a network; this case is about getting access to the deepest layer of a machine already compromised, in order to neutralize the one thing still capable of stopping him. It is the endgame move, the deepening of access that clears the board — and BYOVD is the reliable way to make it.

2. The Signed Key the Attacker Brings

Now the mechanism, because its cleverness is the heart of the case, and it turns a security control into the attack. The obstacle to running code in the kernel is Windows' driver-signing requirement: drivers, which run in the kernel, must carry a valid signature from a vendor Microsoft trusts, or Windows refuses to load them. This requirement exists precisely to stop an attacker from loading a malicious driver of his own making — if he writes his own kernel malware, he cannot sign it with a trusted vendor's key, so Windows will not load it, and he is locked out of the kernel. For the naive attack, the signing requirement works.

BYOVD sidesteps it entirely, and the sidestep is the whole idea: the attacker does not try to load a malicious driver, because he does not need one. He loads a legitimate driver — a real, functional, vendor-signed driver from an actual hardware or software company — that happens to contain a vulnerability. Because the driver is legitimately signed, Windows trusts it and loads it without complaint; the signing requirement is satisfied, honestly, because the signature is genuine. And then, with the vulnerable driver now running in the kernel, the attacker exploits its flaw — a bug that lets him read and write kernel memory, or execute code — to do in the kernel what his own unsigned malware never could. He did not defeat the signing requirement; he complied with it, using someone else's valid signature on a driver that should never have been trusted with kernel access despite being signed. The signature verified that the driver came from a real vendor; it said nothing about whether the driver was safe, and the driver was not.

This is why the technique is named for the attacker bringing the driver himself. He does not hope the target has a vulnerable driver installed; he carries one — a specific, known-vulnerable, validly-signed driver, selected in advance for having exactly the flaw he needs and exactly the signature Windows will accept — and he brings it to every target. The honeypot's own detection corpus tracks this class: the WinRing0 driver, a legitimately-signed low-level hardware-access driver, is documented in security detection rules as loaded by threat actors, by cryptocurrency miners like XMRig, and by malware, precisely for this privilege-escalation purpose. WinRing0 is one of dozens — vulnerable signed drivers from graphics-card makers, anti-cheat systems, system utilities, and hardware monitors have all been weaponized this way, which is why Microsoft maintains a "vulnerable driver blocklist" of known-abused drivers. The supply is large and continually replenished, because every vendor that ever shipped a signed driver with a serious bug added another key to the attacker's ring. The attacker's genius is simply to keep that ring, and to bring the right key to each door.

3. Importing the Flaw Instead of Finding It

Pause on the strategic inversion BYOVD represents, because it is what makes the technique so reliable and so hard to defend against by the usual means. Every exploitation-based attack the register has covered so far depended on the target having a vulnerability: the web-RCE case needed an unpatched web app, the edge-appliance case needed a flawed VPN, the Redis case needed a specific escalation bug. In each, the attacker was hunting for a weakness in what the target chose to run, and the target's defense was to have no such weakness — to patch, to harden, to close the flaw. The contest was over the target's own attack surface.

BYOVD inverts this completely. The attacker does not hunt for a flaw in the target's software, because he does not need one — he brings his own. The vulnerability he exploits is in the driver he supplied, not in anything the target chose to install or failed to patch. This means the target's patching discipline, however perfect, is irrelevant to whether BYOVD works: the target can have every piece of its own software fully updated, no vulnerable drivers of its own anywhere, and BYOVD still succeeds, because the attacker introduces the vulnerable driver himself at attack time. He is not exploiting the target's weakness; he is importing a weakness of his own choosing, pre-selected for reliability, and running it on the target's machine. The flaw was never the target's to fix.

This portability is what makes BYOVD a dependable, repeatable tool rather than an opportunistic one. The same vulnerable driver works on essentially any Windows machine that will load it, because the flaw travels with the attacker rather than residing in the victim. An attacker who has weaponized a particular vulnerable driver can use it against target after target, with the same reliability each time, because nothing about the target determines whether it works — only whether the target's defenses block that specific driver from loading. This is why the defense, as the last section will argue, has to shift from "patch your vulnerabilities" (useless here, since the vulnerability is not yours) to "block the bad drivers" (the only thing that actually stops the technique). BYOVD is the case where the attacker stopped depending on the defender's mistakes and started supplying his own reliable flaw — a profound and unsettling shift, because it means a perfectly-patched target is not, by that fact alone, safe from having its kernel taken.

4. RANSOMED — Blinding the Watcher Before the Theft

Now the disposition, and it is RANSOMED because BYOVD has become a signature move of the modern ransomware campaign, deployed for one specific and decisive purpose: to blind the defender's last line of detection before the encryption fires. To see why this matters so much, recall where EDR sits in the story. Case 11 established that the modern intrusion is quiet — valid credentials, living off the land, nothing overtly hostile — until the very end, when the attacker finally does the one unambiguously malicious thing: deploy the ransomware. That final act is loud, and behavioral EDR is specifically built to catch it, to see the mass encryption beginning and stop it. EDR is, for many organizations, the last thing standing between a quiet intrusion and a catastrophic one.

BYOVD is how the ransomware crew removes that last thing. Before they detonate, they use a vulnerable driver to reach the kernel, and from the kernel they run an "EDR-killer" — a purpose-built tool that terminates, blinds, or unhooks the endpoint-detection product across the machines they control. The EDR cannot defend itself, because the attacker is now beneath it in the privilege hierarchy; the protection that stops an ordinary administrator from killing it is worthless against kernel code. Once the EDR is down, the defender is blind: the tool that would have seen the encryption starting, and raised the alarm, and perhaps stopped it, is dead. And only then, with the watcher blinded across the estate, does the crew encrypt everything, unopposed. The loud final act, which EDR was built to catch, happens in a room where EDR is no longer watching, because BYOVD turned out the lights first.

This is why the disposition is RANSOMED even though BYOVD is neither the way in nor the payday. The vulnerable driver does not breach the network — a credential or an exploit did that, cases ago. It does not encrypt anything or collect the ransom. Its role is purely to clear the last obstacle from the path: to take a ransomware campaign that the defender's EDR might have caught and detonated it into one the defender never saw coming, because the seeing tool was killed first. BYOVD is the move that converts a detectable intrusion into an unstoppable one, and it does so at the most critical moment, right before the strike. In the anatomy of a modern ransomware attack, it is the step between "the attacker is inside and could still be caught" and "the attacker cannot be caught anymore," and that step is exactly what makes the difference between an incident contained and an enterprise encrypted. The disposition follows the campaign the technique serves, and the campaign is ransomware — made unstoppable by a signed driver the attacker brought to blind the watcher.

5. Blocking the Key at the Door

The register owes the defense, and BYOVD's defense is unusual because the technique's greatest strength — that the flaw is the attacker's, not the target's — is also the location of its weakness: the attack depends entirely on loading one specific vulnerable driver, so if that driver cannot load, the whole technique fails. The defense, therefore, is not to patch (the vulnerability is not yours to patch) but to block the bad drivers at the door.

The central control is Microsoft's vulnerable-driver blocklist. Microsoft maintains a list of known-abused drivers — WinRing0 and its many kin — and Windows can be configured to refuse to load any driver on that list, regardless of its valid signature. This directly defeats the technique for every driver on the list: the attacker brings his signed key, Windows recognizes the specific driver as a known-abused one, and refuses to load it despite the valid signature, so the key does not turn. The critical caveat, and the reason the technique still succeeds so often, is that this blocklist is not always enabled by default on all systems and configurations — so the essential defensive action is to ensure it is turned on. Beyond the blocklist, driver allow-listing goes further: rather than blocking known-bad drivers, permit only known-good ones, so that any driver the attacker brings, even a not-yet-blocklisted one, is refused because it is not on the approved list. And virtualization-based protections — hypervisor-protected code integrity (HVCI), sometimes called memory integrity — constrain what even successfully-loaded kernel code can do, raising the bar against the exploitation step itself.

The remaining defenses assume the driver sometimes loads anyway and aim to catch the attempt. The load of a driver is a discrete, logged, relatively rare event, and the load of a new, unusual, or known-vulnerable driver — especially by a non-standard process, which is not how legitimate drivers normally arrive — is exactly the kind of anomaly a defender can hunt for, because it is the detectable moment of the whole technique. Likewise, the EDR should be configured and monitored to detect and resist tampering, so that an attempt to kill it raises an alarm rather than succeeding silently. The through-line of the defense is that BYOVD's dependency on a specific bad driver is its Achilles' heel: unlike a technique that exploits the target's own inevitable imperfections, this one requires the attacker to load a particular known object, and known objects can be blocked and known events can be watched. Block the driver, and the kernel key the attacker brought will not turn; watch the load, and the moment he tries is the moment you catch him. The defense is not to make your machine flawless — that would not help — but to refuse the specific flawed keys the attacker carries, and to watch the lock for the moment one is tried.

6. The counter-narrative, steelmanned

The strongest objection to this case is that BYOVD is not really an "access" vector at all — that it is a post-compromise privilege-escalation technique, useful only after the attacker is already inside, and therefore out of place in a register about how attackers get in.

The argument runs like this. Every other case in the register documents a way into a machine or network from outside — a credential, an exploit, a trusted channel. BYOVD documents none of that; by the time it is used, the attacker already has a foothold, already has administrative rights, and is merely deepening access he already holds. It is, on this view, a defense-evasion and privilege-escalation technique, belonging in a discussion of what attackers do after they are in, not in a register titled "Follow the Access," which is about getting in. Including it, the objection concludes, stretches the register's theme past its meaning: BYOVD is not access to the network, it is a maneuver within a network already breached.

The register concedes the sequencing and defends the inclusion on the register's own terms. Yes, BYOVD is used post-foothold, and the case says so plainly from its first line — it explicitly frames itself as following "the way down" rather than "the way in." But the register's subject is access in the full sense, from the login prompt to the foothold's fate, and access has depth as well as a doorway. Reaching the kernel is the acquisition of the deepest tier of access a machine has, and it is access in exactly the sense the register cares about: a level of control an attacker did not have and now does, sought for what it enables. To insist that only the outermost door counts as "access" would be to stop the register's own story precisely where it gets decisive — because the difference between an attacker who is inside-but-watched and one who has reached the kernel and blinded the watcher is the difference between a contained incident and an encrypted enterprise. That difference is an access difference, and it is the one that determines the disposition. Moreover, the register has never confined itself to initial access alone: the access broker (Case 10) is a market actor, the supply chain (Case 13) attacks a supplier, the valid account (Case 11) is about what a credential is for. The through-line is not "how the first door opens" but "how access is obtained, deepened, monetized, and defended," and BYOVD is the case about the deepest access there is and the decisive use to which it is put. A register of access that stopped at the perimeter and ignored the acquisition of kernel control — the access that decides whether the whole intrusion succeeds — would be omitting the most consequential access move of the modern ransomware attack on a technicality about sequence.

7. Disposition — RANSOMED

Case 16 followed Bring Your Own Vulnerable Driver — the technique by which an attacker already inside deepens his access to the deepest tier a machine has, the kernel, and does it by bringing a legitimate, vendor-signed but vulnerable driver, loading it (Windows trusts the real signature), and exploiting its flaw to run code in the kernel. The signing requirement built to keep attackers out of the kernel is turned into the way in: the attacker complies with it honestly, using someone else's valid signature on a driver that should never have been trusted. And his flaw is portable — he imports a known-vulnerable driver of his own choosing rather than hunting for one in the target, so even a perfectly-patched machine can have its kernel taken, because the vulnerability was never the target's to fix.

The disposition — the foothold's fate — is RANSOMED, because BYOVD's dominant purpose is to clear the last defense from the ransomware's path. From the kernel, the crew runs an EDR-killer to terminate the behavioral tooling that is the defender's final hope of catching the intrusion — tooling that cannot defend itself against an attacker now beneath it in privilege — and then, the watcher blinded across the estate, they detonate the encryption unopposed. The vulnerable driver is neither the way in nor the payday; it is the move that turns a detectable intrusion into an unstoppable one, at the most critical moment, right before the strike. The disposition follows the campaign it serves.

The defense turns the technique's strength into its weakness: because BYOVD depends on loading one specific bad driver, block that driver and the whole attack fails. Deploy and — critically — enable Microsoft's vulnerable-driver blocklist so drivers like WinRing0 cannot load despite valid signatures; go further with driver allow-listing and HVCI memory-integrity protections; and watch for the discrete, anomalous driver-load event and for EDR tamper, because the load is the detectable moment. The vectors do not lie: the attacker brought a real key, the lock accepted it because it was real, the key opened the kernel, and from the kernel he switched off the alarm before he took everything — a signed driver, a blinded watcher, an enterprise encrypted in the dark it created. We do not judge. We record. We let people judge — and then, if they are wise, refuse the flawed keys the attacker carries, and watch the lock for the moment one is tried.

Follow the Access continues. Case 16 disposition: RANSOMED. Confidence: HIGH — BYOVD is a documented, named technique; the vulnerable-driver class (including the WinRing0 driver abused by miners and malware) is tracked in public detection rules and the honeypot's own corpus; the EDR-killer ecosystem and Microsoft's vulnerable-driver blocklist are documented; and MITRE ATT&CK catalogues the technique as exploitation for privilege escalation and defense evasion. The RANSOMED disposition reflects BYOVD's signature role in modern ransomware campaigns (blinding EDR before detonation), connecting to Cases 03 and 11. The case is explicitly framed as a post-foothold deepening of access ('the way down'), which the register defends as within its subject. Classification: TLP:WHITE. Include everything — the vectors do not lie, and they do not judge. The reader judges the signed key, the trusted lock, and the watcher switched off in the dark.