Forense de memoria en SGX ante sospecha de intromisión vía SMI: cuando el enclave no se lee, pero su entorno sí declara

SMM, SMI, SMRAM, Chipsec y Volatility 3 como piezas de una metodología forense para investigar degradación de enclaves SGX desde firmware o desde el modo más privilegiado del procesador.

1. La pregunta forense no es ya “cómo leo el enclave”, sino “cómo reconstruyo lo que lo rodea”

Intel SGX cambió una premisa clásica del análisis forense de memoria: la idea de que, si se alcanza suficiente privilegio, toda la memoria física puede observarse. SGX introdujo una zona protegida, el Enclave Page Cache, dentro de la Processor Reserved Memory, cuyo contenido queda fuera del alcance del sistema operativo, del hipervisor, de DMA y también del System Management Mode. En otras palabras, el Ring −2 puede seguir siendo más privilegiado que el kernel, pero no por ello adquiere derecho a leer el EPC.

Este detalle altera profundamente la forma de investigar una máquina. Durante años, SMM fue una herramienta atractiva para adquisición de memoria porque podía interrumpir el sistema operativo mediante una System Management Interrupt, ejecutar código desde SMRAM y tomar una fotografía bastante coherente del estado de la plataforma. Pero, en una máquina con SGX, esa fotografía tiene una mancha ciega. Las páginas EPC no se leen en claro. En adquisiciones y reconstrucciones SGX-aware, la lectura directa desde fuera del enclave aparece como una zona no observable, frecuentemente representada como 0xFF.

La consecuencia práctica es importante: el analista no debe interpretar la imposibilidad de leer el EPC como ausencia de evidencia. Debe tratarla como una ausencia trazable. La evidencia no vive dentro del secreto, sino en su perímetro: firmware, locks de plataforma, SMRAM, microcódigo, driver SGX, proceso anfitrión, regiones no confiables, interfaz ECALL/OCALL, patrones de AEX, reinicios, cambios UEFI y telemetría de SMI.

La tesis central de este artículo es sencilla: en un incidente donde se sospecha una intromisión vía SMI, SGX no se investiga intentando romper el enclave, sino reconstruyendo cómo fue rodeado, condicionado o degradado.

2. Dos dominios opacos obligados a convivir

SGX y SMM son dominios opacos para el sistema operativo, pero no son equivalentes. SGX protege código y datos de un enclave frente a software privilegiado. SMM protege código de firmware frente al sistema operativo. Ambos se apoyan en hardware, registros de plataforma y microcódigo, pero sus objetivos son distintos.

El enclave SGX vive en el EPC. La CPU mantiene metadatos en el EPCM para controlar a qué enclave pertenece cada página, qué permisos tiene y si puede ser usada en una transición válida. El SMM vive en SMRAM, una región protegida por el chipset y normalmente situada en TSEG. Cuando SMRAM queda bloqueada durante el arranque, el sistema operativo no debería poder leerla ni modificarla. Cuando un evento SMI se dispara, la CPU entra en SMM, ejecuta un handler y después devuelve el control al sistema interrumpido.

El modelo visual puede resumirse así: la CPU y su microcódigo son el árbitro. SMM puede ver prácticamente toda la DRAM física, pero no el EPC. El kernel y los procesos cargan, mapean y enrutan enclaves, pero tampoco leen el contenido protegido. El enclave puede usar memoria no confiable para comunicarse con el exterior, y ahí empieza el terreno forense.

Esta frontera tiene una lectura incómoda. SMM no necesita romper la confidencialidad del enclave para degradar sus garantías efectivas. Un SMI handler hostil puede actuar sobre lo que el enclave necesariamente comparte con el mundo: buffers de entrada y salida, punteros, estructuras OCALL, estado del proceso anfitrión, rutas de fichero, memoria compartida y sincronización. Puede no leer el secreto, pero puede condicionar lo que entra, alterar lo que sale o forzar salidas asíncronas repetidas.

3. El muro 0xFF y la degradación por AEX

Cuando una SMI se produce durante la ejecución de un enclave, la CPU no entrega sin más el contexto real del enclave al SMI handler. Antes ejecuta un Asynchronous Enclave Exit. El AEX guarda el estado del enclave en la State Save Area, sustituye los registros visibles por valores sintéticos y devuelve una apariencia de ejecución fuera del enclave. Desde la perspectiva de confidencialidad arquitectónica, el secreto no debería quedar expuesto.

Sin embargo, la arquitectura no borra mágicamente todo rastro microarquitectónico. La historia de los ataques contra SGX muestra que la separación ideal entre arquitectura y microarquitectura es frágil. Foreshadow demostró que era posible atacar objetivos de seguridad de SGX mediante ejecución transitoria, filtrando secretos del enclave desde la caché. SGAxe fue más allá al mostrar el impacto de recuperar claves de atestación de enclaves arquitectónicos. Para el analista forense, esto tiene una lectura directa: la versión de microcódigo, las mitigaciones aplicadas y la validez de la atestación no son metadatos administrativos. Son evidencia técnica.

En el contexto SMI, el problema adopta otra forma: una ráfaga de interrupciones de gestión (SMI) puede provocar AEX continuos. SGX no promete disponibilidad, pero muchas aplicaciones reales basadas en enclaves sí dependen de una ejecución suficientemente estable. Un SMM comprometido podría degradar el servicio sin leer el EPC. También podría sincronizar SMI con fases concretas de ejecución, observar efectos laterales o manipular memoria no confiable entre una salida y una reentrada del enclave.

Por eso, en el informe forense conviene separar cuatro planos:

1. Confidencialidad del EPC: si el enclave está en release mode y no hay una vulnerabilidad microarquitectónica explotable, el contenido no se lee.
2. Integridad del proceso anfitrión: la pila, GOT/PLT, heap, tablas OCALL y buffers compartidos están fuera del EPC y son observables.
3. Disponibilidad del enclave: tasas anómalas de SMI o AEX pueden indicar degradación, sabotaje o instrumentación.
4. Confiabilidad del adquisidor: si el SMM o la ruta de adquisición están comprometidos, el dump deja de ser neutral.

4. De SMM como adquisidor a SMM como sospechoso

El salto conceptual más relevante es este: antes SMM podía verse como un aliado del forense; ahora también debe ser tratado como un posible sospechoso. Un volcado tomado desde SMM puede ser coherente desde el punto de vista temporal, pero no necesariamente confiable desde el punto de vista de integridad si la SMRAM, los SMI handlers o el firmware UEFI han sido manipulados.

Esto no es una preocupación teórica. Las amenazas UEFI y de bajo nivel llevan años dejando de ser demostraciones de conferencia. LoJax mostró implantes UEFI en campaña real. BlackLotus confirmó que un bootkit UEFI podía eludir Secure Boot en sistemas Windows 11 actualizados mediante CVE-2022-21894. Estas familias no prueban por sí mismas una manipulación de SMI, pero sí justifican un principio de prudencia: en máquinas con SGX, el análisis de memoria que no valida firmware y plataforma es incompleto.

La pregunta forense ya no debe formularse como “¿hay malware en RAM?”. Debe formularse así: ¿puedo confiar en la plataforma que me entrega esa RAM?

5. Chipsec como herramienta de validación de plataforma

Chipsec no es un antivirus ni una herramienta que “encuentre” automáticamente un rootkit SMM. Su valor está en otro sitio: permite comprobar si las condiciones de seguridad de la plataforma son las esperables. En una investigación SGX/SMM, eso es decisivo.

Los módulos de Chipsec que deben formar parte de la adquisición incluyen, al menos, los relacionados con SMRAM, SMRR, DMA sobre SMM, SMI BIOS y ejecución de código SMM fuera de rangos esperados. En un flujo operativo, el analista debería ejecutar y conservar salida íntegra de:

chipsec_main -m common.smm
chipsec_main -m common.smrr
chipsec_main -m common.smm_dma
chipsec_main -m common.bios_smi
chipsec_main -m common.smm_code_chk
chipsec_main -m common.bios_wp
chipsec_main -m common.spi_lock
chipsec_main -m tools.smm.smm_ptr
chipsec_main -m tools.uefi.scan_image
chipsec_main -m tools.uefi.whitelist

La lectura forense de estos resultados debe ser estricta. Si SMRAM no está bloqueada, si SMRR está mal configurado, si la protección frente a DMA falla, si la configuración de SMI no está bloqueada o si SMM_CODE_CHK_EN no está habilitado y bloqueado cuando la plataforma lo soporta, la cadena de custodia se debilita antes de interpretar cualquier hallazgo SGX. Un sistema con una ruta SMM vulnerable puede estar entregando un relato manipulado.

Chipsec también ayuda a cambiar el lenguaje del informe. En lugar de escribir “no se detecta malware en RAM”, una conclusión más honesta sería: “se ha adquirido memoria con las limitaciones derivadas de SGX; el EPC no es observable en release mode; la confianza en la adquisición queda condicionada al estado de SMRAM, SMRR, SPI/BIOS WP, SMI locks y SMM_CODE_CHK_EN; dichos estados han sido comprobados o, si no se han podido comprobar, deben figurar como limitación”.

6. Qué buscar realmente en una sospecha de intromisión vía SMI

Una hipótesis SMI puede llegar por dos caminos. El primero es firmware: un bootkit UEFI o un implante SMM registra, modifica o sustituye handlers que se ejecutan antes o durante el sistema operativo. El segundo es software privilegiado: un driver, kernel module o proceso con capacidad suficiente dispara software SMI o interactúa con interfaces expuestas por firmware vulnerable.

En ambos casos hay que buscar evidencias en capas distintas.

En UEFI/SPI, importan los cambios en firmware, NVRAM, variables de arranque, degradación de Secure Boot, BIOS write protection no bloqueado y diferencias frente a una imagen OEM. En SMM/SMRAM, interesan D_LCK, SMRR, TSEG, protección DMA, SMI handlers no esperados, handlers periódicos, CommBuffers y validación insuficiente de punteros. En SGX/kernel, se buscan rangos EPC, presencia de drivers isgx o DCAP, revisión de microcódigo, flags del enclave y procesos anfitriones. En espacio de usuario, se analizan instrucciones ENCLU, runtimes SGX, tablas ECALL/OCALL, memoria compartida no confiable, pila, GOT/PLT, buffers y comunicaciones. En timeline, se cruzan picos de SMI, AEX, reinicios, cambios UEFI, actividad de enclave, errores de atestación, tráfico cifrado y eventos de sistema.

No basta con una herramienta. Hace falta una matriz de evidencias.

7. Volatility 3 como capa de reconstrucción del proceso anfitrión

Volatility 3 no va a leer el EPC de un enclave en release mode. Pedirle eso sería pedirle que viole el modelo de seguridad que precisamente se está investigando. Su papel es otro: reconstruir el contexto observable del enclave.

En una imagen Linux, el análisis con Volatility puede ayudar a identificar procesos que cargan runtimes SGX, VMAs asociadas a /dev/sgx_enclave o /dev/isgx, cadenas relacionadas con libsgx_urts, sgx_ecall, ocall_table, instrucciones ENCLU y regiones que en el volcado aparecen como páginas 0xFF. Estas señales no prueban una intromisión SMM, pero permiten seleccionar procesos anfitriones, ubicar memoria no confiable y orientar el reverse engineering posterior con radare2, Ghidra u otras herramientas.

El plugin incluido con este artículo, sgx_smi_degradation.py, sigue esa filosofía. Es deliberadamente prudente: no explota nada, no intenta leer EPC, no interactúa con firmware en vivo y no afirma por sí solo que exista compromiso SMM. Lo que hace es producir una triage table con tres tipos de evidencia:

1. Indicadores de plataforma importados desde Chipsec, especialmente fallos en módulos relacionados con SMM, SMRR, SMI, BIOS write protection y SMM_CODE_CHK_EN.
2. Indicadores temporales importados desde una línea de tiempo de SMI, buscando ráfagas o deltas anómalos.
3. Indicadores de proceso en el dump, buscando artefactos SGX, instrucciones ENCLU/ENCLS, cadenas ECALL/OCALL y páginas completamente 0xFF en VMAs muestreadas.

Su salida está pensada para alimentar el informe, no para sustituirlo. Una fila de alta confianza debe leerse como “aquí hay un punto que merece correlación”, no como “aquí está la prueba definitiva”.

(nota: la continuación de este sencillo plugin la he publicado en este enlace de LinkedIN)

Instalación del plugin

Enlace al github que contiene el plugin

Copiar el fichero en el árbol de plugins Linux de Volatility 3:

cp volatility3_plugins/sgx_smi_degradation.py \
   volatility3/volatility3/plugins/linux/sgx_smi_degradation.py

Ejecutar sobre una imagen de memoria:

python3 vol.py -f mem.raw linux.sgx_smi_degradation.SgxSmiDegradation \
  --scan-memory \
  --max-vma-read 1048576

Con evidencias auxiliares:

python3 vol.py -f mem.raw linux.sgx_smi_degradation.SgxSmiDegradation \
  --scan-memory \
  --max-vma-read 2097152 \
  --chipsec-report file:///jaberme/host01/chipsec_report.json \
  --smi-timeline file:///jaberme/host01/smi_timeline.csv \
  --smi-burst-threshold 100

Ejemplo de interpretación:

Scope     PID   Process   Object                         Evidence                         Score Confidence Interpretation
CHIPSEC   0     platform  common.bios_smi                SMILock not set                  8     HIGH       Plataforma o SMM no plenamente confiable...
SMI       0     platform  SMI_TIMELINE                   max_delta=427                   7     HIGH       Ráfaga de SMI compatible con degradación...
PROCESS   1824  broker    0x7f... libsgx_urts.so         ENCLU=14, string:ocall_table     9     HIGH       Proceso anfitrión SGX con transición ENCLU...

La lectura correcta de ese ejemplo no es “SMM está comprometido”. La lectura correcta es: “hay un proceso SGX con interfaz observable, una plataforma con locks deficientes y una anomalía temporal SMI; procede correlación con firmware, SMRAM, SPI/PCR0, red, ficheros y reverse del host”.

8. Propuesta de flujo forense completo

Un procedimiento robusto debería comenzar antes de tocar la RAM. El primer paso es documentar la plataforma: modelo, BIOS/UEFI, versión, microcódigo, estado de SGX, EPC, SGX2 si aplica, Secure Boot, TPM y configuración de arranque. El segundo paso es ejecutar Chipsec y preservar íntegra la salida. El tercero es adquirir memoria con una herramienta SGX-aware, conservando metadatos de EPC aunque el contenido no sea legible. El cuarto es analizar procesos, VMAs y runtimes SGX con Volatility 3. El quinto es reconstruir interfaces ECALL/OCALL y memoria no confiable. El sexto es correlacionar con firmware, PCRs, logs, red y tiempo.

Una cadena mínima de custodia debería contener:

1. Hash de imagen RAM y herramienta de adquisición.
2. Estado SGX: CPUID, EPC, PRMRR, microcódigo.
3. Estado firmware: versión UEFI, Secure Boot, variables de arranque.
4. Estado Chipsec: common.smm, common.smrr, common.smm_dma, common.bios_smi, common.smm_code_chk, BIOS/SPI locks.
5. Evidencia SPI: dump o, al menos, hashes y comparación OEM si es viable.
6. TPM PCR0 y PCRs relevantes si existe arranque medido.
7. Volatility: procesos anfitriones SGX, VMAs, ENCLU, ECALL/OCALL, 0xFF pages.
8. Timeline: SMI, AEX si se instrumentó, reinicios, errores de atestación, cambios UEFI, actividad de red.

El objetivo es poder sostener una conclusión matizada. No “el enclave está limpio” ni “no hay malware en RAM”, sino algo más útil: “el enclave no es observable por diseño; el proceso anfitrión sí lo es; la plataforma presenta o no presenta condiciones de confianza; la hipótesis de degradación vía SMI queda apoyada, debilitada o no concluyente en función de esta matriz”.

9. Indicadores que elevan la sospecha

Hay señales que, por separado, pueden ser débiles, pero juntas merecen escalado:

• SGX activo con proceso anfitrión, uso de runtime SGX y tablas OCALL visibles.
• Páginas 0xFF trazables en el dump, coincidiendo con actividad SGX esperada.
• Microcódigo atrasado frente a vulnerabilidades SGX conocidas.
• Fallos Chipsec en SMRAM, SMRR, SMM DMA, BIOS SMI locks, BIOS WP o SMM_CODE_CHK_EN.
• Variables UEFI modificadas, Secure Boot degradado o inconsistencias en PCR0.
• SMI periódicas o ráfagas coincidentes con actividad del enclave.
• CommBuffers o interfaces de SMI handlers que aceptan punteros de memoria controlables.
• Cambios en memoria no confiable justo antes o después de transiciones ECALL/OCALL.
• Tráfico cifrado sostenido desde el proceso anfitrión con errores de atestación o comportamiento anómalo.

Ninguna de estas señales aisladas basta para afirmar un rootkit SMM. Pero la suma de varias cambia la valoración del riesgo.

Apéndice. Plugin Volatility 3 incluido

El fichero volatility3_plugins/sgx_smi_degradation.py acompaña a este artículo. Su propósito es apoyar el estudio forense de una posible degradación SGX vía SMI desde una imagen Linux y evidencias auxiliares. El plugin produce filas de tipo CHIPSEC, SMI y PROCESS, con puntuación, confianza e interpretación.

Limitaciones importantes:

• No lee EPC en release mode.
• No sustituye Chipsec, un dump SPI ni una validación TPM/PCR.
• No prueba compromiso SMM por sí solo.
• Su valor está en la correlación: proceso anfitrión SGX + locks deficientes + ráfagas SMI + evidencias firmware.

Referencias técnicas seleccionadas

1. F. Toffalini, A. Oliveri, M. Graziano, J. Zhou, D. Balzarotti. The Evidence Beyond the Wall: Memory Forensics in SGX Environments. Forensic Science International: Digital Investigation, 2021.
2. V. Costan, S. Devadas. Intel SGX Explained. IACR ePrint 2016/086.
3. J. Van Bulck et al. Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution. USENIX Security 2018.
4. S. van Schaik, A. Kwong, D. Genkin, Y. Yarom. SGAxe: How SGX Fails in Practice. 2020.
5. Intel. CHIPSEC: Platform Security Assessment Framework.
6. CHIPSEC documentation. common.bios_smi and common.smm_code_chk modules.
7. ESET Research. BlackLotus UEFI bootkit: Myth confirmed. 2023.
8. ESET Research. LoJax: First UEFI rootkit found in the wild. 2018.
9. Volatility Foundation. Volatility 3 Documentation: Writing Plugins.