YellowKey y GreatXML: BitLocker no te protege si el atacante llega al arranque

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: 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.

(Actualización, 7-jul-2026: ya hay más datos. YellowKey quedó con CVSS 6.8 y afecta a Windows 11 24H2/25H2/26H1 y Windows Server 2025 (incluido Server Core). Antes del parche acumulativo de junio, Microsoft publicó el 20 de mayo una mitigación provisional: un script que monta la imagen de WinRE, edita su registro SYSTEM offline para quitar la entrada vulnerable y vuelve a sellar WinRE conservando la confianza de BitLocker. Microsoft ahora afirma que pasar a TPM+PIN bloquea eficazmente el ataque —coherente con lo que decía este post, aunque conviene seguir tratándolo como barrera y no como prueba criptográfica—. Otro detalle del PoC: el shell irrestricto se dispara manteniendo CTRL durante el arranque de WinRE.)

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.

(Actualización, 7-jul-2026: sigue sin CVE y sin parche. Microsoft reconoció públicamente el reporte y dice estar “investigando la validez y el posible alcance” de la afirmación, recalcando que no se le reportó por sus canales antes de hacerse público. En paralelo, algunas fuentes lo rastrean con el identificador interno de Defender Vulnerability Management TVM-2026-0001 —el patrón de nombre que usa Microsoft cuando aún no hay CVE asignado—, que todavía no está mapeado a ningún CVE público. En resumen: la mitigación de este post no cambia; GreatXML sigue siendo la pieza “abierta” de la pareja.)

Lo que los artefactos reales confirman (analizado en laboratorio)#

Aunque la ventana del abuso es ciega (WinRE, sin EDR), los artefactos que ambas piezas dejan en disco son concretos y estables —y son lo que se puede cazar después—.

GreatXML: el unattend.xml es un mapa completo del ataque. Analizado el fichero real, no es un binario: es un autounattend generado con una herramienta pública (el generador de schneegans.de, según su propio comentario) encadenado en varios passes:

• En el pass windowsPE escribe X:\pe.cmd con start X:\Windows\System32\conhost.exe y lo ejecuta → un conhost en el RAM disk de WinPE, donde el volumen BitLocker ya está desbloqueado.
• En oobeSystem crea dos cuentas locales —Admin (grupo Administrators, contraseña en blanco) y User— y configura AutoLogon de Admin. Esa cuenta es la persistencia que “sobrevive a IR”: queda en el sistema completo, no solo en WinPE.
• En specialize corre PowerShell sin restricciones que extrae y ejecuta C:\Windows\Setup\Scripts\Specialize.ps1 (que hace net accounts /maxpwage:UNLIMITED).
• FirstLogon.ps1 es anti-forense: pone AutoLogonCount=0 y borra C:\Windows\Panther\unattend.xml, unattend-original.xml y Wifi.xml tras el primer arranque.

De ahí salen artefactos forenses de alta fidelidad, todos post-boot: la presencia de C:\Windows\Panther\unattend.xml / unattend-original.xml, las cuentas locales Admin/User con contraseña en blanco, las claves AutoAdminLogon/AutoLogonCount en HKLM\...\Winlogon, y los scripts C:\Windows\Setup\Scripts\Specialize.ps1 / FirstLogon.ps1 con sus .log.

YellowKey: el artefacto es un árbol de logs CLFS/TxF plantado. Lo que se copia es la estructura System Volume Information\FsTx\<GUID>\FsTxLogs\ con ficheros CLFS Base Log (FsTxLog.blf, FsTxKtmLog.blf) y sus contenedores FsTxLogContainer* / FsTxKtmLogContainer*. La señal no es su contenido (son logs de transacción NTFS legítimos por formato), sino dónde aparecen: estos logs viven normalmente en la raíz de un volumen NTFS fijo; encontrarlos en un USB, en la partición EFI o en la de recuperación es la anomalía.

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”:

Todo cifrado en reposo carga una cláusula que casi nunca se lee: “siempre que el atacante no controle el arranque”. BitLocker no falla aquí — cumple exactamente lo que promete, contra la amenaza que imaginó. El problema es que un modelo de amenaza es una apuesta sobre lo que el otro no va a hacer, y estas dos piezas hacen justo eso. Un candado impecable en una puerta que se abre por el marco. Y lo más incómodo no es el bypass: es que el panel sigue diciendo “protegido” mientras alguien lee el disco. La protección que no puede fallar de forma visible ya falló una vez sin que nadie lo notara.

• 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.
• Residuo forense de GreatXML (post-boot). Como el unattend.xml se autoborra, cazá lo que deja después: cuentas locales inesperadas con contraseña en blanco (Admin/User), AutoLogon activado y los scripts de setup. Es hunting retrospectivo, no tiempo real:

# Residuo de GreatXML tras el arranque
Get-LocalUser | Where-Object { -not $_.PasswordRequired } |
    Select-Object Name, Enabled, PasswordRequired, LastLogon
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' |
    Select-Object AutoAdminLogon, DefaultUserName, AutoLogonCount
Test-Path 'C:\Windows\Panther\unattend.xml','C:\Windows\Setup\Scripts\Specialize.ps1',
          'C:\Windows\Setup\Scripts\FirstLogon.ps1'

• Ubicación de los logs TxF (YellowKey). Un árbol System Volume Information\FsTx\<GUID>\FsTxLogs\ (con FsTxLog.blf/FsTxKtmLog.blf y sus contenedores) en medios extraíbles, la partición EFI o la de recuperación es anómalo: esos logs CLFS pertenecen a la raíz de un volumen NTFS fijo, no a un USB.

Mitigación#

# 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

MITRE ATT&CK#

Referencias#

• The Hacker News — New GreatXML Exploit Bypasses Windows BitLocker: https://thehackernews.com/2026/06/new-greatxml-exploit-bypasses-windows.html
• SecurityWeek — ‘GreatXML’ Zero-Day Exploit Bypasses BitLocker: https://www.securityweek.com/greatxml-zero-day-exploit-bypasses-bitlocker/
• BleepingComputer — Windows BitLocker zero-day gives access to protected drives (YellowKey): https://www.bleepingcomputer.com/news/security/windows-bitlocker-zero-day-gives-access-to-protected-drives-poc-released/
• GuardSix — Inside the Latest Chaotic-Eclipse Releases: MiniPlasma, GreenPlasma, YellowKey: https://guardsix.com/blog/inside-the-latest-chaotic-eclipse-releases-mini-plasma-greenplasma-and-yellowkey
• ThreatLocker — GreatXML: Exploiting the WinRE trust boundary behind BitLocker: https://www.threatlocker.com/blog/greatxml-exploiting-the-winre-trust-boundary-behind-bitlocker
• NVD — CVE-2026-45585: https://nvd.nist.gov/vuln/detail/CVE-2026-45585
• (act. 7-jul) Help Net Security — Microsoft provides mitigation for “YellowKey” (CVE-2026-45585): https://www.helpnetsecurity.com/2026/05/20/yellowkey-bitlocker-mitigation-cve-2026-45585/
• (act. 7-jul) Eclypsium — YellowKey: The BitLocker Bypass Hidden in Windows Recovery: https://eclypsium.com/blog/yellowkey-bitlocker-bypass-windows-recovery-environment/