El otro día efectuamos un análisis forense de memoria de una máquina en Windows en producción, y lo hicimos empleando dos herramientas: Mantech Memory DD y Volatility.

Hoy vamos a realizar otro análisis empleando herramientas distintas, para ir ampliando un poco el abanico de metodologías que existen, que son muchas. Utilizaremos Mandiant Memoryze y AuditViewer, y nuestro objetivo es el mismo que teníamos el otro día: obtener e interpretar los datos volátiles (RAM) de una máquina en ejecución.

1. Extracción de los datos forenses

Una vez hayamos instalado Mandiant Memoryze, lo primero es generar un esquema XML con el tipo de datos que vamos a extraer. Los autores recomiendan usar un script similar al que sigue:

 
< ?xml version="1.0" encoding="utf-8"?>
<script xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" chaining="implicit">
  <commands>
    <command xsi:type="ExecuteModuleCommand">
      <module name="w32processes-memory" version="1.0.34.0" />
      <config xsi:type="ParameterListModuleConfig">
<parameters>
<param name="pid">
            <value xsi:type="xsd:unsignedInt">4294967295</value>
          </param>
<param name="handles">
            <value xsi:type="xsd:boolean">true</value>
          </param>
<param name="sections">
            <value xsi:type="xsd:boolean">true</value>
          </param>
<param name="ports">
            <value xsi:type="xsd:boolean">true</value>
          </param>
<param name="strings">
            <value xsi:type="xsd:boolean">false</value>
          </param>          
        </parameters>
      </config>
    </command>
    <command xsi:type="ExecuteModuleCommand">
      <module name="w32drivers-signature" version="1.0.34.0" />
    </command>
    <command xsi:type="ExecuteModuleCommand">
      <module name="w32kernel-rootkitdetection" version="1.0.30.0" />
       <config xsi:type="ParameterListModuleConfig">
<parameters>
<param name="idt">
            <value xsi:type="xsd:boolean">true</value>
        </param>
<param name="ssdt_index">
            <value xsi:type="xsd:boolean">true</value>
        </param>
<param name="ssdt_inline">
            <value xsi:type="xsd:boolean">true</value>
        </param>
<param name="drivers">
            <value xsi:type="xsd:boolean">true</value>
        </param>
        </parameters>
      </config>
    </command>
  </commands>
</script>
 

Este script permite extraer la siguiente información:

• Una auditoría completa de procesos, con puertos (si realizan llamadas TCP/IP), manejadores y secciones. No se capturan strings, porque consumen un elevado espacio en disco al barrer el espacio de direcciones de los procesos en ejecución, y para el caso que nos ocupa, no nos ofecerá información relevante.
• Un barrido de firmas de drivers para enumerar la totalidad de controladores cargados, incluso los que están ocultos como consecuencia de romper los vínculos con la lista de módulos cargados (PsLoadedModuleList)
• Detección de hooks, analizando hooks de kernel comunes (ojito, que aunque sí es frecuente, no todos los provocan elementos malware)

Salvaremos este documento con el nombre AllAudits.Batch.XML, en la misma ruta donde hayamos instalado Memoryze. Una vez esto hecho, estamos en condiciones de efectuar la extracción, indicándole al programa que emplee el script que acabamos de generar:

C:\Archivos de programa\Mandiant\Memoryze>Memoryze.exe -o -script AllAudits.Batch.xml -encoding none

La ejecución de Memoryze generará una serie de ficheros. En nuestro caso:

Los ficheros issues son aquellos que recogen problemas a la hora de efectuar la extracción. Hay uno para cada tipo, y conviene repasarlos para determinar qué nos hemos dejado en el tintero, y por qué. Normalmente responderán a warnings relacionados con la inaccesibilidad a la hora de traduccir o mapear direcciones de memoria, pero no perdemos nada echando un ojo a los avisos generados durante el evento de extracción.

2. Interpretación de los resultados.

Al ser estructuras XML son datos fácilmente interpretables utilizando cualquier editor, si bien nos apoyaremos en AuditViewer, un conjunto de scripts de Python desarrollados por los mismos programadores de Memoryze, lo que facilitará enormemente la ordenación e inspección de resultados.

Es por tanto que necesitaremos Python para poder interpretar el output de la auditoría, y adicionalmente, WxPython como GUI toolkit (esto permitirá visualizar en modo de interfaz gráfico el script de análisis). Mi consejo es descargar el runtime win32-unicode para Python 2.6 (el que a día de publicar este texto, es la última versión estable)

Una vez cumplidos los requisitos, un doble click sobre AuditViewer.py bastará para poder abrir el visor de auditoría, aunque el que lo prefiera, puede lanzarlo desde la linea de comandos.

Una vez abierto el interfaz, seleccionaremos la auditoría (directorio Audits en el directorio de instalación de Memoryze) y automáticamente, se parsearán los resultados de los ficheros XML generados en la adquisición.

La información es cuantiosa, y merece la pena efectuar una captura de prueba para poder ver los detalles. Por poner un ejemplo, esta es la información que nos permite ver que en el momento de adquirir los datos, se estaba ejecutando con PID 3232, una sesión PuTTY desde una IP local 192.168.213.250 a la de otra máquina con IP 192.168.213.254 (en este caso, es mi servidor FreeBSD), identificando el usuario Windows con el cual se está ejecutando el programa. Como curiosidad, en la misma captura aparece fdm.exe, el proceso de Free Download Manager, así como el propio proceso de Memoryze (memoryze.exe) y del motor Python que da servicio al visor de auditoría (python.exe)

En este otro ejemplo, el usuario de sistema NT AUTHORITY\SYSTEM, con PID 4, ejecuta dos acciones TCP/IP, la primera es una conexión Samba contra el servidor FreeBSD de mi red local, indicando IPs, y la siguiente, es una conexión HTTP contra una IP de Sourceforge. También se indican las IPs origen y destino.

Como podéis ver, los procesos de extracción son completos y permiten obtener para un sistema en ejecución información valiosa que puede ser empleada en procesos de investigación. Los procesos de adquisición y análisis de información volátil son cada vez más oportunos, ya que buena parte de la carga incriminatoria de las pruebas puede residir en la actividad que una máquina en funcionamiento tenía en un momento determinado (por ejemplo, en el momento de detener a un sospechoso). Estos análisis complementan la información recogida siguiendo el paradigma forense tradicional, en el que existe un escenario post-mórtem con la máquina apagada, con lo que siempre que sea posible, es recomendable su aplicación.

Ni que decir tiene que este tipo de herramientas se puede emplear para el self assessment, es decir, el autoanálisis de máquinas en el caso de que, por ejemplo, se presenten dudas sobre el estado de contaminación de la misma.

Un saludo,

Vamos a ver un ejemplo muy sencillo sobre cómo ejecutar una inspección forense de la memoria de un sistema Windows.

Para ello vamos a necesitar dos herramientas: Mantech Memory DD y Volatility, sobre el cual ya hablamos en este blog. Sobre la elección de ambas herramientas es principalmente porque son libres y gratuitas, con lo que experimentar no tendrá coste para nosotros.

El análisis forense de volcados de memoria cobra especial importancia en eventos de respuesta ante incidentes, ya que permite obtener una foto de cómo se encuentra la RAM, así como para obtener información relevante para los análisis de máquinas donde se desea saber el estado de la memoria antes de proceder a su apagado. La RAM es volátil, y si pulsamos off, nos quedamos sin información.

Extracción de un volcado de memoria

Tal y como hemos comentado, emplearemos una utilidad que se llama MDD. La sintaxis básica es la siguiente:

mdd_1.3.exe -o nombredelvolcado

Así, por ejemplo:

En este proceso hemos obtenido un fichero que se llama volcadomemoria.img, cuyo MD5 (importante para preservar la integridad de la evidencia) es cf1d38ca7dbf0ab7f1444df158cc7150 y que ha resultado exitosa para 258009 operaciones de mapeo, siendo infructuosa en 3634 operaciones. El tamaño resultante es de 1.071.689.728 bytes.

Análisis del volcado

Nos apoyaremos en Volatility. Este framework permite el análisis de volcados de memoria y es mutiplataforma (siempre y cuando tengamos Python instalado)

Es bastante fácil de usar. Así, por ejemplo, si deseamos conocer los procesos que estaban ejecutándose en memoria, emplearemos

$ python volatility pslist -f nombredelvolcado

En nuestro caso:

No muestro la totalidad de los procesos de una manera intencionada. En este ejemplo vemos los procesos smss.exe (gestor de sesiones de Windows), csrss.exe (client server runtime), winlogon.exe (aplicación de logon de Windows), services.exe (servicios y controlador) y lsass.exe (ejecutable LSA Windows)

Volatility permite lanzar muchas consultas interesantes desde el punto de vista forense. Veamos algunos ejemplos

Obtención de propiedades de la imagen

$ python volatility ident -f volcadomemoria.img
Image Name: volcadomemoria.img
Image Type: XP SP2
VM Type: pae
DTB: 0x73a000
Datetime: Tue Dec 02 22:19:29 2008

Fecha y hora del volcado

Aunque es parte de la consulta anterior, se puede invocar de modo independiente

$ python volatility datetime -f volcadomemoria.img
Image local date and time: Tue Dec 02 22:19:29 2008

Módulos cargados en el sistema

La lista es, obviamente, mucho más larga. Está truncada intencionadamente.

Objetos EPROCESS

En este ejemplo vemos un proceso correspondiente a la utilidad Blowfish Advanced CS (bfacs.exe), una utilidad que os recomiendo para cifrar información personal en vuestros discos.

Ficheros abiertos por cada proceso

Esta consulta es muy intensa, pero es extremadamente útil. Mostramos un ejemplo:

************************************************************************
Pid: 1036
File \WINDOWS\system32
File \WINDOWS\system32\ega.cpi
************************************************************************

Y para identificar ese PID recurrimos a la lista de procesos:

$ python volatility pslist -f volcadomemoria.img | grep 1036
csrss.exe 1036 960 13 704 Tue Dec 02 18:24:06 2008

De donde se deduce que el proceso csrss.exe está empleando el fichero fichero de codificación (codepage information file) \WINDOWS\system32\ega.cpi

En cuanto a aplicaciones convencionales:

************************************************************************
Pid: 4008
File \Archivos de programa\Mozilla Firefox
File \Documents and Settings\sergioadmin\Application Data\Mozilla\Firefox\Profiles\12hgbwhw.default\parent.lock

De donde se deduce que el usuario ejecutaba Firefox, con PID 4008, y empleando el perfil 12hgbwhw.default (el cual podremos inspeccionar con la imagen del disco duro que levantemos en el escenario).

Volatility tiene muchas más funciones, y estas tan sólo son algunas. La idea es mostrar cómo se adquiere un volcado de memoria, el tipo de información que puede almacenar, cómo se lanza un procesado básico, así como la importancia de levantar este tipo de información siempre que sea posible.

Espero que el texto os resulte de utilidad.

Un saludo,