BlackX, bootkit UEFI, ataca misiones diplomáticas de Tayikistán, Uzbekistán y Turkmenistán

En las primeras semanas de 2026, organizaciones diplomáticas en Asia Central —concretamente en Tayikistán, Uzbekistán y Turkmenistán— fueron atacadas con un nuevo bootkit UEFI al que los investigadores de Kaspersky han bautizado como BlackX. Según el informe técnico publicado por la firma rusa, el objetivo principal de este malware es socavar las defensas de arranque de Windows y desactivar o eludir soluciones de seguridad de terceros para mantener acceso persistente y encubierto a equipos de alto valor.

Los hechos confirmados por Kaspersky son los siguientes: BlackX actúa a nivel de firmware UEFI, instala componentes tanto en la partición del sistema como en la partición UEFI, explota una vulnerabilidad conocida en Secure Boot (CVE‑2022‑21894, la llamada “Baton Drop”) y entrega un payload de kernel que inyecta un driver firmado fraudulentamente y un conjunto de cargas útiles en espacio de usuario dedicadas a espionaje y control remoto. La firma observó archivos concretos usados en la instalación —por ejemplo, un ejecutable instalado en C:\ProgramData\Intel\inst.exe y un archivo cifrado usado como paquete— y procedimientos de ejecución con claves RC4 que permiten la descompresión y escritura de componentes en disco.

Técnicamente, BlackX retoma la misma técnica que el bootkit BlackLotus: añadir claves (MOK, Machine Owner Keys) o cargar binarios EFI antes de que el sistema operativo inicie, de modo que el código malicioso se ejecute con privilegios muy tempranos y pueda interferir con Secure Boot y mecanismos antimalware. La explotación de CVE‑2022‑21894 permite precisamente cargar binarios no autorizados en esa fase. Es importante subrayar que la explotación no es trivial: para desplegar un bootkit ampliamente el atacante necesita privilegios administrativos en la máquina o acceso físico al equipo; por tanto, BlackX se usa como mecanismo de persistencia y evasión después de un compromiso inicial, no como vector inicial, algo ya señalado por Microsoft cuando se documentó BlackLotus.

Qué hace el código tras la carga: el componente UEFI instala un driver de kernel firmado con un certificado perteneciente a una entidad que posteriormente fue revocada, e intenta alterar el funcionamiento de soluciones de seguridad en el sistema (con rutinas específicas para productos de Kaspersky y Avast, que Kaspersky considera ineficaces en la muestra analizada). Además, el paquete incluye cargas en espacio de usuario: un troyano de acceso remoto que puede descargar módulos .NET y usar servicios legítimos de sincronización en la nube como Google Drive, OneDrive y Yandex.Disk como canales de mando y control para camuflar el tráfico, y una DLL maliciosa (sideloaded por googleupdate.exe) que ejecuta un binario en Rust que contacta a un dominio remoto para recibir plugins adicionales.

La atribución técnica es parcial y cautelosa: Kaspersky vincula la campaña a un actor con metodologías consistentes con ataques patrocinados por China, y asocia BlackX con APT41 basándose en solapamientos técnicos y tácticos y en análisis cruzados con reportes previos. ESET, por su parte, ha documentado familias y operaciones bajo el paraguas de APT41 (FishMonger/Aquatic Panda) que usaron backdoors como SprySOCKS y, en ocasiones, componentes UEFI. Estas conexiones son, sin embargo, estimaciones basadas en indicadores y patrones de comportamiento: la atribución a un actor estatal sigue siendo una inferencia forense, no una prueba irrefutable.

Por qué algunos sistemas siguen siendo vulnerables aunque estén "parcheados": la vulnerabilidad CVE‑2022‑21894 tiene un parche, pero mitigaciones adicionales requieren pasos manuales para añadir y bloquear certificados en la lista de bloqueo de Secure Boot (DBX). Kaspersky señala que muchos administradores no realizaron esas acciones manuales —por ejemplo, añadir la CA usada por ciertos binarios a la lista prohibida—, y por eso BlackX puede seguir siendo efectivo incluso en máquinas con actualizaciones aplicadas. Para detalles sobre la protección del proceso de arranque y gestión de DBX, Microsoft mantiene documentación técnica de referencia: Microsoft Secure Boot guidance.

Consecuencias prácticas: la presencia de un bootkit como BlackX en un entorno diplomático significa control persistente por debajo del sistema operativo, dificultad superior para detectar la intrusión con herramientas tradicionales, y riesgo real de espionaje continuado (recopilación de archivos, exfiltración discreta, movimientos laterales con credenciales comprometidas). Además, si los binarios maliciosos quedan inscritos en el firmware o se añadieron claves MOK, una simple reinstalación del sistema operativo no garantiza la remediación; la infección puede sobrevivir a un formateo sin intervención a nivel de firmware.

Qué es seguro y qué no está confirmado: está confirmado que Kaspersky observó la campaña contra misiones diplomáticas en los países citados y que el bootkit reutiliza la técnica de BlackLotus para evadir Secure Boot. Es una estimación razonable, apoyada por análisis de ESET, que actores asociados a APT41 están detrás, pero la atribución completa puede contener incertidumbres y depende de correlaciones de indicadores y metodologías. También se desconoce públicamente si el código original de BlackLotus fue comprado o replicado por ingeniería inversa; ambos escenarios son plausibles y mencionados por los expertos.

Recomendaciones concretas e inmediatas para administradores y responsables de seguridad:

1) Auditar y aplicar la mitigación de DBX/Forbidden List: además de instalar todos los parches de Windows, ejecute los pasos manuales recomendados por Microsoft para gestionar la lista de certificados bloqueados en Secure Boot y garantizar que certificados comprometidos no permitan la carga de binarios maliciosos (ver la guía de Microsoft arriba).

2) Revisar la integridad del firmware y particiones UEFI: use herramientas forenses y de integridad como CHIPSEC (https://github.com/chipsec/chipsec) para detectar modificaciones en la partición EFI, claves añadidas (MOK) o binarios inesperados en el arranque.

3) Si hay sospecha de compromiso, aislar y forensear antes de reparar: imágenes de disco offline, volcado de memoria, y análisis de la partición UEFI deben preceder a cualquier reinstalación. En entornos diplomáticos de alto riesgo considere reflasheo de firmware por proveedores confiables y reinstalación completa desde medios verificados.

4) Revisar privilegios y vectores de acceso inicial: dado que el despliegue requiere privilegios elevados o acceso físico, investigue cómo los atacantes obtuvieron esos privilegios (phishing, credenciales expuestas, explotación de servicios, acceso físico) y aplique mitigaciones: rotación de contraseñas, autenticación multifactor, segmentación de redes, revisión de cuentas con privilegios y control de acceso físico.

5) Monitorizar tráfico saliente y actividades inusuales en servicios en la nube: BlackX utiliza servicios legítimos de sincronización como C2; audite uso de cuentas en Google Drive, OneDrive y Yandex.Disk, y establezca políticas de control y alertas para accesos no habituales.

Las amenazas a nivel UEFI elevan el listón técnico de la respuesta y obligan a que las organizaciones de alta exposición replanteen sus procesos de gobernanza sobre firmware, parches y listas de confianza. Para comprender el contexto y antecedentes técnicos del vector original BlackLotus conviene revisar el análisis de ESET publicado en 2023 sobre ese bootkit: ESET — BlackLotus analysis. Para referencias de CVE y detalles técnicos de las vulnerabilidades citadas, consulte las fichas oficiales en NVD: CVE‑2022‑21894 y CVE‑2023‑24932.

En resumen, BlackX es un resurgimiento y adaptación de una técnica de alto impacto que obliga a dejar de lado soluciones superficiales (solo aplicar el parche) y a asumir un enfoque forense y de firmware completo. Para organizaciones diplomáticas y otras instituciones críticas, la prioridad debe ser comprobar la integridad del arranque y cerrar los vectores que permitieron el ingreso inicial del atacante.