¿Basta con Secure Boot para detener BlackLotus?

No por sí solo. BlackLotus explota un administrador de arranque de Windows antiguo, firmado de forma válida, en el que Secure Boot sigue confiando. Aplicar las actualizaciones sustituye el administrador de arranque en el disco, pero no impide que un atacante traiga el antiguo y vulnerable. La solución es la revocación: añadir el antiguo certificado de firma a la DBX para que el firmware rechace los administradores de arranque firmados con él, una vez que el dispositivo haya pasado a un administrador de arranque firmado con Windows UEFI CA 2023.

¿Qué ocurre cuando caducan los certificados de Secure Boot de Microsoft de 2011?

Los dispositivos siguen arrancando; en general, el firmware UEFI no comprueba la caducidad de los certificados al validar los componentes de arranque. El problema es el mantenimiento: tras la caducidad, Microsoft ya no puede firmar con los certificados antiguos nuevos administradores de arranque ni actualizaciones de DB y DBX, de modo que los dispositivos que nunca recibieron los certificados 2023 dejan de recibir correcciones de seguridad de la cadena de arranque. Llevar todos los dispositivos a los certificados KEK y DB de 2023 es lo que los mantiene actualizables.

¿Las actualizaciones de Secure Boot desencadenarán la recuperación de BitLocker?

Normalmente no cuando las aplica Windows y BitLocker usa la vinculación a PCR 7, porque Windows espera el cambio y vuelve a sellar la clave. La recuperación puede producirse en dispositivos con un perfil de PCR sin PCR 7, con algunos firmwares o cuando los cambios se hacen fuera de Windows. Asegúrese de que todas las claves de recuperación están custodiadas y pruebe cada modelo de hardware en un anillo piloto antes del despliegue general.

Secure Boot, UEFI y las mitigaciones de BlackLotus

Todo lo que Windows hace para protegerse, desde BitLocker hasta Credential Guard, supone que el código que se ejecutó antes de Windows era de confianza. Secure Boot impone esa suposición: el firmware UEFI solo ejecuta componentes de arranque firmados por claves de su base de datos de firmas. Bootkits como BlackLotus demostraron que «Secure Boot está activado» no equivale a «la cadena de arranque es segura», y los certificados de Microsoft que anclan todo el sistema se están sustituyendo.

El pilar de endurecimiento de BitLocker comprueba que Secure Boot está activado. Esta guía va más allá: las bases de datos de claves, las mitigaciones de CVE-2023-24932, la transición a los certificados 2023 y el endurecimiento del firmware. Forma parte de la serie BitLocker y seguridad del arranque.

Cómo decide Secure Boot qué se ejecuta

Variable	Contenido	Quién la actualiza
PK (Platform Key)	La clave del OEM; propietario de la plataforma	Firmware del OEM
KEK (Key Exchange Key)	Claves autorizadas a actualizar DB y DBX, incluida la KEK de Microsoft	El OEM, o actualizaciones firmadas por la PK
DB (firmas permitidas)	Certificados y hash del código de arranque de confianza: la CA de Windows de Microsoft, la CA UEFI de terceros de Microsoft	Actualizaciones firmadas por una KEK
DBX (firmas prohibidas)	Certificados revocados y hash de código de arranque con vulnerabilidades conocidas	Actualizaciones firmadas por una KEK

El firmware solo ejecuta un componente de arranque si su firma se encadena a DB y no figura en DBX. Los administradores de arranque de Windows se han firmado con Microsoft Windows Production PCA 2011; los shims de Linux y muchas ROM opcionales se encadenan a Microsoft Corporation UEFI CA 2011; las actualizaciones de DB y DBX de Microsoft se firman con Microsoft Corporation KEK CA 2011.

Por qué BlackLotus cambió las reglas

BlackLotus (CVE-2022-21894, seguida de CVE-2023-24932) abusa de un administrador de arranque antiguo pero firmado de forma válida con el certificado PCA 2011. Secure Boot lo ejecuta sin problema, y el atacante aprovecha su vulnerabilidad para desactivar protecciones y cargar un bootkit sin firmar que persiste por debajo del sistema operativo, incluso con BitLocker en uso.

Actualizar Windows sustituye el administrador de arranque en la partición del sistema EFI, pero un atacante con derechos de administrador puede volver a copiar el antiguo y vulnerable. La única corrección duradera es dejar de confiar en el certificado PCA 2011 mediante la DBX, lo que a su vez exige que todos los dispositivos arranquen antes un administrador de arranque firmado por la nueva Windows UEFI CA 2023. Ese orden, junto con el riesgo de dejar inservibles los medios de arranque, explica por qué Microsoft hizo las mitigaciones opcionales y escalonadas.

Paso 1: inventariar el estado actual

En cada dispositivo:

PowerShell

Confirm-SecureBootUEFI                         # True = habilitado; error = arranque BIOS heredado/CSM
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).Bytes) -match 'Windows UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name KEK).Bytes) -match 'KEK 2K CA 2023'

Recopile estos datos con un script de cumplimiento, junto con el modelo y la versión de firmware (Get-CimInstance Win32_ComputerSystem, Get-CimInstance Win32_BIOS). Los dispositivos que todavía arrancan en modo BIOS heredado o CSM necesitan primero una conversión: mbr2gpt.exe /validate /allowFullOS y después /convert, para luego pasar el firmware a solo UEFI y habilitar Secure Boot.

Las directivas de cumplimiento de Intune pueden exigir Secure Boot mediante Device Health > Require Secure Boot to be enabled on the device, que se basa en la atestación del registro de arranque medido y no en el resultado de un script.

Paso 2: aplicar las mitigaciones de CVE-2023-24932

Microsoft documenta el procedimiento completo en KB5025885 («How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932»). Lea la versión actual antes de empezar; el calendario de aplicación ha cambiado varias veces. El mecanismo es un valor del registro que indica a Windows qué pasos de mantenimiento de Secure Boot debe realizar en los siguientes reinicios:

Text

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Secureboot
Value: AvailableUpdates  (REG_DWORD)

En el momento de escribir esto, los pasos documentados son:

Paso	AvailableUpdates	Efecto	Evento de confirmación (registro del sistema, origen TPM-WMI)
1	`0x5944`	Desplegar los certificados de Secure Boot 2023 (Windows UEFI CA 2023 en DB, más la KEK 2023 y las CA de terceros cuando proceda) y el administrador de arranque firmado por Windows UEFI CA 2023	1036 (DB actualizada)
2	(ninguno: verificar)	Confirmar que `UEFICA2023Status` en `...\Secureboot\Servicing` indica `Updated` y que el administrador de arranque firmado en 2023 está instalado	1799
3	`0x80`	Añadir Windows Production PCA 2011 a DBX (la revocación)	1037
4	`0x200`	Aplicar al firmware la actualización del Secure Version Number (SVN)	1042

Windows borra cada bit una vez procesado; la tarea de mantenimiento se ejecuta cada 12 horas y algunos pasos necesitan uno o dos reinicios. Haga primero los pasos 1 y 2, de forma amplia. Pase a los pasos 3 y 4 solo cuando se hayan actualizado todos los medios de arranque que podrían arrancar el dispositivo (paso 4 más abajo), porque tras la revocación todo lo firmado solo con PCA 2011 deja de arrancar. Los errores aparecen como eventos del mismo origen: 1795 (el firmware devolvió un error; normalmente se corrige con una actualización de firmware del OEM), 1796 (error inesperado, con el código de error) y 1801 (los nuevos certificados aún no se han aplicado al firmware). El evento 1808 confirma que un dispositivo tiene todos los nuevos certificados necesarios.

Paso 3: pasar a los certificados 2023

Los certificados de 2011 caducan en 2026: la KEK y la CA UEFI de terceros en junio, la Windows Production PCA en octubre. La caducidad no impide que los dispositivos arranquen, pero les quita la capacidad de recibir nuevas actualizaciones de DB/DBX de Secure Boot y nuevos administradores de arranque firmados con la cadena antigua.

El estado objetivo para cada dispositivo:

KEK: Microsoft Corporation KEK 2K CA 2023
DB: Windows UEFI CA 2023, más Microsoft UEFI CA 2023 y Microsoft Option ROM UEFI CA 2023 cuando se confía en código de terceros
Administrador de arranque: firmado por Windows UEFI CA 2023

Microsoft distribuye estas actualizaciones mediante el mantenimiento de Windows y documenta varias formas de desplegarlas de forma deliberada:

Registro: AvailableUpdates = 0x5944 en HKLM\SYSTEM\CurrentControlSet\Control\Secureboot despliega todos los certificados necesarios y el administrador de arranque firmado en 2023. El progreso se indica en HKLM\SYSTEM\CurrentControlSet\Control\Secureboot\Servicing: UEFICA2023Status pasa de NotStarted a InProgress y a Updated, y UEFICA2023Error es distinto de cero en caso de error. MicrosoftUpdateManagedOptIn = 1 en la clave Secureboot inscribe en su lugar el dispositivo en el despliegue controlado de características de Microsoft.
Directiva de grupo: Computer Configuration > Administrative Templates > Windows Components > Secure Boot, incluida Enable Secure Boot Certificate Deployment.
Catálogo de configuración de Intune: Enable Secureboot Certificate Updates, Configure Microsoft Update Managed Opt In y Configure High Confidence Opt-Out.

Las opciones de directiva requieren actualizaciones acumulativas recientes, así que consulte las indicaciones actuales de Microsoft sobre la actualización de certificados de Secure Boot para conocer la compilación mínima de cada versión de Windows.

Las actualizaciones de KEK deben estar firmadas por la Platform Key del OEM, así que algunos modelos necesitan una actualización de firmware antes de que Windows pueda aplicarlas. Siga el progreso por modelo, no solo por dispositivo.

Paso 4: actualizar los medios de arranque y las vías de recuperación

Antes de cualquier revocación:

WinPE y PXE: vuelva a generar las imágenes de arranque de Configuration Manager y WDS a partir de medios actuales del Windows ADK para que incluyan el administrador de arranque firmado en 2023.
Unidades USB de instalación y recuperación: vuelva a crearlas a partir de medios actuales. Microsoft publica indicaciones y herramientas para actualizar los medios de arranque.
Entorno de recuperación de Windows en cada dispositivo: confirme que WinRE se ha actualizado junto con el sistema operativo.
Máquinas virtuales: las VM de generación 2 de Hyper-V, las de VMware y las de la nube tienen su propio firmware virtual y sus claves de plantilla. Consulte las indicaciones del proveedor de su hipervisor sobre las actualizaciones de KEK y DB, y use la plantilla de Secure Boot Microsoft Windows para los invitados Windows en Hyper-V.

Paso 5: endurecer el propio firmware

Cualquiera con acceso físico puede desactivar Secure Boot en la configuración del firmware, salvo que el firmware esté bloqueado:

Configuración	Valor
Modo de arranque	Solo UEFI; CSM/heredado desactivado
Secure Boot	Habilitado, modo estándar con las claves de fábrica (no modo de configuración ni personalizado)
Contraseña de administrador del firmware	Definida, única por dispositivo o por modelo, guardada en su almacén de secretos
Arranque desde USB / red	Desactivado o protegido por la contraseña de firmware donde no se necesite
CA UEFI de terceros de Microsoft	Desactivada en los dispositivos solo Windows cuando las ROM opcionales lo permiten (los equipos Secured-core se entregan así)
Puertos Thunderbolt / DMA externos	Confíe en Kernel DMA Protection; vea la guía de VBS y DMA

Aplique esta configuración con las herramientas del OEM (todos los grandes fabricantes ofrecen utilidades de línea de comandos para configurar la BIOS) o, en hardware compatible registrado en Windows Autopilot, con perfiles Device Firmware Configuration Interface (DFCI) de Intune, que además pueden bloquear la configuración del firmware frente a cambios locales. Mantenga el firmware actualizado mediante Windows Update o el canal del OEM: muchas correcciones de Secure Boot llegan como actualizaciones de firmware.

Qué se rompe

Los medios de arranque antiguos dejan de funcionar tras la revocación en DBX: las memorias USB del cajón del soporte técnico, las imágenes PXE, los medios de recuperación de copias de seguridad de terceros.
Errores de firmware: algunos modelos rechazan las actualizaciones de DB, KEK o DBX, o no arrancan después de ellas. Pruebe cada modelo en piloto.
Los sistemas de arranque dual y Linux dependen de la CA UEFI de terceros; desactivarla o revocar los shims les afecta.
Solicitudes de recuperación de BitLocker en los dispositivos sin vinculación a PCR 7. Confirme primero la custodia con la guía de claves de recuperación y suspenda BitLocker durante un reinicio (Suspend-BitLocker -MountPoint C: -RebootCount 1) alrededor de las actualizaciones de firmware.
Las ROM opcionales de GPU y controladoras de almacenamiento adicionales pueden necesitar la CA de terceros.

Comprobarlo

Confirm-SecureBootUEFI devuelve True en todos los dispositivos.
DB contiene Windows UEFI CA 2023 y KEK contiene Microsoft Corporation KEK 2K CA 2023 (comandos del paso 1).
El registro del sistema muestra los eventos de confirmación de cada paso aplicado (1808 cuando todos los certificados están instalados), UEFICA2023Status indica Updated y AvailableUpdates ya no contiene los bits que definió (es normal que quede un 0x4000 tras 0x5944).
En los dispositivos revocados, un medio de arranque antiguo firmado con PCA 2011 no arranca y muestra una infracción de Secure Boot. Pruébelo una vez por modelo en el laboratorio, no en producción.
El cumplimiento de Intune indica que Secure Boot está en buen estado; los registros de arranque medido de C:\Windows\Logs\MeasuredBoot están presentes para la atestación.

Lista de comprobación

Todos los dispositivos arrancan en modo UEFI con Secure Boot habilitado en modo estándar
Inventario del estado de DB, KEK y administrador de arranque por dispositivo y por modelo
Windows UEFI CA 2023 en DB y administrador de arranque firmado en 2023 instalado en todas partes
KEK 2023 desplegada; modelos que necesitan actualizaciones de firmware identificados y actualizados
Medios de arranque, imágenes PXE, WinRE y plantillas de VM actualizados
Revocación de PCA 2011 y actualización de SVN aplicadas, anillo por anillo, tras actualizar los medios
Contraseña de firmware definida, arranque heredado y externo desactivados, configuración bloqueada

Una cadena de arranque de confianza es la base de Credential Guard y de la integridad de memoria. Consulte la entrada del glosario sobre Secure Boot para una definición más breve que compartir con personas no especialistas.