14 min readOct 19, 2026

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

Bring your own vulnerable driver (BYOVD) is having a moment in endpoint security. Some of the buzz is earned. Some of it is overblown. This series unpacks both and shows the evidence for each. This piece turns the noise into specific behavior a detection team can hunt.

"EDR killer," a tool built to shut down endpoint detection and response (EDR), is one phrase doing the work of four different attacks. Detection teams treat it as a single thing and write one rule that catches one technique and misses the other three. The fix is to split the category and hunt each one on its own telemetry.

The four techniques share a goal and little else. Bring-your-own-vulnerable-driver loads a signed but flawed driver and drives kernel termination through it. Bring-your-own-installer abuses a trusted installer or upgrade path to swap the agent out. Admin-to-kernel walks an already-elevated session into Ring 0 through a documented gap. Driverless suspension never touches the kernel and freezes or filters the agent from user space. One detection cannot see all four.

The cost of conflating them is a coverage gap you cannot see. A single driver-load rule looks like coverage for "EDR killers," but the bring-your-own-installer and driverless paths leave no driver-load event at all, so that rule is silent while the agent dies.

Four Techniques, Four Hunts

Each leaves a distinct footprint. Below is the taxonomy and the observable to hunt for each.

Technique	What the attacker does	Primary observable	Telemetry source
Bring-your-own-vulnerable-driver	Loads a signed, flawed driver and issues kernel termination through it	Driver load with untrusted or first-seen signature, then a service create	Sysmon Event ID 6, System Event 7045
Bring-your-own-installer	Abuses a trusted installer or upgrade path to replace the agent	Unexpected agent upgrade or reinstall outside change windows	Install or upgrade events against a change-window baseline
Admin-to-kernel	Walks an elevated session into the kernel through a known gap	Kernel-callback removal, loss of expected kernel telemetry	EDR kernel-callback integrity reporting
Driverless suspension	Freezes or filters the agent from user space, no driver	Process suspension or telemetry-egress blocking with no driver load	Process-state events, WFP filter changes, agent heartbeat

Each hunt gets the same treatment: the observable, the telemetry source and event ID, the rule logic in plain terms, and the false-positive consideration. A detection engineer can ship the first one this week, and the rest follow as the baselines clean up.

Hunt One: Bring-your-own-vulnerable-driver

Bring-your-own-vulnerable-driver is the loudest of the four and the first one to instrument. The live LOLDrivers project tracks thousands of vulnerable signed drivers, most reachable without admin rights, a deep supply of signed-but-flawed kernel access with mature, copyable detection logic already in the public domain.

The primary observable is a driver load that does not match a trusted, previously-seen signature. Sysmon Event ID 6 is the core signal, logging each driver load with ImageLoaded, Hashes, Signed, Signature, and SignatureStatus. Any SignatureStatus other than Valid warrants investigation.

Two signature-based detections are worth building directly. The first keys on the driver-load signature status itself: alert on any driver load whose signature status is not Valid, which catches the signature-enforcement bypass and the BYOVD loader chain. The second is a first-seen detection: alert on a driver whose hash, signer, or version has never been seen on the host before, so anomalous drivers surface on first load instead of after the kill.

The false-positive consideration is real. Patch cycles introduce new signers and hashes constantly, and a first-seen rule will flare on legitimate new software. Published detection content that joins Event ID 6 driver loads against a known-bad driver table ships with an explicit false-positive warning. Plan for a tuning period and an allowlist before this rule goes to a 24/7 queue.

The SentinelOne® Annual Threat Report reaches the same conclusion for hunting at scale, urging teams to chase suspicious behavior rather than specific hashes or file names. It names kernel-mode drivers derived from POORTRY used to kill EDR and delete security files, the posture every hunt below adopts.

POORTRY is the canonical signed-driver kill primitive defenders hunt. SentinelLABS traced the STONESTOP loader and the POORTRY kernel driver, which received a process-kill IOCTL to terminate security tools. The driver carried valid WHQL signatures, later revoked under advisory ADV220005. A signed kernel driver issuing process-termination IOCTLs is the behavior this hunt exists to catch.

Know your coverage baseline before you trust prevention to backstop this hunt. The attack surface reduction (ASR) rule blocks a vulnerable signed driver from being written to disk. It does not block a driver already present from loading, so a driver the blocklist policy would block keeps running until reboot and an in-progress kill chain survives policy activation. The CodeIntegrity Operational log Event ID 3099 confirms when the blocklist policy is applied on a host. It does not catch an attack. It tells you whether your driver-blocking policy is live.

Hunt Two: The Kill Chain As a Correlation Target

The strongest version of the loud hunt is the ordered sequence, because a single event tells you far less than the chain it belongs to. Public research documents the full bring-your-own-vulnerable-driver chain and its detection points. It runs as sc.exe service create (Sysmon Event ID 1) plus a service install (System Event 7045), then a driver load at Event ID 6, then a DeviceIoControl device-control call (IOCTL), then callback removal and security-process termination.

Correlating that ordered sequence is far stronger than alerting on any single step. A service create alone is common, and a driver load alone is common. The same two within seconds, followed by an IOCTL to the freshly-loaded driver, is a fingerprint ordinary administration does not produce. Build a windowed sequence rule keyed on the service name to the image path to the device handle.

This chain shows up in real intrusions. Public threat research documents the pattern across named campaigns including Kasseika, BlackByte, and RansomHub. Attackers register a vulnerable driver as a kernel service via sc.exe, name that service to mimic a Windows update, then abuse IOCTLs for kernel primitives. The service-name masquerade is itself a tell. A "KB" service name attached to an unsigned or first-seen driver image is a high-confidence pair, so watch the join between the 7045 service-install name and the Event ID 6 image it loads.

The false-positive profile for the correlation beats the single events by design, because the conjunction is rare even when each part is common. The cost moves from alert volume to engineering effort: you need reliable event ordering and a join key, which means Sysmon tuned to capture both the service and the driver-load fields. Ship this second, after the single Event ID 6 rule is stable.

Hunt Three: Kernel-callback Removal and The Kernel-Originated Kill Loop

Admin-to-kernel needs a different lens, because the kill itself can happen entirely below the EDR's user-mode vantage point. Independent security research argues that admin-to-kernel falls short of a real security boundary and that the driver blocklist is an incomplete defense against it. Once code reaches Ring 0, it can remove the hooks the EDR relies on before it issues a kill.

Callback removal is its own observable, distinct from a process kill, and it deserves its own hunt. SOC Prime documented Qilin loading rwdrv.sys for raw memory read and write alongside a malicious hlpdrv.sys for kernel-callback manipulation, removing EDR kernel callbacks across more than 300 products. The same rwdrv.sys plus hlpdrv.sys pairing appears in Akira and other crews. The observable to instrument is the silent disappearance of kernel callbacks, a loss of expected callback telemetry from the EDR's own integrity reporting.

The termination that follows can run as a kernel-mode loop. The user-mode component enumerates running processes on a repeating, fixed-interval loop and sends the target PIDs to a masquerading kernel-service driver via IOCTL. The driver then calls ZwTerminateProcess in kernel mode, bypassing protected-process light entirely.

The fixed-interval rekill cadence is itself a signature. A user-mode agent that respawns and dies again on a repeating, fixed interval is being killed from below, not crashing on its own. That behavioral fingerprint is what you hunt when the callbacks are already gone.

The false-positive consideration is that this hunt depends on telemetry the attacker is actively trying to remove. Treat callback-integrity loss and the rekill cadence as corroborating signals rather than standalone alerts, paired with the cross-domain witnesses below.

Hunt Four: Bring-your-own-installer and Driverless Suspension

Bring-your-own-installer is the quietest of the four, and it leaves no driver-load event at all. SentinelOne documented this tamper bypass, where an attacker abuses a trusted installer or upgrade path to swap the agent out. SentinelOne shipped Local Upgrade Authorization, default-on for new customers, plus a detection rule and a hunting query against the bypass.

The hunt is an unexpected agent upgrade or reinstall outside a sanctioned change window. Your driver-load rule will never fire, because no vulnerable driver was ever loaded. The rule logic compares each event against a baseline of approved change, so you need a clean inventory of sanctioned upgrade windows and the package signers you deploy. Any agent install, uninstall, or version change outside that window is the finding. This is the hardest false-positive profile of the four, because without that inventory, normal patching drowns the queue. Build the baseline first.

Driverless suspension is the fourth class, and it abuses user-mode tricks that never touch the kernel. EDR-Freeze suspends the EDR process by racing the WerFaultSecure crash handler, entirely in user mode. EDRSilencer uses Windows Filtering Platform (WFP) filters to block EDR telemetry across roughly 16 products. These two leave different observables, so hunt them separately.

For the suspend path, watch for process-suspension state changes against the agent process that no maintenance action requested. For the filter path, watch for new WFP filters that match the agent's known egress destinations and silently drop its outbound telemetry, the EDRSilencer pattern. Legitimate updates and some VPN software touch process state and WFP filters, so scope the rules to the agent's own process and endpoints.

Why These Hunts Must Keep Pace

This work is urgent because the tooling has industrialized. SentinelLABS traced AvNeutralizer, also called AuKill, to the cybercrime gang FIN7, sold on Russian-language forums for $4,000 to $15,000 and adopted by Black Basta, AvosLocker, MedusaLocker, BlackCat, Trigona, and LockBit. That commoditization is the theme of SentinelOne's latest Annual Threat Report, which describes the industrialization of the modern cyber breach with mature automation accelerating intrusions. Public reporting tracked EDRKillShifter, a driver-based killer the RansomHub crew added to its arsenal and offered through an affiliate program, turning a hard kernel technique into a checkbox. Defenders face a market, not a single actor, so the hunts have to generalize across tools.

The Kill Is a Detection Gift

Here is the reframe most teams miss. They read the kill attempt as a defense failure and stop there. Read it instead as a high-confidence signal that ransomware is about to fire.

The Cyber Security Agency of Singapore documents the EDR-killer-then-ransomware sequence across multiple gangs, with the killer firing shortly before the ransomware. The minutes between the kill and the encryption are minutes you can act in. A correlated chain alert or a fixed-interval rekill detection that fires in that window is a live intervention point, not a post-incident artifact. The same advisory frames the whole category this way. EDR-killer activity is detectable via driver-load monitoring, suspicious process-termination patterns, and attempts to disable telemetry, three observables that map cleanly to the four hunts above.

There is a rarer, cleaner signal worth a dedicated rule. Independent researcher Peter M. flagged Windows Event ID 7031, a service that terminated unexpectedly. Scoped to security services, it is an ideal detection candidate, and quiet enough to alert on directly. A forced kernel termination often leaves a crash trail the service control manager records anyway. The kill leaves a fingerprint even when it succeeds.

When the Kill Succeeds nyway

Assume the kill works. You still are not blind. A successful kill produces an absence-of-signal you can alert on directly: agent-health drop, heartbeat loss, and the absence of expected telemetry, all findings alongside your suspicious-event rules. The SentinelOne Annual Threat Report describes one SaaS compromise that ran for 71 days until an automated detection correlated activity a manual review of sign-in logs had missed. Absence-of-signal correlation is exactly the kind of work a human queue rarely sustains alone.

Cross-domain telemetry survives the kill. Once the endpoint sensor is silenced, logging that operates independently of the agent remains as a witness, including network-based detection and cloud-based security monitoring. The attacker can kill the agent on one host. They cannot kill the firewall logs, the identity provider, and the cloud control plane at the same instant, and those sensors still record the lateral movement, credential use, and command-and-control that precede ransomware. Route them into the same hunt so the endpoint blind spot does not become total.

The false-positive consideration for the absence case is the most demanding of all. Absence-of-signal detection requires a reliable baseline of expected heartbeat, or a maintenance reboot looks like an attack. Tie the heartbeat-loss rule to the change-window inventory you built for bring-your-own-installer. A silent agent on a host with no scheduled maintenance, correlated with network or identity activity, is the alert.

Honest Tuning Notes

The order you ship it in decides whether analysts trust it, so sequence the rollout by signal quality. Start with the loud bring-your-own-vulnerable-driver hunt, because Sysmon Event ID 6 is low-volume and the rules already exist. Add the chain correlation next, since correlated sequences cut the false positives single events generate. Save the absence-of-signal and unexpected-upgrade hunts for last, after the baselines clean up. Shipping them out of order floods analysts and teaches them to ignore the alerts.

Retire the Wrong Scoreboard

Stop scoring on "did the kill succeed." Score on "did we catch the kill." Catching it early gives the response team the minutes that decide whether files get encrypted.

Deploy this on Monday. Turn on Sysmon Event ID 6 logging and the untrusted-driver and first-seen rules for the loud class. Build the service-create-to-driver-load-to-termination correlation for the chain. Add a dedicated Event ID 7031 rule and an agent-health heartbeat monitor for the absence case. Wire network, identity, and cloud telemetry into the same view so a silenced sensor is not a silenced investigation.

The shift is from waiting for a verdict to running a hunt. That posture depends on an agent that keeps running and keeps telemetry flowing under attack, so demand the survivability test data before trusting any vendor's claim, ours included.

Why This Is the Work SentinelOne Exists to Do

Running these hunts in the minutes before encryption is where the contest is won, and that window is exactly what SentinelOne built Purple AI® to operate inside. Its Agentic Investigation capability runs the kind of zero-click investigation these hunts describe. It correlates the driver load, the service install, the callback removal, and the silence that follows, then renders a verdict and a response at machine speed. The kill attempt becomes the trigger, and the investigation is already running while the attacker still believes the sensor is blind.

Most security teams cannot run four hunts around the clock, and the attacker knows which hours are thin. Wayfinder, SentinelOne's managed detection and response practice, runs them for you, putting human hunters and autonomous investigation on the same telemetry every hour of every day. The kill is the middle of the story, and the platform is built to catch it there.

Step back across the whole series. It traced the EDR killer through four moves. A market with a price list. An industry with suppliers and resale. The trust gap it operates inside. And the hunts that catch it. One idea held the whole way through. A defender who watches behavior beats one who chases the binary of the week. Attackers turned the kill into a product. The answer is the one move a supplier cannot re-skin. It is the reach into the kernel to terminate what defends the host. Defenders are the protagonists of that story, and the platform exists to keep them there. A safer future for humanity is built by the people who refuse to look away when the kernel turns hostile.