Cuando el EDR se queda corto: forense de memoria para 400 analistas SOC
El 21 de octubre dimos la sesión de forense de memoria del bootcamp SOC Nivel 2 de Comunidad DOJO. El caso que recorrimos: una alerta de inyección de procesos donde el EDR podía probar que algo se inyectó, pero no qué.
7 min de lectura
El miércoles 21 de octubre dimos la sesión de forense de memoria del bootcamp de Analista SOC Nivel 2 organizado por Comunidad DOJO. Más de 400 analistas de toda Latinoamérica pasaron por la llamada, lo que la convierte en la sala más grande a la que le hemos enseñado.
Elegimos el tema por un cambio que la mayoría de los equipos SOC ya siente. Los ataques que nos llegan hoy casi nunca traen un archivo que valga la pena escanear. La carga se arma en memoria, corre dentro de un proceso que viene con Windows y deja muy poco en disco para enviar a ningún lado. Así que queríamos dedicar noventa minutos al lugar donde al atacante le cuesta más no dejar rastro: la RAM.
Por qué vale la pena mirar la memoria
Todo lo que se ejecutó tuvo que existir en memoria en algún momento. Ese es el argumento completo, y se sostiene por más cuidadoso que haya sido el atacante con el disco.
Un volcado te da procesos e hilos, archivos abiertos y su contenido, URLs y direcciones IP, credenciales, claves de registro, líneas de comando y shellcode en una región que nadie escribió en disco. También es el único lugar donde algunos ataques se ven. La inyección de procesos, la carga reflectiva de DLLs, el process hollowing y buena parte de las técnicas de evasión de EDR viven en memoria por diseño.
Adquirir el volcado sin arruinarlo
La mitad de la sesión fue adquisición, porque es ahí donde los casos se dañan antes de empezar.
Las herramientas no son polémicas: WinPmem, DumpIt, FTK Imager, LiME en Linux, o el propio EDR
— CrowdStrike lo hace desde una sesión RTR con xmemdump. La disciplina alrededor importa más
que cuál elijas.
Orden de volatilidad. Adquiere la memoria antes que nada. No después del reinicio que alguien propone mientras todavía estás en la llamada.
Firma de drivers. Windows Driver Signature Enforcement espera un driver firmado, y si tu herramienta de adquisición tiene uno es algo que conviene averiguar antes de un incidente y no durante.
Integridad. Calcula el SHA-256 al terminar. Anota la herramienta, la versión, el host y la hora. Un volcado por el que nadie puede responder es un volcado que los abogados de tu cliente no van a poder usar.
Llévate también los archivos de paginación. pagefile.sys, swapfile.sys y hiberfil.sys
están en la raíz del disco y suelen guardar páginas que ya no están en RAM. El archivo de
hibernación es casi una foto completa de la memoria en un momento anterior, que a veces es
justo el momento que querías.
El caso: una alerta que el EDR no pudo terminar
Lo que sigue es el escenario que armamos para la sesión. Corre sobre un host de laboratorio en nuestro propio tenant de CrowdStrike, y la inyección la hace una prueba T1055 de Atomic Red Team, no un intruso real. Enseñamos con datos de laboratorio a propósito: lo que importa es el método, y el método es idéntico.
CrowdStrike levanta una detección sobre notepad.exe. Proceso sospechoso, revisar el árbol de
procesos.
Revisar el binario no lleva a ningún lado, y esa es la primera lección.
El árbol de procesos es donde se pone interesante.
CreateRemoteThread.exe corre contra notepad.exe, y notepad.exe después lanza
calc.exe. Pregúntate con qué frecuencia el Bloc de notas abre la Calculadora por su cuenta.
El EDR nos dijo bastante. Algo se inyectó en un proceso legítimo, y ese proceso hizo después algo que no le corresponde. Lo que el EDR no puede decirnos es qué se inyectó. La telemetría describe el acto. No contiene la carga.
Ese es el momento de adquirir un volcado de memoria.
Cuatro pasos dentro del volcado
Usamos Volatility 3 y trabajamos las primeras cuatro fases del método de seis pasos de SANS.
Identificar procesos sospechosos. windows.pslist muestra notepad.exe con PID 6036 y un
padre 4828 — y el proceso 4828 no aparece por ningún lado en la lista. windows.psscan recorre
la memoria buscando estructuras EPROCESS en vez de seguir la lista activa, así que comparar
ambos es rutina. Donde no coincidan, piensa en DKOM: quien edita PsActiveProcessHead puede
desenlazar un proceso en ejecución de la lista que lee el Administrador de tareas, sin
detenerlo.
Analizar los objetos del proceso. windows.cmdline, windows.dlllist, windows.handles y
windows.getsids. Notepad corría como Administrator. Entre sus handles había un directorio
bajo AppData\Local\Temp. Una DLL cargada desde fuera de las rutas del sistema siempre merece
una segunda mirada aquí.
Revisar artefactos de red. windows.netstat para sockets vivos, windows.netscan para
barrer la memoria en busca de estructuras, incluidas conexiones ya cerradas. En la segunda es
donde suele aparecer el C2 de ayer.
Buscar código inyectado. Y aquí es donde cae la lección.
Por qué malfind no encontró nada
windows.malware.malfind es el plugin obvio, y no devolvió nada para notepad.exe.
Malfind busca regiones privadas, ejecutables, escribibles y sin respaldo de un archivo en disco. La lógica es buena. También es pública, y el atacante sabe leer:
- Reservar la región como
READWRITE - Escribir la carga
- Cambiarla a
READEXECUTE - Ejecutarla
- Volverla a dejar en
READWRITE
Para cuando alguien captura la memoria, la región se ve como una reserva escribible cualquiera. Malfind pasa de largo. El código sigue ahí.
Así que dejamos de preguntarle a la herramienta y enumeramos el proceso nosotros —
windows.vadinfo --pid 6036 --dump para volcar cada región del árbol VAD, y después leer las
cabeceras.
xxd. La cadena calc ya se lee en la columna ASCII.
objdump. La instrucción en el offset 0xa es push 0x636c6163: cuatro bytes que deletrean calc. El resto recorre el PEB para encontrar WinExec y la llama. Ahí está la carga cuyos efectos veía el EDR sin poder ver su contenido.
Una región vecina empezaba con MZ seguido de !This program cannot be run in DOS mode, es
decir un PE en memoria sin nada equivalente en disco.
El volcado respondió la pregunta que el EDR había abierto y dejado sin cerrar.
MITRE ATT&CK
Técnicas cubiertas en la sesión. Son las técnicas que enseñamos y demostramos contra un host de laboratorio, no hallazgos de un caso de cliente.
| Táctica | Técnica | ID |
|---|---|---|
| Evasión de defensas | Process Injection | T1055 |
| Evasión de defensas | Process Injection: Dynamic-link Library Injection | T1055.001 |
| Evasión de defensas | Reflective Code Loading | T1620 |
| Evasión de defensas | Rootkit | T1014 |
Lo que queremos que los analistas se lleven
Un hash limpio no prueba nada sobre el comportamiento. notepad.exe era genuino, firmado e
intacto. La parte maliciosa nunca tuvo un archivo propio.
La lógica de detección publicada la pueden leer los dos lados. Malfind es excelente y tiene un punto ciego documentado. Saber cómo decide tu herramienta es lo que te permite notar cuándo un resultado está sospechosamente callado.
El forense de memoria no reemplaza al EDR. Termina lo que el EDR empezó. CrowdStrike encontró la actividad, nos dio las relaciones entre procesos y la línea de tiempo, y nos dijo dónde apuntar el microscopio. El volcado fue lo que nos dejó leer la carga.
También dedicamos tiempo a MemProcFS, que monta un volcado como una unidad de disco y es una puerta de entrada más amable que la línea de comandos de Volatility para quien recién empieza.
Trabajar con nosotros
Duntze Security ofrece detección y respuesta gestionada y forense digital para empresas en Panamá y Latinoamérica. Los analistas que vigilan tu entorno son los mismos que responden cuando pasa algo, y los que dan sesiones como esta.
Si tu EDR alguna vez te dijo que algo se había inyectado sin decirte qué, esa es la brecha que cerramos. Cuéntanos qué estás protegiendo.
Disponibles para charlas y formación sobre forense de memoria, DFIR y operaciones SOC, en español, inglés o alemán.