CONTENTS
0 windows privilege rings
1 driver signature enforcement (dse)
2 the byovd concept
3 attack flow
4 post-exploitation capabilities
5 detection & mitigations
──[ 0. Windows Privilege Rings ]──
Windows split execution into privilege levels called rings. Each ring is
isolated and can only reach lower-privilege rings through well-defined channels
(APIs, syscalls, drivers, callbacks).
User Land (Ring 3) — where normal apps live. Memory isolated per
process. Kernel can kill anything.
Kernel Land (Ring 0) — Windows core, device drivers, EDR kernel pieces.
Code has full access: all memory, all devices.
Going from Ring 3 to Ring 0 legitimately means loading a signed kernel driver.
──[ 1. Driver Signature Enforcement (DSE) ]──
Windows enforces DSE: only drivers signed by Microsoft (or by a vendor with a
cross-signed cert) load into the kernel.
Microsoft's signing process is roughly a two-year ordeal.
Writing your own malicious driver becomes impractical for most attackers. A
kernel zero-day works too but costs a fortune and gets patched fast.
──[ 2. The BYOVD Concept ]──
BYOVD walks around DSE entirely. Instead of writing a new driver, you ship a
legitimate, fully-signed driver from a known vendor — one with a known
vulnerability.
Legitimate ✓ Microsoft signed it. DSE allows it.
Vulnerable ✓ A CVE or logic flaw lets Ring 3 read/write kernel
memory through it.
Usual suspects: hardware vendors (Intel, ASUS, Dell, Gigabyte…) whose old
drivers expose raw memory read/write IOCTLs with zero validation.
──[ 3. Attack Flow ]──
Prereq: local admin or SYSTEM already (you need that to load a kernel driver).
Loading via the Service Control Manager:
sc create PwnDrv binPath="C:\temp\vulnerable.sys" type=kernel
sc start PwnDrv
Or do it programmatically with NtLoadDriver(). Once loaded, your userland
process talks to the driver via DeviceIoControl() calls, abuses the vuln, and
gets kernel read/write primitives.
──[ 4. Post-Exploitation Capabilities ]──
With arbitrary kernel R/W, you can:
Direct Kernel Object Manipulation (DKOM)
Tweak EPROCESS to hide processes from task list, unlink them from the
kernel process list, or upgrade their token privileges.
EDR Blinding
Find the kernel callback tables (PsSetCreateProcessNotifyRoutine,
PsSetLoadImageNotifyRoutine, etc.) and zero out the EDR's callback
pointers. EDR stops receiving notifications.
Token manipulation
Steal or duplicate SYSTEM tokens to escalate in userland.
──[ 5. Detection & Mitigations ]──
Microsoft's answer:
HVCI (Hypervisor-Protected Code Integrity) — hardware-enforced check
that blocks loading any driver not signed with a current EV cert. Most
BYOVD drivers predate the HVCI requirements.
Microsoft Vulnerable Driver Blocklist — list of known-vulnerable
drivers shipped via Windows Update and Defender. Keeps growing.
LOLDrivers (loldrivers.io) — community catalogue of drivers known to
be abused in the wild.
Defender side, alert on:
- Driver loads of binaries that aren't in the approved blocklist
- DeviceIoControl calls to drivers with no legitimate user-mode clients
- DKOM indicators: processes in tasklist with no matching kernel entries
BYOVD is worth understanding deeply because it underpins most of the other EDR
bypasses in this series — kernel callbacks need Ring 0 access to patch, and
BYOVD is usually how you get there.