Check Point revela que BTR.sys, componente legítimo de Windows Defender, puede ejecutar operaciones arbitrarias en Ring 0 usando solo su protocolo nativo de configuración
Un driver firmado por Microsoft, diseñado para limpiar amenazas que requieren reinicio del sistema, puede ser reutilizado como motor de operaciones de kernel sin necesidad de explotar vulnerabilidades ni corromper memoria. La investigación de Check Point Research sobre BTR.sys — el componente de remediación en arranque de Windows Defender — documenta por primera vez cómo un mecanismo de seguridad legítimo expone primitivas de ejecución en Ring 0 que pueden ser controladas mediante la construcción de transacciones encriptadas válidas. El hallazgo surgió durante una respuesta a incidentes donde actividad sospechosa resultó ser remediación legítima de Defender, pero el análisis posterior reveló un patrón de diseño que transforma infraestructura defensiva en capacidad ofensiva.
El driver que se esconde detrás de nombres aleatorios y streams alternativos
BTR.sys no aparece en disco con ese nombre. El driver está embebido como recurso PE dentro de MpEngine.dll y se despliega únicamente cuando Windows Defender necesita remediar una amenaza que requiere reinicio — típicamente, eliminar un archivo bloqueado por otro proceso. El archivo resultante sigue el patrón de ocho letras minúsculas aleatorias con extensión .sys, y se registra como servicio de arranque del sistema con el mismo nombre aleatorio. Durante la investigación de Check Point, el driver apareció como mzqnjtaq.sys con entrada de servicio en HKLM\SYSTEM\CurrentControlSet\Services\mzqnjtaq, configurado para cargarse en el arranque (Start REG_DWORD = 1) y con un parámetro Args apuntando a un Alternate Data Stream denominado :changelist adjunto al propio archivo del driver.
Ese stream contiene una estructura binaria encriptada con RC4 que funciona como configuración del driver. La clave de 256 bytes está embebida en la sección .rdata del driver y se mantiene consistente entre versiones. La integridad de la configuración se valida mediante una variante de CRC-32 que omite la inversión final de bits, resultando en un valor equivalente al inverso bitwise de un CRC-32 estándar. El driver lee esta configuración al iniciar, ejecuta las transacciones especificadas — operaciones de archivo y registro en Ring 0 — y solicita su propia descarga inmediatamente después. Es un componente de un solo uso que se autodestruye tras completar su tarea.
Por qué un driver legítimo activó alertas de comportamiento malicioso
El investigador Jiří Vinopal de Check Point inició el análisis durante una respuesta a incidentes donde telemetría de endpoint mostraba patrones asociados típicamente con cargadores de kernel maliciosos: driver con nombre aleatorio desplegado poco antes de un reinicio, creación de entrada de servicio transitoria, rutinas de encriptación RC4, interacción con un Alternate Data Stream, y comportamiento de autolimpieza tras ejecución. La hipótesis inicial fue que un actor de amenaza había aprovechado el driver para actividad post-explotación. La investigación confirmó que el comportamiento era remediación legítima de Defender, pero esa conclusión desencadenó una pregunta más profunda: si un componente de seguridad firmado por Microsoft puede ser confundido con malware por sus propias características de diseño, qué impide que sea reutilizado intencionalmente con ese propósito.
La respuesta está en el protocolo de configuración. BTR.sys no expone una interfaz IOCTL estándar — lee instrucciones desde el stream :changelist cifrado con una clave conocida y validado con un checksum predecible. Check Point desarrolló BTR_CLI, una herramienta de investigación que construye transacciones encriptadas válidas y ejercita la funcionalidad del driver de forma segura. La herramienta demuestra que es posible instruir al driver para ejecutar operaciones arbitrarias de archivo y registro desde Ring 0 sin explotar ninguna vulnerabilidad, sin corromper memoria, y sin depender de técnicas BYOVD (Bring Your Own Vulnerable Driver) que requieren drivers de terceros con fallas conocidas. El driver ya está firmado, ya está presente en sistemas con Windows Defender, y ya tiene capacidad de ejecución en kernel — solo requiere una configuración válida.
Cómo se convierte en técnica de bypass de EDR sin drivers vulnerables de terceros
La investigación documenta que BTR_CLI puede ser utilizado como técnica de bypass de soluciones EDR y antivirus mediante la desactivación de componentes de seguridad desde Ring 0, usando exclusivamente un driver legítimo de Microsoft. A diferencia de técnicas BYOVD tradicionales — que dependen de cargar drivers de terceros con vulnerabilidades documentadas y que generan alertas por firma o comportamiento anómalo — esta técnica reutiliza infraestructura ya confiable del sistema operativo. El driver no necesita ser cargado manualmente: ya está presente como parte de Windows Defender. No necesita ser firmado por el atacante: ya tiene firma válida de Microsoft. No necesita explotar una vulnerabilidad: su funcionalidad nativa incluye operaciones de archivo y registro en kernel.
El patrón es similar al observado en componentes de remediación de otros productos de seguridad que operan en Ring 0 para garantizar que las amenazas no puedan resistir la limpieza mediante hooks en modo usuario. La diferencia es que BTR.sys expone esa capacidad mediante un protocolo de configuración que puede ser replicado externamente una vez que se conoce la estructura de las transacciones encriptadas. Check Point no publicó el código completo de BTR_CLI ni los detalles de construcción de transacciones — la herramienta se describe como instrumento de investigación para demostrar capacidades, no como exploit público — pero la ingeniería inversa completa del driver y su formato de configuración está documentada en la publicación.
Exposición en América Latina por dependencia de Windows Defender en infraestructura crítica
La técnica tiene implicancia directa en sectores de América Latina donde Windows Defender es la solución antivirus primaria en infraestructura crítica y entornos corporativos, particularmente en organizaciones de Brasil y México que adoptaron configuraciones de seguridad nativas de Windows como estrategia de reducción de costos de licenciamiento. El driver BTR.sys está presente en cualquier sistema con Windows Defender activo — no requiere configuración especial ni módulos opcionales — lo que significa que la superficie de ataque documentada por Check Point existe por defecto en millones de endpoints en la región. A diferencia de técnicas BYOVD que requieren privilegios administrativos para cargar un driver externo y que pueden ser bloqueadas mediante políticas de firma de código, esta técnica reutiliza un componente ya cargado y confiable del sistema operativo.
El riesgo no es teórico: la investigación surgió de un caso real de respuesta a incidentes donde el comportamiento del driver fue inicialmente clasificado como sospechoso por telemetría de endpoint. Si equipos de seguridad con capacidad de análisis forense confunden actividad legítima de BTR.sys con cargadores de kernel maliciosos, la técnica inversa — usar el driver para actividad maliciosa disfrazada de remediación legítima — presenta un desafío de detección significativo. La ausencia de indicadores tradicionales de BYOVD (carga de driver de terceros, firma inválida o revocada, comportamiento anómalo de servicio transitorio) complica la construcción de reglas de detección que no generen falsos positivos en operaciones normales de Defender.
Nuestro análisis
El caso de BTR.sys expone un patrón recurrente en componentes de remediación de productos de seguridad: la necesidad de operar en Ring 0 para garantizar efectividad contra amenazas persistentes crea primitivas de ejecución que, una vez documentadas, pueden ser reutilizadas con propósito inverso. La diferencia con vulnerabilidades tradicionales es que no hay nada que parchear — el driver funciona exactamente como fue diseñado. La capacidad de ejecutar operaciones arbitrarias de archivo y registro desde kernel no es un bug: es el requisito funcional de un motor de remediación que debe poder eliminar archivos bloqueados y modificar claves de registro protegidas sin importar qué hooks o protecciones haya instalado el malware.
La publicación de Check Point no incluye exploit completo ni herramienta pública, pero documenta suficiente detalle del protocolo de configuración (estructura de transacciones encriptadas, clave RC4 embebida, validación de integridad mediante CRC-32 modificado) como para que la técnica sea reproducible por actores con capacidad de ingeniería inversa. La pregunta operativa para equipos de seguridad en la región no es si la técnica será adoptada — la investigación ya demuestra viabilidad — sino cómo diferenciar uso legítimo de BTR.sys por parte de Defender versus uso malicioso por parte de un atacante que construye transacciones válidas. La telemetría estándar de carga de drivers firmados no es suficiente: el driver ya está firmado y ya es confiable. La detección requiere análisis de comportamiento del stream :changelist y correlación con actividad conocida de remediación de Defender, un nivel de visibilidad que no todas las soluciones EDR implementan por defecto. ¿Cuántos otros componentes de remediación en productos de seguridad exponen primitivas similares sin que hayan sido documentadas públicamente todavía?