Rastros de ejecución

Lo primero que se mira en una imagen de memoria es el árbol de procesos: qué corría y quién lanzó a quién. Volatility 3 lo reconstruye a partir del volcado, y lo que salta no es un proceso raro por su nombre, sino un parentesco imposible: un documento de ofimática que aparece como padre de powershell.exe. Un usuario abriendo una hoja de cálculo no lanza PowerShell; una macro maliciosa dentro del documento, sí. Ese vínculo padre-hijo, capturado en la memoria, es de las señales más claras de ejecución maliciosa, incluso antes de mirar qué hacía el hijo.

El nombre del proceso miente fácil —cualquiera llama a su malware svchost.exe—; el parentesco no, porque describe cómo nació, y un origen imposible no se puede disfrazar.

Ese powershell.exe no corría vacío: se lanzó con una línea de comandos, y esa línea sigue en la memoria. Recuperarla es lo que convierte "PowerShell sospechoso" en "PowerShell que descargó un ejecutable desde una dirección externa y lo lanzó" —el argumento con la URL, el parámetro que oculta la ventana, la instrucción codificada. La memoria conserva el comando completo tal como se invocó; el disco rara vez lo guarda tan íntegro. Por eso la imagen de RAM vale tanto: es la diferencia entre saber que algo se ejecutó y saber exactamente qué hizo.

Leer ese argumento es reconstruir la intención sin ejecutar nada. La huella cuenta la historia; no hace falta —ni se debe— volver a correr el comando para saber qué hacía.

La memoria da el instante; el disco da la historia. Windows registra qué programas se han ejecutado aunque ya no corran ni exista el binario: artefactos de ejecución (Prefetch, Amcache y otros) que anotan el nombre del ejecutable, cuándo corrió y cuántas veces. Autopsy los extrae de la imagen de disco. Así se descubre que el ejecutable descargado corrió a una hora concreta —aun cuando el atacante lo borró después—, porque el rastro de que corrió no está en el fichero, está en el registro que Windows llevó de él.

Que el binario ya no esté no significa que no haya prueba de su ejecución. El sistema operativo lleva su propia contabilidad, y esa contabilidad sobrevive al borrado del programa.

El servidor de ficheros mol-fs01 es Linux, y ahí los artefactos cambian de nombre pero no de lógica. Lo ejecutado y lo accedido queda en otras fuentes: el historial de comandos del intérprete (.bash_history), los registros de autenticación (/var/log/auth.log) que anotan quién entró y desde dónde, y —si la máquina siguiera viva— los procesos activos y sus binarios en /proc. Reconstruir la ejecución en Linux es leer esas fuentes con el mismo criterio: qué se ejecutó, con qué cuenta, desde dónde, y correlacionarlo con la hora del incidente en el puesto Windows.

El oficio es el mismo en los dos sistemas: la ejecución deja huella en sitios distintos, y saber dónde mira cada sistema es lo que permite seguir el rastro cuando el atacante salta de una máquina a otra.

Abre el laboratorio de rastros de ejecución y mira el árbol de procesos del volcado de memoria. Busca el proceso cuyo padre es imposible: un documento de ofimática como padre de un intérprete de comandos. La anotación sobre su línea de comandos recuperada —la que prueba la ejecución maliciosa— lleva el código de la sala.