Microsoft responde al fallo YellowKey de BitLocker
Microsoft ya ha reaccionado al nuevo problema de seguridad que afecta a BitLocker, el sistema de cifrado integrado en Windows, después de que el investigador conocido como «Nightmare Eclipse» publicara detalles técnicos y una prueba de concepto funcional del ataque «YellowKey», una vulnerabilidad que permitiría acceder a unidades supuestamente protegidas incluso cuando el cifrado está activo.
La compañía ha registrado el fallo como CVE-2026-45585 y reconoce que se trata de una vulnerabilidad de bypass de seguridad que puede explotarse con acceso físico al equipo, algo especialmente delicado en portátiles corporativos, estaciones de trabajo o equipos que dependen únicamente del TPM para desbloquear BitLocker durante el arranque. Todavía no existe un parche definitivo, así que Microsoft está tirando de mitigaciones temporales mientras prepara la actualización de seguridad correspondiente.
Contenido
¿Cómo funciona el ataque «YellowKey» contra BitLocker?
Según los detalles publicados por el investigador, el ataque aprovecha el entorno de recuperación de Windows, conocido como WinRE, mediante archivos manipulados que se cargan desde una memoria USB o desde una partición EFI preparada para ello, abriendo una consola del sistema con permisos elevados incluso cuando la unidad está cifrada con BitLocker. La parte preocupante no es solo el acceso, sino que hablamos de un método relativamente sencillo para cualquiera que tenga acceso físico al dispositivo.
Ya hemos visto otras veces cómo BitLocker acaba dependiendo demasiado del módulo TPM sin una segunda capa de autenticación, y aquí vuelve a aparecer exactamente el mismo problema: si el sistema arranca y confía automáticamente en el hardware, un atacante con acceso local puede intentar manipular la cadena de arranque y colarse antes de que Windows levante todas las protecciones.
Microsoft recomienda abandonar el modo TPM exclusivo en BitLocker
La medida más importante que plantea Microsoft pasa por dejar de usar BitLocker únicamente con autenticación TPM y activar un PIN obligatorio durante el arranque, algo que añade una segunda barrera y evita que el acceso físico al dispositivo sea suficiente para intentar explotar la vulnerabilidad.
En la práctica, la empresa recomienda:
- Desactivar el inicio automático de
autofstx.exe - Reconfigurar la cadena de confianza de BitLocker dentro de WinRE
- Obligar al uso de PIN de arranque junto al TPM
- Aplicar políticas centralizadas mediante Group Policy o Microsoft Intune
Este último punto tiene bastante sentido en entornos corporativos, sobre todo porque muchas empresas activan BitLocker masivamente dejando la configuración por defecto de Windows, algo cómodo para despliegues rápidos pero bastante menos sólido frente a ataques físicos como este.
El problema vuelve a poner el foco sobre la seguridad física en Windows
Lo interesante de «YellowKey» es que no rompe directamente el cifrado de BitLocker ni descifra la unidad por fuerza bruta, sino que aprovecha un escenario donde el propio entorno de recuperación acaba concediendo más privilegios de los que debería. Eso cambia bastante la lectura del problema, porque vuelve a demostrar que el eslabón débil muchas veces no está en el algoritmo criptográfico sino en todo lo que rodea al proceso de arranque.
También deja otra lectura incómoda para Microsoft: depender solo del TPM como método de desbloqueo automático sigue siendo demasiado arriesgado en equipos sensibles, especialmente ahora que cada vez vemos más ataques dirigidos al boot chain, al firmware y a los entornos de recuperación de Windows.
A falta del parche definitivo, activar un PIN de arranque junto a BitLocker pasa de recomendación opcional a medida prácticamente obligatoria para cualquiera que maneje información sensible en Windows.
