How BYOVD Attacks Use a Signed Driver to Reach the Windows Kernel

When attackers compromised internet-facing AhsayCBS backup servers in October 2026, one of the files they dropped was a kernel driver named `WinRing0x64.sys`. That driver is not malware in the usual sense. It is a legitimate, validly signed Windows driver, and the attackers brought it with them on purpose. This is a bring-your-own-vulnerable-driver attack, usually shortened to BYOVD, and it is one of the most reliable ways to get from code execution to full control of a Windows machine.

Why the Kernel Is the Prize

Windows runs code at two broad privilege levels. User mode is where applications and most malware live. Kernel mode is where the operating system core, the memory manager and device drivers run, with direct access to hardware and to every process on the machine. Code in the kernel can read and write any memory, disable protections, and hide itself from tools that only see user mode.

Microsoft has spent years making it hard to get there. Since 64-bit Windows, kernel-mode drivers must be cryptographically signed by a trusted authority before the system will load them. The intent is that only vetted code runs in the kernel. BYOVD is the technique attackers use to defeat that intent without ever forging a signature.

How BYOVD Works

The insight behind BYOVD is that "signed" and "safe" are not the same thing. Over the years, many hardware vendors have shipped legitimately signed drivers that contain exploitable bugs, often an interface that lets a user-mode program ask the driver to read or write arbitrary physical memory, access hardware registers, or call privileged CPU instructions. The driver was signed because it came from a real company, and the signature never expires just because someone later found a flaw.

An attacker who already has administrative code execution in user mode, as the AhsayCBS intruders did after chaining the backup server's authentication bypassAuthentication Bypass📖A security vulnerability that allows an attacker to circumvent the login verification process and gain unauthorized access to a system without providing valid credentials. and command injectionCommand Injection🛡️A security vulnerability that allows attackers to execute arbitrary operating system commands on the host system through a vulnerable application., performs three steps. First, drop a copy of the known-vulnerable signed driver onto disk. Second, load it, which Windows permits because the signature is valid. Third, send the driver crafted requests that abuse its bug to reach into kernel memory. From there the attacker can do what signed, well-behaved drivers are never supposed to allow.

`WinRing0` is a textbook example. It is a driver that exposes low-level hardware access, including model-specific registers and port I/O. Legitimate monitoring and overclocking tools have used it for years. In the AhsayCBS case the attackers loaded it so their XMRigXMRig🛡️An open-source, high-performance miner for the Monero cryptocurrency. It is widely abused by attackers who deploy it on compromised servers to mine coins using stolen compute, often disguised as a legitimate process. cryptocurrency miner could tune the processor for better mining performance. The same primitive, raw hardware and memory access from the kernel, is equally useful for far more damaging goals.

What Attackers Do Once They Are in the Kernel

Cryptomining is a comparatively benign use of kernel access. The more dangerous BYOVD payloads target security software. From the kernel, malware can terminate or blind endpoint detection and response agents by stripping the callbacks they register to watch process creation, or by killing their protected processes outright, something user-mode malware cannot touch. This is often called an EDR killer, and a working vulnerable driver is the usual delivery mechanism.

Kernel access also enables stealth that survives a surface-level cleanup. A rootkit operating below the level of normal tooling can hide files, processes and network connections, and can re-establish itself after a reboot. That is why, in the AhsayCBS incidents, the right response to a confirmed compromise is to re-image the host from trusted media rather than delete the miner and move on. A userland sweep does not reliably see what a kernel implant has done, and the reasoning is the same as for appliances where you should learn how to detect unauthorized file changes on a hardened appliance rather than trusting the running system to report on itself.

Defending Against BYOVD

You cannot patch a vulnerable driver you do not control, but you can stop it from loading. Microsoft maintains a vulnerable-driver blocklist that the kernel consults, and keeping it enabled and current blocks the well-known offenders, including the families attackers reach for most. On modern Windows, memory integrity, part of the virtualization-based security feature set, raises the bar further by isolating kernel-mode code integrity checks.

Application control that allows only an explicit set of drivers is stronger still, because it flips the model from blocking known-bad to permitting known-good. That takes inventory and testing, but on a server with a fixed, well-understood role, such as a backup server, the set of drivers that legitimately needs to load is small and stable.

The most important defense, though, is denying the attacker the administrative foothold that BYOVD requires. BYOVD is a privilege-escalation and defense-evasion step, not an entry point. It only comes into play after someone is already running code with enough rights to load a driver. In the AhsayCBS case that foothold came from an exposed management interface and an unpatched flaw, which is why the primary fix in the AhsayCBS Backup Server Exploitation event was to take the console off the public internet. Everything downstream, including the kernel driver, depends on that first door being open.

The Takeaway

A signed driver is a statement about who wrote the code, not a guarantee that the code is safe to run. BYOVD turns that gap into a dependable path from administrative user-mode access into the Windows kernel, where defenses can be disabled and persistence can be hidden. Keep the vulnerable-driver blocklist on, prefer explicit driver allowlisting on fixed-role servers, and treat any confirmed kernel-level compromise as a rebuild rather than a cleanup. Most of all, remember that BYOVD is the second move: the way to never face it is to close the privilege-escalation opportunity that lets an attacker load a driver in the first place, which ties directly to Why Your Backup Server Is a Tier-0 Target.