En junio de 2026, el equipo Threat Hunter de Symantec Carbon Black publicó un análisis detallado de cómo Hackledorb, el grupo responsable del ransomware DragonForce, permaneció entre uno y dos meses infiltrado en una importante empresa de servicios estadounidense. Antes de desplegar el ransomware, y antes incluso de eliminar un solo proceso de seguridad, los operadores cargaron cuatro controladores en modo kernel de forma secuencial. Tres de ellos tenían vulnerabilidades CVE documentadas. El cuarto, un controlador de audio de Huawei al que los operadores denominaron «Havoc Process Terminator», no presentaba ninguna vulnerabilidad conocida en el momento de su implementación.
Una nota sobre la denominación de los grupos. Symantec Carbon Black identifica a este operador como «Hackledorb»; Trend Micro denomina al mismo grupo «Water Tambanakua». «DragonForce» hace referencia al cártel de ransomware en su conjunto; varios operadores llevan a cabo ataques bajo esa marca. Su origen sigue sin confirmarse: Intel 471 señala que el operador principal publica en ruso en foros de ciberdelincuencia; una posible conexión con Malasia se remonta a un grupo hacktivista independiente que negó cualquier vínculo a principios de 2024.
Qué comprueba realmente un certificado de controlador de Microsoft
Todos los controladores que se carguen en una versión moderna de Windows deben contar con una firma válida de Microsoft. Ese requisito es real.
Lo que comprueba: que el controlador proceda de un proveedor que haya superado el proceso de certificación de Microsoft y que el archivo binario no haya sido alterado. Lo que no comprueba: si el controlador contiene vulnerabilidades de seguridad. Ese nunca fue el objetivo de este filtro.
La firma del núcleo es una garantía de procedencia: indica quién ha distribuido el código. No es una garantía de que el controlador no pueda ser objeto de un ataque.
«Bring Your Own Vulnerable Driver» (BYOVD) es lo que ocurre cuando un atacante aprovecha esa brecha. Carga un controlador legítimo y firmado que presenta un fallo de seguridad conocido, utiliza ese fallo para desactivar el software de seguridad y, a continuación, lleva a cabo el ataque. Windows detecta una firma válida y carga el controlador con normalidad. El registro de eventos registra una instalación rutinaria. Todo parece estar en orden.
La misma biblioteca, dos campañas
Esta campaña no es un caso aislado.
En junio de 2026, ESET publicó un estudio sobre GentleKiller, un marco BYOVD que un segundo grupo de ransomware distribuye a sus afiliados como herramientas estándar previas al ataque. Utiliza controladores firmados de varios proveedores legítimos para desactivar las herramientas de seguridad de 48 proveedores, entre los que se incluyen Defender, CrowdStrike, SentinelOne y Sophos. ESET confirmó 478 víctimas en más de 70 países.
Ambas campañas utilizaron un controlador de audio de Huawei. En la campaña de diciembre de 2025, ese controlador no presentaba ninguna vulnerabilidad documentada cuando los operadores lo implementaron. Huntress publicó su análisis tres meses después, tras el ataque.
La biblioteca de controladores abarca un estudio de videojuegos, un proveedor de productos de seguridad, un fabricante de hardware de audio y una empresa de prevención del fraude. Se trata de empresas legítimas que distribuyeron código firmado y que no tuvieron nada que ver con lo que ocurrió después. El proceso de firma validó cada controlador en el momento de su lanzamiento y siguió validándolos después de que se detectaran las vulnerabilidades.
La lista de bloqueo no puede bloquear lo que aún no se ha encontrado
Microsoft mantiene una lista negra de controladores vulnerables. Se aplica de forma rigurosa y está actualizada, y funciona.
El problema es el momento. Un controlador se añade después de que aparezca en un ataque, después de que se registre un CVE y después de que la campaña haya generado suficiente repercusión. En el ataque de diciembre de 2025, tres controladores tenían CVE documentados que aún no se habían incluido en la lista de bloqueo. El controlador de Huawei no tenía ningún CVE.
No se trata de un fallo del proceso, sino de una limitación estructural. La lista de bloqueo es reactiva. Los atacantes aprovechan el margen de tiempo que transcurre entre el momento en que se puede explotar una vulnerabilidad y el momento en que la defensa se pone al día.
La única ventana de detección
Hay un momento en el que un defensor puede interceptar un ataque BYOVD antes de que se desactiven las herramientas de seguridad.
Cuando un controlador se carga como servicio de Windows, el sistema registra el ID de evento 7045. Este evento se activa mientras las herramientas de seguridad siguen en ejecución, antes de que comience la secuencia de cierre. La supervisión de esos registros para detectar instalaciones de controladores que se desvíen de tu línea de base habitual te brinda una oportunidad para actuar.
Una vez que se ejecuta la secuencia de eliminación, esa ventana se cierra.
También existe una solución estructural: al habilitar la integridad de la memoria (también conocida como HVCI) se aplica una política de controladores más estricta que bloquea esta técnica antes de que se ponga en marcha. La mayoría de los entornos empresariales no la han habilitado. Requiere compatibilidad de hardware y pruebas de compatibilidad que muchas organizaciones aún no han completado. La solución existe. La implementación se está retrasando.
Lo que no cubre el certificado
La firma de código indica quién ha distribuido el controlador. No indica si alguien más podría aprovecharlo años más tarde.
Ambas campañas se nutren de una biblioteca que abarca los ámbitos de los videojuegos, la ciberseguridad, el hardware y el software empresarial. Se trata de proveedores legítimos con firmas válidas, todos ellos al alcance de cualquier atacante que encuentre la vulnerabilidad adecuada.
BYOVD no altera el sistema de firma del núcleo de Windows. Lo utiliza.
La inclusión en la lista de bloqueados tras la «armamentización» es un enfoque reactivo. La integridad de la memoria (HVCI) es la solución estructural. Hasta que se implante de forma más generalizada, la detección práctica se centra en buscar el ID de evento 7045 para detectar cargas anómalas de controladores.
La detección no falla. Es incompleta.
Vectra AI en la capa de red, no en el terminal, por lo que la secuencia de desactivación que se describe aquí no le afecta. Si quieres profundizar en cómo la detección basada en la red se integra con los controles de los terminales y de identidad en las tres brechas, el libro electrónico «Mind Your Attack Gaps» describe la arquitectura completa.