Skip to content

Driver abuse

Unveiling BYOVD Threats: Malware’s Use and Abuse of Kernel Drivers

https://www.ndss-symposium.org/wp-content/uploads/2026-s1491-paper.pdf NDSS 2026

  • Some drivers exist solely to implement system level features or to expose privileged operations to user-mode applications.
  • If these drivers contain vulnerabilities, malicious actors can exploit them to bypass security mechanisms, gain elevated privileges, and execute undetected malicious code in the OS kernel. Vulnerable drivers are routinely patched and replaced with new, more secure versions.
  • Bring Your Own Vulnerable Driver (BYOVD) is a sophisticated malware attack technique that leverages legitimate but vulnerable kernel drivers to compromise computer systems. In these attacks, malicious software brings along its own copy of a vulnerable third-party driver and loads it into the operating system – effectively reintroducing into the system an old vulnerability it already knows how to exploit
  • While BYOVD is becoming increasingly popular among malware authors, defense techniques are lagging behind. Modern EDR systems, although effective at monitoring user-mode activity, are often blind to actions that take place in the kernel.
  • For instance, when a malware sample loads and abuses the Zemana anti-malware driver to terminate Windows Defender, public sandboxes on VirusTotal detect only the driver load event, but fail to capture how it is used once loaded into the system. This limitation stems from a fundamental lack of visibility into internal kernel-level communications.

Background

  • Driver Signature Enforcement (DSE) ensures that each kernel driver loaded in the system is signed. To sign a driver, developers submit the binary to Microsoft’s Windows Hardware Dev Center, where it undergoes a suite of security and compatibility checks before Microsoft applies its digital signature
  • While there have been cases of malicious drivers signed by Microsoft [16], this is a risky approach for malware developers. Instead, attackers often exploit legitimate signed drivers with vulnerabilities that expose kernel functions to user-mode programs.
  • Malware authors target drivers that allow arbitrary memory access or dangerous actions like process termination, kernel memory mapping, privileged file access, and I/O monitoring, executing user-specified code at the kernel level.

  • A common way to trigger a vulnerability in a driver is to send a properly crafted request. Windows supports two different types of communications with kernel drivers: Minifilter APIs and I/O Request Packet (IRP).

  • Once a driver with the desired characteristics is identified, the malware must drop it on disk and then load it after successfully infecting the system. This procedure is due to the fact that typical methods used to load drivers (e.g., sc.exe, NtLoadDriver, or CreateService) require a file path pointing to a location on disk and cannot be performed from memory.

  • However, loading a driver in Windows requires the process to already run with administrative privileges. This raises a crucial question: why would malware bother loading a driver if it already has administrative privileges?

  • The answer lies in the design of modern Windows operating systems. Some processes and system components are so essential to maintaining the security and integrity of the system that even administrators are prohibited from modifying them. Only the kernel has the necessary privileges to modify these highly protected system parts.

  • Protected Processes Termination (PPL) provides a flexible protection model designed to isolate processes. They are extensively used to isolate different operating system components, such as process management, the LSASS, Microsoft Defender.

  • Modern EDRs are implemented by using a combination of user-mode PPL processes (that contain the detection logic), and kernel-mode drivers (that provide access to privileged resources).
  • Malware can no longer terminate user-space EDR components (even when running with administrative privileges), thanks to their protection under the PPL mechanism.
  • An attacker could find a way to limit the EDR functionalities through other kinds of vulnerabilities, exploit flaws in the PPL implementation, or perform a BYOVD attack to abuse an existing driver that allows a user-mode process to kill even PPL processes.