Check Point descubrió que BTR.sys, componente legítimo de remediación de Microsoft, puede ser reprogramado para borrar archivos del sistema y modificar el registro desde el kernel — sin explotar ninguna vulnerabilidad.
Investigadores de Check Point Research descubrieron que un driver firmado por Microsoft, parte de Windows Defender, puede ser reutilizado como motor de operaciones a nivel kernel capaz de eliminar archivos, modificar el registro y neutralizar controles de seguridad. El hallazgo no se basa en una vulnerabilidad tradicional ni en el modelo conocido como BYOVD (traer tu propio driver vulnerable): en cambio, abusa de funcionalidad intencionalmente construida dentro del driver de remediación en tiempo de arranque de Defender, identificado como BTR.sys. El researcher Jiří Vinopal realizó ingeniería inversa del driver y su formato de transacción no documentado, confirmando que BTR.sys puede ser instruido para realizar operaciones arbitrarias de archivos y registro desde modo kernel. La técnica funciona en todas las versiones de Windows desde Windows 7 hasta Windows 11 25H2 completamente actualizado.
Cómo un mecanismo de limpieza legítimo se convierte en vector de ataque
BTR.sys es un componente legítimo firmado por Microsoft que Defender utiliza cuando necesita realizar remediación que requiere reinicio, como eliminar un archivo bloqueado. La técnica descubierta por Check Point abusa de la forma en que BTR.sys recibe sus instrucciones: en lugar de exponer una interfaz IOCTL convencional, el driver lee una configuración encriptada almacenada en un Alternate Data Stream adjunto al propio driver. Vinopal encontró que la configuración utiliza encriptación RC4 con una clave hardcodeada de 256 bytes y un checksum CRC-32 personalizado.
Una vez desencriptada, la configuración contiene una secuencia de acciones que incluyen eliminación de archivos, eliminación de directorios, movimiento de archivos y operaciones de registro. Las operaciones de registro identificadas incluyen eliminación de claves y valores, establecimiento de valores, modificación arbitraria del registro y, potencialmente, manipulación de persistencia o controles de seguridad. Cuando el destino se establece en System32, la primitiva de movimiento de archivos puede convertirse en una capacidad de escritura arbitraria de archivos, señaló Vinopal.
La ventana de oro: 34 segundos sin protección durante el arranque
Check Point identificó un factor agravante en la ubicación de BTR.sys dentro de la secuencia de arranque de Windows. El driver no puede ejecutarse como un driver de arranque tradicional Start=0, pero puede ejecutarse muy temprano en la Fase 1 cuando se configura como driver de sistema Start=1 en el grupo Boot Bus Extender. Esto crea lo que Vinopal denominó una ventana de oro: el sistema de archivos ya está disponible para modificación, pero los servicios de seguridad importantes y los componentes de protección en modo usuario aún no han iniciado.
El servicio principal de antivirus inicia aproximadamente 34 segundos después de que el driver BTR haya terminado su trabajo. Check Point demostró que este timing puede ser utilizado para eliminar binarios de Defender y modificar claves de registro relacionadas con Defender antes de que los servicios de protección puedan lanzarse. La técnica fue automatizada con una herramienta de prueba de concepto llamada BTR_CLI, que incluye la extracción del driver legítimo desde la instalación local de Defender, la construcción de la transacción encriptada y la carga del driver. Al utilizar la copia propia de BTR.sys de la máquina objetivo, la herramienta evita introducir drivers externos como en los ataques BYOVD convencionales.
Dieciocho versiones firmadas con la misma clave de encriptación
Los investigadores identificaron 18 versiones únicas de 64 bits del driver firmado por Microsoft y encontraron el mismo formato de transacción y clave RC4 a través de las versiones examinadas. Esta consistencia en el diseño a lo largo de múltiples versiones del driver sugiere que el formato de transacción y el esquema de encriptación han permanecido sin cambios durante años, ampliando la superficie de sistemas potencialmente afectables. No hay evidencia de explotación en la naturaleza hasta el momento de la publicación.
Microsoft Security Response Center determinó que la técnica no cumplía los criterios para servicing inmediato, argumentando que requiere privilegios preexistentes. La posición de Microsoft refleja un debate más amplio en la industria sobre qué constituye una vulnerabilidad cuando la funcionalidad abusada es intencional y requiere acceso administrativo previo. Sin embargo, la capacidad de operar durante la ventana de arranque antes de que los controles de seguridad estén activos representa un escenario de post-compromiso donde un atacante con privilegios puede consolidar persistencia de forma particularmente efectiva.
Exposición en América Latina por dependencia de Defender en infraestructura corporativa
La técnica tiene implicancias directas para organizaciones en México, Brasil, Colombia y Argentina que dependen de Windows Defender como solución de endpoint primaria en entornos corporativos. Aunque no hay datos específicos de explotación en la región, la adopción de Defender como reemplazo de soluciones de terceros ha crecido en sectores financiero y gubernamental latinoamericano durante los últimos tres años, impulsada por estrategias de consolidación de licenciamiento Microsoft. La ventana de 34 segundos sin protección durante el arranque representa un riesgo particular en escenarios de ransomware donde los atacantes ya han obtenido privilegios administrativos y buscan desactivar defensas antes de la fase de encriptación.
Check Point recomendó que el bloqueo basado en firmas es inefectivo porque BTR.sys es legítimo, sugiriendo en cambio el uso de contexto comportamental. Buscar señales de que el driver está siendo utilizado fuera de sus flujos normales de Defender, como linaje de procesos inusual y actividad inesperada de archivos o registro, puede ayudar a detectar el abuso. La detección requiere capacidad de monitoreo a nivel kernel durante la fase de arranque, algo que no todas las soluciones EDR implementan de forma efectiva.
Nuestro análisis
Este caso ilustra una categoría de riesgo que no encaja en las taxonomías tradicionales de vulnerabilidades: funcionalidad legítima con potencial de abuso que requiere privilegios preexistentes pero que opera en un contexto temporal donde las defensas aún no están activas. La decisión de Microsoft de no considerar esto como un problema que requiere servicing inmediato es técnicamente defendible bajo el modelo de amenaza tradicional (requiere admin), pero ignora el valor táctico de la técnica en cadenas de ataque post-compromiso. La consistencia de la clave RC4 hardcodeada a través de 18 versiones del driver sugiere que el diseño de BTR.sys no contempló originalmente un escenario de abuso, tratándolo como un mecanismo interno de remediación en lugar de una superficie de ataque potencial.
La ventana de 34 segundos representa un problema arquitectural más profundo: la secuencia de arranque de Windows permite que componentes con capacidades de modificación del sistema se ejecuten antes que los servicios de protección. Esto no es exclusivo de BTR.sys — otros drivers de sistema legítimos con capacidades similares podrían presentar vectores comparables si sus formatos de configuración fueran reverse-engineered. La pregunta que queda abierta es si Microsoft considerará rediseñar la secuencia de arranque de Defender para cerrar esta ventana temporal, o si la industria terminará aceptando que la protección efectiva en escenarios post-compromiso requiere soluciones que operen a un nivel más bajo que el propio sistema operativo.