El EDR killer que aprovecha un driver antiguo y expone la amenaza BYOVD en Windows

Una investigación reciente de Huntress destapó una maniobra que suena a déjà vu para cualquiera que siga la seguridad en Windows, pero que sigue funcionando en el mundo real: actores maliciosos aprovecharon un antiguo driver legítimo de EnCase para crear un “EDR killer” capaz de identificar y apagar decenas de herramientas de seguridad en los equipos infectados.

Antes de entrar en detalles, conviene recordar qué es un EDR killer. Se trata de un programa malicioso diseñado específicamente para desactivar o eludir soluciones de respuesta y detección en endpoints. Suelen operar con privilegios de kernel porque, desde ahí, pueden desenganchar mecanismos de protección y terminar procesos de seguridad que en modo usuario serían inaccesibles. En este caso concreto los investigadores de Huntress vieron cómo la pieza maliciosa se disfrazó como una utilidad de actualización de firmware y cargó un driver antiguo llamado EnPortv.sys, perteneciente a EnCase (producto de investigación forense ahora en OpenText).

La técnica empleada no es nueva y tiene nombre: “Bring Your Own Vulnerable Driver” o BYOVD. En lugar de buscar un exploit en el kernel actual, los atacantes introducen un driver firmado legítimamente pero vulnerable —o con funcionalidades que permiten abuso— y lo usan para ejecutar operaciones en modo kernel. Grupos y muestras de malware han explotado BYOVD de forma recurrente; firmas antiguas, comportamientos de firma de drivers y excepciones en las políticas de Microsoft han hecho que este enfoque siga siendo efectivo. Para entender la técnica con más profundidad vale la pena leer análisis y piezas de contexto sobre BYOVD, como el artículo de ESET sobre el tema aquí.

En la intrusión descrita por Huntress, el acceso inicial se obtuvo mediante credenciales comprometidas de un SSL VPN de SonicWall, y la cuenta no tenía habilitada autenticación multifactor. Tras el acceso los atacantes realizaron un reconocimiento interno intenso —pings ICMP, sondeos NetBIOS, actividad SMB y ráfagas TCP de tipo SYN— y, según los investigadores, el actor probablemente pretendía desplegar ransomware aunque la campaña fue interrumpida antes de soltar la carga final. El caso subraya una verdad operativa: la ausencia de MFA y la supervisión deficiente de registros de VPN son puertas de entrada habituales para intrusos. Microsoft ha documentado repetidamente la efectividad de MFA para reducir compromisos; por ejemplo, su blog de seguridad describe cómo MFA bloquea la inmensa mayoría de intentos de toma de cuentas aquí.

El vector técnico central fue el driver EnPortv.sys, un componente de EnCase. Aunque su certificado digital fue emitido en 2006, expiró en 2010 y fue revocado, Windows seguía permitiendo su carga por un detalle de implementación del mecanismo de firma de drivers: la comprobación se basa en la verificación criptográfica y en sellos de tiempo, no en una consulta en tiempo real a listas de revocación (CRL) para todos los casos, y además existe una excepción que aplica a certificados emitidos antes del 29 de julio de 2015. Esa excepción, junto a las distintas políticas históricas de firma, abrió la puerta para que el driver pudiera instalarse y registrarse como un servicio de hardware OEM falso, logrando persistencia resistente a reinicios.

Una vez en kernel, el malware usó la interfaz IOCTL del driver para ordenar al sistema que terminara procesos de servicios de seguridad, eludiendo protecciones como Protected Process Light (PPL). Según Huntress la muestra viene con una lista de 59 procesos objetivo —entre agentes EDR y antivirus— y ejecuta un bucle de terminación cada segundo, de forma que si un proceso protegido se reinicia, el killer lo mata de nuevo al instante. Esa combinación de persistencia a nivel kernel y la capacidad de manipular procesos del sistema es lo que la convierte en una amenaza crítica para entornos con controles concentrados en EDR tradicionales.

Si quieres leer el análisis técnico, el informe de Huntress describe el flujo completo, indicadores y mecanismos de persistencia aquí. La nota pública de prensa y coberturas adicionales, como la de BleepingComputer, ayudan a situar el incidente en el panorama más amplio de abusos de drivers firmados.

¿Qué puede hacer un equipo de seguridad para reducir este tipo de riesgo? Primero, hay que atacar la causa más directa del acceso: las cuentas de acceso remoto. Habilitar MFA en todos los accesos remotos, vigilar logs de VPN y limitar privilegios de cuentas son pasos que suelen detener el avance inicial de estas campañas. En segundo lugar conviene aprovechar las mitigaciones que Microsoft ofrece para drivers y aislamiento de kernel: habilitar HVCI/Memory Integrity (parte de la "core isolation" en Windows) ayuda a aplicar la lista de drivers vulnerables bloqueados por Microsoft; la documentación técnica de Virtualization-based Security y HVCI aporta contexto sobre cómo funciona este aislamiento aquí y la guía de Microsoft sobre Windows Defender Application Control (WDAC) explica cómo controlar qué binarios y drivers se permiten en una flota aquí.

Además de HVCI y WDAC, existen reglas y controles en las soluciones de seguridad modernas pensadas para reducir la exposición a drivers firmados que fueron revocados o que funcionan de forma maliciosa. Implementar reglas de Attack Surface Reduction (ASR), monitorizar la creación de servicios kernel que se hagan pasar por OEM/hardware y bloquear firmas conocidas problemáticas son medidas que Huntress también recomienda. La documentación de ASR en Microsoft Defender for Endpoint es un buen punto de partida para equipos que gestionan entornos Windows aquí.

No es solo cuestión de tecnología: la detección temprana de movimientos horizontales e inteligencia sobre actividad inusual en la red interna son críticas. En el caso analizado, los intrusos realizaron barridos ICMP, sondeos NetBIOS y tráfico SMB ruidoso; monitorizar esos patrones y alertar sobre ráfagas anómalas —como altas tasas de SYN— puede interrumpir una operación antes de que el actor despliegue sus herramientas de persistencia. Asimismo, es importante preparar respuestas que incluyan aislamiento de segmentos afectados y revisión forense de credenciales expuestas.

Para equipos que gestionan soluciones forenses o que usan herramientas de terceros firmadas de hace años conviene revisar inventario y telemetría: ¿qué drivers con firmas antiguas hay desplegados en tu parque? ¿aparecen drivers instalados que se registran como componentes OEM y no coinciden con hardware real? Bloquear y revisar drivers firmados con certificados emitidos hace mucho tiempo o revocados reduce la superficie para ataques BYOVD. La política de firmas de Microsoft para drivers en modo kernel y las excepciones históricas están documentadas en la documentación para desarrolladores y firmas de drivers; leer esa normativa ayuda a entender por qué antiguos certificados siguen siendo aceptados por algunas versiones de Windows aquí.

Este incidente vuelve a poner sobre la mesa una lección importante: las defensas modernas requieren capas. Confiar únicamente en un EDR sin controles de acceso fuertes, sin aislamiento de kernel y sin políticas que restrinjan drivers firmados no es suficiente. Un buen plan de defensa combina controles preventivos (MFA, políticas de firma y bloqueo de drivers), detección (telemetría de red y endpoints) y respuesta (procedimientos para desacoplar, contener y analizar).

Si gestionas infraestructura Windows, revisa primero las cuentas con acceso remoto y obliga MFA. A continuación evalúa la posibilidad de activar HVCI/Memory Integrity, configurar WDAC/ASR según tu riesgo y auditar la presencia de drivers firmados históricamente en tus equipos. Para detalles técnicos y los indicadores de compromiso del incidente, consulta el informe de Huntress aquí y, para contexto sobre BYOVD, la investigación de ESET aquí.

La buena noticia es que las defensas existen y se están fortaleciendo. La mala es que la compatibilidad histórica, el uso legítimo de herramientas forenses o de administración y la complejidad del ecosistema de drivers siguen proporcionando resquicios que los atacantes aprovechan. Tener una política clara sobre drivers, una supervisión activa y controles de acceso robustos reduce de forma notable la posibilidad de que un actor convierta una vulnerabilidad histórica en un incidente devastador.