Golismeando en la memoria RAM

Publicado por Pedro C. el 13-03-2013

Vamos con prisas, no tenemos cobertura de 3G, GPRS ni WIFI's disponibles para recibir nuestro email y vemos el equipo de un compañero para poder entrar en nuestra cuenta de correo para ver si nos han enviado esa información tan importante que esperamos... Le pedimos que nos deje entrar y por supuesto, nos aseguramos que no tiene ningún keylogger en funcionamiento. También, por defecto, entraremos de forma segura en nuestra cuenta de correo por webmail pues veremos el "candado seguro" y comprobamos que tampoco tiene instalados proxies ni nada raro. Abrimos el Internet Explorer y nos logueamos en la cuenta. Miramos nuestro correo y cerramos la sesión.

Como hemos cumplido con todos los pasos recomendados, estamos seguros... no??? Nada más lejos de la realidad... En la memoria RAM se almacena todo y dependiendo de la aplicación empleada, las cadenas suelen quedar en texto plano para uso y disfrute de los amigos de lo ajeno como veremos en ésta entrada y donde podremos golismear los datos que contiene.

Volcado de memoria de procesos

Vamos a analizar el contenido de un fichero volcado de la memoria RAM en búsqueda de las credenciales de acceso empleadas. Abriremos un Internet Explorer y entraremos a nuestra cuenta de gmail, outlook, facebook, etc... De momento no vamos a cerrar la sesión para demostrar poco a poco cómo podremos conseguirlo.

Para ello, tenemos una suite de excelentes herramientas integradas desde 1996 diseñadas por Mark Russinovich y Bryce Cogswell. Son las denominadas Sysinternals Utilities y que incluso, nos permiten su ejecución "en la nube".

Vamos a emplear la herramienta pslist para listar los procesos que se encuentran en ejecución. Abriremos un CMD con permisos de administrador y pondremos:

c:\Users\s4ur0n>pslist

pslist v1.3 - Sysinternals PsList
Copyright (C) 2000-2012 Mark Russinovich
Sysinternals - www.sysinternals.com

Process information for EVIL5:

Name	 	Pid   Pri      Thd     Hnd     Priv	CPU Time	Elapsed Time
iexplore	560	6	9      121     38744	0:00:01.497	0:01:54.612	
[...]
cmd	       4571	8	1	24	2648	0:00:00.046	0:00:19.044
pslist	       5024    13	1      153	2668	0:00:00.078	0:00:00.152
				

Recordar que también podemos emplear findstr [opciones] "filtro" para buscar un proceso concreto redireccionando la salida anterior con el pipe "|" por ejemplo de la forma pslist | findstr "iexplore"

Observaremos que tenemos abierto el navegador Internet Explorer con el PID (Identificador de Proceso) 560. Vamos a volcar toda la información que tiene la RAM sobre dicho proceso en un fichero que podremos analizar en búsqueda de credenciales de usuario. Usaremos la herramienta procdump de la forma:

c:\Users\s4ur0n>procdump -ma 560 -o dump_iexplore.dmp

ProcDump v5.13 - Writes process dump files
Copyright (C) 2009-2013 Mark Russinovich
Sysinternals - www.sysinternals.com
With contributions from Andres Richards

Writing dump file C:\Users\s4ur0n\dump_iexplore.dmp ...
Writing 148MB. Estimated time (less than) 2 seconds.
Dump written.				
				

Ya tenemos un fichero con toda la información que había en la RAM del proceso 560 asociado con Internet Explorer. Ahora, vamos a obtener todas las cadenas que contiene dicho fichero para buscar posteriormente las credenciales empleadas. Para poder filtrar sólo las cadenas, emplearemos la herramienta strings de SysInternals:

c:\Users\s4ur0n>strings dump_iexplore.dmp > dump_iexplore.txt				
				

Como habremos comprobado, cuando finaliza, no da ningún tipo de información, pero habrá generado el fichero dump_iexplore.txt con todas las cadenas de texto que tuviera. Vamos a editarlo para poder buscar las credenciales empleadas:

c:\Users\s4ur0n>notepad dump_iexplore.txt				
				

Ahora, por ejemplo, si el usuario ha entrado en su cuenta de correo del servicio de Gmail buscaremos la cadena "https://accounts.google.com/ServiceLogin" y podeis imaginaros lo que significan las dos líneas que van a continuación. Bingo!!! El usuario y su contraseña empleados para el acceso.

Y ahora, la parte "maligna" que podría haber sido crear un fichero .cmd que abra el explorer, busque el pid y haga un volcado de la información del proceso a intervalos regulares programados... Estaríamos completamente "vendidos" en alguno de los momentos aunque cerrasemos correctamente la sesión...

Volcado de toda la memoria RAM

Vamos a emplear ahora, una de nuestras herramientas forenses favoritas, DumpIt de MoonSols que podeis descargar aquí. Básicamente es la fusión de win32dd y win64dd en un ejecutable. Basta un clic para poder ejecutarla volcando todo el contenido de la memoria en un archivo y es rápida, pequeña y portable.

La ejecutaremos haciendo un doble clic o bien, desde línea de comandos. Veremos que tan sólo es necesario contestar "y" para volcar toda la RAM.

  DumpIt - v1.3.2.20110401 - One click memory dumper
  Copyright (c) 2007 - 2011, Matthieu Suiche 
  Copyright (c) 2010 - 2011, MoonSols 

    Adress space size:		5895094272 bytes (   5622 Mb)
    Free space size:         1100327911424 bytes ( 195680 Mb)

    * Destination = \??\C:\Users\s4ur0n\EVIL5-20130311-021418.raw

    --> Are you sure you want to continue? [y/n] y
    + Processing... Success.				
				

Conforme vemos, ha generado un fichero de la forma NOMBRE_EQUIPO-FECHA-HORA.raw que vamos a investigar o que emplearemos para hacer un análisis forense posterior con otras herramientas.

Procederemos ahora con la herramienta WinHex de X-Ways Software Technology AG a abrir el archivo que hemos conseguido.

Pulsamos Archivo, Abrir y seleccionamos el fichero .raw del volcado. Pulsamos en Ver y elegimos Sólo pantalla de texto y ahora en Búsqueda, Encontrar texto y pondremos por ejemplo, términos como Passwd, assword, login, etc... marcando la casilla List search hits, up to.... Nos aparecerá una barra de progreso y finalmente, tendremos una lista con todas las ocurrencias. Nos iremos desplazando con los cursores para encontrar aquella información que buscamos.

Provocando un BSOD

Vamos a emplear por último otra interesante herramienta de SysInternals para provocar un BSOD (Blue Screen of Death). Emplearemos NotMyFault para simular un error a través de un controlador de dispositivo (driver) y que nos realice un volcado completo de la memoria. Recordar que en esos ficheros MEMORY.DMP que tenemos a veces rondando por %SystemRoot% puede haber información muy interesante. Se puede configurar desde el Panel de Control, Sistema, Protección del Sistema, Opciones avanzadas y en el apartado de Inicio y recuperación.

Descargamos NotMyFault y bastará con descomprimirlo en el escritorio. Nos iremos a la versión correcta (32 ó 64 bits) y ejecutaremos NotMyFault.exe con las opciones por defecto (encontrándose seleccionado High IRQL fault (kernel-mode)) dándole al botón Crash para que provoque el BSOD.

Bonita y conocida pantalla, no??? Nunca os ha aparecido???

Como veremos, al final de la misma muestra la información que está volcando la memoria:

A problem has been detected and windows has been shut down to prevent damage
to your computer.

DRIVERS_IRQL_NOT_LESS_OR_EQUAL

[...]

Collecting data for crash dump ...
Initializing disk for crash dump ...
Beginning dump of physical memory.
Dumping physical memory to disk: 100			
				

Con lo cual, ya tendremos el fichero en %systemroot%\MEMORY.DMP para poder abrirlo con Windows Debugger (WinDbg.exe) que es parte del "Windows Software Development Kit (SDK)" o con herramientas más profesionales como nuestra preferida Volatility de la que hablaremos en sucesivas entregas.

Como moraleja, pensar muy bien las cosas antes de emplear un equipo no controlado ya que no es oro todo lo que reluce!!!

Recordaros que en los Cursos especializados de Seguridad Informática y Administración de Sistemas que ofrecemos en Academia MADESYP realizamos y establecemos las contramedidas con todo esto y mucho más...

Ser buenos y no hagáis maldades!