Signed, Trusted, Weaponized: Inside the BYOVD Playbook Powering Modern Ransomware

By: Cynet Research Labs

Introduction

Bring Your Own Vulnerable Driver (BYOVD) has become one of the most observed techniques for obtaining privileged kernel access during modern cyber intrusions. Rather than finding a new vulnerability, threat actors abuse legitimately signed but vulnerable drivers that the operating system already trusts. By abusing functionality exposed by these vulnerable drivers, they obtain powerful kernel capabilities without finding new vulnerabilities or being affected by patches, making advanced defense evasion techniques more practical and repeatable.

Cynet Research and CyOps teams have observed BYOVD being adopted with increasing frequency, particularly by ransomware operators. Across these investigations, a consistent operational pattern emerges threat actors attempt to establish privileged kernel access early in the intrusion to reduce the complexity of the stages that follow.

Although BYOVD is not a new technique, its continued adoption has fundamentally changed the economics of modern attacks. Instead of investing in sophisticated kernel exploitation, threat actors increasingly rely on publicly available vulnerable drivers to obtain reusable kernel primitives that simplify privilege escalation, defense evasion, and interaction with protected Windows security mechanisms.

The Driver: A driver is a software component that enables Windows to communicate with hardware and low-level operating system services. Many drivers run in kernel mode, where code executes significantly greater privileges than a normal user-mode application. Kernel code can reach memory, processes, and security controls that user-mode code cannot. That is why a driver bug, or an unsafe driver interface, can affect the whole system, not just one app.

Device Object: Windows exposes a driver through a device object: a kernel object that represents the driver as something applications can connect to. The driver often publishes a user-visible name such as \\.\MyDriver. That name is the communication endpoint through which applications send requests to the driver.

IRP (Input/Output Request Packet): An IRP is a kernel data structure created by the Windows I/O Manager to represent an input/output request as it travels through the driver stack. When an application calls DeviceIoControl, Windows packages the request into an IRP containing information such as the requested operation, the associated buffers, the originating process, and the status of the request. The IRP is then delivered to the driver’s dispatch routine, which processes the request and eventually completes it with success or error status. Because the IRP carries both caller-controlled data and kernel-managed metadata, the driver must interpret its contents carefully and validate all relevant fields before performing privileged operations.

IOCTL (Input/Output Control): An IOCTL is a structured request sent from a user-mode application to a driver by calling DeviceIoControl. Each request contains many fields; some of the interesting fields are:

• A control code identifying the requested operation.
• Optional input and output buffers containing the associated data.

In a well-designed driver, each IOCTL performs a narrowly defined task, and sensitive operations are carefully validated before execution. Problems arise when a driver exposes privileged functionality to untrusted callers or fails to validate the request, the caller, or the supplied data.

The Dispatcher: Inside the driver, incoming IOCTLs are routed by a dispatcher, typically the handler for IRP_MJ_DEVICE_CONTROL. The dispatcher reads the control code and decides which internal function should run, like a switchboard connecting a request to the right handler.

The dispatch routine is responsible for validating every request before executing privileged operations. It verifies that the requested IOCTL is permitted, that the supplied buffers are valid, and that the request originates from an authorized caller. When these validation checks are incomplete or incorrect, functionality intended only for trusted kernel code may become accessible through the driver’s IOCTL interface.

Every BYOVD attack ultimately depends on this execution path. Rather than exploiting a new interface, threat actors abuse the same trusted communication path used by legitimate applications, turning it into a reusable attack vector.

The BYOVD Problem

The driver is not malware by design. It is real, trusted software, often from a hardware vendor or security product with a normal device object and a normal IOCTL interface. Threat actors do not need to exploit Windows itself. They load that driver, open a handle to its device, and send IOCTLs through the same API any legitimate application would use.

The failure mode is specific:

1. The application sends an IOCTL with unexpected or malformed data in the input buffer.
2. The dispatcher passes the request to a handler function that does not validate the data correctly.
3. The driver performs privileged operations that should normally remain inaccessible to untrusted user-mode applications.
4. Those calls become an attack primitive: a building block that threat actors can reuse to disable security software, tamper with kernel memory, or escalate privileges.

BYOVD is not the installation of a malicious driver. It is the abuse of a legitimate driver’s vulnerable IOCTL interface, allowing untrusted user-mode input to reach privileged kernel functionality that Windows intended only for trusted kernel code.

For defenders, the implication is straightforward. None of these kernel-level capabilities become available until the vulnerable driver has been successfully loaded by Windows. That makes the driver load itself one of the earliest and most valuable opportunities to detect, prevent, and disrupt the attack before it accelerates into its later stages.

What Kernel Access Makes Possible

The previous section explained why BYOVD has become an increasingly common technique in modern threat campaigns. The next question is what threat actors gain once a vulnerable driver has been successfully loaded into the Windows kernel.

Once kernel access has been established, the focus shifts from obtaining privileged execution to using the kernel capabilities that support the remainder of the intrusion.

• Across modern BYOVD campaigns, these kernel capabilities consistently support three operational objectives. Reducing Security Visibility: One of the first objectives after kernel access is reducing the visibility available to defenders. Endpoint security products rely on kernel callbacks, Event Tracing for Windows (ETW), and other security mechanisms to generate the telemetry used to detect and investigate malicious activity. Once privileged kernel access has been established, these mechanisms become significantly easier to influence, reducing the visibility defenders depend on throughout the intrusion.
• Impairing Security Controls: The next objective is impairing the endpoint security products protecting the compromised system. Threat actors frequently use their newly acquired kernel capabilities to tamper with security software, attempt to terminate protected security processes, or otherwise interfere with their operation. Once endpoint security products have been impaired, defenders lose not only prevention capabilities but also much of the telemetry and response capability they rely on to detect, investigate, and contain the intrusion.
• Preparing for the Next Stage: The objective of obtaining kernel access is rarely the kernel access itself. Instead, these capabilities prepare the environment for the remainder of the intrusion. By reducing security visibility and impairing security controls, threat actors create the operational conditions needed to continue the intrusion with fewer defensive barriers before progressing toward their objective.

The importance of these operational objectives becomes clear during real incident response investigations. The following case study demonstrates how this operational workflow appeared during a real-world BYOVD intrusion investigated by the Cynet Research and CyOps teams, and how preventing the vulnerable driver from loading interrupted the attack before those capabilities became available.

Investigation Outcome

Cynet detected and prevented the attempted driver from loading before the newly created service could establish privileged kernel execution. Interrupting the intrusion at this stage preserved endpoint visibility and prevented the kernel primitives required to weaken security controls before ransomware deployment from becoming available.

Because the vulnerable driver never loaded, telemetry remained intact throughout the investigation. The Cynet platform continued collecting endpoint telemetry while the CyOps team correlated the attempted BYOVD activity with the broader intrusion, validated the threat actor’s objectives, and initiated response actions, including endpoint isolation where appropriate.

To understand why PoisonX provided an effective BYOVD primitive during this intrusion, it is useful to examine how the driver exposes privileged functionality after being loaded into the Windows kernel.

Why this mattered in the investigation

PoisonX is significant not because it is unusually sophisticated, but because it transforms a trusted signed driver into a reusable kernel primitive. Had the driver loaded successfully, the threat actors would have obtained the kernel capabilities required to weaken endpoint protections before ransomware deployment.

In this engagement, Cynet detected and prevented the driver from loading before kernel execution was established. That interruption preserved endpoint telemetry, prevented the loss of visibility that typically precedes defense impairment, and enabled the CyOps team to investigate and contain the intrusion before the attack progressed further.

Research Observation

Across multiple Cynet incident response engagements  a consistent operational pattern emerged. Regardless of the ransomware family or vulnerable driver involved, threat actors repeatedly attempted to establish privileged kernel access before disabling security controls or progressing ransomware deployment.

Although different campaigns leveraged different legitimately signed vulnerable drivers, including PoisonX, GoFly, CcProtect, and UnknownKiller, the objective remained consistent: to obtain reusable kernel capabilities that simplify defense evasion and accelerate the remainder of the intrusion. Rather than treating individual vulnerable drivers as isolated indicators, defenders should recognize BYOVD as a recurring stage within a broader attack workflow. Identifying and interrupting this stage provides an opportunity to preserve endpoint visibility and contain the intrusion before threat actors gain kernel-level control.

Conclusion

Bring Your Own Vulnerable Driver (BYOVD) has evolved from a niche post-exploitation technique into a practical and repeatable component of modern ransomware operations. Rather than investing in sophisticated kernel exploits, modern ransomware operators increasingly abuse legitimately signed but vulnerable drivers to obtain privileged kernel capabilities that simplify privilege escalation, defense evasion, and interaction with protected Windows security mechanisms.

This research demonstrates that BYOVD is not defined by any single vulnerable driver. Rather the technique is characterized by a repeatable operational workflow:

• Establish initial access
• Load a signed vulnerable driver
• Obtain privileged kernel capabilities
• Weaken security controls
• Accelerate toward the attack objective

Although the vulnerable driver may differ between campaigns, the operational workflow remains remarkably consistent, providing defenders with a reliable opportunity to detect and interrupt the intrusion before kernel-level capabilities become available.

As BYOVD adoption continues to increase, organizations should treat vulnerable driver abuse as an early-stage intrusion indicator rather than an isolated event. Detecting driver loading, monitoring service creation, and preserving endpoint telemetry provide defenders with an opportunity to interrupt the intrusion before threat actors obtain the kernel capabilities that enable defense impairment and accelerate ransomware deployment.

IOCs

Files

Registry Keys:

MITRE Mapping