Bootkit UEFI: Bootkitty en Linux y el legado de BlackLotus

Informatec Digital » Linux » Bootkit UEFI: Bootkitty en Linux y el legado de BlackLotus

Los bootkits UEFI se han convertido en uno de los vectores más inquietantes del panorama de amenazas moderno: se ejecutan antes del sistema operativo, pueden desactivar defensas y logran persistencia con privilegios elevados. En los últimos años hemos pasado de meras pruebas de concepto a casos reales activos como BlackLotus en Windows, y ahora aparece el primer diseño orientado a Linux, bautizado como Bootkitty, que abre una nueva etapa para el ecosistema del software libre.

Este artículo recopila y ordena la información clave de múltiples fuentes reconocidas para explicar cómo operan los bootkits UEFI, qué distingue a Bootkitty en Linux, por qué BlackLotus marcó un antes y un después en Windows, qué indicadores de compromiso vigilar y qué medidas defensivas aplicar. Además, se comentan casos relevantes como LoJax, ESPecter, MoonBounce o MosaicRegressor, así como reglas de detección y tácticas MITRE ATT&CK relacionadas.

Qué es un bootkit UEFI y por qué supone un riesgo serio

Un bootkit UEFI es código malicioso que se ejecuta en las primeras fases del arranque, cuando el firmware inicializa el equipo y antes de que el sistema operativo tome el control. Al operar a tan bajo nivel, pueden inhibir mecanismos como la verificación de firmas o la carga de controladores legítimos, desplegar payloads en modo kernel o usuario y mantenerse ocultos frente a buena parte de las contramedidas tradicionales.

Conviene distinguir entre distintos niveles de software malicioso de arranque: los implantes de firmware (ej. LoJax en 2018) modifican directamente el SPI flash, mientras que los bootkits residen normalmente en la partición de sistema EFI (ESP), algo más accesible pero con capacidades similares para tomar el control temprano del proceso de inicio.

La evolución reciente de vulnerabilidades en UEFI y la falta de revocaciones oportunas de binarios defectuosos en la base de revocación (dbx) han facilitado que actores ofensivos puedan abusar de componentes firmados pero vulnerables para eludir Secure Boot, como ocurrió con la explotación de CVE-2022-21894 (Baton Drop) en el caso de BlackLotus.

Contexto histórico: de las PoC en Windows a casos in the wild

La primera gran demostración pública de un bootkit UEFI moderno se remonta a 2012, cuando Andrea Allievi documentó una PoC capaz de operar en entornos Windows con UEFI. A esa línea le siguieron otras pruebas —EfiGuard, Boot Backdoor, UEFI-bootkit— que mostraban la viabilidad técnica del enfoque.

Tras esa primera etapa de experimentación, tardaron años en aparecer amenazas activas en sistemas reales. En 2021 se publicaron ESPecter (investigado por ESET) y el bootkit de FinSpy (analizado por Kaspersky), y en 2023 irrumpió BlackLotus, el primer bootkit conocido en burlar UEFI Secure Boot en equipos totalmente actualizados con Windows 11.

Hasta hace muy poco, todos estos casos tenían un rasgo común: estaban orientados exclusivamente a Windows. Ese paradigma se rompe con el hallazgo de Bootkitty, centrado en Ubuntu y, por tanto, en el mundo Linux.

Bootkitty: primer bootkit UEFI enfocado en Linux

En noviembre de 2024 apareció en VirusTotal una aplicación UEFI desconocida (bootkit.efi) que, tras su análisis, resultó ser Bootkitty, el primer bootkit UEFI diseñado para Linux, en concreto para ciertas versiones de Ubuntu. Según telemetría disponible, no hay evidencias de despliegue in the wild; todo apunta a una prueba de concepto temprana, con múltiples artefactos de desarrollo.

Importante actualización: a comienzos de diciembre de 2024 surgió la confirmación de que se trataba de un proyecto académico desarrollado por participantes del programa coreano Best of the Best (BoB). Su objetivo declarado era concienciar sobre los riesgos y fomentar medidas proactivas. Esta pieza encaja con lo observado por los analistas: un bootkit funcional pero con soporte limitado y señas de PoC, no un arma terminada para campañas masivas.

Compatibilidad, firma y señales de PoC

Bootkitty viene firmado con un certificado autofirmado, de modo que no logra ejecutarse si Secure Boot está activo salvo que se incorporen manualmente certificados del atacante. Aun así, su lógica intenta que el arranque del kernel continúe con normalidad parcheando en memoria funciones de verificación antes de que GRUB ceda el control.

Su compatibilidad es reducida. Para localizar funciones a modificar recurre a patrones de bytes codificados que no abarcan múltiples versiones de kernel o de GRUB, lo que lo vuelve operativo solo en configuraciones concretas y susceptible de provocar cuelgues si el offset no corresponde a la versión presente.

Entre los artefactos de PoC destacan dos rutinas que imprimen en pantalla un ASCII art con el nombre Bootkitty y un listado de posibles autores; además, en el arranque muestra cadenas específicas y referencias como «BlackCat» sin relación con el grupo de ransomware ALPHV/BlackCat. El binario también sobrescribe la cadena de versión y el banner de Linux con el texto “BoB13”.

Cadena de ejecución y hooks en UEFI y GRUB

Al iniciarse, Bootkitty comprueba el estado de SecureBoot leyendo la variable UEFI homónima. A continuación instala ganchos en los protocolos de autenticación de UEFI —EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication y EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState— para forzar EFI_SUCCESS como resultado, anulando la evaluación real de la integridad de imágenes PE UEFI.

Después, carga desde la ESP un GRUB legítimo localizado en la ruta codificada /EFI/ubuntu/grubx64-real.efi (presumiblemente una copia que el atacante depositó). Con GRUB en memoria, sin ejecutarlo todavía, el bootkit parchea y engancha varios puntos críticos, incluidos:

• peimage::start_image (embebido en GRUB), para interceptar el momento en que el stub EFI del kernel (vmlinuz.efi) está cargado en memoria. Desde aquí, Bootkitty localiza y parchea la rutina responsable de la descompresión del kernel, muy probablemente zstd_decompress_dctx dependiendo de la compilación.
• shim_lock_verifier_init, parte de shim_lock en GRUB, aunque el hook aplicado resulta irrelevante porque otro enganche evita que llegue a ejecutarse, y además la modificación introduce el flag GRUB_VERIFY_FLAGS_SINGLE_CHUNK, que en teoría endurece la verificación.
• grub_verifiers_open, que queda alterada para devolver inmediatamente sin invocar comprobaciones de firma, lo que neutraliza el flujo normal de verificación en GRUB.

Hook de descompresión del kernel y parches en memoria

El enganche sobre la descompresión del kernel restaura temporalmente los bytes originales, permite que la función auténtica descomprima la imagen y acto seguido aplica parches en la memoria del kernel ya expandido. Esta fase es crítica para deshabilitar controles y preparar la carga de módulos o binarios adicionales.

Concretamente, la lógica observada reescribe la cadena de versión con “BoB13”, modifica la función module_sig_check para que retorne 0 (así el kernel acepta módulos sin firma aún con Secure Boot activo, con CONFIG_MODULE_SIG_FORCE o con module.sig_enforce=1), y sustituye la primera variable de entorno del proceso init por “LD_PRELOAD=/opt/injector.so /init”.

La idea tras LD_PRELOAD es forzar la carga prioritaria de un ELF compartido para sobrescribir funciones o insertar lógica extra, técnica común en ataques de userland. Llama la atención la presencia de “/init” dentro del valor de LD_PRELOAD; el sentido exacto no resulta del todo claro y refuerza la lectura de que estamos ante un desarrollo temprano.

Durante pruebas de laboratorio, el sistema mostraba el kernel como tainted tras el arranque con Bootkitty; además, en dmesg se aprecian las cadenas retocadas y el rastro de la variable LD_PRELOAD, que también puede verse en /proc/1/environ. En equipos con Secure Boot activo, un indicio empírico es que el kernel acepte cargar un módulo sin firmar en runtime, lo que no debería suceder sin el parcheo previo.

BCDropper y BCObserver: piezas auxiliares asociadas

En paralelo se descubrió un módulo de kernel sin firma apodado BCDropper, subido a VirusTotal por el mismo remitente que el bootkit. Contiene referencias a “BlackCat” en cadenas y rutas de depuración y una funcionalidad de ocultación de archivos (filtra nombres con prefijos como “injector”, en línea con el LD_PRELOAD apuntando a /opt/injector.so).

BCDropper extrae un ELF incrustado denominado BCObserver en /opt/observer y lo ejecuta mediante /bin/bash. Además, retira su propio rastro de la lista de módulos cargados y provee funciones de rootkit típicas (ocultar archivos, procesos, puertos), aunque el dropper no las explote todas directamente.

BCObserver, por su parte, espera a que se inicie el gestor de pantalla gdm3 y a continuación intenta cargar /opt/rootkit_loader.ko usando la syscall finit_module, garantizando que el módulo se inyecta cuando el sistema ya ha completado el arranque gráfico.

No existe certeza absoluta de que estas piezas estén ligadas al mismo autor que Bootkitty, pero el parcheo de module_sig_check sugiere que la finalidad era permitir la carga de módulos no firmados, encajando con lo que hace BCDropper/BCObserver.

IoCs y técnicas MITRE ATT&CK relevantes

Los siguientes indicadores de compromiso y clasificaciones pueden ayudar en la búsqueda de señales iniciales en entornos Linux donde pudiera haberse probado la PoC:

SHA-1	Nombre	Detección	Descripción
35ADF3AED60440DA7B80F3C452047079E54364C1	bootkit.efi	EFI/Agent.A	Bootkitty UEFI bootkit.
BDDF2A7B3152942D3A829E63C03C7427F038B86D	dropper.ko	Linux/Rootkit.Agent.FM	BCDropper.
E8AF4ED17F293665136E17612D856FA62F96702D	observer	Linux/Rootkit.Agent.FM	BCObserver.

Mapeo MITRE ATT&CK más destacado para este conjunto de piezas y comportamiento observado, útil para un Threat Model básico:

Táctica	ID	Nombre	Descripción
Resource Development	T1587.001	Develop Capabilities: Malware	Bootkitty es un bootkit UEFI nuevo.
	T1587.002	Develop Capabilities: Code Signing Certificates	Muestra firmada con certificado autofirmado.
Execution	T1106	Native API	BCObserver usa finit_module para cargar un LKM.
	T1129	Shared Modules	Bootkitty fuerza LD_PRELOAD en init.
Persistence	T1574.006	Hijack Execution Flow: Dynamic Linker Hijacking	Parcheo de entorno de init con LD_PRELOAD.
	T1542.003	Pre-OS Boot: Bootkit	Despliegue en la ESP.
Defense Evasion	T1014	Rootkit	BCDropper como LKM para ocultación.
	T1562	Impair Defenses	Deshabilita verificación de firmas en GRUB y kernel.
	T1564	Hide Artifacts	Oculta su módulo de la lista de módulos del kernel.

Rastros en sistemas Linux y sugerencia de mitigación

En instalaciones Ubuntu afectadas se han observado indicios forenses como la cadena de versión del kernel alterada a BoB13 (visible con uname -v), modificaciones en el banner del arranque (dmesg) y presencia de LD_PRELOAD en /proc/1/environ. El kernel puede quedar marcado como tainted, un comportamiento que no se da sin el bootkit.

Una medida rápida cuando el bootkit sustituye GRUB consiste en devolver el archivo legítimo de /EFI/ubuntu/grubx64-real.efi a su ubicación original en /EFI/ubuntu/grubx64.efi para que shim arranque el GRUB auténtico. Hay que recordar que esto solo cubre el escenario concreto en el que el despliegue haya sido exactamente así.

BlackLotus: el caso paradigmático en Windows

BlackLotus se hizo conocido por ser capaz de ejecutar su bootkit UEFI incluso en Windows 11 completamente parcheado con Secure Boot habilitado. Estuvo a la venta por 5.000 dólares (200$ por actualización) desde octubre de 2022, con geofencing para evitar sistemas de Armenia, Bielorrusia, Kazajistán, Moldavia, Rumanía, Rusia y Ucrania.

Explotó la vulnerabilidad CVE-2022-21894 (Baton Drop), parcheada por Microsoft en enero de 2022, pero todavía aprovechable tiempo después porque binarios vulnerables y firmados seguían sin estar añadidos a la lista de revocaciones UEFI (dbx). El instalador introduce copias de bootloaders vulnerables firmados de forma válida para alcanzar persistencia y eludir Secure Boot.

Entre sus capacidades, era capaz de desactivar BitLocker, la integridad de memoria (HVCI) y Microsoft Defender, desplegar un driver en kernel que protege los ficheros del bootkit en la ESP, y un downloader HTTP en modo usuario que corre dentro de winlogon.exe, con técnicas anti-VM, antidepuración y ofuscación. El tamaño del bootkit era reducido (en torno a 80 KB), lo que favorece su sigilo.

Se han documentado cadenas internas y artefactos curiosos, como referencias a la serie Higurashi en nombres de componentes y en el certificado autofirmado, además de mensajes ofuscados no utilizados. Son detalles que no disminuyen su peligrosidad, pero sí aportan contexto sobre su desarrollo.

Cómo protege Windows el arranque: Secure Boot, Trusted Boot, ELAM y Measured Boot

En Windows, la cadena de confianza de arranque se apoya en varias capas. Secure Boot valida firmas del firmware y del bootloader; Trusted Boot verifica la integridad del kernel y componentes de arranque; ELAM prioriza la carga de un controlador antimalware antes que otros drivers de arranque no Microsoft; y Measured Boot registra hashes en el TPM para atestación remota.

Por defecto, los equipos certificados incluyen Secure Boot activo y confían en el certificado de Microsoft y en otros cargadores aprobados. No obstante, mantener habilitada la CA UEFI de terceros de Microsoft amplía la superficie de ataque al confiar en bootloaders de múltiples distribuciones, incluidos aquellos con vulnerabilidades conocidas. Muchos dispositivos de núcleo protegido exigen desactivar la confianza en esa CA de terceros para endurecer la postura por defecto.

Para permitir Linux en entornos protegidos, la aproximación recomendada es añadir de forma explícita la firma del cargador deseado a la base de datos UEFI o, como última opción, desactivar Secure Boot —medida que reduce sensiblemente la protección ante bootkits. En cualquier caso, estos cambios requieren intervención manual en firmware y no pueden ser automatizados por software malicioso.

La atestación con Measured Boot permite a un servidor de confianza valorar si un endpoint mantiene intacta su cadena de arranque. El TPM firma la evidencia y, combinada con telemetría adicional, posibilita aislar equipos comprometidos en redes de cuarentena hasta su remediación.

Reglas de detección y vigilancia proactiva

Más allá de la instrumentación nativa de Windows, la comunidad ha publicado reglas Sigma útiles para detectar actividad asociada a estos escenarios. Entre ellas, crear un fichero de firmware bajo System32 por un proceso no perteneciente al sistema, o la deshabilitación de la Integridad de Memoria (HVCI) mediante claves de registro (técnicas T1562 y T1112 de MITRE ATT&CK). Estas detecciones están mapeadas a múltiples SIEM/EDR/XDR.

Para Linux, conviene correlacionar eventos de arranque (journald/dmesg), cambios en uname -v y variables de entorno de PID 1, además de revisar cargas de módulos sin firma o operaciones sospechosas sobre la ESP. Integrar estos rastros con reglas de comportamiento en el EDR mejora la probabilidad de descubrir un intento de persistencia temprana.

Panorama más amplio: LoJax, ESPecter, MoonBounce, MosaicRegressor y nuevas señales

El primer implante de firmware UEFI observado in the wild fue LoJax (2018), seguido por campañas con MosaicRegressor y MoonBounce, este último notable por elevar el listón de sofisticación en rootkits UEFI. En 2021, ESPecter y el bootkit de FinSpy demostraron que la etapa pre-SO seguía siendo un objetivo atractivo para actores avanzados.

En el terreno Linux, Bootkitty ha sido la primera prueba funcional de su clase, con alcance limitado. Y ya en 2025 han aparecido referencias a “HybridPetya” como evolución de la familia Petya con capacidades de bootkit UEFI, con muestras subidas a VirusTotal desde Polonia. Aunque el análisis aún es preliminar, es un recordatorio de que esta categoría de amenazas continúa en expansión.

Recomendaciones prácticas para reducir el riesgo

En entornos Linux, mantener Secure Boot activo, aplicar actualizaciones de firmware (UEFI) y kernel, y asegurarse de que la lista de revocación (dbx) está al día son pilares innegociables. Monitoriza que module.sig_enforce esté en 1 o que CONFIG_MODULE_SIG_FORCE esté habilitado cuando proceda y evita cargar módulos procedentes de fuentes no confiables.

Audita regularmente la partición ESP en busca de cambios no autorizados en rutas como /EFI/ubuntu/grubx64.efi y verifica que no existan “copias” sospechosas (grubx64-real.efi). Cualquier alteración en el flujo de verificación de GRUB debe investigarse.

En Windows, además de Secure Boot, refuerza Trusted Boot, habilita HVCI cuando sea compatible con el hardware, y adopta atestación remota basada en TPM con políticas de acceso condicional. Minimiza la confianza en CA de terceros si no es estrictamente necesaria y acelera la adopción de revocaciones cuando publican fallos en componentes de arranque.

Algunas soluciones comerciales integran escáneres UEFI capaces de revisar el firmware en busca de componentes maliciosos. ESET afirma ser el único proveedor del top 20 de endpoint por ingresos que ofrece esta capacidad integrada para sus clientes, una aproximación que puede aportar valor en defensa de hardware en profundidad.

La trayectoria de las últimas campañas deja claro que el eslabón de arranque sigue siendo un objetivo preferente. Con telemetría adecuada, hardening de firmware/bootloaders y revisiones de integridad sistemáticas, es posible elevar notablemente el listón y complicar la vida a los adversarios.

El estado del arte de los bootkits UEFI confirma que la frontera entre PoC y operación real se cruza cada vez más rápido: Bootkitty evidencia que Linux ya está en el punto de mira, BlackLotus consolidó la viabilidad en Windows, y el ecosistema de defensa debe priorizar la higiene de arranque, la actualización de la dbx, la monitorización de IoCs y la atestación remota para cortar de raíz cualquier intento de persistencia pre-SO.