Investigador de seguridad afirma que Microsoft creó una puerta trasera en BitLocker y publica un exploit

• El investigador de seguridad Nightmare-Eclipse publicó YellowKey y afirmó que puede eludir el cifrado completo de volumen de BitLocker sin contraseña
• YellowKey puede reproducirse copiando la carpeta FsTx a una unidad USB con un sistema de archivos compatible con Windows y siguiendo una secuencia específica en WinRE
• Una vez completado el procedimiento, se abre una shell de comandos y, según se informa, es posible explorar, copiar y realizar operaciones con archivos en volúmenes protegidos por BitLocker
• Nightmare-Eclipse sostiene que el comportamiento de bypass solo aparece en la imagen oficial de WinRE, lo que plantea la posibilidad de una puerta trasera intencional
• Se indicó que los sistemas afectados son Windows 11, Server 2022 y Server 2025, y se agregó que Windows 10 no estaría afectado

---

Condiciones de funcionamiento de YellowKey

• El investigador de seguridad Nightmare-Eclipse publicó YellowKey y afirmó que puede eludir por completo el cifrado de volumen completo de BitLocker
• YellowKey puede reproducirse copiando la carpeta FsTx incluida a una unidad USB formateada con un sistema de archivos compatible con Windows, como NTFS, FAT32 o exFAT
• También se informa que puede funcionar sin una unidad USB si se copian los archivos de FsTx a la partición EFI de Windows y se desconecta temporalmente el disco cifrado del sistema
• Después, se debe reiniciar el sistema protegido con BitLocker, entrar en el Windows Recovery Environment (WinRE) y seguir una secuencia específica de entradas
• Si el procedimiento se completa con precisión, aparece una shell de comandos y, según se indica, permite explorar y copiar volúmenes protegidos por BitLocker o realizar otras operaciones con archivos sin contraseña

Fundamentos de la sospecha de puerta trasera

• Nightmare-Eclipse afirma que YellowKey es demasiado anómalo como para considerarlo un bug de seguridad previamente desconocido, y plantea la posibilidad de que Microsoft haya introducido una puerta trasera legítima en el sistema de protección de datos de BitLocker
• La base de esa sospecha es que los componentes que causan el problema solo se encuentran en la imagen oficial de WinRE
• Aunque los mismos componentes también existen en la imagen estándar de instalación de Windows, se afirma que allí no aparece el comportamiento de bypass de BitLocker observado en sistemas reales
• Nightmare-Eclipse declaró: “No se me ocurre otra explicación más que el hecho de que esto fue intencional”, y añadió que Windows 10 no está afectado, mientras que solo Windows 11, Server 2022 y Server 2025 se verían impactados

Verificación externa y divulgación adicional

• Se informa que investigadores externos confirmaron que YellowKey funciona de la manera descrita en el material de GitHub de Nightmare-Eclipse
• Nightmare-Eclipse también publicó un segundo exploit, GreenPlasma, del que se dice que permite escalación de privilegios
• GreenPlasma no incluye el código completo de prueba de concepto para lograr acceso a nivel SYSTEM, pero insinuó que podría revelar más detalles antes del Patch Tuesday del próximo mes

Mitigación

• Se plantea que la mitigación ante la sospecha de comportamiento tipo puerta trasera de YellowKey es relativamente sencilla
• Expertos en seguridad recomiendan no depender de un solo sistema de cifrado y evaluar también alternativas de cifrado completo de disco bien revisadas
• Como ejemplo, se menciona VeraCrypt

[GN⁺]

Comentarios de Hacker News

• Por lo que se ve en las publicaciones del investigador Nightmare-Eclipse, quien descubrió esta vulnerabilidad, esto venía desde hace casi una semana
  El martes 12 de mayo de 2026 dijo: “esta vez son dos vulnerabilidades [YellowKey] [GreenPlasma] [...] el próximo Patch Tuesday le traerá una gran sorpresa a Microsoft”, y el miércoles 13 de mayo escribió: “cuando pueda contar la historia completa, la gente verá que mi explosión fue bastante razonable, y tampoco hará que Microsoft se vea nada bien”
  Blog del autor: https://deadeclipse666.blogspot.com/
  En una primera entrada de marzo de 2026 hay algo como: “alguien rompió nuestro acuerdo, me quedé sin nada y hasta perdí mi casa. Sabían que esto iba a pasar y aun así me apuñalaron por la espalda. Esta no es mi decisión, es la de ellos”
  No sé muy bien cómo interpretarlo, pero suena un poco como si un insider estuviera básicamente “filtrando” esto, y parece que otras personas también pueden reproducir los resultados

  • Más que un insider, se lee como alguien que estaba siguiendo el proceso de divulgación de vulnerabilidades con Microsoft y, por alguna razón, se enojó y terminó publicándolo
  • Ya se discutió varias veces en HN, por ejemplo aquí: https://news.ycombinator.com/item?id=48130519
    Que esto sea o no una puerta trasera depende, al final, de cómo suelas ver la diferencia entre “bug o backdoor”, y no es una historia simplona del tipo “Microsoft = malo, BitLocker hackeado” como le encanta a la prensa tecnológica
    El punto clave es un bug en la función de reproducción del registro de transacciones NTFS del Windows Recovery Environment WinRE, que permite leer el registro de transacciones NTFS de un volumen externo y aplicarlo al sistema de archivos montado. Eso permite a un atacante omitir la autenticación de WinRE
    En BitLocker sin PIN ni contraseña, cualquier bypass de autenticación termina siendo un bypass del cifrado de disco. El bootloader ya desprecintó el disco, y este tipo de “defecto” estructural también existe en Linux con la misma configuración. Por ejemplo, pasa igual si usas la casilla Hardware Disk Encryption agregada relativamente hace poco en el instalador de Ubuntu
    Si no aparece evidencia adicional, que el problema del registro de transacciones NTFS sea una puerta trasera implantada o simplemente un bug de enumeración depende del nivel habitual de teorías conspirativas que suele haber en el desarrollo de exploits. Personalmente, me parece un bug plausible, y la debilidad de desprecintar al arranque es bien conocida y bastante obvia, así que no lo veo como una revelación que vaya a sacudir al mundo, aunque sí es un bug interesante
  • Tengo ganas de leer rápido una buena entrada de blog sobre qué pasó realmente y por qué esta persona terminó exponiendo a M$ de esta manera

• Mejor resumen: https://infosec.exchange/@wdormann/116565129854382214
  El exploit publicado no afecta a BitLocker con PIN. Sin PIN, BitLocker de por sí no es seguro
  El autor original afirma que tiene un exploit que también funciona con PIN, pero todavía no ha mostrado pruebas

  • ¿En tu empresa exigen PIN? Más importante aún: ¿la aseguradora de ciberseguridad que paga la empresa exige PIN?
    Nunca he visto una empresa que exija PIN para BitLocker
  • BitLocker tiene incluso un nivel por encima del PIN: puedes usar una memoria USB que contiene una clave usada solo al arrancar. Como los datos no se guardan en el dispositivo, parecería estar a salvo de este ataque
  • Si asumimos que lo del exploit para la versión con PIN es cierto, resulta interesante por qué publicó esta versión debilitada e inútil en vez de la versión con PIN. Tengo algunas ideas, pero ninguna con fundamento

• Fuente: https://infosec.exchange/@wdormann/116565129854382214
  “Una sesión típica de WinRE tiene el directorio X:\Windows\System32 y dentro está el archivo winpeshl.ini”
  “Pero en el exploit YellowKey, parece que fragmentos de Transactional NTFS en la unidad USB pueden borrar el archivo winpeshl.ini de otra unidad”
  Interesante. No conozco bien este entorno, pero ¿será ingenuamente un problema de crear o pasar file handles? Si es así, ¿por qué entonces haría falta ingresar teclas durante el reinicio de WinRE?
  También me pregunto qué tan parcheable será esto. No se podrá tocar una enorme cantidad de memorias USB de WinRE, así que ¿podrían actualizar permisos del lado de BitLocker? ¿Haría falta descifrar y volver a cifrar? Parece que todavía falta mucho por salir

  • La parte que falta es por qué WinRE tiene privilegios. Windows guarda la clave de descifrado en el TPM, para que WinRE pueda descifrar el disco incluso sin la clave de recuperación
    Por eso este ataque requiere WinRE y no simplemente arrancar con algo como un Live CD de Ubuntu
    Además, no hace falta parchear todas las memorias USB existentes de WinRE. Si se revoca la firma de Secure Boot, ya no pasará la validación del TPM y, por lo tanto, no podrá descifrar ningún disco

• “Los expertos en seguridad normalmente recomiendan no depender de un solo sistema de cifrado y evaluar alternativas de cifrado de disco completo bien revisadas, como VeraCrypt”
  Si realmente metieron una puerta trasera en el FDE, tendría más sentido decirle a la gente que deje de usar Windows por completo y use Linux
  Si metieron una puerta trasera en el FDE, entonces hay que asumir que no habrá solo una puerta trasera en el sistema operativo en sí. No se debe confiar en software privativo, ni tampoco en software open source que no haya sido auditado correctamente

  • En general no uso productos de Microsoft, pero ni siquiera en tu computadora correría VeraCrypt
  • O podrías usar algo como VeraCrypt, que es open source

• Esto parece menos un problema exclusivo de BitLocker y más un bypass de inicio de sesión. Si dependes del TPM sin PIN, el descifrado ocurre automáticamente
  Normalmente eso debería estar bien, porque el atacante no tendría que poder pasar de la pantalla de login, pero este exploit aparentemente muestra cómo obtener una shell sin restricciones en el entorno de recuperación
  El investigador afirma que también tiene una forma de omitir el PIN, pero todavía no la ha publicado

  • Si no obtuvo recompensa mediante el proceso de divulgación, quizá decidió que era mejor vendérselo a alguien dispuesto a pagar

• ¿Cuándo van a empezar los expertos en seguridad a rechazar roles de “seguridad de productos Microsoft”? Yo ya llegué a ese punto
  La seguridad de productos Microsoft no es más que un trabajo ocupado hasta que la siguiente ola de deuda técnica demencial y codicia de MS vuelva a derrumbarlo todo. Y ahora hasta hay backdoors

  • Eso no es un rol de “seguridad”, es un rol de cumplimiento. Para la mayoría de los clientes corporativos, eso es realmente todo lo que importa
    Cumplieron todas las reglas de compliance y siguieron las “mejores prácticas” influenciadas por MS, así que pase lo que pase, ya no será culpa de ellos
  • iOS también crea por defecto respaldos de iCloud sin cifrado de extremo a extremo, así que las autoridades pueden pedir chats, historial del navegador, etc. Signal es una excepción notable
    Puedes activar ADP para tener respaldos cifrados de extremo a extremo, pero puede no servir de mucho si tus interlocutores no lo tienen activado
    No es por defender a Microsoft, sino por decir que todas estas empresas fueron parte de PRISM
  • En el mercado corporativo se gana demasiado dinero con esto como para que la gente empiece a rechazar el trabajo solo porque le da flojera
  • ¿“Y ahora hasta hay backdoors”? ¿“Ahora”?
    ¿Hablamos de por qué, cuando una versión de Windows NT salió por error con los símbolos de depuración activados, el nombre de la clave que Microsoft decía que era una “clave de respaldo” terminaba en ..._NSAKEY?
    Una sola vez, literalmente una sola vez, Windows salió con los símbolos de depuración activados y justo el nombre de la clave criptográfica era “NSAKEY”
    Claro, la gente que sigue haciéndose de la vista gorda ante las fechorías del Estado dirá que eso era completamente normal y repetirá tal cual la excusa tan elaborada de Microsoft de que “no era una puerta trasera”

• Tras revisar un poco más el exploit, esto apunta a BitLocker en modo solo TPM. O sea, no hay autenticación previa al arranque
  Si Secure Boot valida la cadena de arranque, el TPM entrega por sí solo la clave de cifrado. Con acceso físico, no hace gran diferencia
  Puedes arrancar con una USB con el exploit y obtener una shell de emergencia, o comprar un microcontrolador de 5 dólares y soldarlo a ciertos pines de la motherboard para husmear la clave del TPM
  Microsoft está vendiendo algo inseguro en términos generales como si fuera cifrado de disco completo. Si alguien puede poner un exploit en una memoria flash, obtener una shell y revisar y copiar archivos, también puede comprar un microcontrolador y seguir un video de YouTube sobre soldadura
  Así que el problema no es el “exploit” en sí, sino la falsa sensación de seguridad que vende Microsoft

  • Lo de “entrar a una shell de emergencia con una memoria booteable” no funciona. El TPM solo entrega la clave al arrancar un sistema operativo “aprobado”; específicamente, tiene que coincidir el estado de PCR al que está vinculada la clave de cifrado
    Lo de espiar la clave del TPM soldando a ciertos pines con un microcontrolador de 5 dólares solo es posible en dTPM. fTPM no es vulnerable a eso y se usa mucho más que dTPM
  • Ubuntu también sacó FDE basado en TPM hace algunas versiones. Ya en ese momento pensé lo mismo y decidí no usarlo
    Escribir una passphrase al arrancar ya es memoria muscular y te da una seguridad simple en la que puedes confiar
    Puedes recuperar los datos incluso sin la motherboard
    Para uso diario, quizá un esquema híbrido podría estar bien: usar un slot con Secure Boot+TPM+passphrase para frenar ataques evil maid, y dejar otro slot de passphrase de respaldo
  • Afirma que también hay un exploit para TPM+PIN, pero todavía está por verse si eso es confiable
    https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
  • Linux LUKS también puede configurarse exactamente de la misma manera
    Esto parece menos un ataque contra BitLocker y más un ataque contra la cadena de Secure Boot
    El valor de un desbloqueo sin PIN existe cuando el modelo de amenazas se limita a descarte de discos, extracción del disco o separación entre el TPM y el disco
    Si varias personas usan el equipo con regularidad, introducir un PIN puede ser incómodo o imposible. Por eso se termina delegando el control de verificación de acceso a componentes confiables del sistema operativo
  • Es un bug muy serio, pero BitLocker sí es cifrado de disco completo. Lo que pasa es que se puede omitir la autenticación

• ¿Alguien recuerda esa leyenda que decía: “Usar TrueCrypt no es seguro y puede contener problemas de seguridad sin corregir”? ;)

  • Me hace pensar en TrueCrypt/VeraCrypt. Probablemente sea una solución de cifrado más segura. Después de esto, desde luego se ve más segura