A la caza del mutante, parte IV

Estándar

Parte I

Parte II

Parte III

Parte V

Hola a tod@s!

En esta penúltima parte, vamos a realizar la búsqueda de MUTANT (MUTEX), a través de la herramienta volatility, y realizando para ello un análisis forense offline.

Para poder realizar esta búsqueda con éxito, el gran Andreas Schuster implementa un módulo para volatility, a través del cual,  y resumido en pocas palabras, realiza una búsqueda de la cadena Mut? En memoria paginada y no paginada.

Imagen 1.- Búsqueda de cadena Mut?

 El resultado es increíble, extrayendo no sólo la dirección de memoria y el nombre del Mutant, si no también información interesantísima, como por ejemplo el identificador de proceso (Client ID) que lo tiene referenciado.

Imagen 2.- Aplicación del módulo MutantScan en Volatility

En la próxima y última entrega, analizaremos la memoria offline, e intentaremos buscar evidencias, partiendo de los mismos principios que el estudio de Andreas Schuster. Lo único que vamos a cambiar esta vez, será la herramienta. En vez de utilizar Volatility Framework, se utilizará la herramienta WinDBG (Debugging Tools for Windows), y realizando las consultas de forma manual.

Saludetes!!

Referencias

Searching for Mutants

_KMUTANT Structure

Poolfind (MDSN)

Volatility Framework Installer

Estándar

Hola a tod@s!!

Hace tiempo que salió al público el estupendo trabajo de muchos investigadores que dio como resultado la herramienta Volafility Framework.

Los que me conocéis, sabéis que yo llevo dando por saco con el tema de la memoria RAM desde hace bastante tiempo. Gracias a Dios, que conforme más tiempo pasa, más información sobre este tema hay.

Yo mismo he dado algún que otro Webcast en Microsoft sobre este mismo tema, he hablado en las FIST, y en algún que otro Asegur@IT.

El Framework está escrito en su totalidad en Python. En su día, para hacer funcionar la herramienta, tanto en Windows como en Linux o MAC, tan sólo hacía falta instalar Python y vualá! Ya teníamos el Framework en funcionamiento.

Hoy día la cosa ha cambiado bastante. Existen multitud de Plugins que hacen de la herramienta una tool muy poderosa para analizar por completo la memoria RAM, pudiendo ahorrar costes en tiempo en un análisis forense corporativo o por proyecto. E incluso por diversión!!

El problema para gente que está empezando en esto, es que a día de hoy existen tantos plugins y dependencias, que instalar la herramienta desde cero, y dotarla de una funcionalidad aceptable, puede conllevar una inversión de tiempo importante.

Esto lo pensó en su día Jamie Levy (aka Gleeda), colaboradora habitual en el desarrollo de Volatility Framework, y desarrolló, entre otros impresionantes plugins, uno con la posibilidad de descargar todos los plugins de un tirón. El script para la versión 1.4 de la herramienta, e instalación bajo Linux, lo tenéis disponible aquí.

Yo he realizado mi particular script (en batch! con dos cojones!! jaja) para la total instalación de Volatility Framework, junto con todas sus dependencias. Entre las “capacidades” del Script de instalación se encuentran los siguientes puntos:

  • Descarga e instalación de Python, MinGW
  • Descarga e instalación de YARA (Gracias Hispasec!!), PYGame, PIL (Python Image Library), Distorm3
  • Descarga e instalación de Volatility Framework 1.3 (Versión estable)
  • Descarga e instalación de Plugins válidos para la versión 1.3
  • Compilación automática e instalación de diversos plugins
  • Procesado de Logs de todo lo que se descarga
  • Procesado de HASH (MD5 y SHA1) de todo lo que se descarga
  • Inclusión de rutas en PATH para dotar de máxima funcionalidad
  • Inclusión de shell de comandos con el botón derecho del ratón para facilitar el análisis (Open cmd Here)

Ahora mismo, el script es totalmente funcional para instalarlo en Windows XP/Vista/7, y, como hoy en el FTSAI nos vamos a “pelear” con la memoria y todos sus componentes, me ha parecido buena idea colgarlo por aquí.

En su día, hablando con Lympex de opensec.es, éste me pasó una versión que desarrolló para Linux, la cual todavía no he puesto en el proyecto, debido a que tiene que actualizarse. Me ha prometido que cuando la tenga funcional la colgará en el proyecto.

El proyecto está alojado en Google, y ahora sí…. No tienes excusa para seguir ampliando conocimientos en materia Forense, porque documentación hay, y facilidades también!!

http://code.google.com/p/volatility-installer/

Esta semana he empezado a realizar el mismo script en PowerShell, debido a que como batch tiene muchas restricciones, he tenido que “tirar” de herramientas de terceros, como 7zip, wget y HashMyFiles para hacerla totalmente funcional. El script es muy sencillo de utilizar y no requiere parámetros. Sólo doble clic, y a jugar….

Nota: Tanto Python, como las dependencias, junto con MinGW, se instalan de manera interactiva con el usuario. Las instalaciones son del entorno Next–>Next, menos MinGW, que necesitaremos marcar las opciones de MAKE, más el compilador. Este paso de “interacción” es necesario, ya que de manera desatendida no se compilan bien algunas bibliotecas en Python bajo Windows.

Doy por supuesto (y por invitado!) que colaboraciones y ayudas, serán muy, pero que muy bien recibidas…..

Update.- Chema, de opensec, ya me ha pasado el script de instalación y está subido al proyecto. Su script soporta la instalación de Volatility Framework en los sistemas Arch, Debian y FreeBSD!

Buen fin de semana a tod@s!!

Ceregumil concentrado II + GMAIL 1ª Parte

Estándar

Hola a tod@s!

Me tomo la libertad de plagiar el título del Post de mi compi Pedro Sánchez para hablaros de otra herramienta similar a la que os ofrece Pedro en su Blog.

Este caso es ligeramente diferente, pero sigue un mismo fin. El caso es que se presupone que puede haber información de cuentas de GMAIL en memoria RAM o almacenadas por el proceso. Como bien comenta Pedro, el proceso puede guardar, dependiendo de cómo esté de recursos la máquina en ese momento, la información en varios lugares. Nosotros intentaremos realizarlo desde la RAM. Para ello vamos a utilizar una herramienta de Spectra que, no sé por qué, ha pasado desapercibida durante mucho tiempo. La herramienta se llama User Mode Process Dumper, y sobre ella vamos a trabajar.

Esta herramienta tiene la capacidad de volcar al vuelo, y sin tener que matar al proceso, la memoria del proceso que le pasemos como parámetro. Vuelca incluso procesos de sistema!

Para ello, tenemos dentro de la herramienta, un ejecutable llamado Userdump.exe, el cual utilizaremos para este fin. La herramienta tiene soporte para 64 bits y plataformas basadas en Itanium, lo cual es un punto a su favor.

Y para los desarrolladores, esta herramienta tiene un instalador, el cual instala un driver en el sistema, para que pueda Hookear ciertas llamadas al kernel. Realizará estas funciones para dotar a la herramienta de volcar la memoria de un proceso cuando éste finalice de forma no planeada, forzosa, etc…

El funcionamiento de esta herramienta es bastante lógico y muy sencillo de utilizar. Para ello, no tendremos ni que utilizar la herramienta TaskList para visualizar los procesos por línea de comandos, ya que la herramienta viene programada, con el parámetro -p, para realizar esta función.

userdump1

Imagen 1.- Userdump mostrando procesos

Una vez que hayamos visualizado los procesos por línea de comandos, podremos extraer el contenido de la memoria del proceso que queramos, utilizando para ello la herramienta userdump.exe. El funcionamiento básico, como hemos dicho antes, es bastante sencillo de utilizar.

userdump

Imagen 2.- UserDump extrayendo memoria de un proceso determinado

Una vez extraído la memoria del proceso, podremos utilizar le herramienta de SysInternals-Spectra Strings para extraer el texto.

Strings iexplore.dmp > iexplore.txt

Una vez realizado ese cambio, podremos buscar, con la herramienta FindStr o Find texto específico o cadenas de texto específico.

strings

Imagen 3.- Resultado extracción Strings

En el próximo post veremos diferentes técnicas para extraer la misma información, pero automatizando las tareas.

Saludos!

Volcados de memoria. De W2k3 SP1 en adelante

Estándar

En anteriores artículos, hemos dado un repaso a las herramientas de software que hay para realizar volcados de memoria en sistemas basados en Windows.

Este tipo de técnicas, hasta ahora sólo valían para equipos anteriores a Windows 2003 SP1, ya que en el Service Pack 1 de Windows 2003 se introdujo una medida por la cual el objeto \Device\PhysicalMemory no es accesible en modo usuario.

Este cambió se debió, principalmente, porque en anteriores versiones de Windows, este objeto estaba protegido únicamente con una ACL. Un exploit podría utilizar capacidades como WMI o incluso la herramienta CACLS para cambiar las propiedades de ese objeto en segundo plano o bajo línea de comandos.

Matthieu Suiche desarrolló una herramienta hace meses, llamada Win32DD, la cual accede a la memoria en modo kernel, saltándose así la protección y provocar con éxito un volcado de memoria. Lo mejor de esta aplicación es la no limitación de sistema operativo, lo que abre un gran abanico de posibilidades en el ámbito forense. Con esta herramienta podremos obtener volcados de memoria a partir de sistemas Windows 2003 SP1en adelante.

La herramienta es gratuita, el código fuente se publica con ella, y podéis hacer uso de ella en el siguiente link.

http://www.msuiche.net/countcount/click.php?id=2

Referencias: http://technet.microsoft.com/en-us/library/cc787565.aspx

Saludos!

Análisis memoria RAM. Búsqueda de procesos I

Estándar

En todo análisis forense, se debe atender a un orden de volatilidad. Los datos contenidos en la memoria RAM y el archivo de paginación están en los primeros puestos de este orden. Por esto mismo, es por lo que muchas empresas que se dedican al forense informático, en muchas de sus variantes, deciden prescindir de investigar lo que hay en RAM, para dedicarse a otra información menos volátil, como por ejemplo el contenido del disco duro. El problema viene cuando sólo tenemos como pruebas un volcado de memoria (DUMP) o un archivo de paginación (pagefile.sys).

En este artículo y en el siguiente, haré mención a las herramientas que tenemos a día de hoy para analizar un volcado de memoria RAM (DUMP).

A día de hoy, pienso que la memoria RAM es de vital importancia en una investigación, ya que entre otras cosas, podremos encontrarnos con lo siguiente:

  • Procesos en ejecución
  • Procesos en fase de terminación
  • Conexiones activas (TCP-UDP)
  • Ficheros mapeados (Drivers, Ejecutables, Ficheros)
  • Objetos en caché (HTML,JavaScript,Passwords)
  • Elementos ocultos (Rootkits)

Como en toda investigación, la información que podamos recopilar depende de muchos factores, tales como el sistema operativo, el TimeLive de la máquina y lógicamente, el tamaño de la memoria RAM. Pongamos como ejemplo a Windows Vista y Windows XP. Windows Vista maneja de forma diferente los datos en memoria RAM. Utiliza mucho el acceso a RAM, para no cargar tanto al disco duro, ya que el acceso a memoria RAM es mucho más rápido que el acceso a disco. Windows XP no carga tanto la RAM, y en cambio utiliza mucho más el archivo de paginación.

Dependiendo del sistema operativo tendremos más o menos herramientas para realizar búsquedas. En este artículo mostraré una para Windows 2000, y que se llama memparser.

Memparser es una herramienta creada a raíz de un reto forense y desarrollada por Chris Betz. Antes de desarrollar la herramienta en cuestión, tuvo que debuggear un kernel de un Windows 2000 SP4 para buscar similitudes, identificar estructuras, y analizar el código resultante del debugging.

Cada proceso en Windows 2000 es representado por un bloque ejecutivo de proceso (Executive Process). Cada bloque representa a un proceso y contiene estructuras y datos relacionados con ese objeto. En la memoria también residen los hilos que crean estos procesos (ETHREAD), tokens de acceso, Kernel Process (KPROCESS), el cual tiene información sobre el tanto por ciento del kernel utilizado por cada proceso, etc…

La herramienta en cuestión busca lo siguiente:

  • EPROCESS
  • Objetos de Kernel
  • Drivers
  • Contenido de memoria

De todas las herramientas que hay, esta es la más completa de todas, ya que podremos desde listar los procesos que hay en un volcado de memoria, hasta por ejemplo sacar el contenido de la memoria del ejecutable, y con el que podremos, por ejemplo, buscar posibles restos de malware.

En sucesivos artículos, repasaremos las diferentes opciones que tenemos para otros sistemas operativos.

Enlaces

Memparser (SourceForge)

Inside Microsoft Windows 2000 Third Edition

Análisis de memoria RAM. Un Caso extraño

Estándar

En el artículo anterior, estuvimos viendo la recogida de información de la memoria RAM haciendo uso de los objetos del sistema operativo. En este artículo veremos la recogida de información desde otra perspectiva.

En ocasiones, y tras un ataque exitoso, un sistema puede presentar algo de inestabilidad, posiblemente debido a la eliminación de ficheros esenciales de sistema, instalación de aplicaciones no compatibles con el sistema, parcheo de estructuras del Kernel, etc.. Cuando un sistema presenta este cuadro de síntomas, no es de extrañar que el sistema presente un BSOD, indicando que algo está fallando, y es entonces cuando nos tenemos que preguntar: apagamos el equipo? Reiniciamos el equipo?

Un ejemplo válido se puede dar con el rootkit FU. Ampliamente conocido, este rootkit trabaja en modo Kernel sobreescribiendo estructuras propias del mismo, lo que le permite por ejemplo ocultar procesos. En muchas ocasiones, y tras instalarlo en el sistema, el proceso que se desee ocultar se oculta con facilidad, pero a la hora de detectarlo, puede que el sistema operativo presente un BSOD indicando que hay “algo” que no va bien. El proceso que sigue Windows para pintar la pantalla azul es el siguiente:

  • Manda parar las interrupciones del sistema
  • Llama a la CPU a detener
  • Pinta la pantalla azul
  • Notifica el driver que ha fallado
  • Si el DUMP está configurado, lo prepara para su volcado

En el procedimiento interno intervienen procesos como smss.exe, winlogon y savedump, los cuales son los que realizan las llamadas para extraer el volcado y pasarlo a un fichero. En el transcurso en el que el sistema vuelca el contenido de la RAM hasta que lo deposita en su correspondiente fichero, el sistema debe de guardar los datos en el archivo de paginación pagefile.sys. Al reiniciar el sistema operativo después de un BSOD, el proceso savedump es el encargado de pasar el volcado de memoria a su correspondiente fichero. Para que el procedimiento no presente errores, el archivo de paginación debe ser por lo menos 1’5 veces más grande que la memoria RAM. Si el archivo de paginación no sigue esta premisa, el volcado de memoria no se completará, o se completará con errores (Volcado corrupto).

Habrá ocasiones en las que cuando se nos presente un caso con estas características y se presente un BSOD, no podamos reiniciar el equipo para obtener muestras, con lo que atendiendo al RFC  3227, en un principio tan solo podríamos realizar un análisis de ficheros y disco, obviando los aspectos de memoria RAM. Pero gracias al comportamiento que tiene Windows a la hora de realizar el volcado de memoria, podemos recuperar ese volcado gracias al archivo de paginación.

dump.png

Para realizar la conversión, utilizaremos de nuevo la herramienta dd para volcar el contenido del archivo de paginación a un nuevo archivo DMP.

ddpagefile.png

Finalmente, podemos comprobar su integridad con las herramientas dumpchk o dmpchkex, ambas explicadas en anteriores artículos.

dmpchkpagefile.png

En posteriores artículos nos centraremos en la clase de información que podremos extraer de un volcado de memoria.

Enlaces:

Opciones de rendimiento en Windows XP

Optimizar archivo de paginación

DPM Magic

Memoria Virtual

Windows Hang and Dump Analysis (Mark Russinovich)

Saludos!

Análisis de memoria RAM. Verificando la integridad

Estándar

Una vez que hemos realizado los volcados de memoria, llega la hora de verificar la integridad de las mismas para comprobar si son factibles a la hora de trabajar con ellas. En este artículo presentaré herramientas de verificación de volcados de memoria en formato DMP, formato escogido para trabajar con las herramientas de debugging de Microsoft.

Este tipo de herramientas se hacen indispensables para la persona que se dedique o tenga relación directa con el análisis de volcados de memoria, ya que por un despiste, podemos perder horas y horas de trabajo. Si estamos trabajando con tipos de datos no muy grandes (Menor a un Giga por ejemplo), el proceso de copiado de éstos se hace sencillo, pero cuando trabajamos con equipos en los que la memoria RAM sobrepasa los 4GB, el transporte y análisis de éstos se hace mucho más complicado (Dependiendo del tipo de volcado que tenemos configurado en la máquina), y necesitamos más que nunca verificar la integridad de éstos. Si un volcado de memoria se genera de forma corrupta, no podremos abrirlo con ningún debuggeador, y tendremos que utilizar otras técnicas más austeras, complejas y tediosas para su análisis.

El funcionamiento de este tipo de utilidades es sencillo en su forma. Abren el volcado de memoria en busca del fallo que lo ha causado, como el código de error, y muestran el tipo de arquitectura de máquina, tipo de sistema operativo, etc.. Si no hay ningún código de error que muestre lo contrario, el volcado de memoria será íntegro, y podremos transportarlo en un medio seguro para poder trabajar con él.

A continuación muestro las dos herramientas más usadas para este tipo de verificación.

DumpChk

De las dos que presento en este artículo, dumpchk es la más completa, ya que esta herramienta nos va a mostrar mucha información sin tener que depurar nada, simplemente ejecutando este comando.

Esta herramienta nos va a mostrar desde el sistema operativo en donde proviene el volcado, uptime de la máquina, versión de compilación del sistema operativo, offset de la base del kernel, tipo de arquitectura, etc… Como podréis observar, muchísima información base y sin tener que depurar nada.

dumpchk.png

Esta herramienta, junto con muchas otras (Como bindiff para comparar ejecutables), las tenemos en el mismo CD de Windows XP por ejemplo, o descargando las Support Tools de Windows XP SP2, desde esta dirección:

http://www.microsoft.com/downloads/details.aspx?familyid=49ae8576-9bb9-4126-9761-ba8011fabf38

Si el volcado de memoria no es válido para ser tratado con las herramientas de debugging de Microsoft, nos aparecerá una respuesta diferente a la anterior:

errordumpchk.png

DumpCheck Utility (Citrix)

DumpCheck Utility, es otra de las grandes herramientas desarrolladas por Dmitry Vostokov. Esta herramienta también nos ayudará a verificar la integridad de un volcado de memoria. Cuando la integridad del volcado es correcta para que podamos realizar el análisis con Windbg, la herramienta mostrará lo siguiente:

dmpcheck.png

Si la herramienta detecta que el volcado de memoria no cumple con los criterios de integridad, o lo que es lo mismo, que el volcado está corrupto, la herramienta mostrará lo siguiente:

dmpcheckerror.png

Esta herramienta, junto con una explicación más detallada, la podéis descargar de aquí.

DumpCheck Utility Explorer (Citrix)

Para los que necesiten tener esta herramienta mucho más a mano, y no le guste tanto la línea de comandos, Dmitry Vostokov ha diseñado la misma herramienta, pero integrándola por completo en nuestro Explorer de Windows, haciendo esta tarea mucho más fácil, y mucho más amena para muchos. El funcionamiento es el mismo, pero esta vez sólo tendremos que utilizar el botón derecho del ratón. El resultado es el mismo que el anterior.

checkdump.png

La herramienta en cuestión, junto con su explicación detallada, la podéis descargar de aquí 

En el próximo artículo veremos un caso extraño de recolección de evidencias, aplicando técnicas diferentes y herramientas mostradas en estos artículos, consiguiendo un resultado óptimo.

Enlaces

Utilizar DumpChk en ambientes Windows NT, 2000 y 2003

Utilizar DumpChk en ambientes Windows XP

Saludos!