Kaspersky ha documentado BlackX, un bootkit UEFI que aprovecha la vulnerabilidad Baton Drop (CVE-2022-21894) para saltarse el arranque seguro (Secure Boot) de Windows en equipos con todas las actualizaciones instaladas. Lo detectó a principios de 2026 en una campaña de espionaje contra agencias diplomáticas de Tayikistán, Uzbekistán y Turkmenistán, que atribuye con confianza media al grupo APT41.
Las claves de BlackX en 30 segundos
- El equipo GReAT de Kaspersky publicó el análisis el 22/10/2026 tras hallar el bootkit a principios de año en una campaña de espionaje.
- Las víctimas son organismos diplomáticos de Asia Central y la autoría se asigna con confianza media a APT41.
- El exploit se parece mucho al de BlackLotus y permite registrar claves propias para cargar cualquier archivo EFI.
- Los equipos estaban parcheados, pero sus administradores no habían revocado a mano el certificado Windows Production PCA 2011.
El hallazgo no descubre un fallo nuevo. Baton Drop se corrigió en 2022 y en marzo de 2023 ESET ya confirmó que BlackLotus lo explotaba para comprometer equipos con Windows 11 totalmente actualizados. Lo que muestra BlackX es que, más de tres años después, la corrección sigue incompleta en muchas organizaciones porque su parte decisiva exige una acción manual del administrador.
Un exploit heredado de BlackLotus con otra carga útil
Según el informe, los atacantes instalaban BlackX después de comprometer la red de la víctima y obtener privilegios de administrador. Un instalador descifraba con RC4 los componentes y los escribía tanto en la partición del sistema como en la partición UEFI.
Kaspersky describe la implementación del exploit como muy parecida a la de BlackLotus, el bootkit que se anunció en foros en octubre de 2022 por 5.000 dólares. Su objetivo es registrar claves de propietario de la máquina (MOK, Machine Owner Keys) propias, de modo que el firmware acepte archivos EFI arbitrarios. El código de BlackLotus se filtró en GitHub en julio de 2023 de forma incompleta, y algunas muestras contienen fragmentos ausentes de ese repositorio que sí aparecen en BlackX. Kaspersky no ha podido determinar si los autores aplicaron ingeniería inversa o consiguieron el código fuente. El controlador de núcleo y las cargas posteriores, en cambio, son distintos.
Ese controlador está firmado con un certificado ya revocado, emitido a nombre de Wenjiang District Mingyu Network Technology Service Studio. Desactiva retrollamadas de los productos de seguridad y manipula proveedores de Event Tracing for Windows (ETW) para dificultar la monitorización. Algunas rutinas solo se activan ante productos de Kaspersky o Avast, aunque la compañía afirma que no tuvieron efecto sobre sus soluciones. Para proteger sus propios archivos, el controlador intercepta los intentos de abrirlos y devuelve en su lugar la calculadora de Windows.
En modo usuario, Kaspersky identificó dos herramientas. La primera es un troyano de acceso remoto (RAT) que usa Google Drive, OneDrive o Yandex.Disk como canal de mando y control para ejecutar código .NET y mover archivos. La segunda, OxiDLLRunner, es una DLL ofuscada con OLLVM que carga googleupdate.exe mediante sideloading; descifra el archivo v8_context_snapshot.bin y lanza un código en Rust que descarga complementos desde archivetj[.]com. La atribución a APT41 (también llamado Brass Typhoon, Wicked Panda o Barium) se apoya en un identificador compartido con un implante descrito por ESET y en técnicas habituales de actores de habla china.
No es el primer caso de componentes antiguos que siguen siendo válidos en la cadena de arranque, como los shim olvidados de UEFI que socavan el arranque seguro o la vulnerabilidad CVE-2024-7344 en UEFI Secure Boot.
Por qué el parche de Baton Drop no bastó
Todas las víctimas de BlackX tenían Windows al día. El problema, según Kaspersky, es que la protección completa pasa por revocar el certificado Windows Production PCA 2011, con el que están firmados los gestores de arranque vulnerables, y esa revocación no se produce al instalar la actualización: el administrador tiene que activarla. Kaspersky lo presenta como un hueco en el proceso, porque los administradores rara vez toman medidas manuales después de parchear.
Microsoft tiene prevista una fase de aplicación obligatoria en la que la revocación se hará de forma automática en los equipos compatibles, sin opción de desactivarla. Su documentación indica que esa fase no empezará antes de enero de 2026 y que se avisará con al menos seis meses de antelación, pero cuando Kaspersky publicó su informe todavía no se había puesto en marcha. Tampoco ayuda la caducidad del certificado, que expiró el 19/10/2026: según los investigadores, eso no impide que se carguen binarios vulnerables firmados con él mientras no figure en la lista de bloqueo del firmware.
Cómo comprobar y aplicar las revocaciones en Windows
Microsoft detalla el procedimiento en el artículo de soporte KB5025885, ligado a la vulnerabilidad CVE-2023-24932. Todo se hace desde una consola de PowerShell con privilegios elevados, modificando el valor AvailableUpdates (REG_DWORD) de la clave de registro HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > Secureboot y ejecutando después la tarea programada Secure-Boot-Update, ubicada en la ruta Microsoft > Windows > PI del Programador de tareas. Los pasos son estos:
- Añadir los certificados de 2023. Con el valor 0x5944 se incorpora el certificado Windows UEFI CA 2023 a la base de datos de firmas permitidas (DB) y se instala el gestor de arranque firmado con él.
- Verificar. El cmdlet Get-SecureBootUEFI permite comprobar que la DB contiene Windows UEFI CA 2023, y el valor UEFICA2023Status de la subclave Servicing debe indicar Updated.
- Revocar PCA 2011. El valor 0x80 añade Windows Production PCA 2011 a la lista de firmas prohibidas (DBX). La consulta de la DBX con Get-SecureBootUEFI debe devolver ese nombre.
- Actualizar el SVN (opcional). El valor 0x200 escribe en el firmware el número de versión seguro, que bloquea la vuelta a gestores de arranque antiguos.
El registro de eventos sirve de control: Microsoft asocia el ID 1036 a la incorporación del certificado de 2023, el 1799 al nuevo gestor de arranque, el 1037 a la revocación de PCA 2011 y el 1042 a la actualización del SVN. La compañía advierte de que, con Secure Boot activo, las revocaciones son irreversibles y no desaparecen al formatear el disco; que los medios de recuperación e instalación antiguos pueden dejar de arrancar si no se actualizan antes, y que algunos equipos pueden entrar en recuperación de BitLocker, por lo que conviene guardar la clave de 48 dígitos. Además, estos pasos son preventivos y no limpian un equipo ya comprometido.
Preguntas frecuentes
¿Qué es BlackX?
Es un bootkit UEFI descubierto por Kaspersky que explota Baton Drop para saltarse Secure Boot e inyectar un controlador malicioso en el núcleo de Windows.
¿Basta con tener Windows actualizado para protegerse de BlackX?
No. Las víctimas tenían todos los parches, pero no habían revocado manualmente el certificado Windows Production PCA 2011.
¿Qué relación tiene BlackX con BlackLotus?
Kaspersky considera que su exploit es muy parecido al de BlackLotus, aunque BlackX usa un controlador y cargas útiles diferentes.
¿La caducidad del certificado PCA 2011 resuelve el problema?
Según Kaspersky, no. Aunque expiró el 19/10/2026, los binarios firmados con él pueden seguir cargándose mientras el certificado no esté incluido en la DBX.
Fuentes:
- Securelist (Kaspersky): informe sobre el bootkit UEFI BlackX
- BleepingComputer: BlackX UEFI bootkit exploits Baton Drop flaw to bypass Secure Boot
- Microsoft: KB5025885, gestión de las revocaciones del gestor de arranque de Windows (CVE-2023-24932)
- Microsoft Tech Community: Revoking vulnerable Windows boot managers
