BYOVD significa Bring Your Own Vulnerable Driver, es decir «trae tu propio controlador vulnerable». En este esquema el atacante no necesita una vulnerabilidad de día cero reciente en Windows. El hacker aporta un controlador firmado legítimo, pero a menudo obsoleto y vulnerable, y luego obliga al sistema a cargarlo.
El problema es que los controladores se ejecutan en la capa más privilegiada del sistema operativo. Un fallo o una función insegura dentro del controlador puede otorgar una palanca universal: lectura y escritura de la memoria del núcleo, desactivación de mecanismos de protección, detención de procesos de EDR, ocultación de actividad. Frente a esto, los trucos habituales a nivel de usuario parecen casi inocuos.
BYOVD rara vez es el «primer paso». Más a menudo se recurre a él después de phishing, robo de credenciales o la explotación de una vulnerabilidad que ya otorgó privilegios de administrador. La instalación del controlador casi siempre requiere privilegios elevados, y los atacantes lo tienen en cuenta, construyendo una cadena para que BYOVD actúe como acelerador en la segunda mitad del ataque.
Hay además un beneficio psicológico: desde fuera todo parece legítimo. El controlador está firmado, el nombre del proveedor resulta familiar, en el disco aparece un .sys común. Por eso la defensa no se reduce solo a firmas, sino a disciplina: qué controladores se permiten en la infraestructura y quién tiene derecho a instalarlos.
A continuación se explica por qué BYOVD funciona, cómo es una cadena de ataque típica y qué medidas reducen el riesgo en la práctica. Al final hay enlaces a recursos que ayudan a mantenerse al tanto.
Por qué un controlador vulnerable abre la puerta al núcleo
El controlador del núcleo se ejecuta en ring 0 e interactúa con las estructuras internas de Windows. Si el controlador gestiona de forma insegura los códigos de control IOCTL, puede, a petición desde el modo usuario, hacer cosas que un programa normal no puede. En la práctica, el proceso de usuario obtiene un «control remoto» sobre operaciones peligrosas pensadas para mantenimiento de hardware, diagnóstico o administración.
Las capacidades más frecuentes para el atacante: primitivas para escribir en la memoria del núcleo, acceso a la memoria física o a los registros, verificación débil de permisos para operaciones peligrosas, y a veces funciones directas como terminar procesos o desactivar componentes de protección. A veces es un error, a veces es legado de modos «de diagnóstico» que en su día facilitaron la vida al soporte técnico, pero que al final facilitaron la vida a otras personas.
La firma del controlador añade peso al ataque. Windows bloquea componentes no firmados, y BYOVD explota la confianza en la firma como transporte. El controlador puede formar parte de utilidades para monitorizar hardware, actualizar firmware, diagnóstico de bajo nivel, y por eso pasa desapercibido. Especialmente en entornos donde los empleados usan «herramientas útiles» y al departamento de TI le resulta más fácil mirar hacia otro lado que discutir cada vez.
Otro punto práctico para el atacante: una vulnerabilidad en un controlador suele ser más estable que una en el propio sistema operativo. El controlador puede no cambiar durante años, seguir aceptando IOCTL peligrosos y funcionar igual en distintas versiones de Windows. Esto convierte a BYOVD en una herramienta útil para escalar ataques cuando se necesita un resultado predecible y no una combinación complicada de condiciones.
Al final el atacante obtiene un método reproducible para alcanzar el kernel. Para grupos de ransomware y operadores de malware esto es pragmático: menos explotación compleja, más control sobre la máquina y más posibilidades de desactivar silenciosamente las defensas antes de que estas «avisen» en la consola.
Cómo es un ataque BYOVD paso a paso
En la máquina se introduce un controlador y un pequeño componente de usuario que se comunica con él mediante IOCTL. Después el controlador se registra como servicio y se carga con los medios estándar de Windows. A veces esto se hace abiertamente, a veces se disfraza como la instalación de software legítimo, y a veces simplemente se esconde en un directorio atípico con un nombre que parece ser algo del sistema.
El punto clave para la detección es la carga del controlador. Antes de que el código ejecute en ring 0, a los defensores les es más fácil reaccionar: se ven la creación del servicio de controlador, la aparición de un nuevo .sys, intentos de carga, y eventos de integridad de código. En ese momento muchas soluciones EDR todavía pueden detener el desarrollo del ataque o al menos dejar una señal visible en la telemetría.
Después el atacante explota la vulnerabilidad para realizar operaciones en el núcleo. Objetivos típicos: desactivar u cegar EDR/AV, quitar banderas de protección, suplantar permisos de procesos, preparar la carga oculta de otro controlador o la persistencia. Un escenario especialmente desagradable es cuando el controlador vulnerable se usa como trampolín y luego se introduce en el sistema un controlador claramente malicioso que sin esa preparación no podría consolidarse.
Tras el exitoso «traslado» al kernel, las trazas se vuelven más difusas. El agente de seguridad puede caer repentinamente o dejar de ver eventos, mientras que el sistema sigue funcionando aparentemente con normalidad. Por eso BYOVD suele actuar como una pasarela técnica antes del cifrado o la exfiltración: primero se apaga la «alarma», luego viene todo lo demás.
La esquema suele encajarse en una secuencia corta:
- Obtención de privilegios de administrador.
- Entrega y registro del controlador firmado y vulnerable.
- Explotación de IOCTL para operaciones en modo núcleo.
- Desactivación de la protección y acciones posteriores (cifrado, robo de datos, persistencia).
BYOVD no está vinculado a un solo grupo. Se repite porque controladores similares aparecen en diferentes nichos y el efecto para el atacante suele ser el mismo: control rápido del equipo a nivel de núcleo.
De dónde provienen los controladores vulnerables y cómo protegerse
El primer origen son catálogos públicos e investigaciones. El proyecto LOLDrivers recopila controladores vulnerables y maliciosos conocidos y proporciona material para su detección, y el catálogo de controladores es útil para buscar por nombre y hashes. Para ampliar el panorama resulta útil el análisis de Cisco Talos.
El segundo origen es el análisis de software popular. Un controlador puede tener IOCTL peligrosos simplemente porque el desarrollador en su día creó una interfaz «cómoda» hacia el hardware. Para el atacante es casi una biblioteca lista de funciones del núcleo, sin necesidad de escribir su propio controlador desde cero. Y sí, este es uno de esos casos en que «cómodo» y «seguro» quedan en lados opuestos de la barrera.
La defensa más práctica es bloquear controladores problemáticos conocidos. Microsoft desarrolla la Microsoft Vulnerable Driver Blocklist y actualiza regularmente el archivo DriverSiPolicy.p7b. Es recomendable empezar por la documentación sobre las reglas recomendadas para bloquear controladores, así como por la ayuda sobre cómo gestionar la lista de bloqueo a través de Windows Security: KB5020779.
Además de las listas de bloqueo, es importante la «higiene de privilegios»: menos administradores locales, control sobre la instalación de controladores, activado el aislamiento del núcleo y HVCI, y monitorización de ejecuciones inusuales de sc.exe y pnputil.exe. Si por compatibilidad se ha desactivado la lista de bloqueo, conviene documentar las excepciones y revisarlas con regularidad en lugar de dejarlo en un modo «lo arreglaremos después».
Para la monitorización son útiles indicadores que no dependen del nombre del controlador:
- creación del servicio del controlador y posterior carga de un nuevo .sys;
- controlador en un directorio no estándar o con un nombre de un solo uso;
- serie de terminaciones de procesos de EDR/AV o desactivación de sus componentes;
- eventos de Code Integrity relacionados con bloqueo o intento de carga de un controlador.
Para entender el contexto convienen algunos análisis. Elastic describe la lógica de BYOVD y escenarios típicos de uso. Y Microsoft ofrece material sobre el centro de notificación de controladores vulnerables y maliciosos, que ayuda al ecosistema a reaccionar más rápido.
Conclusión
BYOVD se basa en la paradoja de la confianza: la firma del controlador facilita su entrada en el sistema, pero no garantiza la seguridad de sus funciones. Si en su interior hay una primitiva peligrosa, la firma se convierte en un pase al kernel y no en una barrera.
Por eso la protección debe ser aburrida y sistemática: actualizaciones de Windows, lista de bloqueo de controladores vulnerables activada, control de administradores y la instalación de controladores según las normas. Cuantas menos utilidades «ajenas» que requieran un controlador por conveniencia haya en la infraestructura, más difícil será para el atacante encontrar la palanca adecuada.
Y una última conclusión práctica: un nuevo servicio de controlador o un intento de cargar un .sys desconocido merece la misma atención que la ejecución de un .exe sospechoso. En la era BYOVD eso suele ser el mismo incidente, solo en distintos pisos del sistema, y es mejor capturarlo antes de que se convierta en el titular de un informe sobre otro «cifrado» repentino.
