Killing the Sensor First: What Happens Before the Encryptor Runs

Introduction

Read enough ransomware reports and you start noticing the same gap. Initial access is documented in detail. The encryptor is documented in detail. The minute in between, where the endpoint agent quietly stops talking, gets a single line.

That minute is where the intrusion is actually won.

The stage nobody watches

Once an operator has local admin on a host, encryption is rarely the next move. Blinding the sensor is. ESET describes EDR killers as a predictable, standard stage of modern ransomware operations, with attackers gaining high privileges first and then launching a killer to cripple endpoint defences before deploying the payload.

For an MDR this changes how you read a quiet console. A client’s EDR going silent on three machines at once used to be filed under agent maintenance. In 2026 it deserves an escalation on its own merits, before anyone finds a ransom note.

Why a signed driver works so well

The technique behind most of these tools is BYOVD, bring your own vulnerable driver. The goal is kernel-mode privileges, often called Ring 0, where code has unrestricted access to system memory and hardware. An attacker cannot load an unsigned malicious driver, so instead they bring one signed by a reputable vendor, typically a hardware manufacturer or an old antivirus version, that happens to carry a known vulnerability.

Nothing is forged at any point. The drivers carry valid signatures from real vendors, which means Windows and most security products are predisposed to trust them. Nobody is cracking a certificate. They are simply loading an old, unpatched version of legitimate software that still contains a kernel level flaw, and old signed copies are trivially obtainable.

Once execution lands at Ring 0, the attacker can terminate protected processes, tamper with kernel callbacks and switch off telemetry from underneath the layer the EDR operates in. This is also why tamper protection settings offer no comfort here. They run at user mode privilege level and cannot stop a tool that has already reached the kernel.

What changed over the last eighteen months

BYOVD stopped being an APT speciality somewhere in 2025 and became commodity tooling. ESET now counts almost 90 EDR killers in active use, 54 of them BYOVD based, abusing 35 distinct vulnerable drivers between them. Worth remembering when you read attribution reports: affiliates rather than core operators usually pick which killer to deploy, so the driver tells you very little about who is on the keyboard.

Three things are worth pulling out of the 2026 research.

The tooling now ships with the kit. ESET’s June 2026 investigation into the Gentlemen operation found that the operator centrally develops and maintains its own EDR killer framework, GentleKiller, and hands it to every affiliate as part of onboarding. The variants abuse drivers from Safetica, Zemana, Qihoo 360, IObit and Huawei.

“high operational effectiveness and tight integration”
Jakub Souček, ESET, on the Gentlemen toolkit

Blocklists are being outrun on purpose. Check Point documented more than 2,500 distinct variants of a single driver, TrueSight.sys, produced by tweaking eight bytes in the PE header, each with a unique hash and a still valid signature. In an April 2026 intrusion, Expel found the attacker using ktapi.sys, a Kontron industrial driver that was not on any public blocklist at the time.

And the scale of some of this is genuinely uncomfortable. Cisco Talos published research in April 2026 showing that Qilin had built a technique capable of disabling more than 300 endpoint detection and response products.

The category is also widening past drivers entirely. ESET identified script based tools that lean on built in commands like taskkill, net stop or sc delete, with some variants combining scripting with Windows Safe Mode. Driverless options such as EDRSilencer and EDR-Freeze disrupt security tooling without touching the kernel at all.

Where the chain leaves traces

The sequence barely varies across families, which is the good news. Drop the driver, register it as a service, exploit it to reach Ring 0, then start killing processes. Each step maps to telemetry you already collect.

BYOVD attack chain and the matching detection telemetry

Everything to the right of the exploit step is already too late. The detection value sits on the left.

Four places to look

Start with the driver landing on disk. It has to be written somewhere before it can load, so file creation monitoring against known vulnerable driver hashes gives you the earliest possible warning. The community maintained LOLDrivers database is the obvious feed for that.

Then service creation. Loading a driver normally creates a kernel service, which puts Sysmon Event ID 13 on service registry keys and Event ID 6 on driver load at the centre of this. Rules that fire on a new driver being installed as a Windows service give you warning before the kill sequence starts.

Third, Code Integrity logging. Under Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational, Event ID 3099 confirms which blocklist policy is genuinely active on a machine. Half the value here is discovering how much of your estate is not enforcing the policy you assumed it was.

Fourth, and least practised, the silence itself. A gap in endpoint telemetry followed by evidence of malicious activity is a strong sign the EDR was disabled during that window. Agents that stop reporting, unexpected kernel driver installations in event logs and odd traffic picked up by network monitoring all point the same way.

That last one deserves its own rule. Detection pipelines alert on events. Almost none of them alert on the absence of events. A rule that fires when an agent stops checking in, correlated against a recent service creation on the same host, costs very little to build and covers the exact scenario where every other control has been switched off.

Hardening, and its ceiling

The controls that actually operate at or below the attack surface are HVCI, the Microsoft Vulnerable Driver Blocklist and detection on driver installation. HVCI verifies kernel code before execution and enforces the blocklist, and you can check it per device under Windows Security, Device Security, Core isolation. If Memory Integrity is greyed out, something is blocking it and that machine is worth a ticket.

Alongside that, enable the ASR rule “Block abuse of exploited vulnerable signed drivers” so the driver never lands:

Add-MpPreference `
    -AttackSurfaceReductionRules_Ids 56a863a9-875e-4185-98a7-b882c64b5ce5 `
    -AttackSurfaceReductionRules_Actions Enabled

Merge the driver block rules into a WDAC base policy on your most critical assets, deploy it in audit mode first, and keep local admin rights tight, since the whole chain assumes them.

Be realistic about what this buys you. Blocklisting stops known vulnerable drivers, while capable operators rotate to signed drivers that are not on the list yet, or exploit flaws unknown to Microsoft and the EDR vendors, which bypasses enforcement entirely. There is movement on the platform side at least. By April 2026, Microsoft was reported to be removing trust for older cross signed kernel drivers in newer Windows releases, which could shrink the abusable surface considerably given how many LOLDrivers entries are cross signed.

Conclusion

An EDR killer is a line item in a ransomware as a service onboarding package now, not an exotic capability. Two things follow from that. Stop treating the endpoint agent as a trusted narrator and correlate it against identity, authentication and network telemetry that lives somewhere the attacker has not reached. And build the unglamorous detections, because by the time the encryptor runs, the best evidence you had was written twenty minutes earlier by a .sys file nobody was watching.