Sábado, 24 de octubre de 2026

Lo más relevante del hosting en el mundo, en español · ehost.ec →

BlackX: nuevo bootkit UEFI que elude Secure Boot incluso en Windows parcheado

Investigadores de seguridad han identificado BlackX, un bootkit UEFI empleado contra misiones diplomáticas en Asia Central que aprovecha omisiones en las revocaciones de Secure Boot; la campaña fue detectada a principios de 2026 y afecta a sistemas Windows con el parche instalado pero sin medidas manuales adicionales.

Por Equipo ehost3 min de lecturaFuente: The Hacker News
BlackX: nuevo bootkit UEFI que elude Secure Boot incluso en Windows parcheado
Imagen ilustrativa generada con inteligencia artificial.

Kaspersky ha identificado un nuevo bootkit UEFI denominado BlackX que ha sido usado para comprometer equipos de misiones diplomáticas en Asia Central, según su informe técnico. La actividad se observó contra organizaciones diplomáticas en países como Tayikistán, Uzbekistán y Turkmenistán a comienzos de 2026 y, según la firma, presenta similitudes con amenazas previas atribuidas al actor vinculado a China conocido como APT41.

Qué es BlackX y por qué preocupa

BlackX es un bootkit: malware que se instala en el entorno UEFI (la capa de firmware responsable del arranque del sistema) para cargar código antes de que el sistema operativo empiece a ejecutarse. Su propósito principal es persistir en el equipo y evadir mecanismos de defensa al más bajo nivel, incluyendo Secure Boot y soluciones de seguridad de terceros.

Los investigadores señalan que BlackX es conceptualmente una reimplementación de BlackLotus, un bootkit que explotaba una vulnerabilidad de omisión de Secure Boot (conocida como Baton Drop) y que se hizo visible públicamente en 2022–2023. Aunque la vulnerabilidad que permitía la carga previa al arranque había sido parcheada por Microsoft, BlackX aprovecha que muchas organizaciones no aplicaron pasos manuales complementarios necesarios para bloquear binarios firmados por ciertos certificados.

Qué falla exactamente: parches vs. revocaciones

Microsoft publicó correcciones para la vulnerabilidad técnica que explotaba BlackLotus, pero la mitigación completa requiere acciones manuales adicionales sobre la base de datos de firma de Secure Boot (DBX). En concreto, es necesario incluir determinados certificados en la lista prohibida del firmware para impedir la carga de binarios firmados con esos certificados.

Kaspersky explica que los atacantes han aprovechado que muchas instalaciones no añadieron esas revocaciones manuales, de modo que BlackX puede explotar la misma técnica y seguir cargando código malicioso incluso en sistemas con el parche aplicado.

Cómo infecta y qué hace en el sistema

Según el análisis, los operadores de la campaña primero obtienen privilegios de administrador en la máquina víctima mediante métodos no detallados en el informe. Con esos privilegios, instalan un ejecutable desde la partición del sistema y dejan ficheros tanto en la partición del sistema como en la partición UEFI. El bootkit instala claves de propietario de máquina (MOK) y carga binarios EFI arbitrarios para interferir con el proceso de arranque y permitir la ejecución de un cargador malicioso.

Una vez conseguido el control del arranque, BlackX entrega un payload UEFI que inyecta un controlador (driver) malicioso en el kernel de Windows. Ese controlador está firmado con un certificado que luego fue revocado, y su funcionalidad incluye intentos de desactivar o interferir con soluciones de seguridad en el host. Además, el bootkit instala componentes en espacio de usuario destinados a espionaje.

Relación con grupos y técnicas conocidas

Kaspersky y otros equipos de investigación han detectado solapamientos técnicos entre BlackX y herramientas usadas por actores relacionados con APT41, como patrones de carga (DLL sideloading) y ciertas cadenas internas en el código. Los investigadores consideran plausible que el grupo haya adaptado o comprado código de una amenaza delictiva (crimeware) y lo haya evolucionado para sus fines.

Qué deben hacer los administradores y responsables de sitios web

  • Verificar y aplicar revocaciones de Secure Boot (DBX): además de instalar los parches de sistema publicados por Microsoft, es imprescindible seguir las guías oficiales para añadir a la lista prohibida los certificados afectados (por ejemplo, el certificado de producción de Windows que se mencionó en análisis previos) para que el firmware rechace binarios firmados con ellos.
  • Comprobar integridad de UEFI y MOK: auditar la partición EFI y revisar claves instaladas en gestores de arranque (MOK) para detectar entradas no autorizadas.
  • Limitar el acceso privilegiado: reforzar controles de administración, segmentación de red y telemetría para reducir la posibilidad de que un atacante obtenga privilegios locales.
  • Detectar anomalías en arranque y drivers: supervisar eventos de arranque, firmas de drivers y comportamiento de soluciones antimalware; sospechar si aparece un driver firmado por un certificado inusual o revocado.
  • Plan de respuesta y recuperación: en casos de sospecha de compromiso UEFI, considerar procedimientos de recuperación que incluyan reinstalación desde medios fiables y reprogramación/actualización de firmware cuando proceda.

La naturaleza de un bootkit implica que su presencia puede ser persistente y difícil de detectar; la prevención exige parches, revocaciones manuales y controles estrictos de acceso privilegiado.

Los administradores deben priorizar estas acciones en entornos de alto valor —misiones diplomáticas, organismos gubernamentales, infraestructuras críticas y redes con datos sensibles— donde la utilidad de un acceso persistente al arranque es mayor para los atacantes.

Lee también:

Fuente: The Hacker News

Compartir