análisis-de-muestras-de-bootkit-y-rootkit

Análisis de Muestras de Bootkit y Rootkit

Cuándo Usarlo

• Un sistema muestra signos de compromiso que persisten incluso después de reinstalar el sistema operativo
• El antivirus y EDR no pueden detectar malware a pesar de evidencia clara de compromiso
• El Arranque Seguro UEFI ha sido deshabilitado o muestra violaciones de integridad
• La forensia de memoria revela comportamiento de rootkit (procesos ocultos, llamadas al sistema interceptadas)
• Se investigan amenazas de nivel de estado-nación conocidas por implementar bootkits (APT28, APT41, Equation Group)

No usar para malware estándar en modo de usuario; los bootkits y rootkits operan a un nivel fundamentalmente diferente que requiere técnicas de análisis especializadas.

Requisitos Previos

• Herramientas de imagen de disco (dd, FTK Imager) para adquirir sectores MBR/VBR
• UEFITool para análisis de volúmenes de firmware UEFI y extracción de módulos
• chipsec para evaluación de seguridad de firmware a nivel de hardware
• Ghidra con soporte para modo real x86 y 16 bits para análisis de código MBR
• Volatility 3 para detección de artefactos de rootkit a nivel de kernel
• Live USB Linux arrancable para análisis offline del sistema

Flujo de Trabajo

Paso 1: Adquirir Sectores de Arranque y Firmware

Extraer MBR, VBR y firmware UEFI para análisis offline:

# Adquirir MBR (primeros 512 bytes del disco)
dd if=/dev/sda of=mbr.bin bs=512 count=1

# Adquirir primera pista (generalmente contiene código bootkit más allá del MBR)
dd if=/dev/sda of=first_track.bin bs=512 count=63

# Adquirir VBR (Registro de Arranque de Volumen - primer sector de la partición)
dd if=/dev/sda1 of=vbr.bin bs=512 count=1

# Adquirir Partición del Sistema UEFI
mkdir /mnt/efi
mount /dev/sda1 /mnt/efi
cp -r /mnt/efi/EFI /analysis/efi_backup/

# Volcar firmware UEFI (requiere chipsec o flashrom)
# Usando chipsec:
python chipsec_util.py spi dump firmware.rom

# Usando flashrom:
flashrom -p internal -r firmware.rom

# Verificar integridad del volcado de firmware
sha256sum firmware.rom

Paso 2: Analizar MBR/VBR en Busca de Código Bootkit

Examinar el código del sector de arranque en busca de modificaciones maliciosas:

# Desensamblar código MBR (modo real de 16 bits)
ndisasm -b16 mbr.bin > mbr_disasm.txt

# Comparar MBR con el MBR de Windows conocido como bueno
# El MBR estándar de Windows comienza con: EB 5A 90 (JMP 0x5C, NOP)
# MBR de Windows 10 estándar: 33 C0 8E D0 BC 00 7C (XOR AX,AX; MOV SS,AX; MOV SP,7C00h)

python3 << 'PYEOF'
with open("mbr.bin", "rb") as f:
    mbr = f.read()

# Verificar firma MBR (bytes 510-511 deben ser 0x55AA)
if mbr[510:512] == b'\x55\xAA':
    print("[*] Firma MBR válida (0x55AA)")
else:
    print("[!] Firma MBR no válida")

# Buscar firmas conocidas de bootkit
bootkit_sigs = {
    b'\xE8\x00\x00\x5E\x81\xEE': "TDL4/Alureon bootkit",
    b'\xFA\x33\xC0\x8E\xD0\xBC\x00\x7C\x8B\xF4\x50\x07': "MBR estándar de Windows (limpio)",
    b'\xEB\x5A\x90\x4E\x54\x46\x53': "VBR NTFS estándar (limpio)",
}

for sig, name in bootkit_sigs.items():
    if sig in mbr:
        print(f"[{'!' if 'limpio' not in name else '*'}] Coincidencia de firma: {name}")

# Revisar entradas de tabla de particiones
print("\nTabla de Particiones:")
for i in range(4):
    offset = 446 + (i * 16)
    entry = mbr[offset:offset+16]
    if entry != b'\x00' * 16:
        boot_flag = "Activa" if entry[0] == 0x80 else "Inactiva"
        part_type = entry[4]
        start_lba = int.from_bytes(entry[8:12], 'little')
        size_lba = int.from_bytes(entry[12:16], 'little')
        print(f"  Partición {i+1}: Tipo=0x{part_type:02X} {boot_flag} Inicio=LBA {start_lba} Tamaño={size_lba} sectores")
PYEOF

Paso 3: Analizar Firmware UEFI en Busca de Implantes

Inspeccionar los volúmenes de firmware UEFI en busca de módulos no autorizados:

# Extraer componentes del firmware UEFI con UEFITool
# GUI: Abrir firmware.rom -> Inspeccionar volúmenes de firmware
# CLI:
UEFIExtract firmware.rom all

# Listar todos los controladores DXE (objetivo más común para implantes UEFI)
find firmware.rom.dump -name "*.efi" -exec file {} \;

# Comparar contra la lista de módulos de firmware conocidos como buenos
# Cada módulo UEFI tiene un GUID - comparar con la línea base del fabricante

# Verificar configuración de Arranque Seguro
python chipsec_main.py -m common.secureboot.variables

# Verificar protección contra escritura de SPI flash
python chipsec_main.py -m common.bios_wp

# Buscar patrones conocidos de malware UEFI
yara -r uefi_malware.yar firmware.rom

Puntos de Detección de Bootkit UEFI Conocidos:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LoJax (APT28):
  - SPI flash modificado
  - Controlador DXE añadido que inyecta agente en Windows
  - Persiste a través de reinstalación del SO y reemplazo de disco

BlackLotus:
  - Explota CVE-2022-21894 para evadir Arranque Seguro
  - Modifica el cargador de arranque de la Partición del Sistema EFI
  - Instala controlador de kernel durante el arranque

CosmicStrand:
  - Modifica el módulo de firmware CORE_DXE
  - Intercepta la inicialización del kernel durante el arranque
  - Inyecta shellcode en la memoria del kernel de Windows

MoonBounce:
  - Implante de SPI flash en el módulo CORE_DXE
  - Función GetVariable() modificada
  - Despliega implante en modo de usuario a través de la cadena de arranque

ESPecter:
  - Modifica el Administrador de Arranque de Windows en la ESP
  - Parchea winload.efi para deshabilitar DSE
  - Carga controlador de kernel sin firmar

Paso 4: Detectar Comportamiento de Rootkit a Nivel de Kernel

Analizar el sistema en ejecución en busca de artefactos de rootkit:

# Forensia de memoria para detección de rootkit
# Detección de ganchos SSDT
vol3 -f memory.dmp windows.ssdt | grep -v "ntoskrnl\|win32k"

# Procesos ocultos (DKOM)
vol3 -f memory.dmp windows.psscan > psscan.txt
vol3 -f memory.dmp windows.pslist > pslist.txt
# Diferencia para encontrar procesos ocultos

# Registro de callbacks del kernel (los rootkits registran callbacks para filtrar)
vol3 -f memory.dmp windows.callbacks

# Análisis de controladores
vol3 -f memory.dmp windows.driverscan
vol3 -f memory.dmp windows.modules

# Verificar controladores sin firmar
vol3 -f memory.dmp windows.driverscan | while read line; do
    driver_path=$(echo "$line" | awk '{print $NF}')
    if [ -f "$driver_path" ]; then
        sigcheck -nobanner "$driver_path" 2>/dev/null | grep "Sin firmar"
    fi
done

# Detección de ganchos IDT
vol3 -f memory.dmp windows.idt

Paso 5: Verificación de Integridad del Proceso de Arranque

Verificar la integridad de toda la cadena de arranque:

# Verificar firma del Administrador de Arranque de Windows
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi

# Verificar winload.efi
sigcheck -a C:\Windows\System32\winload.efi

# Verificar ntoskrnl.exe
sigcheck -a C:\Windows\System32\ntoskrnl.exe

# Revisar registros de Arranque Medido (si TPM está disponible)
# Windows: BCDEdit /enum firmware
bcdedit /enum firmware

# Verificar estado de Arranque Seguro
Confirm-SecureBootUEFI  # Cmdlet de PowerShell

# Verificar configuración de arranque por manipulación
bcdedit /v

# Buscar cambios en la configuración de arranque
# testsigning: debe ser No
# nointegritychecks: debe ser No
# debug: debe ser No
bcdedit | findstr /i "testsigning nointegritychecks debug"

Paso 6: Documentar el Análisis del Bootkit/Rootkit

Compilar hallazgos de análisis exhaustivos:

El análisis debe documentar:
- Estado de integridad del sector de arranque (MBR/VBR) con comparación hexadecimal
- Inventario de módulos de firmware UEFI y verificación de integridad
- Estado de Arranque Seguro y cualquier mecanismo de evasión detectado
- Ganchos a nivel de kernel (SSDT, IDT, IRP, inline) identificados
- Procesos, controladores y archivos ocultos descubiertos
- Mecanismo de persistencia (SPI flash, ESP, MBR, controlador de kernel)
- Resultados de verificación de integridad de la cadena de arranque
- Atribución a familias de bootkit conocidas si es posible
- Pasos de remediación (reflashear firmware, reconstruir MBR, reemplazar hardware)

Conceptos Clave

Término	Definición
Bootkit	Malware que infecta el proceso de arranque (MBR, VBR, UEFI) para ejecutarse antes de que cargue el sistema operativo, obteniendo control persistente de bajo nivel
MBR (Master Boot Record)	Primeros 512 bytes de un disco que contienen código de arranque y tabla de particiones; los bootkits MBR reemplazan este código con cargadores maliciosos
UEFI (Unified Extensible Firmware Interface)	Interfaz de firmware moderna que reemplaza a BIOS; los bootkits UEFI implantan módulos maliciosos en volúmenes de firmware o modifican la ESP
Arranque Seguro (Secure Boot)	Característica de seguridad UEFI que verifica firmas digitales de los componentes de arranque; bootkits como BlackLotus explotan vulnerabilidades para evadirlo
SPI Flash	Chip de memoria flash que almacena el firmware UEFI; bootkits avanzados como LoJax y MoonBounce modifican el SPI flash para persistencia a nivel de firmware
DKOM (Direct Kernel Object Manipulation)	Técnica de rootkit que modifica estructuras del kernel para ocultar procesos, archivos y conexiones de red sin interceptar funciones
Driver Signature Enforcement (DSE)	Característica de seguridad de Windows que requiere que los controladores de kernel estén firmados digitalmente; los bootkits deshabilitan DSE durante el arranque para cargar controladores rootkit sin firmar

Herramientas y Sistemas

• UEFITool: Editor y analizador de imágenes de firmware UEFI de código abierto para inspeccionar volúmenes de firmware, controladores y módulos
• chipsec: Framework de evaluación de seguridad de hardware de Intel para verificar protección SPI flash, Arranque Seguro y configuración UEFI
• Volatility: Framework de forensia de memoria con complementos de análisis SSDT, IDT, callbacks y controladores para detección de rootkit de kernel
• GMER: Herramienta de detección de rootkit de Windows que escanea por ganchos SSDT, ganchos IDT, procesos ocultos y módulos de kernel modificados
• Bootkits Analyzer: Herramienta especializada para analizar código MBR/VBR incluyendo desensamblado y comparación contra líneas base conocidas como buenas

Escenarios Comunes

Escenario: Investigación de Compromiso Persistente que Sobrevive a la Reinstalación del SO

Contexto: Una organización reimaginó una estación de trabajo comprometida, pero las mismas balizas C2 se reanudaron en horas. La forensia de disco estándar no encuentra malware. Se sospecha de un bootkit UEFI.

Enfoque:

1. Arrancar desde un live USB Linux para evitar ejecutar cualquier componente del SO comprometido
2. Volcar el firmware SPI flash usando chipsec o flashrom para análisis offline
3. Volcar los sectores MBR y VBR con dd para análisis del sector de arranque
4. Copiar la Partición del Sistema EFI para verificación de integridad del cargador de arranque
5. Abrir el volcado SPI en UEFITool y comparar GUIDs de módulos contra el firmware proporcionado por el fabricante
6. Buscar controladores DXE adicionales o modificados que no deberían estar presentes
7. Analizar cualquier módulo sospechoso con Ghidra (formato de módulo UEFI x86_64)
8. Verificar la configuración de Arranque Seguro y buscar evasiones basadas en exploits

Errores comunes:

• Analizar el sistema mientras el SO comprometido está en ejecución (el rootkit puede ocultarse del análisis en vivo)
• No revisar el SPI flash (analizar solo componentes de arranque basados en disco omite implantes a nivel de firmware)
• Asumir que el Arranque Seguro previene todos los bootkits (existen evasiones conocidas, ej., CVE-2022-21894)
• No preservar el volcado de firmware original antes de reflashear (evidencia crítica para atribución)

Formato de Salida

INFORME DE ANÁLISIS DE BOOTKIT / ROOTKIT
============================================
Sistema:           Dell OptiPlex 7090 (UEFI, TPM 2.0)
Versión de Firmware: 1.15.0 (Dell)
Arranque Seguro:   HABILITADO (pero evadido)
Método de Captura: Live USB Linux + volcado SPI chipsec

ANÁLISIS MBR/VBR
Firma MBR:        Válida (0x55AA)
Código MBR:       COINCIDE con MBR estándar de Windows 10 (limpio)
Código VBR:       COINCIDE con VBR NTFS estándar (limpio)

ANÁLISIS DE FIRMWARE UEFI
Total Módulos:    287
Esperados por Fabricante: 285
Módulos Extra:    2 NO AUTORIZADOS
  [!] Controlador DXE GUID: {ABCD1234-...} "SmmAccessDxe_mod" (MODIFICADO)
      Tamaño Original: 12,288 bytes
      Tamaño Actual:  45,056 bytes (32KB AÑADIDOS)
      Entropía: 7.82 (ALTA - carga útil cifrada)

  [!] Controlador DXE GUID: {EFGH5678-...} "UefiPayloadDxe" (NUEVO - no está en firmware del fabricante)
      Tamaño: 28,672 bytes
      Función: Inyecta agente de persistencia durante el arranque

INTEGRIDAD DE LA CADENA DE ARRANQUE
bootmgfw.efi:     MODIFICADO (discrepancia de hash, evasión de Arranque Seguro vía CVE-2022-21894)
winload.efi:      MODIFICADO (DSE deshabilitado al cargar)
ntoskrnl.exe:     LIMPIO (pero controlador sin firmar cargado después del arranque)

COMPONENTES DE ROOTKIT DE KERNEL
Controlador:      C:\Windows\System32\drivers\null_mod.sys (sin firmar, oculto)
Ganchos SSDT:     3 (NtQuerySystemInformation, NtQueryDirectoryFile, NtDeviceIoControlFile)
Procesos Ocultos: 2 (PID 6784: beacon.exe, PID 6812: keylog.exe)
Archivos Ocultos: C:\Windows\System32\drivers\null_mod.sys

ATRIBUCIÓN
Familia:          Variante de BlackLotus
Confianza:        ALTA (exploit CVE-2022-21894, patrón de modificación de ESP coincide)

REMEDIACIÓN
1. Reflashear firmware SPI con imagen limpia del fabricante mediante programador de hardware
2. Reconstruir Partición del Sistema EFI desde medios de instalación de Windows limpios
3. Reinstalar SO desde medios verificados
4. Habilitar todas las protecciones de escritura de firmware
5. Actualizar firmware a la versión más reciente (parchea CVE-2022-21894)