Tu EDR dejó de reportar. El dashboard está en verde. Nada alertó. Pero el encryptor ya está corriendo.
Reconstruye de atrás hacia adelante. Un IOCTL fue enviado a un driver de kernel recién cargado, firmado y vulnerable. Con acceso a la memoria física, el atacante terminó los procesos del EDR vía ZwTerminateProcess y eliminó los kernel callbacks. El agente aparece activo y no ve nada. En Tech86 ya vimos este escenario, y es más común de lo que parece.
BYOVD: bring your own vulnerable driver
BYOVD es una técnica donde el atacante trae su propio driver vulnerable al objetivo. El driver tiene una firma válida de Microsoft: es un driver legítimo de un vendor legítimo, solo que con una vulnerabilidad explotable. Windows permite cargarlo porque la firma es válida. Una vez en el kernel, el driver expone IOCTLs que permiten leer y escribir directamente en memoria física.
Con acceso a la memoria física, el atacante opera por debajo de las protecciones del sistema operativo. Termina los procesos del EDR vía ZwTerminateProcess. Elimina los kernel callbacks que el EDR usa para monitorear creación de procesos, acceso a archivos e inyección de threads. El agente del EDR sigue corriendo, aparece activo en el dashboard, pero está ciego. No ve nada porque le arrancaron los ojos desde dentro del kernel.
The Gentlemen, Storm-2697 y la escala del problema
La firma es The Gentlemen, un grupo que surgió de una disputa en el Qilin RaaS en 2025. Microsoft lo rastrea como Storm-2697. Según ESET, el grupo acumuló más de 480 víctimas en 66 países, con más de 250 en América Latina, una concentración regional que sugiere un foco deliberado en nuestro mercado.
El 7 de julio de 2026, el grupo listó a Mercado Libre en su leak site de la dark web. Una reivindicación, no un incidente confirmado. Sin muestra, la brecha no está confirmada. La distinción importa: una publicación en el leak site es una afirmación del atacante, no una evidencia de compromiso. Pero la escala del grupo, más de 480 víctimas en 66 países según ESET, hace que cada reivindicación merezca investigación.
Los dos EDR killers: ThrottleBlood.sys y ktapi.sys
Dos EDR killers se destacan en la operación. El primero es ThrottleBlood.sys, en realidad el ThrottleStop.sys renombrado, una utilidad de overclock legítima. Tiene el CVE-2025-7771 asignado, con CVSS 8.7. El driver expone IOCTLs para leer y escribir en memoria física vía MmMapIoSpace, bypaseando SMEP y SMAP. Con eso mata a los principales EDR del mercado.
El segundo es ktapi.sys, de Kontron. Un zero-day sin CVE asignado. El driver mapea memoria del kernel directamente en el espacio del atacante y bypasea PatchGuard, SMAP y SMEP. La diferencia crítica: ktapi.sys estaba ausente de las blocklists cuando fue descubierto. La blocklist es reactiva: solo bloqueas lo que conoces. Un zero-day sin CVE no está en ninguna lista.
Por qué PPL y las blocklists no bastan
PPL (Protected Process Light) resiste la terminación vía user-mode, pero no vía kernel-mode. Un driver vulnerable cargado en el kernel tiene privilegios suficientes para terminar procesos PPL. La protección asume que el kernel es confiable: cuando el kernel está comprometido vía BYOVD, PPL no ayuda.
Las blocklists de drivers son igualmente limitadas. Bloquean drivers conocidos después de que la vulnerabilidad es descubierta y divulgada. Pero entre el descubrimiento de la vulnerabilidad y la actualización de la blocklist hay una ventana de exposición. Y un zero-day sin CVE, como el ktapi.sys de Kontron, no está en ninguna lista. La defensa no puede depender de conocer todas las amenazas.
Defensa en capas: HVCI, WDAC, canaries e IR offline
La defensa contra BYOVD es en capas porque ninguna capa única es suficiente. HVCI (Hypervisor-Protected Code Integrity) opera en Ring -1, por debajo del kernel, y bloquea las violaciones W^X a nivel del hypervisor. Incluso si un driver vulnerable obtiene acceso a la memoria del kernel, el hypervisor impide la ejecución de código sin firmar.
WDAC (Windows Defender Application Control) con allowlisting de drivers es proactivo: solo los drivers aprobados explícitamente se cargan en el kernel. La blocklist es reactiva; el allowlisting es preventivo. Cuando aparece un nuevo driver vulnerable, ya está bloqueado por defecto.
Monitorea los kernel callbacks para detectar tampering e implanta EDR canaries como tripwires. Si el callback que monitorea los canaries desaparece, sabes que hubo manipulación. Y asume la ceguera del EDR: mantén IR offline y prueba las copias de seguridad regularmente. Cuando el encryptor está corriendo y el EDR está ciego, la copia de seguridad probada es la última línea de defensa.
En Tech86, el SOC 24/7 humano sobrevive al tampering con threat hunting proactivo. El Red Team simula el kill-chain completo del BYOVD, desde el acceso inicial vía infostealer hasta el encryptor. IAM y Zero Trust reducen el credential theft que le da al atacante el acceso inicial necesario para cargar el driver.
Conclusión: el dashboard verde no significa seguro
El dashboard verde no significa seguro. Significa que puedes haber dejado de ver. Cuando el EDR es silenciado vía BYOVD, la ausencia de alertas es el síntoma más peligroso, no la evidencia de un ambiente saludable.
Lo repetimos: asume que el EDR puede quedar ciego. HVCI, WDAC, kernel callbacks, EDR canaries, IR offline, copias de seguridad probadas, IAM y Zero Trust: cada capa existe porque la anterior puede fallar. En Tech86 ayudamos a las empresas a construir defensa en capas que sobrevive al tampering, porque el dashboard verde es la mentira más cara de la seguridad.