Una investigación de Check Point Research vuelve a poner el foco en un escenario poco habitual: no hace falta explotar una vulnerabilidad de terceros ni introducir un controlador “malicioso” externo para causar daño. El punto central es BTR.sys, un controlador que forma parte del ecosistema de Microsoft Defender y que, según el análisis, podría reutilizarse para ejecutar operaciones arbitrarias a nivel de kernel durante el arranque de Windows.
En concreto, el trabajo describe una técnica capaz de eliminar software de seguridad antes de que algunos servicios de modo usuario se terminen de iniciar. A pesar de su naturaleza ofensiva, el hallazgo no implica que el controlador sea defectuoso en el sentido clásico: el problema se entiende más como una frontera de confianza que puede cruzarse si el atacante ya dispone de privilegios de administrador.
Qué es BTR.sys y por qué importa
BTR.sys (Boot Time Removal Tool) es un componente requerido de Windows, incluido como parte del mecanismo de remediación de Microsoft Defender. Esa condición es clave: al tratarse de un recurso integrado y legítimo, no encaja fácilmente en bloqueos típicos como las listas de “controladores vulnerables” ni en políticas de control de aplicaciones como WDAC, al menos sin afectar al propio Defender.
En circunstancias normales, BTR.sys se activa cuando Defender necesita completar la eliminación de malware después de un reinicio. Es decir, se usa para borrar elementos que estaban bloqueados mientras Windows se ejecutaba.
El salto: de remediación a operaciones arbitrarias
El equipo de investigación, liderado por Jiří Vinopal, explica que fue posible reconstruir un protocolo propietario de transacciones del controlador, no documentado públicamente. Con esa comprensión, se observa que cada configuración que se le entrega está cifrada con RC4 usando una clave de 256 bytes incrustada en la sección .rdata del binario. Además, el trabajo indica que esa clave se mantuvo sin cambios a lo largo de 18 versiones de 64 bits enviadas desde Windows 7.
La investigación también detalla cómo una herramienta de prueba de concepto (BTR_CLI) puede localizar el archivo MpEngine.dll dentro de las actualizaciones de definiciones de Defender, extraer el binario BTR.sys embebido y construir una transacción cifrada válida. Con esa transacción lista, el siguiente paso consiste en instalar el controlador como servicio.
Cómo se “instala” el controlador sin señales típicas
Lo llamativo de BTR_CLI es la forma de registrar el servicio. La instalación se realiza mediante escrituras directas en el registro (HKLM), usando parámetros como Type=1, Start=1 y Group="Boot Bus Extender". Según el informe, este enfoque evita pasar por el Service Control Manager y, por lo tanto, no genera una entrada esperada del evento Windows Event ID 7045 (Service Installed).
Cuando BTR.sys se carga, ejecuta la cola de operaciones desde Ring 0 (modo kernel). En el telemetraje se atribuye la actividad al proceso System con PID 4, un detalle relevante porque complica la atribución superficial para quienes solo revisan eventos a nivel de aplicación.
Qué puede hacer BTR.sys durante el arranque
De acuerdo con el análisis, una vez cargado, BTR.sys puede realizar acciones que normalmente solo se esperarían de operaciones internas y muy controladas. Entre las capacidades descritas están:
- Eliminar archivos y directorios que permanezcan bloqueados.
- Mover archivos hacia rutas no restringidas, incluidas ubicaciones sensibles como System32\drivers.
- Borrar claves y valores del registro.
- Escribir nuevos valores de registro de cualquier tipo.
También se describe un modo de activación adicional que programa las operaciones para el próximo reinicio. El impacto práctico es claro: si se consigue que estas tareas ocurran en el momento adecuado, el “stack” de defensa puede perder componentes esenciales antes de que se bloqueen por completo.
El momento crítico: la “golden window”
La investigación introduce un concepto operativo llamado “golden window”: el intervalo posterior a que el sistema de archivos vuelve a estar escribible, pero antes de que los servicios de Defender en modo usuario hayan iniciado. En esa franja, el controlador puede eliminar binarios y módulos de seguridad físicamente en disco, evitando que lleguen a auto-protegerse mediante mecanismos de bloqueo.
En una demostración en vivo durante Black Hat USA 2026 se describe la eliminación completa de la pila de Defender en un Windows 11 25H2 con Tamper Protection activo. Es importante notar que la demostración no implica que sea trivial en todos los entornos, pero sí evidencia la clase de daño que podría producirse si se cumplen los requisitos de acceso.
Requisitos: por qué no es un fallo explotable “sin más”
El informe subraya que explotar esta técnica requiere una cuenta con SeLoadDriverPrivilege. Además, la herramienta de prueba de concepto automatiza la activación de este privilegio para cuentas que ya lo tengan asignado.
Por ello, los autores enmarcan el problema como un asunto de confianza arquitectónica. No se trata de una vulnerabilidad tradicional que cualquier atacante pueda aprovechar desde fuera; se trata de lo que se puede hacer cuando ya existe acceso privilegiado. Tras la divulgación responsable, el MSRC de Microsoft habría confirmado que no cumple criterios para una corrección inmediata de “servicing” porque depende de privilegios administrativos preexistentes (según la explicación atribuida en el documento).
En el repositorio de la prueba de concepto también se menciona que no se planifica un parche. Microsoft no habría confirmado públicamente esa postura en el momento de la publicación.
Señales para detectar abuso de BTR.sys
Como no se observaron evidencias de uso en ataques reales durante el análisis de telemetría y muestras, el enfoque se centra en la detección temprana: ingeniería proactiva antes de que la técnica aparezca en campañas.
Check Point Research lista condiciones e indicadores, incluyendo correlaciones entre Sysmon y eventos de Windows. Entre los que se mencionan:
- Sysmon Event ID 15 (FileCreateStreamHash), cuando el nombre objetivo termina en .sys:changelist para capturar la configuración cifrada en un Alternate Data Stream.
- RegistryEvent (Sysmon Event ID 12 o 13) creando una clave de servicio cuyo valor Args incluye :changelistand y cuyo Group es "Boot Bus Extender", especialmente si no aparece un Windows Event ID 7045 (Service Installed).
- Sysmon Event IDs 11 (FileCreate) y 23 (FileDelete), registrando creación y eliminación rápidas de \SystemRoot\Temp\BootClean.log por el proceso System (PID 4). El informe indica que esta ruta está codificada en el controlador y se dispara sin importar el origen.
- Sysmon Event ID 6 (DriverLoad) inmediatamente seguido de Sysmon Event ID 23 (FileDelete), ambos atribuidos a System (PID 4), como huella de ejecución en modo kernel.
Además, el documento recomienda como endurecimiento restringir la asignación del privilegio SeLoadDriverPrivilege. Esta medida busca reducir la superficie disponible para una posible activación abusiva, incluso si el controlador es parte del sistema.
Cómo encaja con ataques anteriores
El informe compara la idea con técnicas de “bring your own vulnerable driver” (traer tu propio controlador vulnerable), que dependen de controladores firmados de terceros previamente conocidos por ser explotables y de los cuales se puede decidir bloquear. En contraste, la técnica descrita se apoya en un controlador construido dentro de Windows desde hace años, por lo que encaja menos en estrategias basadas únicamente en listas de bloqueo.
El concepto de usar controladores integrados como primitivas ofensivas ya había sido mostrado en otro contexto: el trabajo cita una experiencia relacionada con FIN7, donde un controlador del sistema (ProcLaunchMon.sys) fue aprovechado junto con otro componente para manipular el software de seguridad del endpoint. En el caso actual, la diferencia está en que el foco recae en BTR.sys y su activación en arranque.
Estado actual: evidencia de ataques en el mundo real
Check Point Research afirma no haber encontrado señales de abuso en escenarios reales. Durante su revisión de muestras y de diversas fuentes de telemetría, no observaron el patrón presentado en la investigación. Esa ausencia sugiere que la técnica puede ser desconocida o no utilizada por actores maliciosos por el momento, lo cual hace especialmente valiosa la preparación defensiva.
Qué hacer como organización
Si gestionas endpoints con Windows y ya tienes visibilidad con Sysmon, conviene revisar la capacidad de correlación entre eventos de instalación de servicios, carga de controladores y operaciones rápidas en rutas temporales. La clave no es mirar un único evento, sino buscar combinaciones coherentes con el patrón descrito para BTR.sys.
Además, revisa quién tiene SeLoadDriverPrivilege asignado y aplica el principio de mínimo privilegio. Dado que la técnica depende de privilegios ya disponibles, limitar la asignación de ese permiso puede reducir la probabilidad de que un atacante con acceso administrativo logre ejecutar la cadena descrita.
Finalmente, asegúrate de que tu estrategia de detección contemple el momento del arranque y las fases en las que Defender aún está iniciando componentes. La “golden window” es un recordatorio de que el orden de arranque puede ser tan importante como las reglas de seguridad.
Conclusión
BTR.sys es un controlador legítimo integrado en el funcionamiento de Microsoft Defender, diseñado para remediación tras reinicios. Sin embargo, el análisis de Check Point Research muestra que, con privilegios administrativos concretos y una cadena de operaciones, podría emplearse para borrar o modificar componentes de seguridad antes de que se bloqueen por completo.
Aunque no se hayan observado abusos reales en el momento de la investigación, el trabajo ofrece una ruta clara para mejorar la detección: correlaciones de Sysmon y eventos relevantes, junto con una recomendación práctica de endurecimiento basada en limitar SeLoadDriverPrivilege. Con esa preparación, es más sencillo actuar antes de que una técnica como esta se convierta en una herramienta habitual en ataques contra Windows.
Fuente: https://thehackernews.com/2026/08/microsoft-defenders-own-driver-can-be.html
