BYOVD Blinds Your EDR Before the Ransomware Runs. The Driver-Load Event Is Your Last Clean Detection Window

Consider a representative sequence. A legitimately signed kernel driver loads on a Windows host at 0200, and less than a minute later the EDR sensor on that box stops sending heartbeats. The attacker didn’t forge a signature or necessarily exploit Windows itself — what it exploited was a vulnerability in an old, legitimately signed third-party driver. The driver’s Authenticode signature is valid, the vendor is a real hardware or antivirus company, and the file can pass permissive allow-by-signed or broad publisher policies — because it is signed code, often an older signed version exposing a kernel-write or process-terminate primitive. That is Bring Your Own Vulnerable Driver, and per ESET’s March 2026 research it has moved from specialist tradecraft into commodity ransomware operations: 54 distinct EDR-killer tools abusing a shared pool of 35 signed drivers, out of nearly 90 EDR killers the team catalogued. The driver-load event is the last common BYOVD-specific, high-confidence telemetry point before the vulnerable driver is exercised against the security product, and that window is short, because the driver’s entire purpose is to blind the telemetry you would otherwise use to see it.

TL;DR

• BYOVD has gone commodity: ESET catalogued 54 EDR-killer tools abusing a shared pool of 35 legitimately signed but vulnerable drivers, which can pass permissive signed-code or broad publisher policies because the publisher signature is genuine — even though the authorized binary exposes an abusable kernel capability.
• The attack sequences monitoring against protection on purpose — the user-mode killer installs and starts the signed .sys as a service, opens its device object, and often issues an IOCTL that exposes an abusable privileged operation — arbitrary kernel memory access, callback tampering, or direct protected-process termination — killing or blinding the EDR within seconds — so the driver-load event is your last common BYOVD-specific, high-confidence detection window — forward it with low latency so it’s preserved off-host before the attacker can disrupt Sysmon, event logging, or the forwarder, and so an automated response still has a chance to act before encryption begins.
• Build detection on Sysmon Event ID 6 matched against LOLDrivers by SHA-256 content hash (IMPHASH as supplementary clustering signal, not a substitute), never on filename alone — and first verify your Sysmon config actually populates the Hashes field, since a missing SHA-256 silently causes the lookup to return no match, which reads the same as clean.
• Pair driver-load detection with an EDR heartbeat-gap correlation to catch driverless variants (EDRSilencer blocks the sensor’s outbound traffic via WFP; EDR-Freeze suspends it), and don’t attribute by driver — the same .sys is reused across unrelated tools.
• Layer the hardening: enable Microsoft’s blocklist today (but it’s deliberately not exhaustive and only stops known drivers), plan HVCI and WDAC/App Control allowlisting for locked-down populations, and accept that driver attribution and compatibility inventories make full rollout a multi-quarter effort.

That timing problem is the core defensive problem. The driver-load event should leave the host promptly — not because killing the EDR automatically deletes it (Sysmon writes Event ID 6 to its own operational log, and an admin-level attacker has to take a separate step to erase it), but because that attacker may next disable Sysmon, stop the forwarder, or clear the logs, and because a batched alert that lands after the encryptor has run is a post-mortem, not a defense. Low-latency forwarding preserves the signal and enables a response workflow — but forwarding alone doesn’t stop ransomware; either that response is automated or a preventive control blocks the driver in the first place.

What actually happens on the box

Strip out the operator mechanics and the shape is simple. A user-space process — dropper, loader, ransomware affiliate’s tool of the week — writes a known-vulnerable .sys file to disk, registers it as a kernel service, and starts it. Windows loads it because it satisfies the applicable kernel-signing policy and hasn’t been denied by the vulnerable-driver blocklist or an App Control policy. Many abused drivers carry Microsoft dashboard signatures obtained through hardware certification or attestation; some legacy cross-signed drivers stay loadable under documented exceptions — notably an end-entity certificate issued before July 29, 2015 that chains to a supported cross-signed CA (also a machine with Secure Boot off, or one upgraded from an earlier Windows release). The tool then opens a handle to the driver’s device object and issues the specific IOCTL that hands it an abusable privileged operation: an arbitrary kernel primitive like write-what-where, callback tampering that strips the kernel callbacks (PsSetCreateProcessNotifyRoutine and friends) your EDR registers to see process creation, or a direct “terminate this PID” call. With that, it kills or deafens the protected processes and hands the box to whatever runs next.

No signature was forged, and no exploit chain was fired against Windows itself — but something was exploited: the vulnerability in that old signed driver. The driver satisfied the host’s applicable code-integrity policy even though the authorized binary exposed a dangerous kernel capability — technically correct, operationally catastrophic. This is why the problem lives primarily in the SI and CM families, with SC and supply-chain controls as supporting layers, rather than in Windows patching alone: you are not missing a Windows patch, you are trusting a valid signature on a file whose vulnerable behavior is the feature being abused — and often one your own fleet installed for a legitimate reason and never removed.

ESET’s taxonomy is worth internalizing because it tells you where your detection has to reach. They bucket the killers into script-based killers (seven variants leaning on taskkill, net stop, sc delete), the dominant BYOVD tools (54), anti-rootkit utility abuse (fifteen, misusing legitimate GMER/PC Hunter/HRSword-style tools), and the driverless approaches. That last group is the one people forget. EDRSilencer doesn’t load or exploit a vulnerable third-party driver; it uses the Windows Filtering Platform — whose filters are enforced by kernel-mode components of the networking stack — to block the sensor’s outbound connection to its cloud backend, so the agent may keep running locally while losing its ability to report telemetry or receive backend instructions. EDR-Freeze doesn’t bring a driver either; it abuses the built-in Windows Error Reporting path and WerFaultSecure.exe, keeping the EDR suspended by interrupting the dump workflow before it resumes the target. Different mechanism, same outcome, and if you built your entire program around driver-load detection you will miss both. I wrote about EDR-Freeze separately; the point here is that BYOVD is the biggest slice, not the only one.

One finding from the ESET writeup that changes how you triage: driver-based attribution is mostly noise. The same .sys gets reused across unrelated tools, and a single tool migrates between drivers as blocklists catch up. TfSysMon.sys (the old ThreatFire monitor) shows up under multiple families with no relationship to each other; aswArPot.sys (an Avast anti-rootkit driver) is abused by the Kill-Floor killer; BdApiUtil.sys from Baidu’s AV rides along in several. Seeing a known-abused driver load tells you a high-risk kernel component is active and an EDR-killer execution path may now be available — not, by itself, that a killer is running or which crew is behind it. That same driver may be loading for legitimate legacy hardware, storage, or management software, so building your incident narrative around the driver’s vendor will send you down the wrong road.

The detection, in a real SIEM

Sysmon Event ID 6, driver loaded. That is the event. It is the single most useful signal for BYOVD, and it comes from an agent (Sysmon) separate from your EDR — which may preserve an independent telemetry path when the attacker has disabled the EDR but not yet stopped Sysmon, cleared the event log, or cut forwarding. Sysmon doesn’t hide itself and an admin-level attacker can still stop or reconfigure it, so this is a design advantage, not immunity — and it only helps if you configured hashing and ship with low latency.

The starting detection everyone builds is a lookup join: take the ImageLoaded and Hashes fields off every EID 6 and match them against the community LOLDrivers list of known-vulnerable drivers. Splunk ships this as a hunting detection (Windows Vulnerable Driver Loaded), disabled by default, joining EID 6 against a loldrivers lookup on ImageLoaded and filtering is_driver=TRUE — but its published query matches on the driver’s filename/path (driver_name AS ImageLoaded), not its hash, and it ships as a scheduled hunt rather than a real-time alert. Treat it as a starting point: for BYOVD you want SHA-256 matching evaluated continuously or at low latency, not a periodic hunt over a rename-sensitive field. Elastic’s current prebuilt driver rules are complementary rather than a drop-in equivalent: First Time Seen Driver Loaded baselines a driver’s original filename and signer on Elastic Defend driver events (in the dll.* namespace, not file.pe.imphash), and Untrusted Driver Loaded flags unsigned or untrusted drivers — neither implements the Sysmon EID 6 SHA-256-to-LOLDrivers correlation described here, so you’d build that as an indicator-match against a LOLDrivers hash index. The lookup-join approach is fine as a v1, but it breaks in two specific ways the first week, and you need to fix both before it’s worth paging on.

Match primarily on SHA-256; never rely on filename alone. The .sys filename is attacker-controlled. Rename RTCore64.sys to svchost_helper.sys and a filename-based rule goes dark while the identical vulnerable code loads. The driver’s SHA-256 content hash is the reliable identifier — it’s what you match against LOLDrivers’ known-vulnerable samples, and it doesn’t change under a rename. The import hash (IMPHASH) is useful supplementary signal for clustering related drivers, but it’s a hash of the import table, not the file, so treat it as corroboration, not a substitute for the content hash. But be clear about what a hash buys you: SHA-256 gives high-confidence identification of an exact catalogued sample — it’s precision, not recall. A different vulnerable version, a recompiled or lightly modified binary, an uncatalogued driver, or a tool switching to another driver all slip a hash-only rule (any change to the binary yields a new hash), which is why signer, product, version, prevalence, load path, and install activity still carry the coverage for variants and unseen drivers. Which surfaces the second problem: Sysmon records hashes only for the algorithms named in the global HashAlgorithms setting — a single entry at the root of the config, not something toggled under the driver-load filter. A default or inherited configuration may hash with SHA-1 only, and a custom XML policy that omits the element can produce no hashes at all, so a SHA-256 lookup silently finds no match. Event ID 6 also carries signature information, though Sysmon generates that information asynchronously for performance reasons. Verify that Event ID 6 is collected and that HashAlgorithms includes SHA-256 — check the running config with sysmon -c — because a missing hash doesn’t return a clean verdict, it just returns no match, which reads the same as safe on a dashboard.

Volume is manageable here, which is the nice part. Event ID 6 is normally far lower-volume than process-creation or image-load telemetry — Microsoft treats driver-load monitoring as relatively rare and high-value — but the expected rate varies with boot cadence, hardware, endpoint products, and update systems, so measure it by host role rather than assuming it’s near-zero. A load of a driver that’s never appeared in your baseline is genuinely worth attention. The noise, when it comes, is bursty and predictable: Patch Tuesday driver rollups, GPU driver updates, the EDR agent updating its own kernel components, VPN and backup agents reloading. Resist the urge to collapse that churn into a signer allowlist — the whole threat model here is a legitimately signed driver, and a vendor often signed both the safe and the vulnerable version, so suppressing a certificate can suppress the exact driver you’re hunting. Identify by SHA-256 against known-vulnerable samples first; use signer plus product and version as context, then filename and load path, host role and expected driver inventory, and the correlated install activity. Signer is a tuning dimension, never a blanket pass.

The real false positives are the awkward ones. Anti-cheat drivers on any host a developer games on. Legitimate copies of the exact utilities the anti-rootkit-abuse category weaponizes — if your IR team actually runs PC Hunter or GMER, your own responders will trip the rule, and that ticket lands at 0300 the one night it matters. And the LOLDrivers list itself carries drivers that some environments still run in production for real reasons, particularly older storage and RAID management stacks in server fleets that nobody has repackaged since the vendor got acquired. Tune by drilling into the driver’s hash, signer, product, and version — and, because Event ID 6 doesn’t record which user-mode process loaded the driver, by correlating it with the service-creation, HKLM\SYSTEM\CurrentControlSet\Services registry, and process-creation telemetry that shows how it got there — rather than dropping the driver from the list wholesale.

Now the part most teams get wrong before they get it right: the shipping latency. If Sysmon writes EID 6 to the local event log and your forwarder batches every 30 or 60 seconds, the alert reaches your indexer well after the killer has run — and if the killer also clears logs, you may never index it at all. For BYOVD specifically, configure and measure low-latency forwarding on the Sysmon operational channel (universal forwarder, Elastic Agent, or a WEF/WEC subscription). Be honest about the numbers: WEF’s built-in Minimize Latency profile still batches on a 30-second timeout, and beating that takes custom subscription settings plus end-to-end load testing across the forwarder, collector, network, and SIEM pipeline — none of it a hard real-time guarantee. The goal is to preserve the signal and, ideally, trigger automated containment, not to hand an analyst a host to save by hand in the seconds the killer needs. Time skew makes this worse to reconstruct after the fact: if the host clock and the SIEM disagree by even a few seconds, your “driver load then sensor silence” correlation window gets fuzzy exactly when you need it tight. Verify the Windows Time hierarchy, endpoint clock skew, and SIEM timestamp normalization before you rely on event ordering.

Which brings the second-order detection, the one that catches the driverless variants too: the sensor going silent. Alert on EDR heartbeat gaps. A known-vulnerable or otherwise unexpected driver load, followed by your EDR agent’s process terminating or its cloud check-ins stopping — once you’ve excluded host shutdown, sleep, network loss, maintenance, and agent upgrades — can be a high-confidence correlation. Set the gap interval from the product’s measured heartbeat and ingestion cadence, not a universal one- or two-minute window. Build it as a correlation, not two separate rules nobody joins. The gap in your own telemetry is the tell.

Hardening, and where it gets brittle

Microsoft’s vulnerable driver blocklist is enabled by default on all devices since the Windows 11 2022 update, refreshes quarterly, and ships those updates through the monthly Windows servicing. On your Windows 10 (now ESU/LTSC/legacy) estate and Server builds, don’t infer protection from HVCI or build number — verify the configured state, whether enforcement is actually active, and whether the host has pulled the latest list. But understand what you’re getting: a curated Microsoft list, updated four times a year, that Microsoft itself says isn’t guaranteed to contain every vulnerable driver — it deliberately holds some blocks back to avoid breaking functionality, and the downloadable version of the list is usually more complete than the copy delivered in the OS. It stops the popular, well-known drivers. It does not stop a fresh vulnerable driver an operator found last month that hasn’t been reported yet. Necessary, not sufficient. Pair it with Microsoft’s ASR rule Block abuse of exploited vulnerable signed drivers, which works one step earlier — it stops an application from writing a vulnerable signed driver to disk in the first place, though it won’t stop one already present from loading, which is what the blocklist and HVCI are for.

HVCI (memory integrity) is a stronger complementary layer — it isolates kernel code-integrity enforcement, restricts executable kernel memory, and is one of the conditions (alongside Smart App Control and S mode) under which Windows enforces the built-in blocklist — but it’s not a comprehensive deny for every signed vulnerable driver, and it’s also where enterprise plans go to die. HVCI can prevent incompatible drivers from loading, may not auto-enable where incompatible drivers are present, and can cause application, device, or boot failures if you deploy it without compatibility testing. Compatibility failures can involve older signed drivers and kernel components associated with anti-cheat, VPN, storage, or virtualization products. On a clean modern workstation fleet you can probably turn it on. On a mixed estate with a long tail of legacy line-of-business software, expect a compatibility inventory first and a rollout measured in quarters. This is why HVCI adoption is so uneven: the control is good, the migration is genuinely painful, and the pain scales with how old and how weird your driver inventory is.

The strongest deterministic control, where operationally feasible, is an enforced App Control (WDAC, now App Control for Business) driver allowlist. Instead of blocking known-bad, you permit only the drivers your environment is supposed to run and refuse everything else, which closes the unknown-vulnerable-driver path the blocklist can’t. The operational cost depends on how you write the rules: a hash-only policy is brutal to maintain because every binary update changes the hash and forces a policy update, while publisher-based rules (FilePublisher, WHQLFilePublisher, signer-plus-version) let legitimate product updates through without one. The catch is that a broad publisher or certificate rule can also authorize a vulnerable legacy version signed by that same publisher — it still blocks code outside the trust boundary, it just doesn’t close this BYOVD path — so constrain driver rules with the original filename and a minimum version, and fall back to explicit hashes or denies where you must. Scope it to your locked-down populations first. A FedRAMP High authorization boundary, a high-assurance administrative environment, or a PAW fleet is a reasonable place to enforce hard App Control; a 5,000-seat commercial workforce with BYOD-adjacent laptops is not, at least not on day one.

Control mapping

Treat the table as implementation rationale, not an authoritative one-to-one NIST mapping. The mapping that matters most is SI-4 to SI-3. Your monitoring control has to fire fast enough to be useful before your malicious-code-protection control gets turned off, because the attacker sequenced it that way on purpose. If your driver-load telemetry batches and your EDR is the thing being killed, you have two controls that both look green on the SSP and neither of which fires when it counts.

Get Sysmon EID 6 hashing on, ship it with low latency, correlate it against sensor silence, and enable the blocklist today while you plan the HVCI and App Control work. The commodity killers are loudest at the driver-load event. Make sure you’re listening there before the lights go out.

Sources

• EDR killers explained: Beyond the drivers (ESET WeLiveSecurity)
• 54 EDR killers use BYOVD to exploit 35 signed vulnerable drivers and disable security (The Hacker News)
• ESET Research: A deep dive into EDR killers (ESET Newsroom)
• Detection: Windows Vulnerable Driver Loaded (Splunk Security Content)
• LOLDrivers — Living Off The Land Drivers (community known-vulnerable driver catalogue)
• Microsoft recommended driver block rules (Microsoft Learn)
• BYOVD attack surge: 54 EDR killers exploiting 35 signed vulnerable drivers in 2026 (Bellator Cyber)
• Sysmon — Event ID 6: Driver loaded (Microsoft Learn / Sysinternals)
• Attack surface reduction rules reference — Block abuse of exploited vulnerable signed drivers (Microsoft Learn)
• Windows Filtering Platform architecture (Microsoft Learn)
• EDR-Freeze: a tool that puts EDRs and antivirus into a coma state (Zero Salarium)
• Elastic prebuilt rule: First Time Seen Driver Loaded (Elastic Security)
• Elastic prebuilt rule: Untrusted Driver Loaded (Elastic Security)
• Driver signing policy — kernel-mode code signing since Windows 10 1607 (Microsoft Learn)
• Understand App Control for Business policy rules and file rules (Microsoft Learn)
• Enable memory integrity (VBS / HVCI) (Microsoft Learn)
• Use Windows Event Forwarding to assist in intrusion detection (Microsoft Learn)
• Windows Time service tools and settings (Microsoft Learn)

This post was engineered and validated through a multi-agent AI workflow — drafted, adversarially reviewed by several independent models, checked against primary sources, and given a human review before publishing. See an inaccuracy, or found this useful? Leave a comment below — corrections and feedback are read and shape what comes next.