LA EDICIÓN DEL 4 DE NOVIEMBRE DE 2026
BlackX revela los límites de los parches de Windows frente a los ataques al arranque
Según Ars Technica, BlackX eludió Secure Boot en sistemas Windows que habían recibido los parches correspondientes. Las actualizaciones permiten revocar la confianza en el certificado de los antiguos gestores de arranque vulnerables, pero su instalación no siempre basta para activar esta protección.
Información legal: este contenido ha sido producido por un sistema de inteligencia artificial. Transparencia editorial
El caso BlackX pone de manifiesto una brecha entre los parches instalados y la protección activada durante el arranque de Windows. Según Ars Technica, algunas organizaciones fueron infectadas pese a contar con las actualizaciones correspondientes. Revocar la confianza en el certificado de los antiguos gestores de arranque vulnerables sigue requiriendo una intervención adicional de los administradores.
Instalar los parches correspondientes no bastó para proteger a las organizaciones afectadas por BlackX. En un artículo publicado el 3 de noviembre, Ars Technica describe cómo este programa malicioso eludió Secure Boot pese a esas actualizaciones. El problema reside en que se sigue confiando en antiguos gestores de arranque vulnerables, cuyo bloqueo requiere una acción adicional tras instalar los parches.
Secure Boot comprueba las firmas digitales del software que se ejecuta durante el arranque para impedir la carga de código no autorizado. BlackX y su predecesor BlackLotus explotan una vulnerabilidad del gestor de arranque de Windows, conocida como Baton Drop y registrada como CVE-2022-21894. Microsoft corrigió esta vulnerabilidad en 2022, sin revocar de inmediato la confianza en el certificado que firmaba las antiguas versiones vulnerables. Por tanto, estas todavía podían utilizarse para eludir la protección.
La respuesta se desarrolló después por etapas. En 2023, Microsoft introdujo un nuevo certificado de firma. En 2024, otra actualización proporcionó los medios para incluir el antiguo certificado en la base de datos de firmas prohibidas de Secure Boot. Según Ars Technica, las organizaciones infectadas por BlackX habían instalado estos parches, pero la revocación necesaria no se había impuesto automáticamente.
Esta decisión responde a un riesgo concreto: bloquear el antiguo certificado antes de instalar el nuevo puede impedir que una máquina arranque. Sin embargo, deja en manos de los administradores una operación adicional. Kaspersky, que descubrió las infecciones de BlackX, considera que las instrucciones para activar esta protección son difíciles de encontrar. Por su parte, Microsoft remite a sus clientes a su documentación, informa Ars Technica.
El alcance del ataque debe delimitarse con precisión. Un bootkit requiere que los atacantes hayan comprometido previamente el dispositivo. Su utilidad consiste después en ejecutarse en una fase muy temprana, antes que muchas defensas de Windows, y cargar controladores maliciosos en el núcleo. También puede sobrevivir a una reinstalación del sistema si la partición de arranque infectada permanece intacta. El artículo no aclara la situación de los usuarios particulares.
La lección operativa va, por tanto, más allá de la mera disponibilidad de un parche. En este caso, comprobar que las actualizaciones están instaladas no permite concluir que los antiguos componentes vulnerables se rechacen efectivamente durante el arranque. El incidente ilustra la necesidad de distinguir entre la corrección de una vulnerabilidad, los medios para bloquear sus versiones antiguas y la activación real de ese bloqueo, teniendo en cuenta el riesgo de dejar las máquinas inutilizables.