BlackX: el bootkit UEFI que burla Secure Boot en Windows

BlackX: el bootkit UEFI que atravesó Windows con todos los parches al día

Los equipos comprometidos por BlackX tenían instaladas todas las actualizaciones que Microsoft publicó para cerrar la vulnerabilidad que el malware explota: la de 2022, la de 2023 y la de 2024. Aun así, el bootkit logró ejecutar código antes de que Windows terminara de cargar y antes de que la mayoría de las defensas de seguridad estuvieran operativas. Para cualquier founder que gestione endpoints, servidores o portátiles de equipo, la lección es incómoda: un sistema «totalmente parcheado» no es lo mismo que un sistema mitigado.

El caso lo reportó Ars Technica, y el análisis técnico detrás proviene del informe de Kaspersky, que atribuyó con confianza media la campaña a APT41, un grupo vinculado a China. Los objetivos fueron organismos diplomáticos de Asia Central. Pero el hallazgo técnico es lo que debería preocupar a cualquier empresa: el fallo no está en un parche faltante, sino en un paso manual que casi nadie ejecuta.

Qué es un bootkit UEFI y por qué es tan difícil de detectar

UEFI (Unified Extensible Firmware Interface) es el firmware que se ejecuta inmediatamente después de encender el equipo. Se encarga de cargar la configuración del sistema, identificar e inicializar el hardware y preparar el arranque del sistema operativo.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Dentro de UEFI vive Secure Boot, el mecanismo que establece una cadena de confianza: verifica la firma digital de cada pieza de software de arranque antes de permitirle ejecutarse. Uno de esos componentes es el boot manager, alojado en una partición pequeña y dedicada del disco, y responsable de la carga inicial del sistema operativo.

Un bootkit ataca justo ahí, por debajo del sistema operativo. Por eso es tan difícil de ver: cuando el antivirus o el EDR arrancan, el atacante ya está dentro y puede haber manipulado el entorno. Microsoft lo describió con precisión cuando apareció BlackLotus, según recogió The Hacker News: el bootkit es «principalmente un mecanismo de persistencia y evasión de defensas», no un vector de acceso inicial. Solo puede desplegarse en un equipo donde el atacante ya tiene privilegios de administrador o acceso físico.

El fallo «Baton Drop» que BlackX heredó de BlackLotus

Tanto BlackLotus como BlackX explotan «Baton Drop», un fallo de lógica en el boot manager de Windows que permite saltarse Secure Boot y, bajo ciertas condiciones, extraer las claves de cifrado de BitLocker. Está catalogado como CVE-2022-21894 (puntaje CVSS 4.4) y salió a la luz en 2022.

Microsoft corrigió la vulnerabilidad ese mismo año, pero no revocó la confianza en el certificado usado para firmar los boot managers antiguos y vulnerables. BlackLotus explotó exactamente ese hueco y cargó un driver malicioso en modo kernel.

La cronología del malware original ayuda a dimensionar el problema. BlackLotus se anunció en foros de cibercrimen a fines de 2022 —según Arabian Post, por US$5.000— y ESET confirmó su existencia y capacidades en marzo de 2023, cuando se convirtió en el primer bootkit UEFI documentado públicamente capaz de burlar Secure Boot en sistemas Windows 11 completamente actualizados.

BlackX es, según la evaluación de Kaspersky, una versión actualizada de ese bootkit. Su implementación del exploit es «notablemente similar»: instala Machine Owner Keys (MOK) controladas por el atacante para cargar archivos EFI arbitrarios. La diferencia es que el código fuente completo de BlackLotus nunca se publicó —la filtración de julio de 2023 fue incompleta—, así que los investigadores creen que el operador de BlackX o bien hizo ingeniería inversa del original o compró su código.

El parche que no se activa solo: la brecha que quedó abierta

Acá está el núcleo del caso. El parche de Baton Drop está diseñado para revocar el certificado «Windows Production PCA 2011», usado para firmar componentes UEFI vulnerables. Pero, como explicó Kaspersky, esa revocación no ocurre automáticamente al instalar la actualización: el administrador tiene que activarla a mano, por ejemplo agregando el certificado a la lista de prohibidos de Secure Boot (DBX).

Kaspersky lo llama directamente una brecha en el proceso de actualización, porque es muy poco común que un administrador ejecute acciones manuales después de aplicar un parche. Los atacantes lo sabían: «es probable que el actor de amenaza haya tenido en cuenta que pocas organizaciones comprendían la importancia de activar manualmente el parche de Baton Drop», señalaron los investigadores.

Hay un detalle contraintuitivo que agrega urgencia: el certificado expiró el 19 de octubre de 2026, pero eso no impide que los binarios vulnerables sigan cargándose. La expiración no equivale a una lista negra. Si el certificado no está bloqueado explícitamente, la puerta sigue abierta.

Quién está detrás de BlackX y a quién apuntó

La campaña se detectó a comienzos de 2026 y apuntó a entidades diplomáticas de Tayikistán, Uzbekistán y Turkmenistán. Kaspersky atribuyó la operación a APT41 con confianza media y señaló que sus productos bloquearon un intento de compromiso, aunque no divulgó las instituciones afectadas ni la cantidad de equipos alcanzados.

El vínculo con APT41 se apoya en parte en un informe de ESET de junio de 2026 sobre FishMonger y su backdoor SprySOCKS, usado contra entidades gubernamentales de Honduras, Taiwán, Tailandia y Pakistán entre 2023 y 2024. ESET reconoció similitudes con BlackX —la posible explotación de Baton Drop, el identificador «xdd» y el actor alineado con China— pero aclaró que no puede confirmar ni descartar una conexión directa sin comparar las muestras.

Más allá de la atribución, el arsenal es el de un espía paciente. El driver malicioso de BlackX está firmado con un certificado de Wenjiang District Mingyu Network Technology Service Studio, ya revocado, y manipula Event Tracing for Windows (ETW) y callbacks de registro para cegar al monitoreo. Algunas rutinas solo se activan si detectan productos de Kaspersky o Avast. Y hay un detalle casi burlón: el driver intercepta los intentos de abrir sus propios archivos y, en su lugar, lanza la Calculadora de Windows.

Los payloads de espionaje usan Google Drive, OneDrive y Yandex.Disk como canales de mando y control, para mezclarse con el tráfico corporativo normal. Un segundo componente, OxiDLLRunner, se carga mediante el binario legítimo googleupdate.exe y descarga plugins desde archivetj[.]com.

¿Es Microsoft la responsable?

La pregunta es justa y la respuesta es matizada. Microsoft documentó el paso manual y publicó las instrucciones para completar la mitigación. Hay además una razón de fondo para que la revocación no sea automática: según Arabian Post, puede interferir con sistemas que dependen de componentes de arranque antiguos. Una revocación masiva y silenciosa podría dejar fuera de servicio equipos legítimos.

Del otro lado, Kaspersky sostiene que dejar la mitigación en manos de una acción manual es un diseño defectuoso, porque la expectativa razonable de cualquier equipo de TI es que instalar el parche cierre el agujero. El resultado práctico es el peor de los dos mundos: la organización cree estar protegida, el panel de actualizaciones dice que todo está al día, y la vulnerabilidad sigue explotable.

Para un founder, la conclusión no es culpar a un proveedor, sino cambiar la métrica. «Parcheado» es un estado del sistema de actualizaciones. «Mitigado» es un estado del equipo. No son lo mismo, y la diferencia puede costar meses de espionaje silencioso.

Qué significa esto para tu startup

Si tu empresa corre Windows en endpoints, servidores o portátiles de ingeniería, esto te toca directamente. Estas son las acciones concretas:

Verifica la revocación, no el registro de parches. Revisa si el certificado «Windows Production PCA 2011» está efectivamente en la lista DBX de Secure Boot. Que el historial de Windows Update esté limpio no prueba nada.
Aplica la revocación manual en un piloto primero. Agregar el certificado a la lista de prohibidos puede romper equipos que dependen de componentes de arranque antiguos. Prueba en un grupo reducido antes de desplegar en toda la flota.
Trata el firmware como superficie de ataque. Si sospechas de un bootkit, reinstalar el sistema operativo no alcanza: hay que reflashear el firmware UEFI. Incluye ese procedimiento en tu plan de respuesta a incidentes.
Reduce el acceso de administrador. BlackX necesita privilegios de admin o acceso físico para instalarse. Cada cuenta con permisos elevados que elimines reduce la superficie.
Vigila los canales de C2 «legítimos». El RAT de BlackX usa Google Drive, OneDrive y Yandex.Disk. Si tu política de seguridad bloquea servicios de nube a ciegas, revisa si esa regla cubre también el tráfico saliente hacia ellos.
Si vendes software o hardware, revisa tu cadena de suministro. Un bootkit que se instala antes del sistema operativo es, en la práctica, un problema de integridad de la cadena de arranque de tus productos.

Conclusión

BlackX no inventó nada nuevo: tomó una vulnerabilidad de 2022, la combinó con un paso de mitigación que casi nadie ejecuta y la convirtió en una herramienta de espionaje persistente. Eso es lo que debería inquietar. Los atacantes sofisticados no necesitan un zero-day cuando existe un parche que nadie terminó de activar.

Para las startups hispanohablantes, sobre todo aquellas con funciones de TI compartidas o sin un responsable de seguridad dedicado, la prioridad es simple: auditar hoy si las revocaciones de Secure Boot están aplicadas. Es una tarea de minutos que cierra una puerta que lleva abierta desde 2022.