tech

ShieldCrash: el tercer bypass de Windows Defender en 4 meses, y el PoC ya está en GitHub desde que salió el parche

tech · 6 min de lectura

ShieldCrash: el tercer bypass de Windows Defender en 4 meses, y el PoC ya está en GitHub desde que salió el parche

El mismo componente del Motor de Protección de Malware de Microsoft lleva tres vulnerabilidades encadenadas desde junio. El último bypass llegó a GitHub horas después del Patch Tuesday de septiembre y todavía no tiene parche.

ShieldCrash: el tercer bypass de Windows Defender en 4 meses, y el PoC ya está en GitHub desde que salió el parche

El 8 de septiembre, a unas horas de que Microsoft publicara su Patch Tuesday de septiembre, un investigador anónimo con el alias Nightmare Eclipse subió un repositorio a GitHub. Nombre del repo: ShieldCrash. Descripción: “Windows Defender 0day Vulnerability”. El timing no fue accidente: era la demostración de que el parche que Microsoft acababa de publicar ya tenía un bypass funcional antes de que la mayoría de los usuarios lo aplicara.

No es la primera vez. No es la segunda. Es la tercera en cuatro meses. Y el problema de fondo sigue sin cerrarse.

Tres golpes al mismo componente: RoguePlanet, ShieldBreak, ShieldCrash

Todo empieza en junio de 2026 con RoguePlanet (CVE-2026-50656), una vulnerabilidad crítica en mpengine.dll, el Motor de Protección de Malware de Microsoft. El fallo permitía que una cuenta local sin privilegios escalara a NT AUTHORITY\SYSTEM explotando una condición de carrera. CVSS 7.8. Microsoft la parchó en julio con la versión de motor 1.1.26060.3008.

En agosto, el mismo investigador (entonces bajo el alias “Chaotic Eclipse”) publicó ShieldBreak (CVE-2026-69414): una demostración de que el parche de julio estaba incompleto. Mismo componente, misma clase de ataque. Microsoft lo parcheó en el Patch Tuesday de septiembre con la versión 1.1.26080.3.

Y el 8 de septiembre, mismo día que salió ese parche de ShieldBreak, apareció ShieldCrash: el bypass del bypass. Ahora como “Nightmare Eclipse”. El PoC ya está público en github.com/MSNightmare/ShieldCrash.

El problema de fondo: TOCTOU en la Cloud Filter API

Lo que llama la atención no es que existan bugs en Defender. Eso pasa. Lo raro es que tres investigaciones distintas apunten al mismo componente, una y otra vez, con la misma clase de ataque.

El patrón es una condición de carrera TOCTOU (time-of-check to time-of-use). Cuando Defender escanea un archivo en almacenamiento en la nube (OneDrive, por ejemplo), interactúa con el driver CldFlt.sys durante la hidratación del archivo. Hay una ventana tiny de tiempo entre que Defender verifica la ruta del archivo y cuando realmente lo accede. Ahí es donde entra el ataque: el callback del atacante se dispara justo en ese gap y swaps the target.

Cada parche que saca Microsoft tapa un vector específico de la condición de carrera, pero según el análisis técnico de Endpoint Weekly, ninguno cierra completamente la ventana de tiempo. El investigador lo expresa así: “Microsoft fixed several things to prevent re-exploiting the issue, but they missed a spot.”

Si te suena conocido el patrón de zero-days que se resuelven a medias, ya vimos algo re piola similar con el caso de Adobe Reader: como documentamos en Adobe Reader lleva 4 meses con un zero-day activo y nadie te avisó, las soluciones incompletas son un problema sistémico en la industria, no solo de Microsoft.

Qué puede hacer ShieldCrash (y qué no puede)

Antes de entrar en pánico: el PoC actual permite lectura arbitraria de archivos como SYSTEM. No escritura, no ejecución de código arbitrario con shell completa. Eso limita bastante el vector de ataque inmediato.

Pero hay un detalle que sí pone los pelos de punta: leer como SYSTEM significa que puedes leer los archivos SAM y SYSTEM del registro de Windows. Esos archivos contienen los hashes NTLM de las cuentas locales. Con eso, un atacante puede hacer cracking offline sin necesidad de tocar la red, lo que convierte a ShieldCrash en una herramienta viable para escalada de privilegios en escenarios donde ya hay acceso local.

Sistemas afectados según BleepingComputer:

  • Windows 10 (todas las versiones soportadas)
  • Windows 11 (incluyendo 25H2 y builds del canal Canary)
  • Windows Server 2025

Microsoft aún no ha confirmado oficialmente el bypass ni ha dado ETA de parche.

Lo que puedes hacer HOY mientras esperas el parche

No hay fix oficial, pero hay pasos concretos para reducir la exposición, especialmente si administras equipos en una empresa:

1. Activa Tamper Protection si no está encendido Esto no bloquea la vulnerabilidad, pero sube la barra para que un atacante use el acceso post-explotación para desactivar Defender. Ve a Seguridad de Windows > Protección contra virus y amenazas > Administrar configuración.

2. Aplica KB5120998 de todas formas Aunque ShieldCrash bypasea el parche de septiembre, la actualización sí cierra ShieldBreak y RoguePlanet. Tener las tres vulnerabilidades abiertas es peor que tener solo una.

Verifica que tu versión del motor sea 1.1.26090.xxxx o posterior con:

Get-MpComputerStatus | Select-Object -Property AMEngineVersion

3. Activa Credential Guard si usas Windows 11 Enterprise o Pro Aisla LSASS en una VM mediante virtualización. Bloquea el escenario de robo de hashes aunque un atacante consiga lectura SYSTEM.

4. Reglas ASR (Attack Surface Reduction) Las reglas de reducción de superficie bloquean vectores comunes de entrega inicial. Si ya instalaste el update de septiembre, están disponibles en Defender for Endpoint.

5. Considera pausar la sincronización de OneDrive en endpoints críticos El vector de ataque pasa por archivos en cloud storage. No es una solución permanente, pero reduce exposición en servidores o equipos con datos sensibles.

Para monitoreo avanzado: busca procesos hijo anómalos de MsMpEng.exe o modificaciones inesperadas en C:\ProgramData\Microsoft\Windows Defender\Platform\.

El patrón que debería preocuparnos más que la vulnerabilidad

Lo que hace diferente a este caso del ciclo normal de CVEs es la dinámica entre el investigador y Microsoft. Nightmare Eclipse ha dicho públicamente que la razón de publicar PoCs el mismo día de los parches es una disputa con Microsoft respecto a cómo maneja la divulgación responsable. En esencia: el investigador reporta, Microsoft tarda en responder o parcheaba de forma incompleta, y la respuesta del investigador es acelerar la publicación.

Ese ciclo de confrontación es el que genera el problema sistémico. No solo hay un componente vulnerable. Hay una relación de divulgación rota que produce bypasses publicados antes de que la mayoría de los usuarios parcheen.

Si sigues el tema de ataques cibernéticos en México, el contexto local no ayuda: el blog ya documentó que México registró 237,000 intentos de ransomware en un año y que los actores maliciosos están adoptando IA para evadir detecciones. Un bypass de Defender con PoC público en GitHub es exactamente el tipo de herramienta que se recicla rápido en campañas locales.

La pregunta incómoda para Microsoft

Tres fallas en el mismo componente en cuatro meses no es mala suerte. Es una señal de que el diseño de la integración entre mpengine.dll y la Cloud Filter API tiene un problema estructural que los parches puntuales no están resolviendo.

Mientras Microsoft no publique un fix oficial para ShieldCrash, la recomendación es aplicar los pasos de mitigación de arriba y monitorear los canales de seguridad. Si eres admin de sistemas en México, ya sabes lo que sigue: siguiente Patch Tuesday es el 13 de octubre. O antes, si Microsoft saca un out-of-band patch.

¿En tu empresa ya tienen Tamper Protection activado en todos los endpoints? Ese detalle básico es lo que separa “exposición controlable” de “vector activamente explotable”.

Fuentes

Comentarios

No te pierdas ningún post

Recibe lo nuevo de Al Chile Tech directo en tu correo. Sin spam.

También te puede interesar