Detecting BYOVD Attacks

BYOVD — bring your own vulnerable driver — is how modern intrusions turn off the defenses before the real damage. The attacker installs a legitimately signed but vulnerable kernel driver, exploits it to run code in the kernel, and from there disables EDR and antivirus, dumps credentials, or clears the path for ransomware. Because the driver is signed, it loads without complaint. The detection is the driver load and the service creation behind it. This guide ships the Sigma rule, the LOLDrivers reference, and the kernel hardening that stops it.

BYOVD maps to MITRE ATT&CK T1068 — Exploitation for Privilege Escalation and T1562.001 — Impair Defenses: Disable or Modify Tools. It is the precursor that often precedes LSASS credential dumping — disable the guard, then take the secrets.

What is a BYOVD attack?

Windows trusts signed kernel drivers. BYOVD abuses that trust: rather than signing malware (hard, and revocable), the attacker brings a driver that is already validly signed by a legitimate vendor but contains a vulnerability. They load it, exploit the flaw to execute their own code in kernel space, and now operate below the level most security tooling can observe — able to kill EDR processes, unhook monitoring, and manipulate the system at will.

This is why BYOVD has become a staple of ransomware and advanced intrusions: it is the “turn off the alarms” step. The driver is trusted, so the only reliable signals are which driver loaded and whether it should have.

What does a BYOVD attack look like in telemetry?

The detectable moments are the install (7045) and the load (Sysmon 6). Match the driver’s hash and name against the LOLDrivers catalog and your own allowlist, and a known-bad or never-before-seen driver loading is a high-fidelity alert.

How to detect BYOVD attacks

The core rule flags a kernel driver load that matches a known-vulnerable driver or is otherwise anomalous, using Sysmon Event ID 6.

title: Known-Vulnerable or Unsigned Kernel Driver Loaded
id: 4d8c1f93-darkpwn-illustrative
status: experimental
logsource:
  product: windows
  category: driver_load
detection:
  known_vulnerable:
    ImageLoaded|endswith: ['\rtcore64.sys','\dbutil_2_3.sys','\gdrv.sys','\procexp152.sys']
  unsigned:
    Signed: 'false'
  condition: known_vulnerable or unsigned
falsepositives:
  - Rare legitimate driver installs (allowlist by hash; maintain a known-good list)
level: high

How to test your BYOVD detection

In an isolated VM you own:

1. Load a benign test driver and confirm Sysmon Event ID 6 and the service-creation event appear.
2. Match a known LOLDrivers entry’s hash in a controlled test and confirm the rule fires.
3. Confirm your allowlisted, expected drivers do not trip the rule.
4. Verify the Microsoft vulnerable-driver blocklist blocks a known-bad driver outright.

How to prevent BYOVD attacks

• Restrict who can install drivers to controlled, audited admin processes.
• Keep the blocklist updated — new vulnerable drivers are added regularly.
• Monitor EDR/AV health as a detection of the BYOVD payoff.

Common BYOVD detection mistakes

• Trusting the signature. Signed-but-vulnerable is the entire technique.
• No driver-load telemetry. Without Sysmon EID 6 / 7045, the load is invisible.
• No allowlist or LOLDrivers matching. You miss the known-bad and the novel.
• Not watching EDR health. The driver load’s purpose is to silence it.

BYOVD detection checklist

1. Collect kernel driver-load events (Sysmon Event ID 6) and service installs (7045).
2. Match loaded drivers against the LOLDrivers list and your allowlist.
3. Alert on known-vulnerable, unsigned, or never-before-seen drivers.
4. Correlate driver loads with EDR/AV health and tampering.
5. Enable the Microsoft vulnerable-driver blocklist and HVCI/memory integrity.
6. Enforce a WDAC driver allowlist of expected drivers only.
7. Restrict driver installation to controlled admin processes.
8. Test detection with a benign driver and a known LOLDrivers hash in a lab.

The takeaway

Detecting BYOVD means watching kernel driver loads and service creations, matching them against the LOLDrivers list and your allowlist, and chaining them to EDR-tampering — while preventing with the Microsoft blocklist, HVCI, and WDAC. The driver is signed; trust the list, not the signature. Continue with LSASS credential dumping detection and Sysmon configuration, or browse the full Detection Engineering pillar.