Un ataque con el bootkit UEFI BlackX apuntó a organizaciones con sistemas Windows actualizados, pero Kaspersky informó que logró prevenirlo. La investigación pone el foco en la diferencia entre instalar parches y completar la mitigación de certificados vulnerables.
***
- Un ataque con BlackX apuntó a organizaciones que habían instalado actualizaciones de Windows; Kaspersky dijo que logró prevenirlo.
- La corrección de CVE-2022-21894 no revocó por sí sola la confianza en todos los gestores de arranque vulnerables.
- Kaspersky señaló que las instrucciones para activar una protección adicional podían pasar inadvertidas para administradores de sistemas.
🚨 BlackX apuntó a equipos Windows actualizados
El bootkit UEFI buscó eludir Secure Boot en organizaciones de Asia Central. Kaspersky informó que bloqueó el ataque.
Instalar parches no siempre completa la mitigación: algunos equipos requieren medidas adicionales para revocar la… pic.twitter.com/G7Y33x2zWL
— Diario฿itcoin (@DiarioBitcoin) November 3, 2026
Organizaciones diplomáticas de Asia Central fueron blanco de un ataque con BlackX, un bootkit UEFI diseñado para eludir Secure Boot antes de que Windows termine de cargarse. Kaspersky informó que sus soluciones de seguridad lograron prevenir el ataque. Según la investigación, los equipos afectados por la campaña ya tenían instaladas actualizaciones de Windows, pero eso no necesariamente completaba todos los pasos para bloquear gestores de arranque vulnerables.
El caso, reportado por Ars Technica a partir de una investigación de Kaspersky, no significa que cualquier equipo actualizado esté infectado ni que instalar actualizaciones carezca de valor. La diferencia está en una medida adicional que algunos administradores debían activar para retirar la confianza en certificados antiguos. Si ese paso no se ejecutaba, la cadena de arranque podía conservar una vía de ataque que los parches pretendían cerrar.
Una amenaza que se activa antes de Windows
UEFI es el firmware que toma el control inmediatamente después de encender una computadora y prepara el hardware para iniciar el sistema operativo. Entre sus funciones figura Secure Boot, una protección que verifica las firmas digitales de componentes esenciales y busca impedir que se ejecute software de arranque no autorizado, incluso antes de que Windows y buena parte de sus defensas estén activos.
Uno de esos componentes es el gestor de arranque, almacenado en una partición específica del disco y encargado de iniciar el sistema operativo. Si un atacante consigue que la computadora ejecute una versión vulnerable de ese gestor, puede alterar la cadena de confianza desde una etapa muy temprana. Esa posición permite cargar código malicioso en el núcleo de Windows antes de que entren en funcionamiento muchas herramientas de seguridad.
Los bootkits UEFI requieren que el atacante comprometa primero el dispositivo, pero ofrecen ventajas que los vuelven atractivos: pueden resultar difíciles de detectar sin herramientas especializadas y, si la partición de arranque permanece intacta, sobrevivir a una reinstalación de Windows. Su combinación de sigilo, persistencia y acceso profundo al sistema explica por qué el caso de BlackLotus fue importante: convirtió en una amenaza práctica la posibilidad de eludir Secure Boot.
BlackLotus se conoció públicamente en 2023 como el primer bootkit UEFI documentado que operaba en entornos reales y podía esquivar Secure Boot en equipos con Windows 11 completamente actualizado. Tanto ese malware como BlackX aprovechan Baton Drop, un fallo lógico en el gestor de arranque de Windows identificado como CVE-2022-21894. Bajo ciertas condiciones, la vulnerabilidad también puede permitir extraer claves de cifrado de BitLocker.
Los parches no completaban toda la mitigación
Microsoft corrigió la vulnerabilidad subyacente en 2022, pero esa reparación no revocó de inmediato la confianza en los gestores de arranque antiguos firmados con un certificado que todavía podía validarlos. BlackLotus aprovechó esa brecha para cargar un controlador malicioso en modo kernel. El caso de BlackX vuelve a poner de relieve que corregir el fallo no bastaba para eliminar todas las rutas que dependían de componentes heredados.
En mayo de 2023, dos meses después del descubrimiento público de BlackLotus, Microsoft inició una mitigación gradual. Entre las medidas incorporó el certificado Windows UEFI CA 2023 a la base de datos de confianza de Secure Boot, con el objetivo de permitir el uso de gestores de arranque actualizados y dejar de confiar en versiones vulnerables más antiguas.
En 2024, la empresa presentó otra medida que permitía añadir Windows Production PCA 2011, el certificado antiguo, a la base de datos de firmas prohibidas de Secure Boot. Sin embargo, según el reporte de Ars Technica, esa etapa tampoco revocaba automáticamente la confianza en los gestores vulnerables. La implementación debía avanzar con cautela para evitar que dispositivos sin las actualizaciones necesarias quedaran incapaces de arrancar.
La transición de certificados siguió siendo relevante en 2026. Microsoft informó que los certificados de Secure Boot emitidos en 2011 alcanzaron su vencimiento de 15 años el 19 de octubre de ese año. Esa fecha no permite concluir por sí sola qué medidas de revocación se aplicaron en cada dispositivo, por lo que el estado de cada equipo depende de las actualizaciones y la configuración correspondientes.
Ese equilibrio ayuda a explicar la demora, pero también dejó una diferencia importante entre instalar las actualizaciones y completar la protección. Kaspersky advirtió que muchos administradores suelen considerar terminado el trabajo cuando aplican un parche, salvo que la instalación falle, mientras que las instrucciones para activar esta medida adicional quedaban en documentación de Microsoft y podían ser difíciles de encontrar.
La acción manual y el riesgo que queda
Un investigador de Kaspersky sostuvo que el proceso de despliegue crea un problema práctico porque es poco habitual que un administrador realice pasos adicionales después de instalar una actualización. La firma considera que las instrucciones para activar la protección están enterradas en la documentación de Microsoft y que un profesional de TI promedio podría no advertir su importancia. Esa brecha entre la guía y la rutina de mantenimiento ofrece una explicación de por qué el ataque de BlackX pudo apuntar a sistemas que ya tenían los parches.
Microsoft respondió que aconseja a sus clientes seguir las pautas de una publicación de su Base de Conocimiento difundida dos semanas antes del reporte. No obstante, de acuerdo con la revisión citada por Ars Technica, esa orientación no advertía explícitamente que los parches publicados hasta entonces no protegían por sí solos frente a ataques Baton Drop, ni destacaba que muchos administradores debían realizar una acción adicional descrita en una guía de 2023.
La situación de los usuarios domésticos de Windows no queda clara en la información disponible, por lo que no corresponde asumir que deben seguir exactamente el mismo procedimiento ni que están expuestos en idénticas condiciones. El incidente sí plantea una cuestión general para quienes gestionan equipos: una actualización puede corregir un componente, pero la mitigación completa de una vulnerabilidad de arranque también puede depender de revocar certificados y de que el dispositivo esté preparado para aceptar ese cambio sin perder la capacidad de iniciar.
Kaspersky considera probable que el actor detrás de la campaña supiera que pocas organizaciones habían comprendido la importancia de activar manualmente la protección contra Baton Drop. La firma cree que los atacantes estudiaron el funcionamiento de BlackLotus y desarrollaron un clon de ese bootkit. Se trata de una evaluación de Kaspersky sobre la oportunidad creada por un despliegue incompleto, no de una confirmación de que cada instalación de un parche fallara.
El dilema para Microsoft es técnico y operativo: revocar un certificado antes de que los equipos estén listos podría impedir el arranque de dispositivos, mientras que mantener la confianza en gestores vulnerables puede prolongar una posibilidad de explotación. BlackX pone el foco en una parte menos visible de la seguridad informática: además de publicar correcciones, los proveedores deben explicar con claridad qué acciones faltan y qué riesgos persisten cuando los clientes creen que ya terminaron de actualizar.
Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.
Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.
ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.
Suscríbete a nuestro boletín
Artículos Relacionados
Empresas
Reddit prueba anuncios en sus búsquedas y amplía la presencia de marcas
Estados Unidos
Pedidos de fábricas en EE. UU. registran su mayor avance en más de cuatro años
IA
Netflix prepara una pestaña con recomendaciones temáticas impulsadas por IA
Biohacking
