YellowKey: el exploit Zero-Day que vulnera BitLocker en Windows 11 con acceso físico

Introducción

El martes 16 de mayo de 2026, un investigador que opera bajo el alias Nightmare-Eclipse publicó en GitHub un exploit funcional contra BitLocker, el sistema de cifrado de disco completo de Microsoft. El exploit, denominado YellowKey, aprovecha una debilidad en la gestión de claves de BitLocker cuando el sistema arranca desde un entorno controlado por el atacante. A diferencia de vulnerabilidades tradicionales, no requiere ejecución de código remoto ni privilegios elevados: basta con acceso físico al equipo durante un breve lapso y reiniciar desde un medio externo.

La relevancia técnica de YellowKey no radica en su complejidad —de hecho, usa herramientas comunes como chntpw y manipulación de metadatos NTFS—, sino en que elude por completo la protección del TPM en configuraciones por defecto de Windows 11. Esto impacta especialmente a organizaciones que implementan BitLocker como mecanismo de cumplimiento normativo, como aquellas que trabajan con agencias gubernamentales o manejan información clasificada. Según el Catalogo de Controles de Seguridad de CIS, BitLocker está recomendado con prioridad «Level 2» para entornos empresariales, lo que implica que su vulneración directa puede comprometer el cumplimiento de estándares como ISO 27001 o NIST SP 800-53.

Qué ocurrió

YellowKey no es un ataque de zero-click ni explota una vulnerabilidad en el kernel de Windows. Su vector de ataque es físico y de tiempo limitado:

1. El atacante obtiene acceso temporal al equipo apagado.
2. Fuerza un arranque desde un medio externo (USB, PXE) que contiene un entorno Linux modificado.
3. Monta la partición del disco cifrada y manipula el registro de transacciones NTFS para forzar la carga de un recovery environment alterado.
4. Al reiniciar, Windows interpreta el estado manipulado como una recuperación legítima, omitiendo la verificación del TPM y mostrando la pantalla de recuperación de BitLocker.
5. El atacante introduce una clave de recuperación falsa o modifica el bootloader para extraer los datos antes de que el sistema se reinicie nuevamente.

El exploit fue desarrollado en Rust y publicado como un repositorio público en GitHub: nightmare-eclipse/yellowkey. El código incluye:

• Un parser para archivos $MFT y $LogFile de NTFS.
• Un módulo para inyectar transacciones falsas que simulan un fallo de BitLocker.
• Instrucciones para compilarlo en cualquier distribución Linux moderna con rustc 1.78.0 o superior.

La técnica no es nueva: en 2022, el investigador Mark Baggett demostró en DEF CON cómo manipular el Windows Recovery Environment para extraer claves de BitLocker en sistemas con TPM 2.0. Sin embargo, YellowKey automatiza el proceso y funciona en configuraciones por defecto de Windows 11 23H2 sin necesidad de deshabilitar Secure Boot o modificar el firmware.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e infraestructura

El riesgo principal para entornos empresariales no es la pérdida de datos en sí, sino la exposición de información regulada. Según el Informe de Amenazas de Microsoft de 2025, el 34% de los incidentes de ransomware en organizaciones con más de 1.000 empleados involucraron equipos con BitLocker deshabilitado o comprometido. YellowKey podría ser usado como pivot en ataques dirigidos:

• Ataques a supply chain: Si un equipo de desarrollo es comprometido, el atacante podría extraer claves de BitLocker de discos cifrados que contienen repositorios de código o artefactos de CI/CD.
• Exfiltración de credenciales: Muchos equipos usan BitLocker + Windows Hello for Business para almacenar certificados en el TPM. Un atacante con acceso físico podría extraer estos certificados y usarlos para autenticarse en servicios internos.
• Cumplimiento normativo: Si un equipo con datos de clientes es vulnerado, la organización podría incumplir regulaciones como GDPR (multas de hasta el 4% de los ingresos globales) o HIPAA (sanciones de hasta $1.5 millones por incidente).

Para equipos de seguridad

El exploit evidencia un problema de diseño en BitLocker: la confianza exclusiva en el TPM como único factor de autenticación. Según el NIST SP 800-147, un sistema de cifrado debe implementar al menos dos factores de autenticación para resistir ataques físicos. BitLocker en modo TPM-only no cumple este requisito, incluso cuando se usa con BitLocker To Go o BitLocker Network Unlock.

El impacto se agrava en entornos híbridos:

• Azure AD Join: Equipos unidos a Azure AD con BitLocker habilitado almacenan claves de recuperación en la nube. Un atacante con acceso físico podría forzar un downgrade a modo recuperación y descargar la clave desde el portal de Azure.
• Entornos VDI: Si un equipo virtualizado usa BitLocker con passthrough del TPM, el atacante podría extraer la clave del hipervisor o del host.

Detalles técnicos

Vector de ataque

YellowKey aprovecha tres componentes clave de Windows:

1. NTFS Transactional Logging: BitLocker depende de que el registro de transacciones ($LogFile) refleje un estado consistente del sistema. Al manipular este archivo, el exploit simula un fallo de BitLocker durante el arranque.
2. BitLocker Recovery Environment: El entorno de recuperación de BitLocker (winre.wim) no verifica la integridad del registro de arranque (BCD) si detecta un dirty bit en el sistema de archivos.
3. TPM 2.0 Emulation: El exploit engaña al sistema para que crea que el TPM está fallando, obligando al usuario a ingresar una clave de recuperación manualmente.

Componentes afectados

# Clonar el repositorio
git clone https://github.com/nightmare-eclipse/yellowkey.git
cd yellowkey
cargo build --release

# Montar la partición cifrada (usando dislocker)
sudo mkdir /mnt/bitlocker
sudo dislocker -V /dev/nvme0n1p3 -uUSERPASSWORD -- /mnt/bitlocker
sudo mount -t ntfs-3g /mnt/bitlocker/dislocker-file /mnt/bitlocker_mount

# Inyectar transacción falsa
./target/release/yellowkey inject \
  --mft /mnt/bitlocker_mount/$MFT \
  --logfile /mnt/bitlocker_mount/$LogFile \
  --transaction-id 0x12345678

# Reiniciar y forzar modo recuperación
sudo umount /mnt/bitlocker_mount
sudo dislocker -u -V /dev/nvme0n1p3 -- /mnt/bitlocker

Limitaciones del exploit

• Requiere acceso físico: No funciona de forma remota.
• Deja rastros: Modifica el $LogFile y el $MFT, lo que puede detectarse con herramientas como ntfscat o fsstat de The Sleuth Kit.
• No funciona con BitLocker + PIN: Si el equipo tiene un PIN pre-arranque configurado, YellowKey falla al intentar forzar el entorno de recuperación.

Qué deberían hacer los administradores y equipos técnicos

1. Validar la exposición actual

Ejecutar el siguiente script en equipos críticos para detectar configuraciones vulnerables:

# PowerShell para audit BitLocker
$computers = Get-ADComputer -Filter * -Properties BitLocker*
foreach ($computer in $computers) {
    $bitlocker = Get-BitLockerVolume -MountPoint "C:" -ErrorAction SilentlyContinue
    if ($bitlocker.ProtectionStatus -eq "On") {
        $protector = Get-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorType Tpm
        if ($protector -eq $null) {
            Write-Warning "Equipo $($computer.Name) usa BitLocker sin TPM como único protector"
        } else {
            Write-Host "Equipo $($computer.Name) está protegido con TPM + $($protector.KeyProtectorType)"
        }
    }
}

2. Implementar mitigaciones inmediatas

Para equipos con BitLocker habilitado:

• Habilitar PIN pre-arranque:

  manage-bde -protectors -add c: -p TPMAndPIN
  

– Requisito: Tarjeta TPM 2.0 + firmware actualizado.

– Impacto en UX: Añade ~2 segundos al tiempo de arranque.

• Deshabilitar arranque desde medios externos:

  Set-NetFirewallRule -DisplayName "Denegar arranque PXE" -Enabled True
  bcdedit /set {fwbootmgr} displayorder {bootmgr} /timeout 0
  

• Implementar BitLocker Network Unlock (para equipos en dominio):

  Add-WindowsFeature -Name BitLocker-NetworkUnlock -IncludeManagementTools
  

Para equipos críticos sin BitLocker:

• Migración a VeraCrypt:

  # En Linux (ejemplo para Debian)
  sudo apt install veracrypt
  veracrypt --text --create /dev/nvme0n1p3 --filesystem ntfs --password PROMPT
  

– Ventaja: Soporta cifrado en múltiples capas (AES + Serpent + Twofish).

– Desventaja: No integra con Azure AD ni BitLocker To Go.

3. Monitoreo y detección

Configurar alertas en SIEM para cambios en:

• Eventos de BitLocker:

  <!-- Regla para Splunk -->
  <query>index=windows EventCode=7034 OR EventCode=7035</query>
  

• Accesos físicos no autorizados:

  # Usar auditd en Linux para detectar montajes de ntfs-3g
  auditctl -a exit,always -F arch=b64 -S mount -k bitlocker-manipulation
  

4. Plan de respuesta a incidentes

Si se detecta YellowKey en un equipo:

1. Aislar el equipo: Desconectar de la red y forzar apagado.
2. Analizar logs:

   Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-BitLocker/BitLocker Management'} |
   Where-Object {$_.Id -eq 7036} |
   Select-Object -ExpandProperty Message
   

1. Rotar claves de BitLocker:

   manage-bde -protectors -delete c: -type Tpm
   manage-bde -protectors -add c: -p TPMAndPIN
   

Conclusión

YellowKey no es un fallo catastrófico de BitLocker, pero expone un problema estructural: la confianza exclusiva en el hardware como único factor de autenticación. Para organizaciones que manejan datos sensibles, la solución no es abandonar BitLocker, sino complementarlo con capas adicionales de seguridad:

• PIN pre-arranque obligatorio.
• TPM 2.0 con firmware actualizado.
• Monitoreo continuo de cambios en metadatos NTFS.

En entornos donde la seguridad física no está garantizada (ej.: laptops en viajes o equipos en escritorios compartidos), alternativas como VeraCrypt o cifrado de archivos por usuario (ej.: GPG) son opciones más robustas. Como advirtió el investigador Clive Robinson en los comentarios de Schneier on Security: «Un candado en un galpón no protege un cofre».

La industria ya vio este problema con iPhones en 2016 (caso FBI vs. Apple). Microsoft tiene la oportunidad de corregirlo ahora, o arriesgarse a que YellowKey se convierta en un exploit kit automatizado en foros de hacking.

• Schneier on Security: Zero-Day Exploit Against Windows BitLocker
• Microsoft Security Blog: BitLocker Best Practices
• Elastic: Análisis de YellowKey
• NIST SP 800-147: BIOS Protection Guidelines
• GitHub: yellowkey (Nightmare-Eclipse)