TLP:CLEARAnálisis defensivo de fuentes públicas. Sin pasos de explotación. Parte de la serie [Nightmare Eclipse](/posts/nightmare-eclipse/).

Resumen ejecutivo#

Las seis primeras piezas de la campaña escalaban privilegios o cegaban a Defender. Estas dos hacen algo distinto y, para muchos entornos, más aterrador: leen tu disco cifrado con BitLocker mientras BitLocker sigue reportando “protección activada”. Ninguna rompe la criptografía. Ambas atacan el mismo eslabón débil —el Windows Recovery Environment (WinRE), código de confianza que corre en el arranque temprano, antes de que se establezcan las fronteras de seguridad normales—.

Pero no son intercambiables, y confundirlas lleva a mitigar mal:

YellowKey (CVE-2026-45585)GreatXML (sin CVE)
RequisitoAcceso físico breve (<2 min)Admin una vez en el equipo
Config vulnerableBitLocker TPM-only (sin PIN)Cualquiera donde se corrió Defender Offline Scan
NaturalezaBypass de cifrado in situBackdoor de persistencia
Sobrevive a IR— (es acceso puntual)Sí: aguanta rotación de credenciales y pérdida de acceso remoto
EstadoParcheado (Patch Tue. junio)Sin parche; PoC público, validación externa incompleta

YellowKey: acceso físico + TPM-only = disco abierto#

En la configuración por defecto de muchos despliegues, BitLocker usa TPM-only: el TPM libera la clave automáticamente al arrancar, sin pedir PIN. Es cómodo y transparente… y es justo lo que YellowKey aprovecha.

Mecanismo (nivel conceptual). WinRE confía en la utilidad autofstx.exe para procesar logs de NTFS transaccional (TxF) desde el directorio System Volume Information\FsTx de las unidades conectadas, en el arranque temprano. El atacante planta logs TxF manipulados en un USB o en la partición EFI; autofstx.exe los reproduce y, en el proceso, borra winpeshl.ini —el fichero que gobierna qué hace WinRE—. Sin ese fichero, WinRE cae a un símbolo del sistema sin restricciones, con el volumen BitLocker ya descifrado por el TPM. Acceso total de lectura, sin PIN ni clave de recuperación.

TPM+PIN sube la barrera, pero no es un “fix” total. El investigador señaló que el PoC actual simplemente no ataca el escenario TPM+PIN —no que sea inmune—. Trátalo como mitigación válida y recomendada mientras esperabas el parche, no como una garantía criptográfica. El fix real es el parche de junio.

GreatXML: la trampa de Defender Offline Scan#

GreatXML es más sutil y, en cierto modo, peor, porque convierte una herramienta defensiva en el punto de entrada. La premisa que titula la mayoría de los análisis: si alguna vez corriste Windows Defender Offline Scan en el equipo, ya eres vulnerable.

Mecanismo (nivel conceptual). Un atacante que ya tiene admin copia a la raíz de la partición de recuperación un unattend.xml manipulado y una carpeta Recovery\WindowsRE\ReAgent.xml. Al reiniciar en WinRE (Shift + Reiniciar), el unattend.xml se procesa durante el arranque de WinRE, antes de que BitLocker pida nada y antes de cualquier logon interactivo, y lanza un shell SYSTEM con acceso al volumen cifrado.

Lo que lo hace peligroso no es el acceso puntual, es la persistencia: escribir en la partición de recuperación requiere admin, sí, pero una vez plantados, los ficheros sobreviven a la rotación de credenciales y a la pérdida del acceso remoto. Es una herramienta de acceso persistente a datos que aguanta la respuesta a incidentes: expulsas al atacante de la red, rotas todo, y sigue pudiendo leer el disco con acceso físico.

Estado de validación. GreatXML no tiene CVE (el actor no lo reportó a Microsoft) y, según el propio reporting, es una afirmación de PoC público con validación externa incompleta. El actor dijo que fue un hallazgo accidental que le tomó 4 horas encontrar. Trátalo como técnicamente plausible y sin parche, no como un hecho cerrado.

Por qué la detección clásica falla aquí#

Estos ataques ocurren antes del arranque completo de Windows, en WinRE. Tu EDR no está corriendo. Sysmon no está corriendo. No hay proceso que observar en el momento del abuso. La detección basada en logs de sistema es, por diseño, ciega a la ventana crítica. Por eso el enfoque cambia de “detectar” a “prevenir e integridad”:

  • Integridad de la partición de recuperación. Monitoriza escrituras a la partición de recuperación y a \Recovery\. En un equipo sano, esos ficheros casi nunca cambian; un cambio inesperado es alta señal (especialmente unattend.xml / ReAgent.xml).
  • Inventario de Defender Offline Scan. Audita qué endpoints han ejecutado Defender Offline Scan —incluido durante investigaciones de incidentes, donde es común—: son la superficie de GreatXML.
  • Higiene de medios de arranque. Alerta sobre montaje de USB y accesos a la partición EFI en endpoints sensibles.

Mitigación#

AmenazaControlNota
YellowKeyParche Patch Tuesday junio 2026Fix real
YellowKeyBitLocker TPM+PINSube la barrera; recomendado; no es garantía total
YellowKeyPassword de BIOS/UEFI + deshabilitar boot USBCorta el vector físico del medio externo
GreatXMLRestringir admin localSin admin no se planta el backdoor
GreatXMLAuditar/limpiar la partición de recuperaciónVerifica integridad tras cualquier acceso admin sospechoso
GreatXMLConsiderar endurecer/deshabilitar WinREreagentc /disable donde no sea necesario, en entornos de alta seguridad
AmbasRestringir acceso físicoData-at-rest asume que el atacante no toca el hardware; aquí sí lo toca
# Estado de WinRE (¿habilitado? ¿dónde vive?)
reagentc /info
# Config de BitLocker: ¿TPM-only o TPM+PIN?
manage-bde -status
Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, KeyProtector
El modelo mental que rompe esta pareja. “Cifrado en reposo” protege contra un atacante que se lleva el disco, no contra uno que controla el arranque de la máquina. WinRE es código de confianza que corre antes que tus defensas; cualquier cosa que confíe en datos externos en esa fase (logs TxF, unattend.xml) es superficie de ataque pre-boot. BitLocker sin PIN + acceso al arranque ≈ sin cifrado.

MITRE ATT&CK#

TácticaTécnica
Collection / ImpactT1006 — Direct Volume Access
Defense Evasion / PersistenceT1542 — Pre-OS Boot (abuso de WinRE)
PersistenceT1546 / T1547 — Boot/logon execution (GreatXML: ficheros en partición de recuperación)

Referencias#