CHIPSEC: Framework de Intel para Detectar Rootkits de Firmware

La herramienta que Intel creo para auditar lo que el antivirus no puede ver

Los rootkits de firmware representan la categoria de persistencia mas dificil de detectar en seguridad informatica. Residen en la flash SPI de la placa base, por debajo del sistema operativo, por debajo del disco duro, por debajo de cualquier solucion de endpoint convencional. LoJax (2018), MosaicRegressor (2020), MoonBounce (2022) y CosmicStrand demostraron que esta tecnica no es teorica: actores estatales la utilizan activamente.

CHIPSEC (CHIPset SECurity) es un framework open-source creado por el equipo de seguridad de Intel (Intel Security Center of Excellence) en 2014. Su proposito original era evaluar la seguridad de las plataformas de hardware y firmware de Intel. Con el tiempo se convirtio en la herramienta de referencia para analistas forenses, investigadores de seguridad y equipos SOC que necesitan verificar la integridad del firmware y detectar modificaciones maliciosas.

No es un antivirus de firmware. No tiene firmas. No trabaja en tiempo real. CHIPSEC es un bisturi quirurgico que permite inspeccionar, volcar y verificar cada componente de la cadena de arranque, desde los registros de configuracion del chipset hasta los modulos DXE individuales dentro de la flash SPI.

Que evalua CHIPSEC exactamente

CHIPSEC opera en tres niveles:

Nivel de registros del chipset. Lee directamente los registros de configuracion del Platform Controller Hub (PCH) para verificar si las protecciones de hardware estan habilitadas. Por ejemplo, el bit FLOCKDN del registro HSFS controla si la flash SPI esta bloqueada contra escritura. Si ese bit no esta activo, cualquier proceso con privilegios suficientes puede escribir en el firmware.

Nivel de firmware UEFI. Puede volcar la flash SPI completa a un fichero binario, parsear sus volumenes y modulos, y compararlos contra una imagen de referencia. Aqui es donde detecta implantes como LoJax (que anadia un driver DXE nuevo) o MoonBounce (que modificaba CORE_DXE existente).

Nivel de configuracion de arranque. Verifica el estado de Secure Boot, la configuracion de Intel Boot Guard, los scripts de reanudacion S3 y otras protecciones de la cadena de confianza del arranque.

Instalacion en las tres plataformas

Linux

La plataforma recomendada para CHIPSEC. Requiere compilar un modulo del kernel.

# Dependencias (Debian/Ubuntu)
sudo apt-get install python3 python3-pip build-essential linux-headers-$(uname -r)

# Instalacion desde PyPI
sudo pip3 install chipsec

# O desde fuente (para la version mas reciente)
git clone https://github.com/chipsec/chipsec.git
cd chipsec
sudo python3 setup.py install

# Verificar instalacion
sudo chipsec_main --help

El modulo del kernel (chipsec.ko) proporciona acceso directo a los registros del chipset, la memoria fisica y los puertos de E/S. Sin este modulo, CHIPSEC no puede funcionar. Requiere ejecucion como root.

Windows

Requiere desactivar la aplicacion de firma de drivers (Driver Signature Enforcement) o usar un certificado de prueba.

# Instalacion con pip (como Administrador)
pip install chipsec

# Alternativa: compilar driver desde fuente
git clone https://github.com/chipsec/chipsec.git
cd chipsec
python setup.py install

# Ejecutar como Administrador
chipsec_main --help

En Windows 10/11, Secure Boot y HVCI (Hypervisor-protected Code Integrity) pueden bloquear la carga del driver de CHIPSEC. Para entornos de produccion donde no es posible desactivar estas protecciones, la ejecucion desde UEFI Shell es preferible.

UEFI Shell

La opcion mas directa. Se ejecuta antes de que el sistema operativo cargue, con acceso completo al firmware.

# Copiar CHIPSEC a un USB formateado como FAT32
# Arrancar desde UEFI Shell
# Navegar al directorio de CHIPSEC

fs0:
cd chipsec
python chipsec_main.py

Esta modalidad es especialmente util en respuesta a incidentes cuando el sistema operativo no es de confianza (porque precisamente se sospecha que el firmware esta comprometido).

Modulos clave para deteccion de rootkits

CHIPSEC organiza sus verificaciones en modulos independientes. Cada modulo evalua un aspecto especifico de la seguridad de la plataforma.

Volcado de la flash SPI

El primer paso en cualquier investigacion de firmware. Volcar la flash SPI completa a un fichero binario para analisis offline.

# Volcar toda la flash SPI
sudo chipsec_util spi dump firmware_dump.bin

# Volcar una region especifica (BIOS region)
sudo chipsec_util spi read 0x00000000 0x01000000 bios_region.bin

El fichero resultante contiene toda la imagen del firmware: regiones SEC, PEI, DXE, volumenes de firmware, NVRAM y regiones del vendor. Este volcado se puede analizar offline con UEFITool, Binarly FwHunt u otras herramientas de analisis de firmware.

Para detectar rootkits tipo LoJax o MoonBounce, se compara este volcado contra la imagen original del fabricante byte a byte:

# Comparacion basica de hashes
sha256sum firmware_dump.bin
sha256sum firmware_original_fabricante.bin

# Comparacion binaria detallada
diff <(xxd firmware_dump.bin) <(xxd firmware_original_fabricante.bin)

common.spi_lock: proteccion de escritura SPI

Verifica que el bit FLOCKDN (Flash Lockdown) esta activo en el registro HSFS del controlador SPI. Si este bit no esta configurado, el firmware puede ser modificado desde el sistema operativo, que es exactamente lo que hacen rootkits como LoJax.

sudo chipsec_main -m common.spi_lock

Resultado PASSED: el bit de bloqueo esta activo. La flash SPI esta protegida contra escritura desde el sistema operativo. Esto no es una garantia absoluta (existen ataques que explotan ventanas de tiempo durante el arranque), pero eleva significativamente la barrera para el atacante.

Resultado FAILED: la flash SPI no esta bloqueada. Cualquier proceso con privilegios de administrador/root podria escribir en el firmware. Esta condicion es prerequisito para rootkits como LoJax.

common.bios_wp: proteccion de escritura del BIOS

Verifica las protecciones de escritura especificas de la region BIOS dentro de la flash SPI. Evalua multiples mecanismos: BIOS Lock Enable (BLE), SPI Protected Ranges (PR0-PR4) y el estado de SMM BIOS Write Protect.

sudo chipsec_main -m common.bios_wp

Este modulo es complementario a spi_lock. Mientras spi_lock verifica el bloqueo global de la flash, bios_wp verifica las protecciones granulares que restringen la escritura a regiones especificas del firmware.

common.secureboot: estado de Secure Boot

Verifica que Secure Boot esta habilitado y correctamente configurado. Secure Boot valida criptograficamente cada componente del arranque antes de ejecutarlo, lo que previene la carga de drivers DXE no firmados.

sudo chipsec_main -m common.secureboot

BlackLotus demostro en 2023 que Secure Boot no es infalible (CVE-2022-21894 permitia el bypass), pero sigue siendo una capa de defensa fundamental. Un Secure Boot deshabilitado es una senal de alerta inmediata.

common.uefi.s3bootscript: ataques via reanudacion S3

Verifica la proteccion de los scripts de arranque S3. Cuando un sistema entra en modo de suspension (S3 Sleep) y se reanuda, ejecuta un script que restaura el estado del hardware. Si estos scripts no estan protegidos, un atacante puede modificarlos para desactivar las protecciones de escritura del firmware durante la reanudacion.

sudo chipsec_main -m common.uefi.s3bootscript

Esta tecnica fue documentada por investigadores de Intel y Rafal Wojtczuk en 2015. Permite convertir una vulnerabilidad de escritura durante la reanudacion S3 en persistencia permanente en el firmware. Varios rootkits de firmware han utilizado variantes de este ataque.

Firmware whitelisting: baselines y comparacion

CHIPSEC permite crear una whitelist (baseline) de todos los ejecutables EFI presentes en un volcado de firmware limpio y compararla contra volcados posteriores para detectar adiciones o modificaciones.

# Crear whitelist desde firmware limpio del fabricante
sudo chipsec_util uefi whitelist -f firmware_limpio_fabricante.bin whitelist.json

# Comparar firmware actual contra la whitelist
sudo chipsec_util uefi whitelist -f firmware_dump_actual.bin whitelist.json

Este mecanismo detectaria:

• LoJax: porque anade un driver DXE nuevo que no existe en la whitelist original.
• MosaicRegressor: porque anade multiples drivers DXE nuevos al firmware.
• MoonBounce: porque modifica el hash de CORE_DXE, que no coincidiria con la whitelist.

La limitacion es que requiere tener la imagen original del fabricante como referencia. Sin baseline, la comparacion no es posible.

Flujo practico de analisis forense de firmware

Un workflow estructurado para analistas que necesitan verificar la integridad del firmware en un incidente real.

Fase 1: evaluacion rapida (5 minutos)

Ejecutar la bateria completa de verificaciones de CHIPSEC para obtener una vision general del estado de seguridad de la plataforma.

# Ejecutar todos los modulos de verificacion
sudo chipsec_main

# O solo los modulos relevantes para rootkits
sudo chipsec_main -m common.spi_lock
sudo chipsec_main -m common.bios_wp
sudo chipsec_main -m common.secureboot
sudo chipsec_main -m common.uefi.s3bootscript

Si todos los modulos pasan, el riesgo de compromiso de firmware es bajo (aunque no nulo). Si alguno falla, la investigacion debe profundizar.

Fase 2: volcado y analisis (15-30 minutos)

# Volcar la flash SPI completa
sudo chipsec_util spi dump firmware_investigacion.bin

# Generar hash para cadena de custodia
sha256sum firmware_investigacion.bin > firmware_investigacion.sha256

# Si existe baseline, comparar
sudo chipsec_util uefi whitelist -f firmware_investigacion.bin whitelist_fabricante.json

Fase 3: analisis profundo con herramientas complementarias

CHIPSEC proporciona el volcado. El analisis detallado se realiza con herramientas adicionales.

UEFITool (github.com/LongSoft/UEFITool): GUI multiplataforma para parsear imagenes de firmware UEFI. Permite navegar la estructura de volumenes, extraer modulos DXE individuales, buscar patrones hexadecimales y comparar visualmente dos imagenes de firmware. Es la herramienta de referencia para analisis manual.

Binarly FwHunt (github.com/binarly-io/FwHunt): framework de reglas para deteccion de vulnerabilidades conocidas en firmware. Funciona de forma similar a las reglas YARA pero especificas para firmware. Binarly mantiene un repositorio publico de reglas que cubren vulnerabilidades en UEFI de multiples fabricantes.

LVFS (Linux Vendor Firmware Service, fwupd.org): servicio que distribuye actualizaciones de firmware para Linux. Aunque su funcion principal es la actualizacion, su base de datos de versiones de firmware por modelo de hardware es util para verificar si un sistema ejecuta una version conocida y no modificada.

UEFI Firmware Parser (github.com/theopolis/uefi-firmware-parser): herramienta de linea de comandos para parsear y extraer componentes de imagenes UEFI. Util para scripting y automatizacion.

Mapeo MITRE ATT&CK

CHIPSEC detecta o verifica protecciones contra las siguientes tecnicas:

Tecnica	ID	Verificacion CHIPSEC
Pre-OS Boot: System Firmware	T1542.001	spi_lock, bios_wp, uefi whitelist
Pre-OS Boot: Component Firmware	T1542.002	spi dump + analisis offline
Modify Authentication Process: Secure Boot	T1556.006	common.secureboot
Exploitation for Defense Evasion	T1211	s3bootscript
Firmware Corruption	T1495	spi_lock, bios_wp

El volcado de la flash SPI y su comparacion contra baselines es el metodo mas directo para detectar T1542.001, la tecnica utilizada por LoJax, MosaicRegressor, MoonBounce y CosmicStrand.

Construir un programa de monitorizacion de integridad de firmware

CHIPSEC es una herramienta puntual, no un sistema de monitorizacion continua. Para construir un programa operativo de integridad de firmware:

1. Inventario de baselines. Para cada modelo de hardware en la organizacion, obtener la imagen de firmware original del fabricante y crear la whitelist de CHIPSEC. Almacenar estos baselines en un repositorio con control de versiones.

2. Verificacion periodica. Integrar la ejecucion de CHIPSEC en el ciclo de hardening de equipos. Verificar al menos: despliegue inicial, tras cada actualizacion de firmware, y en cualquier investigacion forense.

3. Politica de actualizacion de firmware. Aplicar actualizaciones de firmware del fabricante de forma sistematica. NIST SP 800-147 (BIOS Protection Guidelines) y NIST SP 800-155 (BIOS Integrity Measurement Guidelines) proporcionan el marco de referencia para establecer esta politica.

4. Alertas en fallos de proteccion. Si spi_lock o bios_wp fallan en un equipo que deberia tenerlos habilitados, tratar como incidente de seguridad y escalar.

5. Cadena de custodia. Todo volcado de firmware en una investigacion debe tener hash SHA-256, timestamp y registro del analista. Los volcados son evidencia forense.

Directrices NIST para seguridad de firmware

NIST ha publicado dos documentos de referencia para la proteccion del firmware:

NIST SP 800-147 (BIOS Protection Guidelines, 2011, revisado 2014): establece los requisitos para proteger la integridad del firmware BIOS/UEFI. Define tres principios: el firmware debe ser actualizable de forma autenticada, las actualizaciones deben estar firmadas criptograficamente y el firmware debe tener mecanismos de proteccion contra escritura no autorizada. CHIPSEC verifica directamente los dos ultimos principios.

NIST SP 800-155 (BIOS Integrity Measurement Guidelines, 2011): describe como medir la integridad del firmware BIOS/UEFI usando Trusted Platform Module (TPM). Define el concepto de Root of Trust for Measurement (RTM) y como extender las mediciones a los PCR (Platform Configuration Registers) del TPM. El firmware whitelisting de CHIPSEC implementa un enfoque complementario al de TPM.

Ambos documentos son la base para los requisitos de seguridad de firmware en frameworks como CMMC (Cybersecurity Maturity Model Certification) y FedRAMP.

Limitaciones de CHIPSEC y del analisis de firmware

CHIPSEC es potente pero no omnisciente. Sus limitaciones deben ser entendidas para no crear una falsa sensacion de seguridad.

Intel Management Engine (ME/CSME). La region ME de la flash SPI esta cifrada y firmada por Intel. CHIPSEC puede volcarla pero no analizarla en profundidad. Un implante en el ME (como los descritos por investigadores de Positive Technologies) seria invisible para CHIPSEC.

Microcodigo del procesador. Las actualizaciones de microcodigo se cargan durante el arranque y no son analizables por CHIPSEC. Un ataque teorico a nivel de microcodigo estaria fuera de su alcance.

Dependencia del chipset. Muchos modulos de CHIPSEC dependen de la definicion del chipset especifico. En plataformas no Intel (AMD, ARM), la cobertura es limitada o inexistente para ciertos modulos.

Ataques de tiempo. Las protecciones verificadas por CHIPSEC (como FLOCKDN) se configuran durante el arranque. Si un atacante puede explotar una ventana de tiempo antes de que el bit se active (race condition durante la fase de arranque), la proteccion puede ser eludida sin que CHIPSEC lo detecte despues.

No es tiempo real. CHIPSEC proporciona una instantanea del estado en el momento de la ejecucion. No monitoriza cambios continuos. Un rootkit que modifique el firmware despues de la verificacion no seria detectado hasta la siguiente ejecucion.

Interpretacion experta. Los resultados de CHIPSEC requieren contexto. Un modulo que falla no significa necesariamente una infeccion: puede indicar un firmware antiguo sin las protecciones modernas. La interpretacion correcta requiere conocimiento del chipset y del modelo de hardware especifico.

Fuentes y referencias

• CHIPSEC: Platform Security Assessment Framework. github.com/chipsec/chipsec
• Intel Corporation. CHIPSEC documentation and module reference. chipsec.github.io
• NIST SP 800-147. BIOS Protection Guidelines. Abril 2011, revisado 2014. csrc.nist.gov
• NIST SP 800-155. BIOS Integrity Measurement Guidelines. Diciembre 2011. csrc.nist.gov
• ESET Research. "LoJax: First UEFI rootkit found in the wild." Septiembre 2018
• Kaspersky GReAT. "MoonBounce: the dark side of UEFI firmware." Enero 2022
• Kaspersky GReAT. "MosaicRegressor: Lurking in the Shadows of UEFI." Octubre 2020
• Matrosov, A., Rodionov, E., Bratus, S. "Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats." No Starch Press, 2019
• Binarly Research. FwHunt: firmware threat hunting rules. github.com/binarly-io/FwHunt
• LongSoft. UEFITool: UEFI firmware image viewer and editor. github.com/LongSoft/UEFITool
• LVFS (Linux Vendor Firmware Service). fwupd.org
• MITRE ATT&CK. Pre-OS Boot: System Firmware (T1542.001). attack.mitre.org
• Wojtczuk, R., Kallenberg, C. "Attacking and Defending BIOS in 2015." REcon 2015

---

Articulo con fines exclusivamente defensivos. MalwareIntel documenta herramientas de verificacion de firmware para ayudar a equipos de seguridad a detectar y mitigar rootkits. No se proporcionan binarios, exploits ni instrucciones de replicacion.