Logs open, EDR screen right in front of me, and I can feel something's wrong — I just can't pinpoint where. Then it hits me: the malicious process is running inside the Windows kernel itself. Hiding behind a legitimate, signed driver. My internal reaction? Again? And yes — BYOVD (Bring Your Own Vulnerable Driver) is still one of the biggest blind spots in this industry.
The GodDamn ransomware group's latest campaign targeting US-based organizations is built entirely on this tactic. (Source: Dark Reading) What really gets under my skin is this: the technique isn't new. BYOVD has been an APT favorite since at least 2021. The industry knows it, researchers write about it, it gets presented at conferences — but operational maturity on the defense side still isn't where it needs to be. I didn't want to write about this again. But I can't just sit here and say nothing.
What the Attacker Is Doing — From a Red Team Perspective
Think about it this way: the target system has an EDR (Endpoint Detection and Response) running. It monitors everything in user-space. Hooks are set, telemetry is flowing. A standard piece of malware gets caught at this layer pretty easily. But what if you go deeper — all the way down to the kernel?
That's exactly where BYOVD comes in. The attacker drops a legitimate driver file onto the system — one that Windows has digitally signed, meaning the OS considers it "trusted" — but that contains a known vulnerability. Loading that driver grants kernel-mode access. From there, the attacker tears out the EDR's hooks, hides processes, and blinds security tooling. After that, whatever they do in user-space, nobody sees a thing.
The flow GodDamn most likely used looks something like this:
- Initial access — via phishing or an exposed service.
- Dropping and loading the vulnerable driver — signed, looks completely legitimate.
- Ripping out EDR hooks from kernel-mode (EDR tampering).
- Ransomware running freely on a now-blind system.
- Encryption and ransom note.
Pay close attention to step 3. During incident response (IR), analysts constantly ask: why didn't the EDR fire? The answer is simple — as far as the EDR is concerned, everything looks calm, because its eyes were gouged out at the kernel level.
(Side note — this is exactly why you shouldn't rely solely on your EDR for kernel telemetry. Keeping a separate ETW [Event Tracing for Windows] channel alive is genuinely life-saving.)
I ran a similar scenario during a red team engagement. During an assessment for Infracore (fictional company, SaaS sector), we discovered that a driver whitelisting mechanism was only checking the driver signature — not whether it had a CVE against it. We loaded a vulnerable-but-signed driver and manipulated kernel handles from there. I still remember the look on the defense team's faces when I handed over the report. "But it was signed," they said. Yeah. Exactly.
Blue Team: How Do You Actually Stop This?
Time to switch modes. Now that we understand the attacker's perspective, let's talk defense.
The first and most critical control: the vulnerable driver blocklist. Microsoft publishes a recommended blocklist alongside HVCI (Hypervisor-Protected Code Integrity). If you have that list active, known vulnerable drivers get blocked from loading outright. One thing to keep in mind: this list is static — it needs to be maintained and updated. Bookmark loldrivers[.]io right now — it's a community-maintained, up-to-date reference for known vulnerable drivers.
Second control: kernel behavior
Note: The original post ends here — the blue team section continues beyond what was provided in the source.