BYOVD Detection: How to Hunt Vulnerable Drivers Used to Disable EDR

BYOVD, short for bring your own vulnerable driver, is an attack in which an intruder with administrator rights loads a legitimately signed kernel driver that has a known flaw, then uses the flaw to elevate their rights even further and do things only the kernel is allowed to do, most often to shut down or blind EDR and other security tools.

The Gentlemen (also tracked as Storm-2697 or GOLD SHERWOOD) ransomware operation builds its own BYOVD tools. In June 2026, ESET published its analysis of GentleKiller, the EDR killer the group develops and offers to its affiliates. ESET found at least eight variants, each abusing a different vulnerable or malicious driver. Together they target more than 400 processes, which ESET mapped to 48 security products.

When a tool like this works, the EDR agent on that host stops reporting. Apart from what the agent was able to send before it stopped, the evidence for detection has to come from other places: Windows logs already forwarded to a SIEM, identity, DNS and network logs, which keep arriving after the EDR goes quiet.

This guide covers BYOVD used to disable EDR on Windows endpoints and servers. It walks through how the attack works, how to hunt the driver load and the kill that follows, what normal driver activity looks like, how to reduce the risk, and what to do when a sensor goes quiet. Other EDR evasion and tampering methods, such as unhooking, exclusions and policy changes, leave different evidence and are not covered here. Each hunt below can run as a recurring part of proactive threat hunting.

{{ebook-cta}}

How does a BYOVD attack disable EDR?

A BYOVD attack comes after the first compromise, such as a phishing payload or a web shell on an exposed server. Loading a driver requires the “Load and unload device drivers” privilege, which Windows grants to administrators by default, so the intruder usually has administrator rights on the host before loading the driver (a good reminder of why it's important to keep users with local administrator rights to a minimum). From there, the sequence is short:

• Drop the driver. The tool writes the driver file anywhere the account can write. The file does not need to have a .sys extension.
• Register it as a service. Windows normally loads a driver from a service entry under HKLM\SYSTEM\CurrentControlSet\Services. ESET reports that the Gentlemen’s EDR killers install and start their drivers as services before exploiting them. The technique is listed in the MITRE ATT&CK framework as T1543.003. A tool that writes the service key to the registry directly and loads the driver this way may not produce the Service Control Manager’s install event. Its registry writes under that key and the driver load itself can still be logged.
• Send it requests. Once the driver is running, the user-mode tool talks to it through DeviceIoControl, according to ESET. Depending on the driver, those requests end protected processes directly, delete files or read and write kernel memory.

This attack path is not viable only due to coding bugs. Microsoft’s blocklist criteria include drivers that circumvent the Windows security model with no malicious intent, such as a driver that hands powerful kernel functions to any caller with administrator rights.

Killing and blinding EDR produce different evidence. GentleKiller terminates security processes, and ESET notes it does so periodically in a loop, so an agent that restarts can be stopped again. The open source tool EDRSandblast takes the other route. It uses a vulnerable signed driver to remove the callbacks EDR drivers register for process, thread and image-load events, among others, and to turn off the ETW Threat Intelligence provider. In that case, the agent’s process keeps running but it doesn't see the kernel events it depends on.

Some of the drivers used in these attacks are built especially for this purpose. ESET identified two of the GentleKiller drivers as rootkits, and Microsoft’s blocklist also covers drivers with malicious behavior and certificates used to sign malware. For hunting, the difference is small: a driver loaded the normal way leaves the same service and load events whether it is vulnerable code being exploited or intrinsically malicious.

BYOVD attacks are well documented in MITRE ATT&CK, including multiple techniques, such as Exploitation for Privilege Escalation (T1068); Windows Service (T1543.003) for the driver service; and Disable or Modify Tools (T1685).

Why should the EDR be the only witness?

Many EDRs see the driver load before anything is stopped, and some block known vulnerable drivers outright. When the EDR raises an alert on the load, the usual triage for EDR alerts applies.

The harder case is the one where the EDR raised nothing, or raised an alert and then went silent. A killer that works on a host has already gotten past whatever blocking was in place there. Once the agent is down, it records nothing more from that host, and the console keeps what the agent sent before then, along with when it last checked in. In this scenario, endpoint based detection opportunities are severely reduced.

BYOVD detection therefore may rely on evidence from telemetry from other sources. Windows events forwarded to the SIEM before the kill no longer depend on the host, though a forwarder that sends in batches may not have shipped the driver install and load yet. Forwarding after the kill depends on whether the tool also targets the log forwarder, and Sysmon’s own logging on whether it targets Sysmon. ESET lists both Sysmon and the Wazuh agent among GentleKiller’s targets. Domain controller authentications, identity provider sign-ins, and DNS, proxy, firewall and DHCP records keep arriving whatever happens to the agent. A domain controller or DNS server that goes quiet is an exception, since it writes those records itself.

How to hunt vulnerable driver loads

Each hunt here tests the same hunt hypothesis: a host loaded a driver it does not normally load, and the driver is one an attacker would choose. Start with the load itself:

• Sysmon. According to the Sysmon documentation, Event ID 6 records each driver load with its hashes and signature information, in fields such as ImageLoaded, Hashes, Signed, Signature and SignatureStatus. Match the hashes against LOLDrivers, a community list of vulnerable and malicious drivers that also publishes Sigma, YARA and Sysmon rules. Event ID 6 carries only the hash types named in your Sysmon config’s HashAlgorithms setting, so confirm they include one that LOLDrivers lists, such as SHA256. If your Sysmon config cuts volume by excluding driver loads from trusted signers, check what it leaves out, because most BYOVD drivers carry a legitimate vendor’s signature. Some EDR killers have also used malicious drivers signed with Microsoft’s own Windows Hardware Compatibility Publisher certificate, so excluding Microsoft or Windows signers would hide those loads.
• Microsoft Defender for Endpoint. Driver loads appear in DeviceEvents with ActionType == "DriverLoad". LOLDrivers publishes a query that joins these events on SHA1 and SHA256 to its driver list. Keep the SHA1 match in any version you write, since Microsoft notes that SHA256 is usually not populated in DeviceEvents. Hunting for telemetry on the DeviceEvents table requires the Defender for Endpoint Plan 2 license, so make sure you have that available when relying on this hunt. Defender’s attack surface reduction rule also logs AsrVulnerableSignedDriverBlocked or AsrVulnerableSignedDriverAudited when an app saves, or tries to save, a vulnerable signed driver to disk. The ASR rule raises no alert, so these events are useful for querying, not for triggering investigations.
• System log. Event 7045 with a service type of kernel mode driver records a new driver service. Splunk’s Windows Vulnerable Driver Installed detection pairs that event with a list of known vulnerable drivers.
• Security log. Event 4697 records the same install when the Audit Security System Extension subcategory is on. Microsoft’s guidance for this event is to report every service with a driver service type (0x1, 0x2 or 0x8) and every service with a start type of 0 or 1. Filter on the service type as well, because a driver service can also have a start type of 2 (Automatic) or 3 (Manual), and EDRSandblast installs its driver as Automatic.
• Blocked loads. When App Control for Business blocks a driver, the Microsoft-Windows-CodeIntegrity/Operational log records event 3077, or 3076 in audit mode. A block still deserves a look, since it can come from an old hardware utility or from an intruder whose first attempt failed.

Next, look at the file before the load. Legitimate drivers usually install under C:\Windows\System32\drivers\, the driver store or a Program Files folder. A driver file written to a temp folder or a user profile shortly before a new driver service appears is a strong lead. A file in the drivers folder still needs checking, since Sophos found the AuKill EDR killer dropping its driver into C:\Windows\System32\drivers\. Microsoft’s security experts team has published a query that flags newly created .sys files with low global prevalence in DeviceFileEvents and joins them to their certificate details. The same post lists Sysmon Event ID 13, a registry value set under the service key, among the traces to collect. To see who acted, read the InitiatingProcessFileName and InitiatingProcessAccountName fields in DeviceFileEvents for the file write, and the Subject fields of event 4697 for the service install. A known installer or deployment agent sends you to the change record; a script host or an unfamiliar binary in a temp folder is the stronger lead.

Don’t rely only on file names. Match on hashes first, then on the signer, because attackers can change a signed driver’s file hash without breaking its signature.

Finally, compare each load against the host’s own history. A server that loads a third-party driver it has never loaded before, outside a patch window, deserves a closer look than a developer laptop doing the same.

How to hunt the kill after the driver loads

The second half of the hunt looks for what the driver was loaded to do. Three patterns are worth querying, and each is stronger when it follows a new driver load on the same host:

• Security agents stopping soon after a new driver. System event 7036 records a service entering the stopped state, and events 7034 and 7031 record a service that terminated unexpectedly, such as an agent killed by a driver. Sysmon Event ID 5 records process terminations. Join these events to the driver loads above and look for an agent that stopped within minutes of a driver the host had never loaded before. An agent upgrade or reinstall can match too, since it can stop the agent’s service and load a new version of the agent’s own driver. Before closing such a hit, confirm the driver is your EDR vendor’s and matches a change record for the rollout.
• Gaps in agent check-ins. The EDR console’s last-seen time shows when each agent stopped reporting. An agent that drops off and returns for brief check-ins (visible in the agent’s check-in history) can mean a tool is ending it in a loop, as GentleKiller does.
• A quiet sensor on a busy host. Join the console’s list of agents that stopped reporting to the other sources by host name or IP address: domain controller authentications, identity provider sign-ins, DNS queries, and proxy and firewall logs. Where hosts get their addresses from DHCP, map each IP to its host through the lease logs for the same time window. A host that has gone silent everywhere is probably off or disconnected. A host that is silent only in the EDR is the one to escalate.

The check-in test is not perfect. When a tool removes the EDR’s kernel callbacks instead of ending the agent, the agent can keep checking in even when it is blind to process and image-load events. EDRSandblast restores the callbacks by default when it finishes, so the drop can be too brief to show in an hourly count. To catch a longer drop, compare each host’s hourly event count from the EDR against the same hours on previous days. That keeps the hunt from flagging a workstation that goes quiet every evening. Then flag hosts whose process events drop sharply while their identity and network activity holds steady.

When these hunts confirm a driver hash, a signer or a service pattern, they become good candidates to become a standing detection rule. A sound detection engineering process can capture these opportunities to write and maintain such rules.

What does normal driver activity look like?

A known vulnerable driver on a host is often there because of legitimate reasons. Many hardware utilities, overclocking tools, anti-cheat products and older vendor tools ship kernel drivers, and some of those drivers appear on LOLDrivers.

Driver installs and updates also arrive in bulk from Windows Update and from deployment tools such as Intune or Configuration Manager. Those usually land on many hosts at once, inside a change window, so on servers a single host loading a new driver outside one stands out. Workstations are noisier, because Windows Update also installs drivers for hardware a user connects. A new driver installed on many hosts at once is not always related to benign activity. The Gentlemen, for example, have abused Group Policies to compromise whole domains.

Build the baseline per host role. Find which known vulnerable drivers are already present, then decide with each owner whether to remove, block or keep each one. Record the drivers you keep and the hosts that need them, and alert on any known vulnerable driver outside that list. An intruder on those hosts can use a kept driver without tripping that alert, so keep the hunts above for check-in gaps and quiet sensors running there.

How to reduce BYOVD risk before you hunt

Several controls cut down the drivers an intruder can use:

• The Microsoft vulnerable driver blocklist. Since the Windows 11 2022 update, the vulnerable driver blocklist is on by default for devices running that update or later, according to Microsoft’s driver block rules. Except on Windows Server 2016, it is also enforced when memory integrity (HVCI), Smart App Control or S mode is active. Microsoft updates it quarterly and ships updates through monthly Windows updates. It can be turned off on the Core isolation page in Windows Security, so confirm it is still on across the fleet.
• App Control for Business with Microsoft’s full block rules. Microsoft says the list it publishes usually contains more known vulnerable drivers than the version in Windows, and that it holds some blocks back to avoid breaking existing software. Teams that want the latest list can apply it through App Control. A driver that is already running is not blocked until the host reboots, according to Microsoft. Run it in audit mode first and review the 3076 events, because blocking a driver can break devices and, in rare cases, cause a blue screen. A stricter App Control policy can allow only the drivers you approve, though that list takes ongoing work to maintain.
• The attack surface reduction rule “Block abuse of exploited vulnerable signed drivers” (56a863a9-875e-4185-98a7-b882c64b5ce5). According to the ASR rules reference, it stops apps from saving vulnerable signed drivers to disk. It does not stop a driver that is already on the machine from loading, so it works alongside the blocklist. It runs only where Microsoft Defender Antivirus is in active mode, not in passive mode behind another antivirus.
• EDR tamper protection. Tamper protection stops many attempts to stop or reconfigure the agent from user mode. How well an agent holds up against a kernel driver varies by vendor, so ask yours what it records and blocks when a known vulnerable driver loads.
• Fewer local administrators. Each account that loses local administrator rights is one fewer account an intruder can use to load a driver. On domain controllers, Print Operators also hold the “Load and unload device drivers” privilege by default, and Microsoft advises granting it there to Domain Admins only.

The blocklist-based controls above reduce the number of drivers an intruder can use, yet none of them covers every driver. Microsoft states that the blocklist isn’t guaranteed to block every driver found to have vulnerabilities. ESET observed the Gentlemen adopting newly released EDR killer proofs of concept within days. That can be before any blocklist includes the driver they use. As of November 2026, LOLDrivers’ per-sample records showed about one in five of its known driver samples still loading with HVCI on. LOLDrivers notes these records are not a live comparison with the latest blocklist. Keep hunting for the driver load and the quiet sensor even where every control above is in place.

What should a SOC do when an EDR sensor goes quiet?

Treat a sensor that stops reporting on an otherwise active host as an incident until someone explains it. Common benign causes include an agent upgrade, a reimage, a laptop leaving the network and an outage in the EDR service itself. Each of these usually leaves a matching change record or affects many hosts at once. When none of them fits, work through these steps:

• Contain through the network and identity. EDR isolation may not work on a host whose agent is down. Isolate the host at the switch, firewall, network access control or VPN instead. Disable or reset the accounts active on it, including service accounts that run there and the local administrator account, and revoke their sessions. Before disabling a service account, check which systems depend on it, because disabling it will break them. In Microsoft Entra ID, access tokens issued before the revocation stay valid until they expire, 60 to 90 minutes by default, unless the app supports continuous access evaluation. Kerberos service tickets issued before an account is disabled can keep working until they expire, 10 hours by default. A client presents them directly to the servers they were issued for, usually with no domain controller check. A connection a ticket has already authenticated is also not interrupted when the ticket expires. To confirm containment held, watch logons by those accounts on those servers as well as in domain controller and identity provider logs. Every minute spent waiting for the agent to come back adds to mean time to contain.
• Collect the driver and its install record. If the host is still running, capture its memory before any reboot or reimage. Then pull the driver file with its hash and signer, the 7045 or 4697 event, the service key under HKLM\SYSTEM\CurrentControlSet\Services, and the process and account that created it. The logon ID in event 4697 can lead to the matching 4624 logon, whose source address, when recorded, shows whether the account came in from another host. If it did, that host is the next to examine.
• Search the fleet. Look for the same driver hash, the same signer, the same service name, the same loader and logons by the same installing account on other hosts. An intruder who disabled one agent may have tried on others, and a host where the agent survived may hold the clearest record of the attempt.
• Look for what usually comes next. The EDR killers in ESET’s report turn up in several ransomware operations, including Gentlemen, Warlock and MedusaLocker. Check the host and its accounts for the steps that often come before encryption, such as Kerberoasting and other credential theft, remote execution on other hosts, AnyDesk or other remote access software installed as a second way back in, data exfiltration, and deletion of shadow copies and backups.

Hunting BYOVD with Prophet AI

Prophet AI Threat Hunter can run hunts like the ones in this guide autonomously, as curated or custom hunts on the schedule your team sets, with scope and cadence under your control. A team can describe a hunt in plain language, such as new kernel drivers on servers or agents that stopped reporting while their hosts stayed active in identity logs. The hunt then keeps running on that schedule across the data sources the team has connected.

When a hunt turns up a lead, Prophet AI SOC Analyst investigates it and documents every query it ran, so an analyst can check the query before trusting the answer. Prophet AI Detection Engineer turns a confirmed finding, such as a driver hash or a service pattern, into a backtested detection your team reviews before it ships. Its coverage map, built from your own investigations, shows which techniques are covered, which have gone quiet and which are dark.

To see these hunts run against your own telemetry, request a demo.