## 1 Introducción Este artículo proporciona un análisis técnico de cómo se puede interactuar con muchos drivers en modo kernel de Windows desde el modo de usuario sin el hardware para el que fueron desarrollados. Este trabajo fue motivado por la investigación de vulnerabilidades orientadas a drivers y la necesidad de evaluar la explotabilidad de hallazgos individuales, que frecuentemente afectan a código cuya accesibilidad está limitada por hardware. La metodología presentada aquí debería ayudar a cualquiera a determinar si una vulnerabilidad particular de un driver en modo kernel de Windows sigue siendo accesible, y por lo tanto potencialmente explotable, incluso en ausencia del hardware para el que fue desarrollado el driver. Se espera que el lector tenga conocimientos básicos de drivers de Windows, especialmente en lo que respecta a objetos de dispositivo. El resto de este artículo está escrito asumiendo que el lector ya está familiarizado con los conceptos descritos en el artículo introductorio: [Anatomy of Access: Windows Device Objects from a Security Perspective](https://atos.net/en/lp/cybershield/anatomy-of-access-windows-device-objects-from-a-security-perspective). Al igual que el artículo introductorio, este recurso no se centra en ninguna clase de bug específica, sino más bien en la superficie de ataque y, hasta cierto punto, en la arquitectura Plug and Play de Windows. Todas las pruebas demostradas aquí se realizaron en **Windows 11 23H2** (winver 10.0.22631.3007). > Para más investigaciones de amenazas y avisos de vulnerabilidades como esta, suscríbase a los blogs de [**Atos Cyber Shield**](https://atos.net/en/lp/cybershield#subscription-form). ## 2 El valor ofensivo de los drivers en modo kernel Además del obvio potencial de Escalada de Privilegios Local, los drivers vulnerables a menudo se abusan en ataques BYOVD, una técnica de post-explotación utilizada por los atacantes para interrumpir las defensas del sistema, como los componentes EDR. Dos criterios principales determinan si una vulnerabilidad de driver es un candidato fuerte para ataques BYOVD: 1. La explotación permite una interrupción significativa de un componente de seguridad que de otro modo sería resistente a la manipulación. Ejemplos incluyen vulnerabilidades a nivel de kernel que otorgan acceso de lectura/escritura de memoria arbitraria, ejecución de código arbitraria o abuso arbitrario de recursos (por ejemplo, sobrescritura de archivos, cierre de handles o terminación de procesos). 2. Su explotabilidad es independiente de condiciones de sistema raras, como la presencia de hardware específico. Aunque los ataques de estilo BYOVD han sido bien documentados durante años, con numerosos informes públicos y artículos de investigación sobre el tema (por ejemplo, [https://www.ndss-symposium.org/wp-content/uploads/2026-s1491-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2026-s1491-paper.pdf), [https://blackpointcyber.com/blog/qilin-ransomware-and-the-hidden-dangers-of-byovd/](https://blackpointcyber.com/blog/qilin-ransomware-and-the-hidden-dangers-of-byovd/), [https://www.sophos.com/en-us/blog/itll-be-back-attackers-still-abusing-terminator-tool-and-variants](https://www.sophos.com/en-us/blog/itll-be-back-attackers-still-abusing-terminator-tool-and-variants)), ninguno de ellos examina específicamente el papel del "gating" de hardware en la accesibilidad de las vulnerabilidades de drivers. ## 3 Creación y mantenimiento de objetos de dispositivo - patrones comunes El análisis proporcionado en este recurso se estructura en torno a los objetos de dispositivo, porque son el vector de ataque más viable. Sin embargo, las técnicas demostradas aquí impactan prácticamente la accesibilidad del código del driver desde el espacio de usuario en general, no solo a través de IRP. Los obstáculos más comunes al atacar un driver a través de su objeto de dispositivo son: 1. El objeto de dispositivo no se crea. 2. El estado interno del driver no permite el ejercicio del comportamiento vulnerable a pesar de que el objeto de dispositivo sea accesible. Ambos escenarios son muy comunes al tratar con un driver de dispositivo desplegado en un sistema sin el hardware físico correspondiente. En el resto del artículo me refiero a menudo a [device stacks y device nodes](https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/device-nodes-and-device-stacks). He cubierto los device stacks de manera bastante amplia en mi [artículo introductorio](https://atos.net/en/lp/cybershield/anatomy-of-access-windows-device-objects-from-a-security-perspective). Si bien un device node y un device stack no son lo mismo, los términos a menudo se usan indistintamente, porque cada device node tiene exactamente un device stack. ### 3.1 Creación incondicional al cargar el driver Muchos drivers, especialmente los no PnP, crean sus objetos de dispositivo directamente desde su función `DriverEntry`, o desde alguna otra función que se invoca en la cadena de llamadas directa que se origina en `DriverEntry`. El driver de demostración [**Multidev_WDM**](https://github.com/Atos-TRC/Atos-TRC-public-samples-and-code/windows-kernel-mode/kernel/multidev_WDM/) ejemplifica este patrón. Podemos ver la creación del dispositivo invocada de inmediato en `DriverEntry`:  Creación de CDO invocada directamente desde `DriverEntry` El driver también elimina el objeto de dispositivo llamando a `IoDeleteDevice`, pero eso solo ocurre cuando se llama a `DriverUnload` (cuando el driver se está descargando):  Limpieza de CDO desde `DriverUnload` Los drivers construidos de esta manera se pueden interactuar después de un despliegue simple que consiste solo en dos pasos: 1. Crear la entrada de servicio del driver: ``` sc.exe create SampleDrv type= kernel start= demand binPath= System32\drivers\SampleDrv.sys ``` * Iniciar el servicio (el driver se cargará): ``` sc.exe start SampleDrv ``` Si miramos un driver elegido al azar de [https://loldrivers.io/](https://loldrivers.io/), veremos que su comando de despliegue coincide con este patrón:  Despliegue de LOL drivers - zam64.sys Pero la mayoría de los drivers de dispositivo no entran en esta categoría, como veremos en las siguientes secciones de este artículo. ### 3.2 Creación y mantenimiento condicional de dispositivos A menudo, las rutinas de inicialización de drivers realizan comprobaciones adicionales. Por ejemplo, los componentes en modo kernel de software de seguridad (**EDR**, antivirus, monitoreo, autenticación mejorada, etc.) tienden a verificar claves y entradas de registro específicas del producto, que se crean e inicializan durante el despliegue normal del producto. Los drivers de dispositivo reales (creados para controlar hardware físico) tienden a crear sus objetos de dispositivo solo en presencia de ese hardware. Sin él, o bien: * no intentan crear ningún objeto de dispositivo, * eliminan cualquier objeto de dispositivo poco después de su creación, llamando a `IoDeleteDevice`. Centrémonos en cómo se implementa esa lógica y evaluemos si y cómo se puede sortear, especialmente desde la perspectiva BYOVD, operando únicamente desde el espacio de usuario (sin acceso físico/hypervisor). Por cierto, el segundo escenario, en el que un objeto de dispositivo se crea primero y luego se elimina poco después, crea una situación que podría considerarse una condición de carrera, porque hay una breve ventana de tiempo en la que el objeto de dispositivo existe. ### 3.3 Callbacks específicos de PnP como ubicación principal de la lógica de inicialización de drivers PnP En drivers compatibles con PnP (que constituyen la mayoría de los drivers de dispositivo