Your EDR stopped reporting. The dashboard is green. Nothing alerted. But the encryptor is already running.
Reconstruct from back to front. An IOCTL was sent to a newly loaded kernel driver, signed and vulnerable. With physical memory access, the attacker terminated the EDR's processes via ZwTerminateProcess and removed the kernel callbacks. The agent appears active, sees nothing. We at Tech86 have seen this scenario — and it is more common than you think.
BYOVD: bring your own vulnerable driver
BYOVD is a technique where the attacker brings their own vulnerable driver to the target. The driver has a valid Microsoft signature — it is a legitimate driver from a legitimate vendor, just with an exploitable vulnerability. Windows allows the load because the signature is valid. Once in the kernel, the driver exposes IOCTLs that allow direct reading and writing of physical memory.
With physical memory access, the attacker operates below the operating system's protections. Terminates the EDR's processes via ZwTerminateProcess. Removes the kernel callbacks the EDR uses to monitor process creation, file access, and thread injection. The EDR agent keeps running — appears active on the dashboard — but it is blind. It sees nothing because its eyes were ripped out from inside the kernel.
The Gentlemen, Storm-2697, and the scale of the problem
The signature is The Gentlemen, a group that emerged from a dispute within the Qilin RaaS in 2025. Microsoft tracks as Storm-2697. According to ESET, the group has accumulated 480+ victims across 66 countries, with 250+ in Latin America — a regional concentration that suggests deliberate focus on our market.
On July 7, 2026, the group listed Mercado Libre on the dark web leak site. Claim, not confirmed incident. No sample, breach not confirmed. The distinction matters: a leak site listing is the attacker's assertion, not evidence of compromise. But the group's scale — 480+ victims across 66 countries according to ESET — makes every claim worth investigating.
The two EDR killers: ThrottleBlood.sys and ktapi.sys
Two EDR killers stand out in the operation. The first is ThrottleBlood.sys — actually ThrottleStop.sys renamed, a legitimate overclocking utility. It has CVE-2025-7771 assigned, with CVSS 8.7. The driver exposes IOCTLs for reading and writing physical memory via MmMapIoSpace, bypassing SMEP and SMAP. With that, it kills the major EDRs on the market.
The second is ktapi.sys, from Kontron. A zero-day without an assigned CVE. The driver maps kernel memory directly into the attacker's space and bypasses PatchGuard, SMAP, and SMEP. The critical difference: ktapi.sys was absent from blocklists when it was discovered. Blocklists are reactive — you only block what you know. A zero-day without a CVE is not on any list.
Why PPL and blocklists are not enough
PPL (Protected Process Light) resists termination via user-mode, but not via kernel-mode. A vulnerable driver loaded into the kernel has sufficient privileges to terminate PPL processes. The protection assumes the kernel is trustworthy — when the kernel is compromised via BYOVD, PPL does not help.
Driver blocklists are equally limited. They block known drivers after the vulnerability is discovered and disclosed. But between the vulnerability's discovery and the blocklist update, there is a window of exposure. And a zero-day without a CVE — like Kontron's ktapi.sys — is not on any list. Defense cannot depend on knowing every threat.
Defense in layers: HVCI, WDAC, canaries, and offline IR
Defense against BYOVD is layered because no single layer is sufficient. HVCI (Hypervisor-Protected Code Integrity) operates in Ring -1, below the kernel, and blocks W^X violations at the hypervisor level. Even if a vulnerable driver gains access to kernel memory, the hypervisor prevents unsigned code from executing.
WDAC (Windows Defender Application Control) with driver allowlisting is proactive: only explicitly approved drivers load into the kernel. Blocklists are reactive; allowlisting is preventive. When a new vulnerable driver appears, it is already blocked by default.
Monitor kernel callbacks to detect tampering and deploy EDR canaries as tripwires. If the callback monitoring the canaries disappears, you know manipulation occurred. And assume EDR blindness: keep IR offline and test backups regularly. When the encryptor is running and the EDR is blind, a tested backup is the last line of defense.
At Tech86, the human 24/7 SOC survives tampering with proactive threat hunting. Red Team simulates the full BYOVD kill-chain — from initial access via infostealer to the encryptor. IAM and Zero Trust reduce the credential theft that gives the attacker the initial access needed to load the driver.
Conclusion: the green dashboard doesn't mean secure
The green dashboard doesn't mean secure. It means you may have stopped seeing. When the EDR is silenced via BYOVD, the absence of alerts is the most dangerous symptom — not evidence of a healthy environment.
We repeat: assume the EDR can be blind. HVCI, WDAC, kernel callbacks, EDR canaries, offline IR, tested backups, IAM, and Zero Trust — each layer exists because the previous one can fail. At Tech86, we help companies build layered defense that survives tampering — because the green dashboard is the most expensive lie in security.