Un investigador solo lanzó 8 zero-days contra Microsoft en 10 semanas. Cada uno cronometrado para el Patch Tuesday. La campaña, bautizada como Nightmare Eclipse, expone fallas estructurales en el ecosistema de seguridad de Windows que van más allá de los parches individuales. Acompañamos cada disclosure y la lección es clara: aplicar parches no es lo mismo que tener cobertura defensiva.
Los 8 zero-days, qué hace cada uno
La campaña cubre una superficie de ataque amplia: escalada de privilegios, bypass de cifrado de disco, degradación del antivirus y re-explotación de fallas antiguas. Según el investigador, estos son los detalles:
- BlueHammer (3 de abril): LPE a SYSTEM vía Defender Engine. CVE-2026-33825. Parchado en el Patch Tuesday de abril.
- RedSun (16 de abril): LPE a SYSTEM vía Defender Engine. CVE-2026-41091. Parchado en el Patch Tuesday de junio.
- UnDefend (16 de abril): degradación del Defender + bloqueo de actualización de firmas. CVE-2026-45498. Parchado en junio.
- YellowKey (13 de mayo): bypass del BitLocker vía WinRE. CVE-2026-50507. Parchado en junio.
- GreenPlasma (13 de mayo): LPE a SYSTEM vía CTFMON. CVE-2026-45586. Parchado en junio.
- MiniPlasma (13-14 de mayo): re-explotación del CVE-2020-17103 (cldflt.sys), falla original de Google Project Zero. Según el investigador, el parche de 2020 aparentemente nunca se aplicó correctamente. Parchado en junio.
- RoguePlanet (10 de junio): TOCTOU en el pipeline de scan/quarantine del Defender → SYSTEM en Windows 11 totalmente parchado, incluido el KB5094126 del Patch Tuesday de junio. Race condition con confiabilidad variable: 100% en algunas máquinas, inconsistente en otras. No funciona en Windows Server. Sin CVE. Sin parche.
- GreatXML (11 de junio): bypass del BitLocker vía artefactos de offline scan del Defender en la partición de recuperación. Requiere acceso administrativo previo: es persistencia post-compromiso, no acceso inicial. Sin CVE. Sin parche. Según Will Dormann, analista de vulnerabilidades respetado, no fue posible reproducir el bypass como se describió. El investigador pidió ayuda para encontrar un trigger alternativo. La confiabilidad práctica es cuestionada.
Explotación activa: cuando el zero-day deja de ser teórico
Tres de estas vulnerabilidades ya fueron observadas en intrusiones reales. Según Huntress Labs, BlueHammer, RedSun y UnDefend fueron usados en ataques documentados el 17 de abril, antes incluso de que muchos administradores supieran que los PoC existían. Según CISA, BlueHammer fue agregado al Known Exploited Vulnerabilities (KEV) catalog el 22 de abril. Según Kaspersky, MiniPlasma estaba en explotación activa desde el 10 de abril.
La velocidad es lo que importa. El investigador publicó BlueHammer el 3 de abril. Huntress documentó explotación el 17 de abril. CISA lo agregó al KEV el 22 de abril. Del disclosure al catálogo federal: 19 días. Para organizaciones que dependen de ciclos mensuales de patching, eso es una eternidad.
RoguePlanet, el zero-day que funciona en Windows 11 parchado
RoguePlanet es el más relevante para quien defiende estaciones Windows hoy. Microsoft endureció el Defender silenciosamente a mediados de mayo, parchando la API mpengine!SysIO* que bloqueaba ataques vía junction. El investigador reescribió el exploit en aproximadamente 3 semanas para sortear el hardening. La firma del Defender (Exploit:Win32/DfndrRugPlnt.BB) detecta solo el binario compilado, no la técnica subyacente.
Esto significa que la técnica sigue siendo viable incluso con la firma activa. Un atacante que recompile el exploit o modifique el binario burla la detección. La race condition en el pipeline de scan/quarantine es una clase de vulnerabilidad, no un bug aislado, y las clases de vulnerabilidad no se resuelven con firmas.
Según Picus Security, el insight central es: "Patch parity is not coverage parity." Aplicar parches no equivale a tener cobertura defensiva contra la clase de técnica subyacente. Microsoft cerró una puerta de junction attack en mayo; RoguePlanet abrió otra. El Patch Tuesday de junio corrigió GreenPlasma y YellowKey; dejó abierto el camino de RoguePlanet.
La tensión entre la investigación de seguridad y la responsabilidad corporativa
Según reportes de la comunidad de seguridad, Microsoft amenazó con acción criminal el 28 de mayo contra el investigador. Tras una reacción negativa significativa de la comunidad de seguridad, la empresa retrocedió y declaró que no tiene intención de procesar a quienes publican investigación de seguridad, según Microsoft. El investigador, sin embargo, afirma que Microsoft inició acción legal. Según reportes de la comunidad de seguridad, GitHub y GitLab eliminaron los repositorios bajo presión. El investigador migró a git autohospedado.
Este episodio revela una tensión estructural: cuando el proveedor de seguridad es también el objetivo, la dinámica entre disclosure y accountability cambia. La comunidad de seguridad necesita investigación independiente para identificar fallas que el vendor no encontró, o no priorizó. Criminalizar esa investigación no elimina las vulnerabilidades; solo las mantiene invisibles.
Qué hacer ahora
En Tech86, nuestra posición es directa: la seguridad por capas no es opcional cuando el propio Defender es el vector de ataque. Un EDR independiente con telemetría propia no depende del mismo engine que está siendo explotado. Cuando el Defender queda ciego, por crash vía UnDefend, por escalada vía RedSun o por race condition vía RoguePlanet, el EDR sigue detectando.
Verifique que Engine esté en 1.1.26040.8+ y Platform en 4.18.26040.7+, según Microsoft. Monitoree los Event IDs 2001/2002/2003 para fallas de actualización y el 4672 para escalada de privilegios. Audite las políticas de BitLocker y la protección de la partición WinRE. Y nunca asuma que un endpoint totalmente parchado está seguro: RoguePlanet demostró que parchado no es lo mismo que protegido.