Can Ransomware Just Turn Off Your EDR? GentleKiller and the BYOVD Wave

The first sign is the console going quiet. On a Friday night an affiliate who has been living in the network for a week runs one command, and across the estate the endpoint agents stop reporting. There is no crash and no tamper alert. A kernel driver loaded a minute earlier walked the callback tables and switched the agents off from underneath the operating system. By the time anyone notices the dashboards have gone dark, the encryptor is already three chunks deep into every file it can reach.

This is the working method of The Gentlemen, a ransomware-as-a-service crew that ESET researchers spent June taking apart. The gang does not gamble on getting lucky against your security stack. It maintains its own EDR killer, a framework ESET calls GentleKiller, with at least eight variants that each abuse a different vulnerable signed driver to terminate more than 400 processes belonging to roughly 48 security products. Microsoft Defender, CrowdStrike, SentinelOne, Sophos, and ESET's own agents are all on the list. Leaked internal chats show the operator, who goes by zeta88, selling EDR-killer packages to affiliates as a product line, and stitching in third-party tools like HexKiller and HavocKiller behind a shared evasion layer.

The technique is Bring Your Own Vulnerable Driver, BYOVD, and it is not new. What changed in 2026 is the industrialization. The same crews now weaponize a freshly published BYOVD proof-of-concept within days, and they hand the finished tooling to affiliates who never had to write a line of it.

Who this is actually for

Read on if your defense against ransomware rests on a single endpoint agent running in Windows user space, which describes almost every small business and plenty of larger ones. If you already enforce Hypervisor-Protected Code Integrity with the Microsoft vulnerable driver blocklist, run your people as standard users, and alert on kernel driver loads, GentleKiller is a bad afternoon rather than a catastrophe, and you can read the rest as a checklist. Be clear about the limits too: BYOVD is a post-foothold move, not an entry point. The attacker already has code execution and local administrator rights on the box before the driver loads. So there is nothing to patch tonight. The real question is whether, once someone is inside, your last line of defense can be switched off before it ever fires.

How the kill actually works

Every EDR killer in this class leans on the same design reality in Windows: a driver signed by a legitimate vendor can still carry a flaw that hands the caller arbitrary read and write access to kernel memory. Windows trusts the signature and loads it. The malware then uses that primitive to do what user-space code is forbidden from doing, which is reaching into the kernel structures the security product depends on.

The Qilin affiliate chain that Cisco Talos documented is a clean example. A malicious msimg32.dll is side-loaded into a trusted process, which drops two drivers: rwdrv.sys, a renamed copy of the ThrottleStop tuning driver, for physical-memory access, and hlpdrv.sys to do the killing. Before it terminates anything, the tool unregisters the kernel callbacks the EDR uses to watch process and thread creation, then suppresses Event Tracing for Windows so the telemetry never leaves the host. Warlock's affiliates run the same play with a vulnerable NSec driver, NSecKrnl.sys. GentleKiller generalizes the pattern across eight interchangeable drivers, so blocking one signature does nothing to stop the next.

The Gentlemen's own encryptor, a Go binary obfuscated with Garble that Microsoft dissected in May, does not even need the driver against Defender. It disables real-time monitoring and writes its own Set-MpPreference exclusions first, then self-propagates through 21 remote-execution methods and a hidden share$ SMB share before encrypting.

What the kill switches off before encryption starts

• The kernel callbacks that let the EDR see process, thread, and image-load events
• Event Tracing for Windows, so nothing is written for a SIEM to pick up later
• The protected-process shield around the AV service, so it can be terminated outright
• Defender real-time monitoring, through native Set-MpPreference exclusions, before the driver even loads

Close the kernel door: HVCI and the driver blocklist

Only a handful of controls operate at or below the layer BYOVD attacks, and they earn your first hour. Hypervisor-Protected Code Integrity (HVCI, shown in Windows Security as Memory Integrity) uses virtualization to enforce code-integrity checks on drivers, which shuts out a large class of the unsigned and tampered drivers these kits rely on. The Microsoft Vulnerable Driver Blocklist goes after the known-bad signed drivers by hash. On Windows 11 22H2 and later it ships on by default, but default and verified are different things, and on Windows 10 and Windows Server it is frequently off entirely.

Check both on a representative machine before you assume you are covered:

# Is HVCI / Memory Integrity actually running? A 2 in SecurityServicesRunning means yes.
$dg = Get-CimInstance -ClassName Win32_DeviceGuard `
  -Namespace root\Microsoft\Windows\DeviceGuard
$dg.SecurityServicesRunning              # expect the list to contain 2
$dg.CodeIntegrityPolicyEnforcementStatus # 2 == enforced

# Is the Microsoft vulnerable-driver blocklist turned on?
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config' `
  -Name VulnerableDriverBlocklistEnable -ErrorAction SilentlyContinue
# 1 == enabled. Missing or 0 on Win10/Server means known-bad drivers are not being filtered.

# Enable the ASR rule that blocks WRITING a vulnerable signed driver to disk.
# Note: this blocks the driver landing on disk, not a driver already present loading.
Set-MpPreference -AttackSurfaceReductionRules_Ids 56a863a9-875e-4185-98a7-b882c64b5ce5 `
  -AttackSurfaceReductionRules_Actions Enabled

Keep the distinction in mind: the ASR rule stops the driver from being dropped in the first place, while HVCI and the blocklist stop a known-bad driver from loading. You want all three, because affiliates carry drivers you have never seen.

The kernel-layer checklist

• Turn on Memory Integrity (HVCI) fleet-wide through Intune, Group Policy, or the Windows Security app, and confirm it is running, not merely configured
• Force the vulnerable driver blocklist on for every Windows 10 and Windows Server host, where it is not automatic
• Move the ASR driver rule from Audit to Enabled once you have confirmed nothing legitimate breaks

Take away the two things every kill needs

A BYOVD kill needs local administrator rights to load a driver, and it needs somewhere to place that driver to load it from. Remove either and the technique stalls. This is where small environments give up the most ground, because the daily-driver account is a local admin and nothing constrains what code runs from a temp folder.

Right-sized controls that break the chain

• Run standard users. Local admin on the workstation is what lets the driver load at all; strip it from daily accounts and grant elevation per task
• Turn on Defender Tamper Protection so a script cannot flip off real-time monitoring or add exclusions with Set-MpPreference
• Add application control (WDAC or AppLocker) to constrain what runs from user-writable paths like C:\Temp, where The Gentlemen stage payloads
• Alert on new hidden shares such as share$, which the crew's encryptor creates to spread

Detect the load, because prevention will miss one

You will not block every driver. New vulnerable signatures appear constantly and the crews weaponize them faster than blocklists refresh, so the load itself has to raise an alert. Windows records driver loads, and every EDR still standing sees them. The trick is writing the rule before you need it. If you run Microsoft Defender for Endpoint, this advanced-hunting query surfaces the suspicious loads:

// Defender for Endpoint / advanced hunting: suspect kernel driver loads
DeviceEvents
| where ActionType == "DriverLoad"
| where FolderPath has_any (@"\temp\", @"\users\public\", @"\programdata\", @"\downloads\")
   or FileName in~ ("rwdrv.sys", "hlpdrv.sys", "nseckrnl.sys", "throttlestop.sys")
| project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessFileName
| sort by Timestamp desc

No Defender for Endpoint? Sysmon event ID 6 records every driver load with its signature status. Ship it to wherever your logs live and alert on loads from user-writable paths or with Signed: false. Pair that with an alert on Defender's own settings changing, because a sudden DisableRealtimeMonitoring or a new exclusion path is the encryptor announcing itself.

Detections worth standing up this week

• A kernel driver loaded from a user-writable directory (Sysmon EID 6 or the query above)
• A known BYOVD driver name or hash from the CISA and Microsoft blocklists
• Defender real-time protection disabled, tamper protection toggled, or a fresh exclusion added
• The ETW providers for your EDR going silent on a host that is otherwise online

Enforce the blocklist before an affiliate tests it on you

The uncomfortable part of GentleKiller is that it turns your security budget into an assumption. You paid for an agent to stop ransomware, and a crew with a fifty-dollar driver can switch it off in the minute before the encryption runs. Closing that gap does not cost more than what you already own. Turn Memory Integrity on and confirm it is running. Force the vulnerable driver blocklist onto every machine that lacks it. Pull local admin off the accounts people use to read email. Then write the two detections above, so that if a driver does load, someone gets paged while there is still time to isolate the host. For a small team without the hours to work through that on every endpoint, this is exactly the assessment we run at Red Hound: map where a ransomware affiliate could shut off your defenses, and close it before they arrive.