Análisis forense con volatility

Bienvenidos a un nuevo post en ByteMind. En el caso de hoy les enseñaremos a realizar un análisis forense con volatility, una herramienta muy útil para la respuesta de incidentes y análisis de malware de un volcado de memoria creado previamente.

 

¿Por qué Volatility?

Volatility es una herramienta forense de código abierto para la respuesta a incidentes y el análisis de malware. Está escrito en Python y es compatible con Microsoft Windows, Mac OS X y Linux.

Es capaz de instalarse en cualquier sistema sobre el cual se disponga de Python, por lo que es compatible con multitud de sistemas ya utilicemos Windows, Linux o Mac, lo que facilita mucho el uso del mismo en diferentes sistemas operativos.

Dispone además de una API extensible y programable, donde además de los propios módulos que ofrece el propio Volatility es posible la creación de módulos personalizados con el fin de llevar a cabo análisis de una forma automática, la creación de una interfaz web o GUI personalizada o simplemente explorar la memoria del kernel de una forma automatizada. Los analistas pueden agregar nuevos espacios de direcciones, complementos, estructuras de datos y superposiciones para soldar el marco de trabajo a las necesidades de un momento dado.

Es posible explorar la documentación propia de dicho módulo desde su página oficial para conocer más a fondo sus componentes internos.

Volatility proporciona capacidades que por defecto el propio depurador del kernel de Windows no permite, como podría ser hacer un carving de un histórico de comandos, buffer de entrada/salida de la consola, objetos de usuario y estructuras de datos relacionados con la red.

Ofrece también una cobertura completa de formatos de archivo donde ofrece la posibilidad de analizar volcados sin procesar, por caída, archivos de hibernación, estados guardados de virtualizadores como VMware o volcados del núcleo de VirtualBox, LiME (Linux Memory Extractor), expert witness (EWF) y memoria física directa sobre Firewire. Además también es posible convertir entre los diferentes formatos disponibles por si utilizamos una herramienta diferente a esta y necesitamos un formato concreto.

Dispone además de una serie de algoritmos rápidos y eficientes que le permiten analizar los volcados de memoria RAM de sistemas de gran volumen sin un consumo de recursos excesivo y en muy poco tiempo.

 

Instalación de Volatility

Para la instalación de Volatility, necesitaremos en primer lugar disponer de Python en la versión 2.7 o superior instalado en nuestro sistema.

Completada esta instalación deberemos de descargarnos el código del mismo desde su repositorio oficial en github con el siguiente comando:

Completado este paso tendríamos dos opciones, instalar el mismo en nuestro sistema o ejecutar directamente el fichero .py disponible en dicho código.

En caso de desear instalar el mismo es tan sencillo como ejecutar el fichero setup.py

Este comando anterior se encargará de instalar las dependencias necesarias para el mismo así como los propios paquetes del mismo, creando a su vez también un fichero ejecutable en la ruta /usr/bin/volatility

Si la opción no es instalarla, podemos ejecutar el mismo directamente con el siguiente comando:

 

Primeros pasos con volatility

Como siempre, al igual que en la gran mayoría de herramientas disponemos de una amplia ayuda con la opción –help

Vista la ayuda del comando vamos a ver ahora diferentes comandos que nos ayudarán a obtener información del dump así como podría ser el sistema operativo del cual se ha realizado, los procesos que corren en la misma, etc.

 

Identificación de imágenes

Imageinfo

Una de las opciones más sencillas y el primer paso en la mayoría de situaciones es descubrir de qué sistema operativo se ha realizado el dump sobre el cual vamos a realizar el análisis, para ello utilizaremos el módulo imageinfo el cual nos indicará esta información. El comando para lograr esto sería el siguiente:

Y que podemos apreciar en la siguiente captura de pantalla donde lo hemos utilizado para conocer el sistema de un dump de memoria de windows:

 

Como vemos en el ejemplo anterior, al realizar la función de imageinfo, este nos ha sugerido varios perfiles a los cuales puede pertenecer el dump, que en este caso pertenece a un sistema Windows XP SP2 y cuya arquitectura es x86.

Conocido el perfil, ahora necesitaremos indicarle el mismo para realizar un análisis más exhaustivo con alguno de los módulos que tengamos disponibles, para indicar el mismo utilizaríamos la opción –profile como vemos a continuación:

 

Kdbgscan

A diferencia de imageinfo, que nos ofrece una serie de perfiles sugeridos, kdbgscan nos ofrece un perfil exacto de la imagen analizada así como el identificados exacto de KDBG. Este plugin escanea las firmas de las cabeceras de la imagen y las contrarresta con los perfiles almacenados en la base de datos de volatility, reduciendo con ello el número de posibles falsos positivos.

Podemos ver un ejemplo en la siguiente imagen donde podemos observar que nos saca el perfil exacto, dando más información de la obtenida anteriormente con imageinfo

 

Kpcrscan

Se puede utilizar este comando para buscar posibles estructuras de KPCR comprobando los miembros con autorreferencia. En un sistema multinúcleo, cada procesador tiene su propio KPCR. Por lo tanto, se podrán ver detalles para cada procesador, incluidas las direcciones IDT y GDT; hilos actuales, inactivos y siguientes, número de CPUs, proveedor y velocidad; y valor CR3.

Si KdVersionBlock no es nulo, entonces es posible encontrar la dirección KDBG de la máquina a través del KPCR. De hecho, el método de respaldo para encontrar KDBG utilizado por complementos como pslist es aprovechar kpcrscan y luego llamar a la función de la API KPCR.get_kdbg().

 

Identificación de procesos

pslist

Para la enumeración de los procesos de un sitema, utilizaremos el plugin pslist. Este recorrerá la lista vinculada que apunta a PsActiveProcessHead y mostrará el desplazamiento, nombre del proceso, ID del proceso e ID del proceso padre del mismo, el número de subprocesos, número de identificadores, así como la fecha y hora en la cuál dicho proceso empezó y terminó. A partir de la versión 2.1 muestra también el ID de sesión y si dicho proceso es un Wow64, es decir, que utiliza un espacio de dirección de 32 bits en un sistema de 64 bits.

Hay que tener en cuenta también que los procesos System y smss.exe no dispondrán de un ID de sesión debido a que el sistema se inicia antes de que se establezcan dichas sesiones. Podemos ver un ejemplo del mismo a continuación:

pslist por defecto mostrará los offsets virtuales para _EPROCESS pero podemos ver los offsets físicos mediante la opción -P:

 

pstree

Podemos ver también esta lista de procesos en forma de árbol utilizando el plugin pstree, lo que enumerará los procesos con la misma técnica utilizada en pslist pero con una vista diferente de la misma y que puede ayudar a identificar de una forma más rápida el padre de cada uno de estos.

 

psscan

Para escanear los diferentes procesos existentes en la imagen utilizamos el plugin psscan que nos permitirá obtener también el ID del offset físico de cada uno de los procesos. Este plugin puede encontrar procesos inactivos, es decir, que terminaron previamente, y procesos que han sido ocultos o desvinculados por un rootkig. 

Si un proceso ha finalizado previamente, el campo Hora de salida mostrará la hora de salida. Si desea investigar un proceso oculto (como mostrar sus DLL), necesitará un desplazamiento físico del objeto _EPROCESS, que se muestra en la primera columna. Casi todos los complementos relacionados con el proceso tomarán un parámetro offset para que pueda trabajar con procesos ocultos.

 

dlllist

El plugin dlllist nos permite ver que librerías del sistema está utilizando el mismo, así como obtener el offset de las mismas, el tamaño que ocupan, ruta en la cuál se almacenan, etc.

Es posible además especificar el ID del proceso sobre el cual queremos realizar este análisis, para ello podemos utilizar la opción -p o –pid como vemos en el siguiente ejemplo:

 

dlldump

Para extraer un DLL desde un proceso del espacio de memoria y analizar el mismo podemos utilizar el comando dlldump. Este comando dispone además de los siguientes parámetros:

• Hacer un dump de todos los DLL de todos los procesos
• Hacer un dump de todos los DLL de un determinado proceso con la opción -p pid o –pid=pid
• Hacer un dump de los DLL desde un proceso oculto con –offset=OFFSET
• Hacer un dump de un PE desde cualquier lugar de la memoria del proceso con –base=BASEDIR, esta opción es útil para extraer archivos DLL ocultos
• Hacer un dump de uno o más DLL que coincidan con una expresión regular con la opción –regex=REGEX. También se puede especificar si es case sensitive o no con la opción –ignore-cas

Para especificar un directorio de salida se utilizaría la opción –dump-dir=DIR o -D DIR.

 

cmdscan

El complemento cmdscan busca en la memoria de csrss.exe en XP, 2003, Vista y 2008 y conhost.exe en Windows 7 los comandos que los atacantes ingresaron a través de una consola (cmd.exe). Este es uno de los comandos más poderosos que puede usar para obtener visibilidad de las acciones de los atacantes en un sistema víctima, ya sea que abran cmd.exe a través de una sesión RDP o que ingresen/elaboren un comando desde un backdoor en red.

Este complemento busca estructuras conocidas como COMMAND_HISTORY buscando un valor constante conocido (MaxHistory) y luego aplicando chequeos de saneo. Es importante tener en cuenta que el valor de MaxHistory se puede cambiar haciendo clic derecho en la esquina superior izquierda de una ventana cmd.exe y yendo a Propiedades. El valor también se puede cambiar para todas las consolas abiertas por un usuario determinado modificando la clave de registro HKCU\Console\HistoryBufferSize. El valor predeterminado es 50 en los sistemas Windows, lo que significa que se guardan los 50 comandos más recientes. Puede ajustarlo si es necesario utilizando el parámetro –max_history=NUMBER.

Las estructuras utilizadas por este complemento no son públicas (es decir, Microsoft no produce PDB para ellas), por lo tanto, no están disponibles en WinDBG ni en ningún otro marco forense. Fueron modificados por Michael Ligh los binarios conhost.exe y winsrv.dll.

Además de los comandos ingresados ​​en un shell, este complemento muestra:

• El nombre del proceso de host de la consola (csrss.exe o conhost.exe)
• El nombre de la aplicación que usa la consola (cualquier proceso que esté usando cmd.exe)
• La ubicación de las memorias intermedias del historial de comandos, incluido el recuento actual de la memoria intermedia, el último comando agregado y el último comando mostrado
• El proceso de la solicitud de manejo

Debido a la técnica de escaneo que utiliza este complemento, tiene la capacidad de encontrar comandos de las consolas activas y cerradas.

 

Memoria de procesos

memmap

El comando memmap muestra exactamente las páginas que residen en la memoria, dado un proceso específico DTB (o kernel DTB si usa este complemento en el proceso inactivo o del sistema). Muestra la dirección virtual de la página, el desplazamiento físico correspondiente y el tamaño de la misma. La información de mapa generada por este complemento proviene del método get_available_addresses del espacio de direcciones subyacente.

A partir de la versión 2.1, la nueva columna DumpFileOffset ayuda a correlacionar la salida de memmap con el archivo de volcado producido por el plugin memdump .

Podemos ver un ejemplo de su uso a continuación:

 

memdump

Para extraer todas las páginas residentes en la memoria de un proceso en un archivo individual, existe el comando memdump. Se deberá indicar el directorio de salida con -D o –dump-dir = DIR como vemos en el siguiente ejemplo:

 

procdump

El comando procdump se utiliza para extraer el ejecutable utilizado por un proceso. Opcionalmente se pueden añadir las opciones -u o –unsafe para omitir ciertas comprobaciones de saneo utilizadas para analizar el encabedo del mismo. Algunos programas maliciosos podrían falsicicar intencionalmente los campos de tamaño del encabezado para provocar que herramientas de volcado de memoria fallasen.

Se puede utilizar también la opción –memory para indicar un espacio entre las secciones de PE que no están alineados con la página. Si no se indica este parámetro, el resultado será un arhivo que se parecerá más al archivado en el disco antes de que se expandan las secciones oportunas.

 

 

Hasta aquí el post sobre análisis forense con volatility, por ahora, y ya es bastante largo. Más adelante añadiré más post con algunos de los plugins más utilizados en volatility, así como los más específicos a la hora de analizar una imagen en busca de malware. Espero les sea de agrado y si tienen algo que decir o dudas al respecto no duden en exponerlas en la sección de comentarios.

PD: ya está disponible la segunda parte de volatility en el siguiente enlace Cazando malware con Volatility