- Bootkitty irrumpe como PoC de bootkit UEFI para Linux, con hooks en GRUB y el kernel.
- BlackLotus explotó CVE-2022-21894 para evadir Secure Boot y lograr persistencia.
- CVE-2024-7344 permitió cargar UEFI no firmados vía reloader.efi; ya revocado.
- Mitigación efectiva: revocaciones UEFI, control de la ESP y atestación con TPM.
Los bootkits UEFI han pasado en pocos años de ser un concepto de laboratorio a convertirse en un quebradero de cabeza real para defensores y fabricantes. En este terreno, la frontera entre prueba de concepto y amenaza operativa se difumina, y casos como BlackLotus o el reciente hallazgo de Bootkitty en Linux lo demuestran con creces.
Este artículo reúne y explica, con lenguaje claro y detalles técnicos cuando aportan valor, lo más relevante publicado por investigadores y empresas del sector: desde la primera PoC de 2012 hasta las campañas modernas, pasando por vulnerabilidades como CVE-2024-7344 que permiten sortear Secure Boot, técnicas de evasión, IoCs y medidas de detección y mitigación que sí funcionan en el mundo real.
Qué es un bootkit UEFI y por qué es tan problemático
Un bootkit UEFI es un implante que se ejecuta antes del sistema operativo, con capacidad para controlar el flujo de arranque, desactivar verificaciones y cargar componentes con altos privilegios. Al operar a tan bajo nivel, puede evadir antivirus tradicionales y hasta ciertas «medidas de arranque seguro» si aprovecha fallos o configuraciones permisivas.
En el panorama real ya se han observado implantes y técnicas persistentes en UEFI como LoJax, MosaicRegressor o MoonBounce, hitos que evidencian cómo un actor puede ocupar el firmware y dominar fases críticas del boot, complicando el análisis forense y la remediación.
Para defender Windows, Microsoft encadena varias capas: Secure Boot (UEFI valida el cargador con certificados de confianza), Trusted Boot (el kernel valida el resto de componentes), ELAM (Antimalware de Inicio Temprano, que inspecciona controladores de arranque) y Measured Boot (mediciones al TPM y atestación remota). Son barreras útiles, pero no infalibles ante vulnerabilidades del propio ecosistema UEFI o configuraciones demasiado amplias de confianza. Además, es posible blindar Windows con Credential Guard, BitLocker y WDAC para reducir riesgo de persistencia a largo plazo.
De PoCs a la vida real: cronología y actores clave
El viaje arranca en 2012 con la PoC de Andrea Allievi para Windows sobre UEFI, seguida por proyectos como EfiGuard, Boot Backdoor o UEFI-bootkit. Pasaron años hasta que se documentaron casos in-the-wild como ESPecter (ESET, 2021) o el bootkit de FinSpy (Kaspersky, 2021), y en 2023 irrumpió BlackLotus, el primer bootkit UEFI capaz de eludir Secure Boot en sistemas plenamente actualizados. En entornos de laboratorio es habitual probar malware en una máquina virtual para evaluar PoCs y detecciones sin poner en riesgo infraestructuras productivas.
Algo había sido constante hasta ahora: la diana eran exclusivamente equipos Windows. Esa suposición se rompió cuando apareció en VirusTotal, en noviembre de 2024, una app UEFI llamada bootkit.efi. El análisis reveló un bootkit, bautizado por sus autores como Bootkitty, diseñado para Linux (Ubuntu). Según telemetría, no hay despliegue real confirmado; y los propios autores, vinculados al programa formativo coreano Best of the Best (BoB), aclararon que se trataba de una prueba de concepto con ánimo de concienciación.
El binario de Bootkitty está firmado con un certificado autofirmado. Eso implica que no se ejecuta con Secure Boot activado salvo que se instalen certificados del atacante. Pese a ello, su lógica ilustra cómo un actor puede parchear, en memoria, componentes del loader (GRUB) y del kernel de Linux para sortear verificaciones.
Bootkitty en detalle: artefactos, compatibilidad y qué modifica
El bootkit contiene funciones no utilizadas que imprimen arte ASCII con el nombre Bootkitty y una lista de posibles autores. También muestra cadenas de texto en cada arranque y referencias a BlackCat dentro de su salida y en un módulo de kernel relacionado, sin que exista relación con el ransomware ALPHV/BlackCat; en parte porque Bootkitty está escrito en C, mientras que ALPHV desarrolla en Rust.
Su compatibilidad es limitada. Para localizar qué funciones tocar, emplea patrones de bytes codificados (técnica clásica en bootkits), pero los patrones elegidos no cubren bien múltiples versiones de kernel o de GRUB. El resultado es que el implante es funcional solo en un conjunto muy acotado de configuraciones y, además, parchea offsets fijos tras la descompresión del kernel: si los desplazamientos no cuadran con la versión, puede sobreescribir datos aleatorios y provocar cuelgues en lugar de compromiso.
El arranque comienza con shim ejecutando Bootkitty, que primero consulta el estado de SecureBoot y coloca hooks en dos protocolos de autenticación UEFI: EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication y EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState. En ambos casos, ajusta la salida para devolver EFI_SUCCESS, anulando en la práctica la verificación de integridad de imágenes PE durante el pre-OS.
Después, Bootkitty carga un GRUB legítimo desde una ruta codificada de la ESP (/EFI/ubuntu/grubx64-real.efi), lo parchea en memoria y engancha funciones clave antes de que se ejecute.
Hooking en GRUB y descompresión del kernel Linux
El implante altera la función start_image del módulo peimage de GRUB, responsable de lanzar binarios PE ya cargados (como el stub EFI del kernel, vmlinuz.efi/vmlinuz). Aprovecha que el kernel ya está en memoria y coloca un hook en la rutina que descomprime la imagen real del kernel (probablemente zstd_decompress_dctx según el build), de modo que, una vez descomprimido, puede parchearlo en caliente.
También modifica la función grub_verifiers_open, que decide si hay que verificar la integridad de cada fichero cargado (módulos, kernel, config…). El hook retorna inmediatamente y, con ello, evita cualquier comprobación de firma. Por su parte, el ajuste en shim_lock_verifier_init resulta confuso: fuerza un flag de verificación más estricto (GRUB_VERIFY_FLAGS_SINGLE_CHUNK), pero esta función ni siquiera llega a invocarse por el otro hook, quedando irrelevante.
Una vez descomprimido el kernel, el código de Bootkitty aplica tres modificaciones en memoria: reescribe la cadena de versión/banner del kernel con el texto «BoB13»; fuerza que module_sig_check() devuelva 0 para que el kernel cargue módulos sin firma; y reemplaza la primera variable de entorno del proceso init para inyectar LD_PRELOAD=/opt/injector.so /init al inicio del espacio de usuario.
La inyección mediante LD_PRELOAD es una táctica clásica para dar prioridad a un objeto compartido ELF y sobreescribir funciones. Aquí la cadena presenta una peculiaridad (incluye «/init» junto a LD_PRELOAD), un detalle que refuerza el carácter de PoC inacabada más que de operación pulida. No se observaron los binarios supuestamente inyectados, aunque un escrito posterior de terceros indicó que se emplean solo para cargar una etapa adicional.
Indicadores, síntomas y una remediación sencilla
Si Bootkitty está presente, es posible ver pistas visibles. El comando uname -v mostrará la versión del kernel con el texto alterado y en dmesg puede aparecer el banner igualmente modificado. Además, es factible detectar que el proceso PID 1 (init) se lanzó con LD_PRELOAD inspeccionando /proc/1/environ, una señal anómala en sistemas legítimos.
En pruebas de laboratorio, el kernel aparece tainted tras el arranque con Bootkitty, y otra comprobación empírica en equipos con Secure Boot habilitado consiste en intentar cargar un módulo sin firma: si la carga se permite en caliente, sugiere que module_sig_check ha sido parcheada.
Si el bootkit se hubiera instalado sustituyendo el binario de GRUB por un intermediario (comportamiento observado), una forma directa de recuperarse es mover el GRUB legítimo desde /EFI/ubuntu/grubx64-real.efi a su ruta original /EFI/ubuntu/grubx64.efi para que shim lo ejecute y la cadena de arranque continúe sin el implante.
BCDropper y BCObserver: ¿piezas conectadas o simple coincidencia?
Junto a Bootkitty se localizó un módulo de kernel sin firma apodado BCDropper, que comparte indicios con el bootkit: cadenas BlackCat/blackcat en metadatos y rutas de depuración, y una función de ocultación de archivos cuyos prefijos incluyen «injector» (en línea con la variable LD_PRELOAD apuntando a /opt/injector.so).
BCDropper deja en /opt/observer un ELF embebido (denominado BCObserver) y lo lanza mediante /bin/bash. Este componente, bastante sencillo, espera a que gdm3 esté activo y, entonces, carga un módulo del kernel desde /opt/rootkit_loader.ko usando finit_module, asegurándose de hacerlo tras el arranque completo del sistema.
Aunque hay señales de relación, no es posible asegurar que ambos elementos provengan del mismo autor o que estén diseñados para operar juntos. Para más inri, la versión de kernel mencionada en su metadata (6.8.0-48-generic) ni siquiera figura entre las soportadas por el bootkit.
IoCs asociados
Los siguientes artefactos se han asociado a los hallazgos comentados. Su valor es principalmente de referencia y laboratorio:
| SHA-1 | Archivo | Detección | Descripción |
| 35ADF3AED60440DA7B80F3C452047079E54364C1 | bootkit.efi | EFI/Agent.A | Bootkitty, bootkit UEFI orientado a Linux. |
| BDDF2A7B3152942D3A829E63C03C7427F038B86D | dropper.ko | Linux/Rootkit.Agent.FM | BCDropper, módulo de kernel. |
| E8AF4ED17F293665136E17612D856FA62F96702D | observer | Linux/Rootkit.Agent.FM | BCObserver, ejecutable de usuarios. |
BlackLotus y CVE-2022-21894: el hito que abrió la veda
BlackLotus se comercializa desde 2022 con un precio en torno a 5.000 USD (más extras por actualización) e incluye técnicas de evasión anti-VM/anti-debug, geofencing para evitar ciertos países (Armenia, Bielorrusia, Kazajistán, Moldavia, Rumanía, Rusia y Ucrania) y, lo más relevante, la explotación de CVE-2022-21894 (Baton Drop) para sortear Secure Boot y obtener persistencia sólida en equipos Windows 10/11 totalmente parchados.
El flujo descrito por la comunidad de seguridad incluye una primera fase con desactivación de protecciones del sistema operativo, el aprovechamiento de la vulnerabilidad heredada en Secure Boot y el registro de una clave de propietario de máquina controlada por el atacante. Tras nuevos reinicios, el implante despliega un driver de kernel y un componente en modo usuario tipo downloader para gestionar la comunicación de mando y control y cargas adicionales.
Para la defensa proactiva, la comunidad ha publicado reglas operativas. Por ejemplo, SOC Prime ofrece detecciones Sigma que buscan la creación sospechosa de ficheros de firmware en System32 por procesos no del sistema o la desactivación de HVCI vía registro. Este tipo de señales, mapeadas a MITRE ATT&CK (p.ej., T0857, T1562, T1112), ayudan a cazar actividad anómala que suele acompañar a los bootkits; también hay guías prácticas para detectar procesos maliciosos con Process Explorer en entornos Windows.
CVE-2024-7344: carga de binarios UEFI no confiables a través de «reloader.efi»
En 2024 se descubrió una vulnerabilidad especialmente delicada, CVE-2024-7344, que afecta a múltiples suites de recuperación firmadas por el certificado Microsoft Corporation UEFI CA 2011. La raíz del problema es el uso de un loader PE personalizado en la aplicación UEFI reloader.efi, en lugar de las API seguras LoadImage/StartImage. El binario descifra y ejecuta contenido desde un archivo cloak.dat sin verificar firmaruras conforme a la política de Secure Boot.
El vector no se limita a equipos con el software instalado, ya que un atacante con privilegios elevados podría desplegar el binario vulnerable en la ESP (partición EFI) de cualquier sistema que confíe en la UEFI CA de terceros de Microsoft y provocar la ejecución de un UEFI no firmado durante el arranque. Entre los productos afectados figuraban suites de Howyar, Greenware, Radix, SANFONG, Wasay, CES y Signal Computer, ya corregidos y revocados el 14 de enero de 2025.
Para verificar protección en PowerShell con privilegios elevados y en Linux (LVFS/dbxtool):
# ¿El sistema confía en la UEFI CA 2011 de Microsoft? (posible exposición)
::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'
# Revocación instalada (64 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
# Revocación instalada (32 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'
# Linux (dbxtool)
dbxtool --list | grep 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
dbxtool --list | grep 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'
Este caso reabre el debate sobre la cadena de confianza: Microsoft mantiene dos certificados ampliamente presentes en equipos UEFI de consumo y empresa (Windows Production CA 2011 y UEFI CA 2011 para terceros). El plan en marcha consiste en migrar a certificados 2023, tras incidentes como BlackLotus y la proliferación de bootloaders vulnerables firmados hace años. En equipos Secured-core, la UEFI CA de terceros suele venir desactivada por defecto.
Protecciones prácticas y personalización del arranque seguro
Más allá de aplicar revocaciones UEFI y mantener firmware/SO al día (Windows Update y LVFS), hay medidas que reducen la superficie de ataque: controlar el acceso a la ESP con reglas de seguridad, personalizar Secure Boot para acotar la confianza a lo necesario (siguiendo guías como la de la NSA) y desplegar atestación con TPM para validar de forma remota el estado de arranque frente a valores de referencia.
En Windows, la combinación de Secure Boot + Trusted Boot + ELAM + Measured Boot ofrece barreras por capas: validación de cargadores, controladores de arranque inspeccionados antes que el resto, y un registro firmado por el TPM que permite al servidor de seguridad separar equipos «limpios» de los que presentan desviaciones. En entornos administrados, esto reduce el tiempo de detección y contención.
En Linux, además de las revocaciones y el control de la ESP, conviene vigilar señales como LD_PRELOAD en el proceso init, el estado tainted del kernel, y correlacionar eventos de carga de módulos (p. ej., finit_module) con rutas inusuales (/opt/*.ko) para detectar intentos de persistencia temprana.
Herramientas, cobertura y MITRE ATT&CK
Según ESET, es el único proveedor del top 20 de endpoint por ingresos que integra un escáner de firmware UEFI en sus soluciones de protección de equipos. Aunque otros fabricantes ofrecen tecnologías relacionadas con UEFI, su propósito no siempre coincide con la inspección directa de firmware. Dado que los ataques UEFI, aunque esporádicos, otorgan control total y persistencia casi absoluta, invertir en esta capa puede marcar la diferencia.
En términos de MITRE ATT&CK, los comportamientos observados encajan con varias técnicas: Pre-OS Boot: Bootkit (T1542.003), Shared Modules/LD_PRELOAD (T1129), desarrollo de Malware (T1587.001) y uso de certificados (T1587.002), además de Rootkit (T1014), Impair Defenses (T1562) y Hide Artifacts (T1564) en el caso de los módulos de kernel que se ocultan a sí mismos.
- T1542.003: Bootkit en la ESP para persistencia pre-OS.
- T1129: Precarga con LD_PRELOAD en el proceso init.
- T1014: Módulos de kernel con funciones de rootkit.
- T1562/T1564: Desactivar verificaciones y ocultarse del sistema.
Linux no es invulnerable: el caso Bootkitty y nuevos nombres en el radar
Durante años, la narrativa popular contrapuso la mayor exposición de Windows frente a la supuesta «impenetrabilidad» de macOS o Linux. La realidad es más matizada: su modelo y cuota los hacen objetivos diferentes, pero no inmunes. La aparición de Bootkitty en Linux demuestra que el conocimiento para crear bootkits existe también para este ecosistema, aunque en este caso concreto hablemos de una PoC académica con soporte limitado.
Incluso han surgido menciones de una variante de ransomware, HybridPetya, que integraría capacidades de bootkit UEFI. Las muestras subidas a VirusTotal en 2025 desde Polonia sugieren desarrollo reciente, si bien conviene tratarlas con cautela hasta que haya análisis independientes y atribuciones sólidas.
Lo importante es interiorizar que la defensa debe cubrir la cadena completa de arranque, minimizar la confianza por defecto en firmas de terceros que no se utilicen, vigilar la partición EFI y consolidar telemetría útil (kernel tainted, eventos de módulos, cambios en verificadores de GRUB o variables UEFI sensibles) para detectar a tiempo.
La fotografía actual del riesgo UEFI combina PoCs con fines educativos, bootkits comercializados como servicio y vulnerabilidades en componentes firmados que, de no revocarse a tiempo, abren la puerta a la ejecución pre-OS no confiable. Mantener firmware y listas de revocación al día, reducir el círculo de confianza y monitorizar la ESP son medidas que, juntas, ponen a los defensores en una posición mucho más fuerte frente a esta familia de amenazas.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.