Introducción
La premisa de que «parchear es suficiente» acaba de recibir un golpe directo en el corazón de la confianza en el arranque seguro de Windows. En una campaña de espionaje activa detectada a principios de 2026, los investigadores de Kaspersky identificaron a BlackX, un bootkit UEFI que logra cargar controladores maliciosos incluso en máquinas que han instalado todas las actualizaciones de seguridad disponibles. El problema no radica en una nueva vulnerabilidad de día cero, sino en un fallo de proceso: la explotación de la vulnerabilidad Baton Drop (CVE-2022-21894) combinada con la inercia administrativa para activar las revocaciones manuales de certificados. Para los equipos de DevOps, SRE y seguridad, esto representa una pesadilla operacional: las defensas perimetrales y el endpoint protection estándar quedan cegados a nivel de kernel antes de que el sistema operativo cargue sus servicios habituales.
Este incidente subraya una brecha crítica en la cadena de suministro de la seguridad del firmware. A pesar de que Microsoft lanzó parches para mitigar Baton Drop hace años, la naturaleza manual de la revocación de la clave «Windows Production PCA 2011» ha dejado una ventana de exposición persistente. Los atacantes de APT41 no necesitaron desarrollar una nueva técnica de bypass; simplemente replicaron y perfeccionaron el método utilizado por BlackLotus, demostrando que la deuda técnica en la gestión de claves de arranque tiene un costo directo en la integridad de las infraestructuras críticas.
Qué ocurrió
BlackX es un bootkit UEFI desplegado en una campaña dirigida a agencias diplomáticas en Asia Central, específicamente en Tayikistán, Uzbekistán y Turkmenistán. El malware explota la vulnerabilidad Baton Drop para inscribir claves de propietario de máquina (MOK) personalizadas en la lista de arranque seguro, permitiendo la carga de archivos EFI maliciosos que de otro modo serían bloqueados por la política de seguridad de la UEFI. Lo más alarmante es que las víctimas comprometidas ejecutaban versiones totalmente actualizadas de Windows 11, lo que confirma que el parche de Microsoft, por sí solo, no cierra la puerta si la revocación del certificado vulnerable no se aplica correctamente en la variable NVRAM del firmware.
La similitud con el bootkit BlackLotus es abrumadora. Los investigadores de Kaspersky señalaron que la implementación del exploit en BlackX es «notablemente parecida» a la de BlackLotus, una herramienta que ha circulado en foros hackers desde octubre de 2022. Sin embargo, BlackX introduce variaciones en el payload de seguimiento y en el controlador del kernel. Existe la sospecha de que el operador de BlackX obtuvo el código fuente original de BlackLotus, ya que el repositorio público filtrado en 2023 estaba incompleto, pero el código faltante en la fuga aparecía en las muestras de BlackX. Esto sugiere un desarrollo basado en ingeniería inversa profunda o en la adquisición de código no público, elevando la sofisticación del ataque por encima de las herramientas genéricas disponibles en el mercado negro.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El impacto principal es la invalidación de la confianza en el arranque de los sistemas operativos. Para los equipos de infraestructura, esto significa que la integridad del sistema desde el POST (Power-On Self-Test) hasta la carga del kernel está comprometida. BlackX despliega un controlador del kernel firmado digitalmente con un certificado revocado emitido a «Wenjiang District Mingyu Network Technology Service Studio». Al cargar este controlador, el malware obtiene privilegios de ring 0, lo que le permite deshabilitar procesos de seguridad, eliminar callbacks del registro y, críticamente, obstruir los proveedores de Event Tracing for Windows (ETW).
La obstrucción de ETW es particularmente devastadora para la observabilidad y la detección de amenazas. Al silenciar los trazadores de eventos, BlackX crea un punto ciego total en los sistemas de monitoreo centralizados como SIEM o plataformas de detección de amenazas en la nube (EDR). Los equipos de SOC no verán alertas de procesos maliciosos porque las fuentes de datos primarias están siendo manipuladas a nivel de kernel. Además, el malware está diseñado específicamente para interferir con soluciones de seguridad de Kaspersky y Avast, aunque el mecanismo de detección de estas soluciones específicas es rudimentario y no funciona contra otros proveedores. Esto implica que, si bien el objetivo inmediato era neutralizar antivirus específicos, la capacidad de ocultamiento general afecta a cualquier solución basada en hooks de usuario o kernel que no utilice métodos de protección alternativos.
Para los arquitectos de cloud, este incidente resalta la importancia de la confianza en la cadena de suministro de las imágenes de máquina virtual y los snapshots. Si una imagen base fue comprometida con este tipo de bootkit a nivel de firmware (en bare metal) o mediante la manipulación de variables UEFI en hipervisores mal configurados, la migración de cargas de trabajo a la nube podría propagar la infección. La dependencia de Secure Boot como garantía de integridad se rompe si la gestión de claves no es proactiva.
Detalles técnicos
La vulnerabilidad subyacente, CVE-2022-21894, conocida como Baton Drop, reside en cómo Windows maneja la revocación de componentes UEFI firmados con el certificado «Windows Production PCA 2011». El parche de Microsoft está diseñado para revocar este certificado, pero la acción de revocación en la variable dbx de Secure Boot no se ejecuta automáticamente durante la instalación del update de Windows. El usuario o el administrador debe invocar manualmente el mecanismo de revocación.
BlackX aprovecha esta inacción. Al no estar presente la entrada de revocación en la NVRAM, el sistema permite la carga de componentes firmados con el certificado vulnerable. Una vez dentro, BlackX inyecta un controlador del kernel que realiza las siguientes acciones:
Es crucial notar que el certificado «Windows Production PCA 2011» tiene una fecha de expiración el 19 de octubre de 2026. Sin embargo, la expiración natural del certificado no impide que los binarios vulnerables carguen en sistemas donde la revocación no se ha aplicado manualmente en la lista dbx.
Qué deberían hacer los administradores y equipos técnicos
La mitigación de este riesgo requiere una acción proactiva que va más allá de Windows Update. Los equipos de infraestructura deben verificar y forzar la revocación de las claves vulnerables en todos los endpoints y servidores bare metal.
Conclusión
El surgimiento de BlackX demuestra que la seguridad del firmware es un frente activo y no un problema resuelto. La explotación de una vulnerabilidad conocida hace años, CVE-2022-21894, sigue siendo viable debido a la complejidad y la falta de automatización en la gestión de claves de arranque seguro. Para los equipos de DevOps y seguridad, el mensaje es claro: la defensa en profundidad debe incluir la validación activa de la integridad de la cadena de arranque. La confianza en que los parches de sistema operativo resuelven todos los riesgos de firmware es una falacia peligrosa. La revocación manual de certificados vulnerables es una tarea crítica de mantenimiento que no puede delegarse a la casualidad.
Fuentes
https://www.bleepingcomputer.com/news/security/blackx-uefi-bootkit-exploits-baton-drop-flaw-to-bypass-secure-boot/