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.

Why does driver signing not stop this?

The most common objection to BYOVD as a threat is that Windows requires kernel drivers to be signed, so an attacker cannot simply load arbitrary code. That is true, and it is also why the technique works.

The attacker is not loading their driver. They are loading somebody else’s legitimately signed, legitimately issued driver that happens to contain a vulnerability — typically an IOCTL handler that exposes arbitrary kernel memory read or write to any process that can talk to the device. Signing verified that the vendor authored it. Signing has nothing to say about whether the code is safe.

Three consequences worth holding onto:

• Revocation is slow and partial. Certificates can be revoked, but doing so breaks every legitimate deployment of that driver, so vendors and Microsoft are cautious. The window between “known abusable” and “actually blocked in the field” is long.
• The supply is effectively unbounded. Decades of hardware utilities, RGB controllers, overclocking tools, backup agents, and abandoned products from companies that no longer exist — all signed, all loadable, many never audited.
• Nothing about the signature looks anomalous at load time. The driver is valid, correctly signed, and from a real company. There is no signal in the signature itself.

This is why the useful mental model is not “malicious driver” but “legitimate driver, malicious purpose.” Every detection that keys on the driver being bad fails; every detection that keys on the driver being unexpected in this environment works.

What telemetry actually catches it?

Given the above, the observable is the load event, and its context. Four signals, in descending order of reliability.

A kernel driver loading that has never been seen in this environment. The strongest and most durable signal, because it is indifferent to which driver the attacker picked. It requires a baseline of known-good drivers per host role — worth building, since most fleets load a small and stable set.

A driver loaded from a user-writable path. Legitimate drivers ship in system locations via installers. One loading from a temp directory, a user profile, or a download folder is almost never routine.

A driver load closely followed by security tooling going quiet. This is the sequence that matters: the load itself may be ambiguous, but a load followed within seconds by an EDR agent stopping, a service terminating, or telemetry gaps is a high-confidence pattern. Correlating those two events is more valuable than either alone.

Service creation for a driver with no corresponding software installation. BYOVD generally requires registering the driver as a service, which leaves a record that can be compared against your software inventory.

The practical point about ordering: the first two are cheap and can be running this week; the third requires correlation and is the one that converts a noisy signal into a confident one. Build the baseline first, add correlation second, and treat the blocklist as a floor beneath both rather than as the control itself.

What does the recovery actually involve?

Because this technique operates at kernel level, the containment and recovery posture differs from an ordinary endpoint incident, and getting it wrong wastes the response.

Treat the host as compromised at the kernel level. Anything running in user space on that machine — including your EDR agent and any collection script you run — is subject to manipulation by code that outranks it. Evidence gathered from the host after the load timestamp deserves low confidence.

Isolate rather than clean. Terminating processes and deleting the driver does not restore trust in the kernel. The defensible outcome is network isolation followed by rebuild from known-good media.

Preserve what you can, from outside. Memory capture and disk imaging are worth doing for investigation, but the analysis should assume an adversary who was able to interfere with collection. Centralised logs shipped before the load are your most trustworthy source.

Trace backwards, not forwards. The driver load required administrative rights, which the attacker obtained earlier through some other means. That earlier activity happened while your telemetry was still trustworthy, and it is both findable and more important — the same foothold will otherwise be reused.

Assume credential exposure. Kernel access implies access to anything in memory on that host, which typically includes credentials. Rotate what the machine held rather than waiting for evidence of misuse.

What should you check on your own fleet this week?

Four checks, each achievable without new tooling, ordered by how much they tell you per hour spent.

Is driver-load telemetry being collected at all? On many fleets the answer is no, and every detection above is unavailable until it is. This is a configuration change to existing endpoint tooling far more often than a purchasing decision.

Is the vulnerable-driver blocklist enabled, and is it actually applying? Enabled in policy and enforced on the endpoint are different states, and drift between them is common after image updates. Verify on a sample of real machines rather than in the console.

Can you list every distinct driver loaded across the fleet in the last month? If that query is impossible, the baseline work has not started. If it returns thousands of rows, the data needs normalising by hash and signer before it means anything.

Does anything alert when your endpoint agent stops reporting? This is the correlation half of the strongest detection, and it is frequently missing entirely — agents go quiet for mundane reasons and teams stop treating silence as signal. Reinstating that alert is often the single highest-value change on this list, because it catches far more than BYOVD.

The pattern across all four: none of them requires knowing which drivers are vulnerable. They rest on knowing what is normal for your environment and noticing deviation, which is why they keep working as the specific drivers in circulation change.

Where does BYOVD sit in an intrusion?

Placing the technique correctly changes how you weight the alert, and it is frequently misjudged in both directions.

BYOVD is a defense-evasion and privilege-escalation technique that appears after initial access and after the attacker already holds local administrative rights. It is not an entry vector. Nobody breaks in with a vulnerable driver — they break in some other way, escalate, and then reach for one because your endpoint agent is in the way.

Two practical consequences follow.

It is a late-stage signal, so it should carry high severity. An alert here is not “someone is probing”; it is “someone is established, privileged, and now removing my visibility.” The appropriate response is closer to a confirmed intrusion than to a suspicious-event triage.

It implies earlier activity you have not yet found. The administrative rights came from somewhere — a credential, an escalation, a misconfiguration. That earlier chain occurred while your telemetry was still trustworthy, so it is both findable and the more valuable investigation. A response that stops at removing the driver leaves the actual entry point intact.

There is also a diagnostic use worth knowing: because BYOVD is almost exclusively used to disable security tooling, its presence tells you the attacker considered your tooling worth defeating. That is a meaningful signal about intent and sophistication, and it argues for treating the incident as targeted rather than opportunistic until shown otherwise.

The framing that keeps the response proportionate: a BYOVD alert is a statement about where the attacker already is, not about what they are trying to do next.

How do you build the known-good driver baseline?

Every detection above depends on knowing which drivers legitimately load in your environment. That baseline is the work, and it is more tractable than it sounds.

Collect driver-load events fleet-wide for two to four weeks. The set is far smaller and far more stable than most teams expect — a typical corporate image loads on the order of dozens of distinct drivers, not thousands, and the list barely moves between reboots.

Segment by host role, not by fleet. Engineering laptops with virtualisation tools, finance workstations, servers, and kiosk machines have genuinely different legitimate driver sets. A single fleet-wide allowlist ends up as the union of every role, which is close to allowing everything.

Key on the file hash and the signer, not the filename. Filenames are attacker-controlled; the hash is not. Recording the signer alongside it gives you a second, coarser grouping when a vendor legitimately updates a driver.

Expect churn from three sources and plan for them so they do not generate permanent noise: vendor driver updates arriving through patching, new hardware models entering the fleet, and software installs that bundle drivers. Each is legitimate and each looks like a first-time-seen load.

The operational shape that works is alert on first-seen, then auto-baseline after review — a new driver generates one alert, an analyst confirms it corresponds to a known change, and it joins the baseline. Volume is high in week one and drops to near zero within a month, which is the pattern to expect rather than a sign the rule is broken.

One honest limitation: this is a detection, not a prevention. It tells you a driver you did not expect just loaded. In an environment where you can go further, enforcing a driver allowlist outright converts the same baseline into a preventive control — a substantially stronger position, and only available once the baseline exists.

Why is the blocklist approach insufficient on its own?

The instinctive control is a driver blocklist, and it is worth understanding precisely what it does and does not buy, because teams frequently treat it as the whole answer.

A blocklist is retrospective by construction. It contains drivers known to be abusable, which means it protects against the drivers somebody already reported. The technique’s entire appeal to an attacker is that the supply of signed, vulnerable, legitimately-issued drivers is enormous and continuously replenished — every hardware vendor, every utility, every abandoned product from a company that no longer exists. A new one costs the attacker a search, not an exploit.

Three properties follow, and they shape where the effort should go:

• Coverage is unknowable. You cannot enumerate the vulnerable drivers you have not heard of, so “the blocklist is enabled” is not a statement about your exposure.
• The behaviour is stable even when the driver is not. Loading a kernel driver from a user-writable path, a driver that has never been seen in the environment, or a driver loaded seconds before a security process dies — none of that changes when the attacker swaps drivers.
• Blocklists arrive late. The window between a driver becoming known-abusable and appearing on a list is exactly the window an attacker is exploiting it in.

So the durable detection watches the act of loading an unfamiliar kernel driver, not the identity of any particular one. Treat the blocklist as a cheap floor that removes the laziest attempts, and put your detection engineering into the invariant behaviour above it.

What should you do when the alert fires?

BYOVD sits near the end of an intrusion, not the beginning, which changes the triage posture. An attacker loading a vulnerable driver already has local administrator rights — that is a prerequisite for the technique. The alert is therefore not “someone is trying to get in”; it is “someone is already privileged and is now trying to disable your ability to watch them.”

That reframing dictates the response order. Assume your endpoint telemetry from that host is unreliable from the load timestamp onward, because defeating it is the entire purpose of the technique. Pivot to sources the host cannot influence: network telemetry, authentication logs from the domain controller, and any centralised log the host shipped before the load.

Then work backwards. The interesting question is not the driver, it is how the attacker obtained the administrative rights the driver required — the initial access and privilege escalation happened earlier, and they are still present in telemetry from before the blind spot opened.

Contain by isolating the host rather than by killing the process. A kernel-level foothold is not reliably remediable from user space, and a host in this state should be treated as needing rebuild rather than cleanup.

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, Sysmon configuration, detecting process injection and the ransomware early-warning signals that BYOVD often precedes, or browse the full Detection Engineering pillar.