Cómo APT41 resucitó el bootkit BlackLotus para atacar a organizaciones diplomáticas en Asia Central

Introducción

En octubre de 2022, Kaspersky GReAT investigaba un anuncio peculiar que se había publicado en un foro de underground. Un ciberdelincuente ofrecía por 5000 dólares un bootkit UEFI, bautizado BlackLotus, capaz de eludir Secure Boot. Como el precio parecía demasiado bajo para una herramienta con capacidades tan potentes, al principio la comunidad de ciberseguridad tomó el anuncio con cierto escepticismo. Dado que no se habían encontrado muestras de BlackLotus en circulación, en ese momento nadie podía verificar las afirmaciones de la publicación del foro.

Anuncio de BlackLotus

Sin embargo, cerca de medio año después, en marzo de 2023, ESET confirmó que el anuncio de BlackLotus no era engañoso. Los investigadores lograron rastrear muestras de este bootkit y comprobar que, en efecto, puede eludir Secure Boot mediante una vulnerabilidad llamada Baton Drop (CVE-2022-21894). Como en 2023 esta vulnerabilidad todavía podía explotarse, Microsoft tuvo que publicar varias actualizaciones de seguridad para corregirla.

Desde que se publicaron esas actualizaciones, el bootkit BlackLotus quedó en silencio: no se conocen públicamente ataques que lo hayan utilizado. Sin embargo, a principios de 2026, descubrimos una muestra de malware similar a BlackLotus, que se utilizó en una campaña APT en Asia Central. En este informe compartimos los detalles de nuestros hallazgos, incluidos los nuevos payloads y la posible atribución de esta campaña.

El regreso del tristemente célebre bootkit

A principios de 2026 identificamos un complejo ataque APT dirigido a organismos diplomáticos de países de Asia Central, en concreto Tayikistán, Uzbekistán y Turkmenistán. En el ataque intervenía un bootkit UEFI al que llamamos BlackX. Tras examinarlo, determinamos que es similar a BlackLotus.

Los atacantes desplegaban BlackX después de haber comprometido previamente las redes de las máquinas víctima, en las que habían logrado obtener privilegios de administrador. Para instalar el bootkit, constatamos que guardan los siguientes archivos:

• inst.exe, un ejecutable instalador;
• PVMDIJGKAX2, un archivo sin extensión cifrado con RC4 que contiene los archivos y strings necesarios para la instalación.

El instalador se ejecutaba con la línea de comandos C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1. El último argumento es la clave RC4 utilizada para el descifrado.

Curiosamente, el archivo inst.exe no contiene strings maliciosos ni blobs incrustados. Todos los archivos necesarios para instalar el payload malicioso se encuentran dentro de PVMDIJGKAX2, lo que dificulta que los equipos de respuesta a incidentes recuperen los componentes del bootkit.

El paquete de instalación guarda un conjunto de archivos, diseñados para explotar la vulnerabilidad Baton Drop, tanto en la partición del sistema como en la partición UEFI. Observamos que la implementación del exploit es muy similar a la utilizada en el malware BlackLotus. Al igual que en el caso de BlackLotus, el objetivo del exploit es instalar claves de propietario de la máquina (Machine Owner Keys, MOK) personalizadas, para poder cargar archivos EFI arbitrarios en las máquinas objetivo y así manipular Secure Boot.

Si bien la cadena de explotación de la vulnerabilidad se implementó de una forma muy parecida a la de BlackLotus, detectamos diferencias entre los exploits de BlackLotus y los de BlackX. Dicho esto, el código fuente del bootkit BlackLotus nunca se ha publicado en línea. Esto podría significar que los atacantes detrás de BlackX aplicaron ingeniería inversa al bootkit BlackLotus o bien compraron su código fuente a ciberdelincuentes. En cualquier caso, se trata de una observación interesante, ya que rara vez vemos a actores APT tomar prestadas ideas o código de actores del cibercrimen.

Payload ejecutado por el bootkit

El payload UEFI que se entrega durante la explotación de Baton Drop tiene el objetivo clásico de un bootkit: inyectar un controlador malicioso en el kernel de Windows. Este controlador es distinto del que despliega BlackLotus y está firmado con un certificado perteneciente a una organización llamada 温江区明宇网络技术服务工作室 (Estudio de Servicios de Tecnología de Redes Mingyu del Distrito de Wenjiang). Al momento de escribir este artículo, este certificado (número de serie: 0bcdf5e0da32d68900b8b7638459d072) ya había sido revocado por su emisor.

El objetivo de este controlador es manipular las soluciones de seguridad instaladas en el equipo. Por ejemplo, desactiva los callbacks de procesos, hilos y registros relacionados con las soluciones de seguridad. También manipula los proveedores de ETW para que las soluciones de seguridad no puedan acceder a su salida. Lo curioso es que algunos de los procedimientos de manipulación están diseñados para ejecutarse solo si en el equipo infectado están instaladas soluciones de Kaspersky o de Avast. Sin embargo, durante el análisis dinámico de este controlador, observamos que esos procedimientos son inútiles: no logran interferir de ninguna manera con los productos de Kaspersky.

Otro aspecto importante es que el controlador protege los archivos relacionados con el bootkit contra cualquier manipulación. Intercepta las solicitudes del kernel para abrir estos archivos y devuelve un identificador (handle) de calc.exe en lugar del identificador del archivo malicioso.

Payloads de segunda etapa en modo usuario

Además de sabotear las soluciones de seguridad, el controlador también se encarga de desplegar un payload en modo usuario. Observamos dos payloads de este tipo en circulación, que se utilizan para ciberespionaje. Uno de ellos es un RAT (troyano de acceso remoto) capaz de cargar payloads .NET de etapas posteriores. Este RAT utiliza almacenamientos en la nube para comunicarse con el servidor C2: observamos versiones que recurrían a Google Drive, OneDrive y también a Yandex.Disk. Una vez conectado al almacenamiento en la nube, el RAT recorre los archivos disponibles allí y los interpreta según el sufijo del archivo. A continuación, se muestra la lista de sufijos admitidos:

Además, observamos otro payload que se entregaba a través del bootkit y al que llamamos OxiDLLRunner. Se trata de una DLL maliciosa ofuscada con OLLVM. Esta es cargada por el archivo legítimo googleupdate.exe (nombre de archivo original: jcef_helper.exe, MD5: AF8A983B9ADA07EAE1259BF2953ABD40), que también entrega el bootkit. La DLL descifra el contenido del archivo v8_context_snapshot.bin, ubicado en la misma carpeta, y luego salta al inicio del contenido descifrado.

Los datos descifrados consisten en un shellcode al comienzo, seguido de un archivo PE (Portable Executable), que es un payload en Rust diseñado para comunicarse con el servidor C2 www[.]archivetj[.]com. Durante la comunicación, este payload debe recibir archivos DLL que exportan una función llamada create_plugin, los cuales se ejecutan luego en hilos independientes.

Atribución

Con base en los siguientes hechos, atribuimos este ataque al actor de amenaza APT41, con un grado de confianza medio:

• En junio de 2026, ESET publicó una entrada de blog sobre los ataques del actor de amenaza FishMonger, que la comunidad considera relacionado con APT41. La publicación describe un implante de kernel con una ruta PDB que comienza con C:\Users\xdd\Desktop. Al describir la campaña, la publicación también sugiere el posible uso de un componente de bootkit UEFI no identificado, que podría explotar CVE‑2023‑24932. Observamos que el identificador “xdd” se usa varias veces en los payloads del bootkit BlackX, por lo que estimamos que BlackX es el bootkit UEFI al que hace referencia la entrada de blog de ESET;
• Los payloads que despliega BlackX se cargan con ayuda de un ejecutable legítimo del que se abusa mediante DLL sideloading, junto con un archivo cifrado; este patrón es habitual entre los actores de amenaza de habla china;
• El archivo OxiDLLRunner fue ofuscado con OLLVM, un ofuscador que suelen utilizar los actores de habla china.

¿Por qué se infectaron las organizaciones objetivo?

Cuando hicimos el análisis inicial de BlackX, pensamos que los atacantes habían logrado desplegarlo por negligencia de las organizaciones objetivo. Baton Drop, la vulnerabilidad utilizada para desplegar BlackX, se dio a conocer en 2023 y fue parcheada, así que al principio supusimos que las máquinas infectadas no tenían instaladas las actualizaciones correspondientes. Sin embargo, nuestra investigación demostró lo contrario: las máquinas atacadas estaban completamente actualizadas.

En cambio, descubrimos que el problema estaba en el propio parche. Según averiguamos, el parche para la vulnerabilidad Baton Drop está diseñado para revocar el certificado “Windows Production PCA 2011”, utilizado para firmar los componentes UEFI vulnerables. Sin embargo, esta revocación no ocurre de forma automática al instalar el parche: el usuario tiene que activarla manualmente. Los pasos para hacerlo son los siguientes:

• Se establece un flag en el registro dentro de HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot;
• Se crea una tarea programada llamada Secure-Boot-Update.

Este parche fue concebido para aplicarse de forma manual: por ejemplo, aplicarlo de forma automática podría inutilizar sistemas de arranque dual que dependen del certificado “Windows Production PCA 2011” para iniciarse. Al mismo tiempo, esta práctica de despliegue de parches genera un problema, ya que es muy inusual que un administrador de sistemas tenga que realizar acciones adicionales después de instalar una actualización. Por lo general, al aplicar parches, los administradores de sistemas no realizan ninguna acción adicional relacionada con ellos, a menos que se produzca un error de instalación. Las instrucciones mencionadas para activar el parche están ocultas en las secciones más profundas del sitio web de Microsoft y, en nuestra opinión, son bastante difíciles de encontrar para un administrador de TI promedio.

Lo curioso es que el plan de Microsoft para desplegar los parches relacionados con Baton Drop menciona una “fase de aplicación obligatoria” (Enforcement Phase) que implica revocar de forma automática el certificado “Windows Production PCA 2011”, sin intervención del usuario. Al momento de la publicación de este artículo, esta etapa aún no se había implementado. El certificado caducó el 19 de octubre 2026; sin embargo, esto no impide que se carguen los binarios vulnerables, a menos que el certificado se encuentre en una lista de bloqueo.

Es probable que el actor amenaza responsable de esta campaña haya llegado a la conclusión de que fueron pocas las organizaciones que comprendieron la importancia de activar a mano el parche de Baton Drop. Por eso, creemos que los atacantes decidieron invertir tiempo en entender cómo funciona BlackLotus y crear una imitación de este bootkit.

Conclusión

La gestión de parches es importante para toda organización, ya que las actualizaciones de los proveedores ayudan a proteger el software y el hardware frente a vulnerabilidades conocidas. Sin embargo, a veces los parches, una vez instalados, no brindan protección contra las fallas que pretenden corregir. La historia de BlackLotus que describimos no es el único ejemplo de este tipo: en 2025, por ejemplo, Microsoft publicó una actualización contra la vulnerabilidad ToolShell que también debía aplicarse manualmente.

No obstante, las soluciones de seguridad modernas están diseñadas para mitigar los casos en los que los parches instalados, por una u otra razón, no protegen contra las fallas de seguridad. Por ejemplo, el componente Prevención de exploits disponible en los productos de Kaspersky impide la ejecución de exploits si el parche no está aplicado o si se trata de una vulnerabilidad de día cero para la que no existe un parche. Por lo tanto, es fundamental equipar todas las máquinas de la organización con soluciones de seguridad y ser constantes en el monitoreo de las alertas que estas generan.