Bring Your Own Vulnerable Driver: What Detection Teams Should Actually Hunt

SentinelOne Splits EDR-Killer Attacks Into Four Distinct Hunts

A detection-engineering writeup published by SentinelOne on October 19, 2026 argues that most defenders are hunting Bring Your Own Vulnerable Driver (BYOVD) attacks the wrong way — by treating every EDR-killing technique as a single, generic "driver abuse" problem. The piece, titled Bring Your Own Vulnerable Driver: What Detection Teams Should Actually Hunt, makes the case that EDR-killer attacks actually fall into four behaviorally distinct categories, each with its own telemetry fingerprint, and that collapsing them into one detection rule lets at least one category slip through undetected every time. Rather than profiling another ransomware incident, the report is aimed squarely at detection teams and SOC analysts, proposing concrete hunting logic for each category so that an EDR kill becomes a tripwire rather than a blind spot.

The framing matters because BYOVD has become a default pre-ransomware step across the criminal ecosystem — SentinelOne's writeup references tooling and tactics tied to FIN7, Black Basta, AvosLocker, MedusaLocker, BlackCat, Trigona, LockBit, RansomHub, Kasseika, BlackByte, Qilin, and Akira, among others. CosmicBytez Labs has previously covered specific incidents where ransomware crews deployed BYOVD and EDR-killer frameworks (Goddamn ransomware's PoisonX driver, The Gentlemen's GentleKiller suite). This report is different in kind: it is a behavioral-hunting methodology, not an incident post-mortem, and it is worth covering separately because the underlying argument — that "EDR killer" is really four different attack primitives — changes how a detection rule should be written.

Report Details

The Four Hunts

SentinelOne's central argument is that "kill the EDR" is not one technique — it is four, and each leaves a different trail.

Hunt 1: Bring-Your-Own-Vulnerable-Driver (BYOVD)

This is the namesake technique: an attacker with local administrative access loads a signed but flawed kernel driver — one with a known vulnerability that lets user-mode code execute arbitrary operations in Ring 0 — specifically to terminate protected security processes. Because the driver carries a valid signature, it can load even on systems enforcing driver signature checks, unless that specific driver has been explicitly blocklisted.

What to hunt: Driver-load events (Sysmon Event ID 6) where the signature status is not cleanly "Valid," paired with first-seen driver hashes or signer certificates on a given endpoint. SentinelOne also points to Microsoft's vulnerable-driver blocklist enforcement (Event ID 3099, confirming the blocklist policy applied) as a signal worth correlating — a blocklist hit followed shortly by a different unsigned-or-oddly-signed driver load is a strong indicator of an attacker iterating past a blocked driver.

Hunt 2: Bring-Your-Own-Installer (BYOI)

Rather than loading a malicious driver, this technique abuses the trusted upgrade or installation path of the security agent itself — swapping in a stripped-down or back-doored binary during what looks like a routine update or reinstall. No kernel exploit is needed because the attacker is working through a channel the agent already trusts.

What to hunt: Agent install or upgrade events (Windows System Event ID 7045, service installation) that fall outside approved maintenance windows, or that don't match the organization's patch-management inventory. This hunt only works if a baseline of legitimate update windows already exists — without it, there's nothing to compare against.

Hunt 3: Admin-to-Kernel Escalation

Here the attacker already has local administrator rights and escalates to kernel level using a documented vulnerability — not necessarily by bringing in a new driver at all, but by abusing a flaw in a driver or component already present on the system. The goal is the same as BYOVD (disable EDR self-protection at the kernel boundary), but the mechanism and artifacts differ.

What to hunt: Loss of EDR kernel-callback integrity — i.e., the security agent's own self-monitoring reporting that its registered kernel callbacks have been removed or tampered with — combined with a fixed-interval "rekill" cadence, where a protected process is repeatedly respawned and killed at regular intervals as the attacker's tooling re-asserts control.

Hunt 4: Driverless Suspension

The most evasive of the four: no kernel driver and no admin-to-kernel escalation at all. The attacker suspends or freezes the security agent entirely from user mode, or blocks its ability to phone home by manipulating Windows Filtering Platform (WFP) filters to cut off telemetry egress. Tools in this category — including techniques resembling EDR-Freeze and EDRSilencer — never touch the kernel, which makes them invisible to any hunt that only looks for driver loads.

What to hunt: Unexplained process suspension of the security agent, unexpected changes to WFP filter state, and — critically — loss of agent heartbeat without a corresponding uninstall, crash, or reboot event. SentinelOne frames this as an "absence of signal" detection problem: the hunt isn't for a malicious event, it's for the quiet disappearance of an expected one.

Impact Assessment

Recommendations

For Detection Engineering Teams

• Build four separate hunting rules, not one — map each to the telemetry SentinelOne outlines (driver-load signature status, install/upgrade timing, kernel-callback integrity, and agent heartbeat/WFP state)
• Correlate event sequences rather than alerting on isolated indicators; a blocklist hit (Event ID 3099) immediately followed by a new unsigned driver load is far more actionable as a pair than either event alone
• Treat an EDR kill as a high-confidence pre-ransomware signal, not a dead end — route it to immediate triage rather than a lower-priority queue, since it may precede encryption by only minutes

For IT and Security Administrators

• Keep the Microsoft vulnerable-driver blocklist enabled and current, and confirm Event ID 3099 is actually being generated and forwarded, not just assumed to be active
• Establish and document approved agent update/maintenance windows so Bring-Your-Own-Installer activity has a baseline to stand out against
• Restrict who can install or load unsigned or newly-signed drivers; limit local administrator rights wherever the business allows it

For Security Leadership

• Ensure security logs and agent heartbeat data are shipped to a remote, tamper-resistant collector — if the local agent can be killed, the attacker should not also be able to erase the evidence that it was killed
• Ask vendors directly how their product reports kernel-callback integrity loss and WFP filter tampering, and whether that telemetry reaches the SIEM independent of the agent's own health status
• Fold EDR-kill detection into ransomware-readiness tabletop exercises — the report's point is that these minutes are actionable, but only if a response plan already exists for "the EDR just went dark"

Key Takeaways

1. SentinelOne's October 19, 2026 writeup reframes "EDR killer" detection into four distinct behavioral hunts: BYOVD, Bring-Your-Own-Installer, Admin-to-Kernel escalation, and Driverless Suspension.
2. Each category leaves a different telemetry fingerprint — driver-load signature anomalies, off-window agent installs, kernel-callback integrity loss, or silent agent-heartbeat drop — and a detection program tuned for only one will miss the others.
3. Tooling and tactics referenced span POORTRY/STONESTOP, AvNeutralizer (AuKill), EDR-Freeze, EDRSilencer, and EDRKillShifter, used across ransomware operations including FIN7, BlackCat, LockBit, RansomHub, Qilin, and Akira.
4. The report treats an EDR kill as a detection gift rather than a failure — the window between the kill and ransomware deployment is time defenders can still act in, provided the kill itself triggers an alert.
5. This piece is explicitly methodology-focused, distinguishing it from prior incident coverage of BYOVD-equipped ransomware strains — it's a blueprint for how to hunt, not a report on who was hit.
6. Defenders should prioritize cross-domain telemetry (network, identity, cloud control-plane logs) as a backstop, since a successfully killed EDR agent cannot be relied upon to self-report its own death.

Sources

• Bring Your Own Vulnerable Driver: What Detection Teams Should Actually Hunt (SentinelOne)