Análisis de Persistencia de Bootkit UEFI
Cuándo Usarlo
- Un sistema comprometido restablece la comunicación C2 después de una reinstalación del SO o reemplazo del disco.
- Se ha manipulado, deshabilitado Secure Boot o muestra una inscripción inesperada de Machine Owner Key (MOK).
- La verificación de integridad del firmware falla contra las líneas base proporcionadas por el proveedor.
- El análisis forense de memoria revela componentes rootkit que se cargan durante la fase de arranque temprano.
- Se investigan campañas de amenazas persistentes avanzadas (APT) conocidas por implementar implantes UEFI.
- Se audita la postura de seguridad del firmware para el endurecimiento de endpoints empresariales.
No usar para bootkits estándar basados en MBR en sistemas BIOS heredados sin UEFI; usar análisis de bootkit MBR/VBR en su lugar.
Requisitos Previos
- Framework chipsec para volcado de flash SPI, inspección de variables UEFI y módulos de seguridad del firmware.
- UEFITool / UEFIExtract para análisis de volúmenes de firmware y extracción de controladores DXE.
- Python 3.8+ con módulos struct, hashlib, subprocess y os.
- USB Linux Live de arranque para análisis sin conexión (evitar ejecutar el SO comprometido).
- Volatility 3 para análisis forense de memoria de artefactos de fase de arranque.
- YARA con conjuntos de reglas de malware UEFI para detección basada en patrones.
- Acceso a líneas base de firmware del proveedor para comparación de integridad.
Flujo de Trabajo
Paso 1: Volcar el Firmware de la Flash SPI
Adquiera el firmware UEFI del chip de flash SPI para su análisis sin conexión:
# Usando chipsec para volcar el contenido de la flash SPI
python chipsec_util.py spi dump firmware_dump.rom
# Usando flashrom como alternativa
flashrom -p internal -r firmware_dump.rom
# Verificar la integridad del volcado
sha256sum firmware_dump.rom
# Leer la información del descriptor de la flash SPI
python chipsec_util.py spi info
# Verificar los permisos de acceso a las regiones de la flash SPI
python chipsec_main.py -m common.spi_access
# Verificar que la protección de escritura de la BIOS esté habilitada
python chipsec_main.py -m common.bios_wp
# Verificar el bloqueo del controlador de la flash SPI
python chipsec_main.py -m common.spi_lock
Paso 2: Inspeccionar las Variables UEFI
Enumere y analice las variables UEFI en busca de modificaciones no autorizadas:
# Listar todas las variables UEFI en un sistema en vivo
python chipsec_util.py uefi var-list
# Listar variables UEFI desde un volcado de flash SPI
python chipsec_util.py uefi var-list-spi firmware_dump.rom
# Leer variables específicas de Secure Boot
python chipsec_util.py uefi var-read SecureBoot 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read SetupMode 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read PK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read KEK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read db D719B2CB-3D3A-4596-A3BC-DAD00E67656F
# Volcar las bases de datos de claves UEFI para su análisis
python chipsec_util.py uefi keys
# Verificar el módulo de configuración de Secure Boot
python chipsec_main.py -m common.secureboot.variables
Paso 3: Analizar la Partición del Sistema EFI (ESP)
Inspeccione la ESP en busca de componentes de arranque no autorizados o modificados:
# Montar la ESP (normalmente la primera partición FAT32, ~100-500MB)
mkdir /mnt/esp
mount /dev/sda1 /mnt/esp
# Listar todos los archivos en la ESP con marcas de tiempo
find /mnt/esp -type f -exec ls -la {} \;
# Buscar indicadores de BlackLotus: directorio personalizado en ESP:/system32/
ls -la /mnt/esp/system32/ 2>/dev/null
# Verificar la firma del Administrador de Arranque de Windows
sigcheck -a /mnt/esp/EFI/Microsoft/Boot/bootmgfw.efi
# Generar hash de todos los binarios EFI para compararlos con valores conocidos
find /mnt/esp -name "*.efi" -exec sha256sum {} \;
# Buscar archivos .efi no autorizados fuera de los directorios estándar
find /mnt/esp -name "*.efi" | grep -v "Microsoft\|Boot\|ubuntu\|grub"
# Buscar grubx64.efi plantado por BlackLotus
find /mnt/esp -name "grubx64.efi" -exec sha256sum {} \;
# Examinar los registros de MeasuredBoot en busca de anomalías (Windows)
# Los registros se encuentran en C:\Windows\Logs\MeasuredBoot\
Paso 4: Escanear el Firmware en Busca de Firmas de Bootkits Conocidos
Analice el volcado del firmware en busca de patrones de malware UEFI conocido:
# Extraer todos los módulos del firmware con UEFIExtract
UEFIExtract firmware_dump.rom all
# Generar una lista blanca de módulos de firmware a partir de la línea base del proveedor
python chipsec_main.py -m tools.uefi.whitelist -a generate,baseline.json,firmware_vendor.rom
# Comparar el firmware actual contra la lista blanca
python chipsec_main.py -m tools.uefi.whitelist -a check,baseline.json,firmware_dump.rom
# Escanear el firmware con reglas YARA específicas para UEFI
yara -r uefi_bootkits.yar firmware_dump.rom
# Escanear los módulos extraídos individualmente
find firmware_dump.rom.dump -name "*.efi" -exec yara -r uefi_bootkits.yar {} \;
# Verificar si el módulo CORE_DXE está modificado (objetivo de MoonBounce, CosmicStrand)
# Comparar GUID y hash contra la línea base del proveedor
Paso 5: Detectar Mecanismos de Bypass de Secure Boot
Verifique la existencia de técnicas conocidas de evasión de Secure Boot:
# Verificar si Secure Boot está habilitado
python chipsec_main.py -m common.secureboot.variables
# Verificar las protecciones de SMM (System Management Mode)
python chipsec_main.py -m common.smm
# Verificar la protección de escritura de la BIOS desde SMM
python chipsec_main.py -m common.bios_smi
# En Windows: verificar la configuración de arranque en busca de indicadores de bypass
bcdedit /enum firmware
bcdedit /v
# Buscar banderas testsigning/nointegritychecks/debug
bcdedit | findstr /i "testsigning nointegritychecks debug"
# Verificar que HVCI (Hypervisor-enforced Code Integrity) no esté deshabilitado
# BlackLotus establece HKLM:\...\DeviceGuard\...\HypervisorEnforcedCodeIntegrity Enabled=0
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled
# Verificar el estado de Secure Boot mediante PowerShell
# Confirm-SecureBootUEFI devuelve True si está habilitado correctamente
Paso 6: Realizar la Verificación de Integridad de la Cadena de Arranque
Verifique cada componente en la cadena de arranque, desde el firmware hasta el kernel:
# Verificar la integridad del firmware contra el hash del proveedor
sha256sum firmware_dump.rom
# Comparar con el hash publicado por el proveedor
# Verificar las firmas del cargador de arranque
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
sigcheck -a C:\Windows\System32\winload.efi
sigcheck -a C:\Windows\System32\ntoskrnl.exe
# Buscar controladores de arranque no firmados o no válidos
sigcheck -u -e C:\Windows\System32\drivers\
# Analizar los registros de Measured Boot en busca de entradas EV_EFI_Boot_Services_Application inesperadas
# Los componentes de BlackLotus aparecen como EV_EFI_Boot_Services_Application
# Análisis forense de memoria para artefactos de la fase de arranque
vol3 -f memory.dmp windows.modules
vol3 -f memory.dmp windows.driverscan
Paso 7: Documentar los Hallazgos del Análisis de Bootkit UEFI
Recopile un informe de análisis completo:
El informe debe incluir:
- Versión del firmware, proveedor e identificación de la plataforma
- Estado de protección de la flash SPI (protección contra escritura, bits de bloqueo, control de acceso)
- Configuración de Secure Boot y cualquier indicador de bypass detectado
- Anomalías en las variables UEFI (claves no autorizadas, db/dbx modificados, inscripción MOK)
- Inventario del contenido de la ESP con verificación de hash contra líneas base conocidas
- Comparación de módulos de firmware contra la lista blanca del proveedor (añadidos, modificados, eliminados)
- Atribución a la familia de bootkit conocida con nivel de confianza
- Resultados de la verificación de integridad de la cadena de arranque para cada componente
- Pasos de remediación (reflash, rotación de claves, reemplazo de hardware)
- Mapeo MITRE ATT&CK (T1542.001 - Firmware del Sistema, T1542.003 - Bootkit)
Conceptos Clave
| Término | Definición |
|---|---|
| Bootkit UEFI | Malware que persiste en el firmware UEFI o en el proceso de arranque, ejecutándose antes de que se cargue el sistema operativo y sobreviviendo a la reinstalación del SO |
| Flash SPI | Chip de memoria flash SPI en la placa base que almacena el firmware UEFI; los bootkits a nivel de firmware como LoJax y MoonBounce modifican el contenido de la flash SPI |
| Partición del Sistema EFI (ESP) | Partición FAT32 que contiene cargadores de arranque y controladores EFI; los bootkits como BlackLotus y ESPecter modifican archivos en la ESP para persistir |
| Secure Boot | Función de seguridad UEFI que verifica las firmas digitales de los componentes de arranque; se puede eludir mediante vulnerabilidades (CVE-2022-21894) o inscripción MOK |
| Controlador DXE | Controlador del Entorno de Ejecución de Controladores que se carga durante el arranque UEFI; los implantes de firmware inyectan controladores DXE maliciosos que se ejecutan antes del SO |
| Machine Owner Key (MOK) | Clave de Secure Boot instalable por el usuario; BlackLotus inscribe MOK controlados por el atacante para firmar cargadores de arranque maliciosos |
| chipsec | Framework de evaluación de seguridad de plataformas Intel para analizar flash SPI, variables UEFI, Secure Boot y configuraciones de seguridad de hardware |
| HVCI | Integridad de Código Impuesta por el Hipervisor, una función de seguridad de Windows que los bootkits deshabilitan para cargar controladores de kernel no firmados |
Herramientas y Sistemas
- chipsec: Framework de Intel para volcar flash SPI, leer variables UEFI, verificar la protección de escritura del firmware y auditar la configuración de Secure Boot
- UEFITool: Analizador de imágenes de firmware UEFI de código abierto para inspeccionar volúmenes de firmware, extraer controladores DXE y comparar GUID de módulos
- sigcheck: Utilidad de Sysinternals para verificar firmas digitales de binarios EFI y componentes de la cadena de arranque
- flashrom: Programador de flash SPI de código abierto para leer y escribir chips de firmware en plataformas compatibles
- YARA: Motor de coincidencia de patrones utilizado con conjuntos de reglas específicas de UEFI para detectar firmas de bootkits conocidos en volcados de firmware
Escenarios Comunes
Escenario: Investigación de Compromiso Persistente que Sobrevive a la Reinstalación del SO
Contexto: Un endpoint empresarial fue reimageado después de una brecha confirmada, pero la misma comunicación C2 se reanudó en cuestión de horas. El endpoint tiene firmware UEFI con Secure Boot habilitado y un chip TPM 2.0. El equipo de seguridad sospecha de un implante a nivel UEFI similar a BlackLotus o LoJax.
Enfoque:
- Arrancar el sistema desde un USB Linux Live confiable para evitar ejecutar cualquier componente del SO comprometido
- Volcar el firmware de la flash SPI usando
chipsec_util.py spi dumppara análisis sin conexión - Montar la ESP y generar el hash de todos los archivos
.efipara compararlos con valores conocidos de hardware idéntico - Buscar el directorio
ESP:/system32/(indicador de BlackLotus) ygrubx64.efino autorizado - Extraer los módulos de firmware con UEFIExtract y comparar el inventario de GUID contra la línea base del proveedor
- Verificar las variables de Secure Boot: buscar inscripción MOK no autorizada o db/dbx modificados
- Verificar la protección de escritura de la flash SPI y los bits de bloqueo usando módulos de chipsec
- Escanear el volcado de firmware y los módulos extraídos con reglas YARA específicas de UEFI
- Si se sospecha de BlackLotus, verificar en el registro si HVCI está deshabilitado y en los registros de MeasuredBoot si hay entradas anómalas
Errores Comunes:
- Realizar el análisis desde el SO comprometido (los componentes del rootkit se ocultan del análisis en vivo)
- Verificar solo la ESP sin examinar el firmware de la flash SPI (se pasan por alto implantes a nivel de firmware como LoJax, MoonBounce)
- Asumir que Secure Boot previene todos los bootkits (existen CVE-2022-21894 y otras evasioness)
- No preservar el volcado de firmware original antes de la remediación (evidencia forense crítica)
- Relfash el firmware sin verificar que la imagen del proveedor sea auténtica y no modificada
Formato de Salida
INFORME DE ANÁLISIS DE PERSISTENCIA DE BOOTKIT UEFI
====================================================
Sistema: Lenovo ThinkPad X1 Carbon Gen 11
Firmware: N3HET82W (1.54) - Lenovo UEFI BIOS
Plataforma: Intel 13th Gen (Raptor Lake)
TPM: 2.0 (Infineon SLB 9672)
Secure Boot: HABILITADO (EVADIDO mediante CVE-2022-21894)
Método de Análisis: USB Linux Live + chipsec + UEFITool
ESTADO DE PROTECCIÓN DE LA FLASH SPI
Protección de Escritura de BIOS: DESHABILITADO [!]
Bloqueo de Flash SPI (FLOCKDN): ESTABLECIDO [OK]
Protección de Escritura de BIOS SMM: DESHABILITADO [!]
Rangos Protegidos de SPI: Solo Región 0 (descriptor)
ANÁLISIS DE VARIABLES UEFI
SecureBoot: Habilitado (valor=1)
SetupMode: Deshabilitado (valor=0)
PK: Lenovo Ltd. (legítimo)
KEK: Microsoft + Lenovo (legítimo)
db: MODIFICADO - contiene entrada no autorizada [!]
[!] Certificado desconocido: CN=Secure Boot Signing, O=Unknown
[!] No presente en la base de datos db de referencia del proveedor
MOK: 1 clave no autorizada inscrita [!]
[!] MOK inscrito: CN=shim, autofirmado, no proviene del proveedor de la distribución
ANÁLISIS DE LA PARTICIÓN ESP
Total de binarios EFI: 12
Verificados (firmados): 9
Modificados (hash diferente): 2 [!]
No autorizados: 1 [!]
[!] EFI/Microsoft/Boot/bootmgfw.efi - MODIFICADO
SHA-256 esperado: a3f2c8...
SHA-256 actual: 7b1e4d...
Firma: Válida (firmado con MOK no autorizado)
[!] EFI/Microsoft/Boot/grubx64.efi - NO AUTORIZADO
SHA-256: e9c1a7...
No presente en la línea base del proveedor
Coincide con la firma del cargador de etapa 2 de BlackLotus
[!] Directorio system32/ presente en la ESP (artefacto de BlackLotus)
Directorio vacío (archivos eliminados post-instalación)
ANÁLISIS DE MÓDULOS DE FIRMWARE
Total de módulos de firmware: 312
Módulos en línea base del proveedor: 312
Módulos añadidos: 0
Módulos modificados: 0
Integridad de la flash SPI: LIMPIA (no se detectó implante a nivel de firmware)
ATRIBUCIÓN DEL BOOTKIT
Familia: BlackLotus
Confianza: ALTA
Persistencia: Basada en ESP (no en flash SPI)
Método de Evasión: CVE-2022-21894 (baton drop)
MITRE ATT&CK: T1542.003 (Bootkit), T1553.006 (Modificación de Política de Firma de Código)
INDICADORES DE COMPROMISO
- Directorio ESP:/system32/ (vacío, artefacto posterior a la limpieza)
- ESP:/EFI/Microsoft/Boot/grubx64.efi (no autorizado, cargador de BlackLotus)
- bootmgfw.efi modificado (refirmado con la MOK del atacante)
- HVCI deshabilitado mediante registro: DeviceGuard\...\Enabled = 0
- Inscripción MOK no autorizada en el almacén de variables UEFI
- El registro de MeasuredBoot muestra EV_EFI_Boot_Services_Application para grubx64.efi
REMEDIACIÓN
1. Reemplazar bootmgfw.efi con una copia auténtica del medio de instalación de Windows
2. Eliminar grubx64.efi no autorizado y el directorio system32/ de la ESP
3. Restablecer las claves de Secure Boot a los valores de fábrica (borrar MOK, restaurar PK/KEK/db)
4. Habilitar la protección de escritura de la BIOS y verificar los bits de bloqueo de la flash SPI
5. Aplicar la actualización de firmware a la versión más reciente (corrige CVE-2022-21894)
6. Habilitar HVCI y verificar mediante Directiva de Grupo
7. Reimportar solo los certificados de confianza en la base de datos db de Secure Boot
8. Monitorear los registros de MeasuredBoot en busca de carga de componentes de arranque anómalos