SentinelOne: Stop Treating 'EDR Killer' as One Attack, Hunt Four
SentinelOne argues that the phrase "EDR killer" lumps together four different attacks, and that detection teams who write a single rule end up catching one technique and missing the other three. In a new blog post, the company proposes splitting the category and hunting each technique on its own telemetry.
- SentinelOne says "EDR killer" covers four distinct techniques: BYOVD, bring-your-own-installer, admin-to-kernel and driverless suspension.
- A single driver-load rule misses the installer and driverless paths, which leave no driver-load event.
- Sysmon Event ID 6 with a non-Valid SignatureStatus or a first-seen driver is the core BYOVD signal, but needs tuning and an allowlist.
- Correlating service creation, driver load and IOCTL in sequence is stronger than alerting on any single step.
- Callback-integrity loss and fixed-interval agent rekills should be treated as corroborating signals for admin-to-kernel attacks.
Four techniques, one label
According to SentinelOne, the four techniques share a goal, shutting down endpoint detection and response (EDR) tooling, and little else. The company describes them as follows:
- Bring-your-own-vulnerable-driver (BYOVD): 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.
The cost of conflating them is a coverage gap that is hard to see. A single driver-load rule looks like coverage for "EDR killers," but the installer and driverless paths leave no driver-load event at all, so the rule stays silent while the agent dies.
Hunt one and two: the driver and the chain
SentinelOne calls BYOVD the loudest of the four and the first to instrument. It points to the LOLDrivers project, which tracks thousands of vulnerable signed drivers, most reachable without admin rights. The core signal is Sysmon Event ID 6, which logs each driver load with fields including ImageLoaded, Hashes, Signed, Signature and SignatureStatus. Any SignatureStatus other than Valid warrants investigation, the company says.
It suggests two signature-based detections: alert on any driver load whose signature status is not Valid, and alert on a driver whose hash, signer or version has never been seen on the host. The second rule will flare on legitimate new software after patch cycles, so SentinelOne advises a tuning period and an allowlist before sending it to a 24/7 queue.
The company also warns about relying on prevention. The attack surface reduction (ASR) rule blocks a vulnerable signed driver from being written to disk, but it does not stop a driver already present from loading. CodeIntegrity Operational log Event ID 3099 only confirms that the blocklist policy is applied on a host.
The second hunt correlates the full ordered chain: sc.exe service create (Sysmon Event ID 1) plus a service install (System Event 7045), a driver load at Event ID 6, a DeviceIoControl call (IOCTL), then callback removal and security-process termination. SentinelOne says the sequence is far stronger than any single step, and notes that public research documents it in campaigns including Kasseika, BlackByte and RansomHub. A service name mimicking a Windows update, such as a "KB" name attached to an unsigned or first-seen driver image, is described as a high-confidence pair. The trade-off is engineering effort: the rule needs reliable event ordering and a join key.
Hunt three: callbacks and the kernel kill loop
For admin-to-kernel, SentinelOne cites independent research arguing that the step is not a real security boundary and that the driver blocklist is an incomplete defense. Once code reaches Ring 0, it can remove the hooks an EDR relies on before issuing a kill, so callback removal deserves its own hunt.
The post says SOC Prime documented Qilin loading rwdrv.sys alongside hlpdrv.sys, removing EDR kernel callbacks across more than 300 products, and that the same pairing appears in Akira and other crews. The observable is the silent disappearance of kernel callbacks, seen as a loss of expected telemetry in the EDR's own integrity reporting.
The termination can run as a kernel-mode loop: a user-mode component enumerates processes at a fixed interval and sends target PIDs to a masquerading driver via IOCTL, which calls ZwTerminateProcess and bypasses protected-process light. An agent that respawns and dies on a fixed interval is, in the company's words, being killed from below. Because this hunt relies on telemetry the attacker is trying to remove, SentinelOne recommends treating callback-integrity loss and rekill cadence as corroborating signals, not standalone alerts.
What it means for detection teams
SentinelOne says a detection engineer can ship the first hunt this week, with the rest following as baselines clean up. The practical message is to map coverage per technique rather than per label: driver-load events for BYOVD, change-window baselines for installer abuse, callback-integrity reporting for admin-to-kernel, and process-state events, WFP filter changes and agent heartbeat for driverless suspension. The company's Annual Threat Report, it says, urges teams to chase suspicious behavior rather than specific hashes or file names.
The excerpt provided covers the first three hunts in detail, with the installer and driverless hunts listed in the taxonomy table.
SentinelOne: Bring Your Own Vulnerable Driver: What Detection Teams Should Actually Hunt
