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!

Anuncios

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

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s