SOC Analyst Perspective: What is BYOVD Attack

Keeping it Simple: Bring Your Own Vulnerable Driver (BYOVD) is when an attacker leverages an already existing, vulnerable driver to perform actions it was not originally intended to do.

I feel a personal duty to overkill — and by overkill, I mean conduct a deep dive into some of the following concepts for someone who considers themselves a beginner, still like myself.

• History of Operating System & Kernel

• What is a Driver

• BYOVD Attack

Note: This is a theory/conceptual discussion — not a how-to. Don’t go do illegal stuff.

History of Operating System & Kernel

First, let’s get a better understanding of the Windows Operating System. One of my favorite lessons from my C programming professor back in college (I am not old, just saying) is that the operating system provides a “beautiful abstraction” for “ugly hardware”.

The operating system manages the hardware and software resources on your computer, including tasks such as resource allocation (which programs need what memory at what time and what programs run first), and providing a user interface (hence the “beautiful abstraction”) and overall ensuring the system is reliable and available to you.

The most common phrase you’ll hear is that the kernel is the core or heart of the operating system. In my opinion, it is a really, really simplified definition. I struggle to write this because, in modern times, the kernel and operating system are often referred to as separate entities due to the distinction between user mode and kernel mode.

Earlier operating systems can be thought of more as “libraries”  (there is less distinction between an operating system and a kernel); these “libraries” were system code that applications could interact with using system calls to perform input/output (I/O) operations. To simplify, this helped automate tasks for many developers at the time.

As the operating system grew and took more of the “manager” role, it seemed a bit risky to have the applications directly access system code, since that code was responsible for providing applications with their functionalities but also for managing hardware and system resources.

In modern times, we are now more familiar with the concept of user mode (where applications run) versus kernel mode (a privileged mode in which the kernel executes system calls from those applications).

We will keep this Windows-specific — there are two types of modes: User Mode and Kernel Mode. Another mention is a concept called a protection ring, which indicates the level of privileges, ranging from end-user applications (typically the lowest) to the kernel (highest).

For further knowledge, check out BCT Engineering Notes - Operating System and Operating Systems: Three Easy Pieces by Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau.

What is a Device Driver?

Think of a device driver as the intermediary of communication between your operating system and hardware. For example, when you plug in a mouse, the operating system uses the driver provided by the mouse’s manufacturer to understand how to communicate with the hardware and provide functionality.

To reiterate, it is risky for the application to directly interact with the hardware, as this can lead to system crashes. So, drivers provide a layer of abstraction for the application — the application doesn’t need to understand the hardware itself, just how to communicate with the driver. The application can make its requests via APIs.

Oversimplified conversation (not including security checks lol):

Application: “Hey API! I need to perform an operation that requires hardware access.”
API: “Ok — I’ll hand your request to the kernel via a system call.”
Kernel: “I’ll dispatch the request to the appropriate driver.”
Driver: “I’ll instruct the hardware to do the thing.”
Kernel: “Hardware did the thing. Here’s the result of the API.”
API: “Ok!”
Application: “Thanks, API — I got the results.”

So, that BYOVD Attack ...

Now, we reach the juicy part: BYOVD!

BYOVD has become a popular method for evading defenses, specifically disabling EDRs. So, what makes BYOVD appealing?

With a legitimate, signed driver, there seems to be a level of inherent trust that the driver has not been tampered with. If you think of some of those modern Antivirus “Antimalware” crap software solutions out there (no offense), many of them don’t check drivers.

It’s also a way to achieve privilege escalation if the driver has kernel-mode access (again, higher privileges).

Let’s brainstorm some more — applications use drivers. What about those EDRs? It’s an application/solution that likely uses one or more kernel drivers. As a defender, I’ll let you do the math on why that’s not so great for us.