futuro robot? futuro inerte?: Análisis de memoria RAM. Un Caso extraño

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

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.