Could a BYOVD Attack Turn Your EDR Off in Seconds—Even If You Think You’re Protected?

You can do everything “right” and still lose your EDR in seconds. That’s the gut-punch behind ESET’s reporting on the Gentlemen ransomware crew and their EDR-killer tooling: a framework researchers dubbed GentleKiller that uses BYOVD (Bring Your Own Vulnerable Driver) to jump into the Windows kernel and start shutting defenses down like flipping breakers. The scary part isn’t just the technique—it’s the engineering discipline: multiple variants, easy driver swapping, and a target list of 400+ security processes across ~48 vendors.

The “EDR Off Switch”: BYOVD, explained like a real incident

Here’s what “turning EDR off” looks like in real life. Not a fancy exploit chain. Not some movie-hacker moment. It’s usually a short, ugly sequence where the attacker gets kernel-level privileges and your endpoint defenses suddenly stop seeing, stopping, or logging the things you’re counting on them to catch.

That’s the core idea behind a BYOVD attack (Bring Your Own Vulnerable Driver): the attacker brings a legitimate Windows driver that has a known security flaw, loads it on the victim machine, then abuses that flaw to do things normal apps can’t do—because drivers run in the Windows kernel. EDR lives close to the action, but once an attacker is operating in kernel space, they’re playing with higher authority than most user-mode protections can handle.

BYOVD in plain terms (no fluff)

Think of Windows as having two “floors”:

• User mode (where most apps and a lot of EDR logic live)
• Kernel mode (where drivers and the OS core live)

BYOVD is the attacker finding a way to get onto the kernel floor. Once they’re there, they can go after security tooling in ways that feel unfair because they are. EDR can alert on suspicious processes all day, but if an attacker can use kernel privileges to interfere with those processes directly, it becomes more like a power cut than a break-in.

What the incident flow often looks like

In ransomware incidents, EDR killer tools show up early because they clear the runway for the rest of the operation. One report notes EDR killers are typically used in the early phase so data theft and encryption can run “unencumbered,” and that they often use BYOVD to elevate privileges and disable security engines .

A simplified play-by-play looks like this:

1. Initial access happens (phish, stolen creds, exposed edge—pick your poison).
2. Attacker lands an EDR killer and a vulnerable driver on disk.
3. They load the driver (it’s “legit” software on paper, just flawed).
4. The driver’s vulnerability is abused to gain kernel-level execution .
5. The attacker kills, blinds, or sabotages security processes and services.
6. Only after defenses are suppressed do you see the “big” steps: lateral movement, mass staging, encryption.

The part defenders hate: steps 3–5 can be fast. And because the technique is built around privilege, not stealth, it can look less like malware tip-toeing around your sensors and more like malware unplugging the sensors.

Why it feels unfair (and why it works)

Most EDR “tamper protection” is strongest against user-mode tricks: service stops, process terminations, registry edits, uninstall attempts.

BYOVD changes the game. With kernel privileges, an attacker can target the very mechanisms EDR uses to watch the system. That’s why this technique keeps showing up in ransomware tradecraft and why frameworks like the one ESET reported on (used by the Gentlemen crew) are built around BYOVD-driven privilege elevation .

If you’re reading this thinking, “We have a top-tier EDR, we’ll be fine,” that’s exactly the point. BYOVD isn’t about outsmarting your alerts. It’s about out-ranking your defenses.

GentleKiller’s playbook: lots of variants, fast driver swaps, huge vendor coverage

Once attackers have a BYOVD path into kernel territory, the next question is simple: how do they keep that “EDR off switch” working when defenders patch, block, and adapt?

ESET’s reporting (as summarized publicly) points to a pretty disciplined answer: GentleKiller isn’t a single tool—it’s a framework with multiple builds that can change its “engine” without changing its whole body.

A framework, not a one-off: why variants matter

GentleKiller has at least eight variants, and those variants impersonate legitimate security products (examples called out include Kaspersky, Valorant, Javelin, and WatchDog).

That impersonation piece matters operationally:

• It can blend into software inventories and casual triage (“looks like a security tool component”).
• It can slow down response when an analyst has to confirm what’s real.
• It gives affiliates a “normal-looking” wrapper they can reshuffle as defenders learn the previous one.

The real trick: fast vulnerable-driver swaps

ESET notes a key design choice: each GentleKiller variant uses different vulnerable drivers to reach the same outcome, but they still share common strings, identical obfuscation approaches, and similar process-killing logic.

Read that again. Different drivers. Same playbook.

That’s how you get speed:

• When a vulnerable driver gets blocked or burned, they swap the driver.
• The “killer” logic stays mostly the same, so they don’t need major code changes to weaponize newly disclosed flaws.

From a defender’s view, this is why BYOVD-based EDR killer tooling keeps resurfacing. You’re not fighting a single artifact. You’re fighting a pattern.

“Am I on the list?” Probably.

ESET states GentleKiller targets more than 400 processes across roughly 48 security vendors/products.

The list includes big names like Microsoft, CrowdStrike, SentinelOne, Palo Alto, Sophos, Trend Micro, ESET, Bitdefender, McAfee/Trellix, and Kaspersky.

A blunt takeaway for security teams: this isn’t “anti-product-X.” It’s anti-security. If you run EDR, MDR agents, AV, or endpoint hardening tools, assume your processes are already mapped, named, and queued up for termination attempts.

What to internalize (quickly)

• Vendor choice doesn’t remove the risk. Coverage is broad by design.
• Driver-blocking and kernel telemetry matter because the attackers are planning to rotate drivers, not retire the technique.

How they keep it stealthy and reliable: packers, signatures, and backup killers

Flexibility gets them in. Staying power is what keeps them winning after your team starts pulling threads.

ESET noted two moves that are all about slowing you down and avoiding single points of failure: commercial packers, signature games, and extra “killer” tooling on standby.

1) Packers that waste your time (Enigma + Themida)

GentleKiller binaries were observed protected with Enigma and Themida—commercial packing/code-protection tools.

Why defenders should care:

• Triage gets slower. Packed samples often look like “noise” until someone invests real reversing time.
• Detections get fragile. Static signatures break easier when the same core logic is wrapped in different protection layers.
• Response gets riskier. Teams hesitate longer before detonating, unpacking, or broadly blocking a file they can’t quickly understand.

This isn’t magic stealth. It’s practical friction. And friction buys ransomware crews minutes when you can’t spare seconds.

2) Stolen signatures (even invalid ones) still create confusion

ESET also observed the actor using stolen digital signatures from legitimate software, even though the signatures were invalid.

That sounds pointless until you’ve been on an incident call where people argue about what “signed” means:

• It can muddy the trust conversation during containment (“is this from a vendor or not?”).
• It can delay blocking decisions when someone worries about breaking a business app.
• It can pollute artifacts you rely on for quick sorting (inventory tools, allowlists, ticket notes).

3) Redundancy: when one EDR killer fails, another might land

ESET reports the Gentlemen crew didn’t bet everything on GentleKiller. Their toolkit also incorporated at least three external EDR-killing tools: HexKiller, ThrottleBlood, and HavocKiller.

That redundancy changes the defender’s math:

• Blocking one hash or one technique doesn’t end the story.
• You can’t treat “we stopped the EDR killer” as closure.
• You have to assume they’ll retry with an alternate tool if the first one hits friction.

A quick operational gut-check: if your playbook only has one response path for “EDR tampering,” attackers with backup killers get multiple shots on goal.

The broader chain: credential theft (OxideHarvest) and why FortiGate config keeps showing up

All the EDR-killing in the world doesn’t matter if the attacker can’t reliably get back in, move around, and stay authenticated. That’s why this activity doesn’t stop at “turn security off.” It’s paired with credential theft and target selection that looks very intentional.

OxideHarvest: credentials first, chaos later

ESET documented a tool called OxideHarvest, described as a Rust-based credential stealer. They also assessed—based on the language choice—that it was likely developed externally.

Why that matters in a ransomware chain:

• Stolen credentials smooth everything out. Remote access, lateral movement, “living off the land,” and persistence all get easier when you’re logging in like a real user.
• It reduces noisy exploits. Attackers don’t always need to smash through controls if they can walk through a door that already trusts them.
• It makes “EDR off” more repeatable. If a first attempt fails, valid creds let them re-stage tooling, re-run steps, and adapt without starting from scratch.

If you’ve ever seen an incident where the same environment gets re-compromised after “cleanup,” this is often why.

Why FortiGate keeps showing up in the targeting

ESET’s analysis also indicates the Gentlemen ransomware picks targets based on the configuration of FortiGate endpoints.

That’s not random “spray and pray.” It’s closer to pre-qualification: find edge setups that are easier to abuse, easier to persist in, or easier to monetize.

And the timing stings. The same reporting points out this is notable given FortiBleed—a recent exposure involving nearly 74,000 FortiGate VPN credentials.

A practical takeaway for defenders:

• Treat edge configuration as part of endpoint protection.
• Assume attackers are using your VPN/edge posture to decide whether you’re worth the effort.
• If you’re relying on “our EDR will catch it,” but your edge is loose, you’re handing them a stable entry point—and OxideHarvest-style credential theft makes that entry point even stickier.

Defenses that actually help: block the driver path, watch the right signals, harden the edge

If attackers are picking targets based on FortiGate configuration and pairing that with credential theft and EDR killers, you can’t defend this with “better alerts” alone. You have to cut off the paths they’re betting on. ESET’s reporting ties these campaigns to BYOVD-based EDR killing and FortiGate-driven targeting, so controls need to map to those realities.

1) Block the driver path (BYOVD mitigation that changes outcomes)

BYOVD works because Windows will load a driver that looks legitimate, even if it’s vulnerable. Your job is to reduce how often “will load” is true.

Prioritize controls in this order:

• Turn on Microsoft’s vulnerable driver blocklist where possible (it’s built for this exact problem: known-bad/abused drivers).
• Use WDAC (Windows Defender Application Control) to restrict driver installs/loads in high-value fleets (servers, admin workstations, VDI, jump boxes).
• Tighten driver trust rules:
  -Validate publisher/certificate chains for drivers.
  -Alert on odd cases where drivers appear “signed” but don’t validate cleanly (attackers have used stolen signatures even if invalid).

2) Watch the right signals (telemetry that catches the “EDR off” moment)

BYOVD and EDR killers tend to create a pattern you can monitor for:

• New or unusual driver loads, especially outside standard IT workflows
• Service/process termination attempts aimed at security tooling (bursts are a tell)
• Sudden loss of EDR visibility on a host (agent stops talking, sensors go quiet)

What’s useful here isn’t one alert. It’s correlation: driver load + security process terminations + EDR telemetry drop in a tight window.

3) Make FortiGate a harder target (because they’re selecting victims by it)

ESET’s analysis indicates target selection based on FortiGate endpoint configuration, which is a strong hint that edge posture is part of the attacker’s filtering logic.

A tight operational checklist:

• Rotate VPN/admin credentials (especially after any credential exposure event)
• Review config for exposure reduction (management interfaces, unnecessary services, broad inbound rules)
• Confirm logging is centralized so you can reconstruct access paths fast

Quick reality check (what “good” looks like)

You don’t need perfection. You need friction in the right places:

1. Driver load gets blocked or loudly logged
2. Security process-kill attempts trigger containment
3. Edge access is locked down enough that stolen creds don’t equal instant re-entry

‍