Skip to content

Más análisis forense de memoria en sistemas Windows: Mandiant Memoryze y AuditViewer

Publicado por Sergio Hernando el 8 diciembre 2008

Hola,

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:

  1.  
  2. < ?xml version="1.0" encoding="utf-8"?>
  3. <script xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" chaining="implicit">
  4. <commands>
  5. <command xsi:type="ExecuteModuleCommand">
  6. <module name="w32processes-memory" version="1.0.34.0" />
  7. <config xsi:type="ParameterListModuleConfig">
  8. <parameters>
  9. <param name="pid">
  10. <value xsi:type="xsd:unsignedInt">4294967295</value>
  11. </param>
  12. <param name="handles">
  13. <value xsi:type="xsd:boolean">true</value>
  14. </param>
  15. <param name="sections">
  16. <value xsi:type="xsd:boolean">true</value>
  17. </param>
  18. <param name="ports">
  19. <value xsi:type="xsd:boolean">true</value>
  20. </param>
  21. <param name="strings">
  22. <value xsi:type="xsd:boolean">false</value>
  23. </param>
  24. </parameters>
  25. </config>
  26. </command>
  27. <command xsi:type="ExecuteModuleCommand">
  28. <module name="w32drivers-signature" version="1.0.34.0" />
  29. </command>
  30. <command xsi:type="ExecuteModuleCommand">
  31. <module name="w32kernel-rootkitdetection" version="1.0.30.0" />
  32. <config xsi:type="ParameterListModuleConfig">
  33. <parameters>
  34. <param name="idt">
  35. <value xsi:type="xsd:boolean">true</value>
  36. </param>
  37. <param name="ssdt_index">
  38. <value xsi:type="xsd:boolean">true</value>
  39. </param>
  40. <param name="ssdt_inline">
  41. <value xsi:type="xsd:boolean">true</value>
  42. </param>
  43. <param name="drivers">
  44. <value xsi:type="xsd:boolean">true</value>
  45. </param>
  46. </parameters>
  47. </config>
  48. </command>
  49. </commands>
  50. </script>
  51.  

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:

mandiant memoryze

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.

auditviewer

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)

auditviewer

auditviewer

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.

auditviewer

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,

Be Sociable, Share!

Categoría/s → Forensics

Escribir un comentario

Note: XHTML permitido. Tu email nunca será publicado.

Suscribirse a los comentarios via RSS