EDR killers, and what they tell you about where enforcement belongs

For most of the last decade the assumption behind endpoint security was that attackers would try to slip past detection. Increasingly they do not bother. They turn it off first.

The tooling for this has a category name now, EDR killers, and it is not a fringe technique. Of roughly ninety EDR killers documented in the wild, fifty four use the same underlying method, and between them they abuse thirty five legitimate, signed Windows drivers.

That number is the interesting part, and it is worth sitting with before reaching for a product answer.

The driver is not malware, which is the whole trick #

Bring your own vulnerable driver, usually shortened to BYOVD, works like this. The attacker does not hunt for a flaw in Windows. They bring a signed third party driver that already has one, drop it on the machine, and let Windows load it.

Windows loads it because there is nothing wrong with the file. The signature is valid. The vendor is real. The driver may well be a legitimate forensic, backup or anti cheat component that thousands of organisations run deliberately. What the attacker wants is the vulnerability inside it, because exploiting that flaw puts them in the kernel.

From the kernel, a security agent is just a process, and processes can be stopped.

The consequences are worse than an agent disappearing from a console. In one documented case built on an old forensic driver, researchers found the technique could silence fifty nine security vendors, and that the agents could continue to look healthy in the management interface while their kernel telemetry had already been cut. The dashboard is green and the sensor is deaf.

A denylist is always describing yesterday #

Windows ships an answer to this, and it is a real one. The Microsoft vulnerable driver blocklist names drivers known to be dangerous and refuses them, and it is enabled by default on most installations where hypervisor protected code integrity is active. If it is off in your estate, turning it on is the cheapest thing on this page.

It is also, structurally, a list of things somebody has already caught.

Microsoft is direct about the limits. Its own guidance states there is no guarantee the blocklist will block every driver with weaknesses, because the list has to balance security against compatibility and reliability. Refusing a driver that a fleet depends on breaks the fleet, so the bar for adding one is not "this driver is exploitable".

The update cadence has been the sharper problem. Microsoft has said the list will be refreshed once or twice a year, and in 2022 researchers found the on device list on some builds had gone roughly three years without an update, with Windows 10 21H2 still carrying block rules dated December 2019. Microsoft fixed the servicing gap, but the shape of the problem does not go away: a list that updates twice a year is being asked to keep pace with thirty five drivers under active abuse and a research community finding more.

This is not an argument that the blocklist is worthless. It is an argument about what kind of control it is. A denylist can only refuse what it has been told about.

The question is not which drivers are bad #

Kernel mode code integrity asks a different question, and it is the one that scales.

App Control for Business does not evaluate whether a driver is known to be dangerous. It evaluates whether the driver is on the list of code you decided may run. A vulnerable driver the attacker brought with them is not refused because somebody catalogued it. It is refused because nobody put it on the list.

That difference removes the race. There is no window between a driver being weaponised and a vendor adding it to a blocklist, because the driver was never going to load either way. Independent write ups of the BYOVD surge reach the same conclusion, which is that moving kernel mode code from a blocklist to a strict allowlist eliminates the BYOVD step entirely.

There is a second structural point worth being precise about, because it is the one people get wrong. Kernel mode validation in App Control is not optional and not something you switch on. Drivers are checked whether or not the policy carries the user mode option, which is the opposite of the situation in user mode. If you want the detail on that asymmetry, what App Control for Business actually is covers it.

You cannot terminate something that is not a process #

The reason an EDR killer works is that the thing doing the enforcing is software running on the machine, with a process identifier, alongside the attacker.

Code Integrity is not that. It is part of the Windows kernel, so there is no executable to terminate, no service to stop and no driver of ours to unload. An attacker who reaches kernel privilege has not reached a place where they can switch off the decision, because the decision is made by the same kernel they are trying to subvert.

We should be careful about how far that claim is taken, because a vendor saying "you cannot turn ours off" deserves scrutiny.

The honest position is that the enforcement is not the soft target, but the policy can be. An unsigned policy sitting on disk can be removed by something with administrative rights, and the machine will come back without it. That is exactly why signed policies and UEFI lock exist, and why they are worth the operational cost on the machines that matter. Signed and unsigned App Control policies goes through that trade off, including the part where a UEFI locked policy is genuinely hard to get rid of, including for you.

The second limit is more mundane. An allowlist for kernel code requires you to know which drivers your estate actually runs, and most organisations do not, because nobody has ever had to ask. That is a discovery problem before it is a policy problem.

This protects EDR, it does not replace it #

The conclusion people reach too quickly is that kernel enforcement makes detection redundant. It does not, and the logic of this particular attack makes the opposite case.

The reason EDR killers exist is that EDR is valuable enough to be worth switching off. Ransomware operators are spending effort on this step precisely because the detection layer would otherwise catch what comes next. If a malicious driver never loads, your EDR is still running, still collecting and still correlating, which is the point.

Microsoft's own guidance is that application control is not a replacement for antivirus, and that remains true here. The layers answer different questions, which App Control vs antivirus vs XDR sets out in full. What kernel mode allowlisting does is remove the step an attacker uses to blind the rest of the stack.

What to actually do #

Confirm the vulnerable driver blocklist is on, and that the version on the device is current rather than whatever shipped with the build. This is free and it is the floor, not the ceiling.

Find out what drivers you run. Not what procurement bought, and not what the gold image contains. Discovery across the fleet, with a version and an owner against each one, is the input every later decision depends on.

PoliEze produces that inventory from the fleet itself, so the awkward decisions below are made against what is actually running rather than against a vendor document. The platform has the detail.

Decide the awkward cases deliberately. A driver with a known flaw that nothing depends on is an easy block. A driver with a known flaw that your card readers or your VPN depend on is a scoping exercise, not a block, and pretending otherwise is how programmes stall.

Then write kernel mode rules as an allowlist and mean it, because the value of the model comes entirely from the default being refusal.

None of that is fast, and the part that takes the time is the discovery rather than the policy. But it is the difference between maintaining a list of drivers somebody else has already caught, and having an estate where the driver an attacker brought with them was never on the list in the first place.

Sources #

• 54 EDR killers use BYOVD to exploit 35 signed vulnerable drivers, for the scale of the technique
• An old forensic driver used to disable endpoint security tools, for agents appearing healthy while telemetry is severed
• BYOVD attack surge analysis, for the allowlist conclusion
• Windows driver blocklist failed to update for three years, for the servicing gap
• How to update your Windows driver blocklist, for the update cadence
• KB5020779, the vulnerable driver blocklist, for Microsoft's own description of the list