Defense evasion has quietly become one of the most consequential stages of an advanced cyber intrusion. As security products have grown harder to beat, attackers have changed their tactics. Rather than attempting to fly under the radar, they are opting to switch off security altogether. With ransomware attacks, in particular, attempting to disable security software is now a standard part of the attack chain. 

One technique has come to dominate the area of defense evasion and, over the past three years, it has become something close to an epidemic. The Bring Your Own Vulnerable Driver (BYOVD) technique lets attackers abuse flaws in legitimate, validly signed kernel drivers to seize control of the Windows kernel itself and operate at the highest level of privilege on a machine. 

Hundreds of vulnerable drivers are already in circulation. New ones are uncovered and shared openly on a regular basis and ready-made BYOVD tooling is now routinely bundled into ransomware-as-a-service (RaaS) offerings alongside the payloads themselves. Once operating in the kernel, attackers can blind, cripple, or simply kill the very products meant to stop them. Furthermore, as this research shows, the kernel hardening Microsoft has built into Windows does little to get in their way.

These techniques, and the defensive measures that can counter them, are examined in detail in the Symantec Threat Hunter Team's latest whitepaper: Lights Out: Defense Evasion in the Age of BYOVD.

Why attackers go to the kernel

Windows runs code at two levels of privilege. User mode is where everyday applications live, and the operating system limits what they are allowed to do. Kernel mode is where the operating system itself runs, and code executing there has almost no restrictions. An attacker who reaches kernel mode can read or change nearly anything on the machine, including the security software trying to protect it.

Vulnerable drivers are the attacker's most reliable route in. A driver is a piece of trusted, digitally signed code that the operating system loads to handle specialist tasks and the Windows kernel fully trusts third-party drivers once they are loaded. The attacker, having gained administrator privileges, can drop a flawed but validly signed driver onto the target machine. Because the driver is signed, Windows loads it automatically. The attacker then sends the driver a specially crafted command that exploits the flaw, and the driver carries out actions on the attacker's behalf that no ordinary program could.

The most common action is to kill the processes belonging to antivirus (AV) or endpoint detection and response (EDR) products, stripping the machine of its defenses. Some variants are more subtle. Attackers may strip the security agent of the rights it needs to function correctly, leaving it running but unable to act. Others tamper directly with the kernel's internal records so that the security product no longer receives notifications about what is happening on the machine, effectively making it blind.

A commoditized technique

BYOVD is popular because it is so effective and relies on legitimate, signed files, which are less likely to raise red flags. A wide range of drivers can be abused this way, with anti-rootkit drivers developed by security vendors among the most exploited. Ready-made tools that automate the attack are openly traded and shared. Examples include TrueSightKiller, a publicly available tool that leverages a vulnerable driver named truesight.sys; GhostDriver, another publicly available process killer; AuKill, which abuses an outdated version of the driver used by the Microsoft utility Process Explorer; and Poortry, a malicious driver whose developers are believed to have succeeded in getting it signed.

Several of these tools have become standard parts of the ransomware toolkit, and a small number of ransomware operators now build their BYOVD component directly into the ransomware payload itself.

Not every attack needs a driver

While BYOVD dominates the picture, it is not the only route attackers can take. Windows shields AV and EDR services with a mechanism called Protected Process Light (PPL), which prevents even administrators from terminating them. The rules, however, leave gaps. An administrator cannot kill a protected process, but they can suspend it, and a paused security product is just as good as a stopped one. Its scans stop completing, yet it still appears to be running, so the restart logic that would normally bring it back to life never triggers and users see no obvious failure.

Windows also arranges its most sensitive processes into a hierarchy of trust levels, and an attacker who can take over or impersonate a process at a higher trust level than the security product gains the right to terminate or tamper with it. Other attackers ignore the local machine altogether and quietly cut the security product off from the vendor's cloud services it depends on for reputation lookups and file-prevalence checks. The agent looks healthy, but its decisions are made with much less information.

Kernel hardening is not enough

Microsoft has added a series of protective features to the Windows kernel over the past decade to make kernel access less useful to an attacker. Kernel Address Space Layout Randomization (KASLR) makes kernel structures harder to find. Hypervisor-Protected Code Integrity (HVCI) stops attackers from patching kernel code. Kernel Control Flow Guard (KCFG) and hardware-enforced stack protection constrains how control can move through the kernel. Each one closes off a category of attack that would otherwise be available. Each one also has a publicly known bypass.

More importantly, the attacks most used against AV and EDR products do not fall into any of the categories these features block. The attacker is not trying to run new code in the kernel, redirect how the operating system works, or rewrite the memory map. They are simply changing information the operating system already holds; flipping the field that says which processes are protected, clearing the entries that tell the kernel which security products want to be notified of events, or downgrading the privileges of a running security agent. These data-only attacks route around kernel hardening entirely.

Microsoft's published servicing criteria for Windows are explicit that, for the New Technology (NT) kernel, administrator-to-kernel is not a security boundary. Attacks of this kind are treated as bypasses of mitigations rather than as exploitation of vulnerabilities, and fixes, when they come, arrive without CVEs and outside the standard security-response process. Kernel hardening is worth deploying, but it cannot be relied on as the primary defense against the attackers seen in the wild.

Shifting the balance: Proactive, not reactive, defenses

Two defensive approaches dominate today's response to BYOVD, and both have meaningful limitations. Microsoft's Vulnerable Driver Blocklist stops recent Windows installations from loading drivers known to be vulnerable, but there is a lag of days, more often weeks, between a driver being identified and the blocklist update reaching enterprise endpoints. Only a subset of known vulnerable drivers is blocklisted at any given time. When defenders block one driver, attackers simply switch to the next.

Signature-based detection faces a similar problem. Many BYOVD tools begin life as open-source proof-of-concept projects on public code-sharing platforms. When the original project is flagged, attackers re-implement it within days, often in a different language. The same underlying technique has been reimplemented in C, C++, C#, Rust, and Go in rapid succession, and each language change defeats the existing hash signature. The result is that static defenses keep defenders permanently reactive.

The approach that genuinely shifts the balance is to monitor what files do when they interact with kernel drivers, not simply which drivers are loaded. Whether a BYOVD tool is a year-old C++ project or a fresh Rust port written last week, the operational pattern is largely the same. A vulnerable driver is dropped to disk. A service is created and started to load it. The malicious component then enumerates running processes and sends the driver a specific input/output control (IOCTL) command instructing it to take a privileged action against security software. Symantec and Carbon Black endpoint products now include behavioral monitoring of these driver interactions, flagging anomalous IOCTL traffic such as process termination requests directed at security products, handle stripping that would crash a security process, and callback removal that would blind the EDR.

This protection is driver-agnostic. A request to terminate a running security product is anomalous regardless of which driver is being asked to perform it, so the detection does not depend on identifying the driver in advance, and it can catch an unknown vulnerable driver the first time it appears in the wild. A vulnerable driver that emerges this week can be covered by behavioral protection immediately. The time advantage attackers have enjoyed since BYOVD became popular is beginning to narrow. Only Symantec and Carbon Black Endpoint products provide comprehensive protection at a behavioral level.

Learn more about this threat in our comprehensive whitepaper: Lights Out: Defense Evasion in the Age of BYOVD.