YellowKey y BitUnlocker: Análisis de la vulnerabilidad de omisión de BitLocker en Windows que parece una puerta trasera
YellowKey y BitUnlocker: Dos descubrimientos independientes de la misma clase de vulnerabilidad: el límite de confianza de desbloqueo automático de WinRE se explota para eludir el cifrado de volumen completo de BitLocker. Uno fue encontrado por un investigador externo que lo llama puerta trasera; el otro fue encontrado por el propio equipo STORM de Microsoft y parcheado como cuatro CVE.
Las Dos Caras de la Misma Moneda
En menos de un año, dos equipos que se aproximaban desde direcciones completamente diferentes llegaron a la misma conclusión aterradora: la protección predeterminada de solo TPM de BitLocker puede eludirse silenciosamente a través del Entorno de Recuperación de Windows (WinRE), dando a cualquier persona con acceso físico acceso completo a la línea de comandos de una unidad “cifrada”.
| Aspecto | BitUnlocker (Microsoft STORM) | YellowKey (Nightmare-Eclipse) |
|---|---|---|
| Descubridor | Equipo STORM de Microsoft | Investigador independiente Nightmare-Eclipse |
| Divulgado | Black Hat USA 2025 / DEF CON 33 (agosto 2025) | GitHub / divulgación pública (mayo 2026) |
| Parcheado | Patch Tuesday de julio 2025 (4 CVE) | Sin parche al momento de escribir |
| Vector de ataque | Manipulación de BCD + PBR en varios pasos | Un solo USB, tecla CTRL durante el arranque de WinRE |
| Afectados | Windows 10/11 + Server | Solo Windows 11 + Server 2022/2025 |
Lo inquietante: ninguno requiere romper AES. Ninguno requiere fuerza bruta de la clave de recuperación. Ambos simplemente atraviesan una puerta que quedó abierta.
BitUnlocker: Microsoft Encuentra Sus Propias Fallas
El equipo STORM de Microsoft presentó BitUnlocker en Black Hat USA 2025 y DEF CON 33. Descubrió cuatro vectores de ataque distintos en WinRE, todos parcheados con el Patch Tuesday de julio de 2025:
CVE-2025-48804: Inyección de Archivo SDI
El proceso de arranque de WinRE utiliza un archivo Boot.sdi (Imagen de Implementación del Sistema). Los investigadores descubrieron que podían añadir una imagen maliciosa de Windows al Boot.sdi legítimo. Dado que WinRE no valida correctamente el WIM después del encabezado SDI, la imagen no confiable arranca como si fuera confiable, heredando los privilegios de desbloqueo automático de WinRE para volúmenes BitLocker.
CVE-2025-48800: Abuso de tttracer.exe
La operación programada de “Escaneo sin conexión” de WinRE ejecuta análisis antivirus contra volúmenes cifrados. La utilidad tttracer.exe (Depurador de Viaje en el Tiempo), un binario legítimo firmado por Microsoft, puede utilizarse para ejecutar cmd.exe por proxy sin activar el mecanismo de bloqueo de BitLocker. El símbolo del sistema hereda los permisos especiales de WinRE para acceder a volúmenes cifrados.
CVE-2025-48003: Tecla Rápida de SetupPlatform.exe
SetupPlatform.exe — un componente que permanece en el registro de aplicaciones confiables después de las actualizaciones de Windows — registra una tecla rápida Shift+F10 que lanza un símbolo del sistema. Crucialmente, esto no activa un bloqueo de los volúmenes BitLocker. Un atacante que pueda influir en la configuración de ReAgent.xml de WinRE puede explotar esto para acceso persistente.
CVE-2025-48818: Descifrado Completo vía PBR
La joya de la corona. Manipulando los almacenes de Datos de Configuración de Arranque (BCD), los atacantes pueden redirigir el flujo de Restablecimiento por Botón (PBR) de WinRE. El archivo ResetSession.xml incluye una directiva DecryptVolume. Colocando un almacén BCD malicioso en el volumen de Recuperación no protegido, el atacante engaña a PBR para que descifre completamente el volumen del SO protegido por BitLocker.
Los cuatro CVE recibieron una puntuación CVSS v3.1 de 6.8 (Media) — debido al requisito de acceso físico. Pero como sabe cualquier profesional de seguridad, “requiere acceso físico” es un consuelo frío cuando roban un portátil en una cafetería.
YellowKey: El Que Rompió Internet
En mayo de 2026, el investigador Nightmare-Eclipse publicó YellowKey en GitHub con una descripción que inmediatamente se volvió viral:
“Uno de los descubrimientos más increíbles que he encontrado, casi parece una puerta trasera, pero qué sé yo, quizás solo estoy loco.”
El Exploit en 5 Pasos
- Crea una carpeta
FsTxen un USB enUSB:\System Volume Information\FsTx - Conecta el USB a una máquina Windows 11 protegida por BitLocker
- Mantén presionada la tecla SHIFT y haz clic en Reiniciar (arranca en WinRE)
- Al reiniciar el sistema, suelta SHIFT y presiona y mantén CTRL
- Se abre un shell con acceso completo y sin restricciones al volumen cifrado por BitLocker
Eso es todo. Sin payload complejo. Sin romper criptografía. Sin clave de recuperación. Solo un USB y el momento adecuado al presionar teclas.
Por Qué Funciona
El componente responsable de este comportamiento existe solo dentro de las imágenes de WinRE. Verifica una bandera llamada FailRelock en un archivo de configuración (RecoverySimulation.ini). Cuando está activada, después de que WinRE desbloquea la unidad BitLocker durante el proceso de recuperación, simplemente nunca la vuelve a bloquear.
El archivo RecoverySimulation.ini en el USB activa el “modo de prueba” para las herramientas de recuperación de WinRE:
[Simulation]
Active=Yes
FailRelock=1Una vez activo el modo de prueba, cmd.exe de WinRE hereda el estado desbloqueado — y lee y escribe en el volumen cifrado como si BitLocker no existiera.
Nightmare-Eclipse demostró que esto afecta a Windows 11 y Server 2022/2025 pero no a Windows 10, sugiriendo que el código vulnerable se introdujo en la versión de WinRE incluida con Windows 11.
¿Puerta Trasera o Error? La Evidencia
Lo que hace a YellowKey particularmente perturbador es el patrón de evidencia que sugiere intencionalidad:
| Observación | Implicación |
|---|---|
La bandera de depuración FailRelock existe solo en WinRE, no en el componente normal de Windows con el mismo nombre | Una instalación de prueba deliberada se envió a producción |
| El mismo nombre de binario existe en Windows normal sin la funcionalidad de omisión | Esto no es un residuo de depuración genérico — se colocó específicamente en WinRE |
| Solo Windows 11+ afectado (Windows 10 no) | El código se introdujo en la nueva imagen de WinRE para Windows 11 |
| Sin documentación, sin herramienta de configuración, sin referencia pública | Las banderas de depuración/prueba estándar suelen documentarse internamente — esta parece haberse ocultado intencionalmente |
The Register citó a expertos de seguridad que dijeron que es “imposible verificar” si esto es una puerta trasera intencional basada en la información disponible. Pero la evidencia circunstancial es, como mínimo, lo suficientemente sospechosa como para exigir una explicación detallada de Microsoft.
Comparación: YellowKey vs BitUnlocker
| Dimensión | BitUnlocker | YellowKey |
|---|---|---|
| Sofisticación técnica | Alta — manipulación de BCD, PBR y XML en múltiples pasos | Baja — USB simple + combinación de teclas |
| Tiempo de ejecución | ~10-30 minutos | ~2 minutos |
| Persistencia | Puede descifrar permanentemente el volumen | Acceso solo por sesión |
| CVE | CVE-2025-48800, 48003, 48804, 48818 | Sin CVE asignado |
| Estado del parche | Corregido julio 2025 | Sin parche |
| Windows 10 afectado | Sí | No |
| Sospecha de puerta trasera | No (divulgación estándar de vulnerabilidad) | Sí (investigador afirma intencional) |
Ambos son complementarios: BitUnlocker demuestra que incluso el propio equipo de seguridad de Microsoft encontró problemas de confianza sistémicos en WinRE, mientras que YellowKey sugiere que el problema podría ser peor de lo que nadie imaginaba — quizás por diseño.
Por Qué Solo TPM No Es Suficiente
La configuración predeterminada de BitLocker en dispositivos Windows modernos usa protección solo TPM. El TPM valida la integridad del arranque (registros PCR) y libera la clave de cifrado automáticamente si el sistema arranca normalmente. Esto proporciona experiencia de usuario perfecta — sin escribir contraseñas en cada arranque.
Pero también significa: cualquiera que pueda arrancar el dispositivo puede obtener la clave.
| Modo de protección | Resistencia a YellowKey | Experiencia de usuario |
|---|---|---|
| Solo TPM | Roto | Mejor (sin contraseña) |
| TPM + PIN | Resistente | Buena (PIN al arrancar) |
| TPM + llave USB | Resistente | Mala (necesita USB) |
| Solo contraseña | Resistente | Mala (contraseña cada arranque) |
| Clave de recuperación | N/A | Solo uso de emergencia |
El exploit YellowKey funciona porque el desbloqueo automático solo TPM confía implícitamente en WinRE. Cuando añades un PIN, el TPM no libera la clave sin el PIN — incluso en WinRE. Esto rompe la cadena de ataque.
Defensa en Profundidad: Estrategias de Mitigación
Inmediato (Sin Necesidad de Reinicio)
Para YellowKey específicamente, hasta que Microsoft publique un parche:
- Habilitar protector TPM + PIN — Ejecuta
manage-bde -protectors -add C: -TPMAndPINdesde un símbolo del sistema elevado - Establecer contraseña BIOS/UEFI — Evita la manipulación de la selección del dispositivo de arranque
- Deshabilitar arranque externo — Configura UEFI para arrancar solo desde almacenamiento interno
- Deshabilitar WinRE — (No recomendado para producción, pero como último recurso)
reagentc /disable
Largo Plazo (Política Organizacional)
| Control | Implementación |
|---|---|
| Directiva de grupo de BitLocker | Exigir Requerir autenticación adicional al inicio → Configurar PIN de inicio de TPM: Requerir PIN de inicio con TPM |
| Secure Boot + DBX | Asegurar que Secure Boot esté habilitado con la lista de revocación más reciente (dbx) |
| System Guard de Windows Defender | Habilitar System Guard Secure Launch (protección SMM) |
| Actualizar WinRE | Aplicar las últimas actualizaciones de la pila de servicio de WinRE (KB5034231 y posteriores) |
| Desbloqueo de red de BitLocker | Para equipos de escritorio unidos a dominio, usar Desbloqueo de Red para evitar los riesgos de solo TPM |
Detección
No hay una detección fiable basada en registros para YellowKey, ya que el exploit opera completamente dentro de WinRE antes de que arranque el SO. Sin embargo:
- Monitorización de comportamiento previo al arranque: Los dispositivos que arrancan inesperadamente en WinRE deben desencadenar una investigación
- Auditorías de acceso físico: Rastrear dispositivos que han estado fuera de la vista
- Registros de arranque USB: El firmware UEFI puede registrar las selecciones de dispositivos de arranque
Lo Que Esto Significa Para el Modelo de Amenazas de BitLocker
El modelo de amenazas tradicional para BitLocker era:
Atacante con acceso físico: Protegido a menos que tengan la clave de recuperación o puedan forzar TPM + PIN.
El modelo de amenazas actualizado después de YellowKey:
Atacante con acceso físico a Windows 11+: Compromiso completo en ~2 minutos usando un USB y una tecla presionada.
Esto es un cambio de paradigma. Significa:
- BitLocker solo TPM en Windows 11 es efectivamente decorativo contra un atacante físico determinado
- El robo de portátiles ahora equivale a una violación de datos a menos que TPM+PIN o protecciones más fuertes estén habilitadas
- Las implementaciones empresariales que dependen de la configuración predeterminada de BitLocker están expuestas — la era de “marcar la casilla y olvidarse” ha terminado
La parte más perturbadora es la asimetría: el atacante solo necesita un USB y dos minutos de acceso físico. El defensor necesita implementar cambios de política, educar a los usuarios y asegurarse de que cada dispositivo tenga TPM+PIN habilitado.
Línea de Tiempo de Divulgación
| Fecha | Evento |
|---|---|
| 2024-2025 | El equipo STORM de Microsoft investiga las superficies de ataque de WinRE |
| 2025-07 | Microsoft parchea los CVE de BitUnlocker en el Patch Tuesday de julio |
| 2025-08 | STORM presenta BitUnlocker en Black Hat USA y DEF CON 33 |
| 2026-05-12 | Nightmare-Eclipse publica YellowKey en GitHub |
| 2026-05-13 | The Register confirma YellowKey con expertos de seguridad |
| 2026-05-13 | La ingeniería inversa de la comunidad confirma el mecanismo de la bandera de depuración FailRelock |
| 2026-05-14 | Este artículo se publica — sin parche oficial de Microsoft |
El Panorama General: Un Patrón de Fallos de Confianza en WinRE
YellowKey no es un incidente aislado. Mirando el panorama más amplio:
| Vulnerabilidad | Año | Componente | Impacto |
|---|---|---|---|
| CVE-2024-20666 | 2024 | Secure Boot / BitLocker | Omisión de función de seguridad |
| CVE-2025-48800 | 2025 | WinRE / tttracer | Omisión de BitLocker vía escaneo sin conexión |
| CVE-2025-48003 | 2025 | WinRE / SetupPlatform | Omisión de BitLocker vía tecla rápida |
| CVE-2025-48804 | 2025 | WinRE / Boot.sdi | Omisión de verificación de arranque |
| CVE-2025-48818 | 2025 | WinRE / PBR | Descifrado completo del volumen BitLocker |
| YellowKey | 2026 | WinRE / bandera de depuración FsTx | Omisión de BitLocker con una tecla |
La superficie de ataque de WinRE/WinPE ha demostrado repetidamente ser el eslabón más débil en la cadena de BitLocker. La decisión arquitectónica de Microsoft de confiar implícitamente en WinRE para el desbloqueo automático — sin atestación criptográfica de lo que WinRE está haciendo — crea una tensión de diseño fundamental: ¿cómo permites la recuperación sin permitir el abuso de la recuperación?
Hasta ahora, cada respuesta ha fallado.
Conclusión
YellowKey y BitUnlocker representan el mismo problema fundamental: el acceso privilegiado de WinRE a los volúmenes BitLocker no puede asegurarse adecuadamente solo con políticas de software cuando un atacante con acceso físico puede manipular el propio entorno de recuperación.
Si eres responsable de la seguridad de Windows en tu organización:
Audita tu configuración de BitLocker hoy. Si TPM+PIN no está exigido, asume que tus datos cifrados son accesibles para cualquiera con un destornillador y un USB.
Capacita a tus usuarios. Un portátil robado ya no es solo una pérdida de hardware — con YellowKey, es una violación de datos garantizada si solo se usa TPM.
Vigila la respuesta de Microsoft. Si pasa el Patch Tuesday sin abordar YellowKey, la teoría de la “puerta trasera” se vuelve significativamente más difícil de descartar.
Referencias
- Repositorio de YellowKey en GitHub: https://github.com/Nightmare-Eclipse/YellowKey
- Cobertura de The Register: https://www.theregister.com/2026/05/13/disgruntled-researcher-releases-two-more-microsoft-zero-days/
- Blog de BitUnlocker de Microsoft: https://techcommunity.microsoft.com/blog/microsoft-security-blog/bitunlocker-leveraging-windows-recovery-to-extract-bitlocker-secrets/4442806
- CVE-2025-48800 (MSRC): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-48800
- CVE-2025-48003 (MSRC): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-48003
- CVE-2025-48804 (MSRC): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-48804
- CVE-2025-48818 (MSRC): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-48818
- Análisis de Saltt Tech: https://www.saltt.tech/insights/bitunlocker-a-deep-technical-analysis-of-a-full-volume-encryption-bypass
Infografía
Figura 1: Flujo del exploit YellowKey — inserción de USB → arranque WinRE → CTRL presionado → shell sin restricciones en volumen cifrado