Llegados a este punto, significa que ya habéis leído la Primera y Segunda parte de esta serie de artículos sobre Análisis Forense en la Nube. En los “episodios” anteriores os contaba la parte teórica del funcionamiento de los sistemas de computación en la nube, para a continuación, explicar como realizar un análisis de la información y artefactos forenses que pudiera albergar un sistema en la nube, en este caso, una instancia de Ubuntu 16, alojada en la nube de Amazon WS.

En este último apartado (III), os contaré como realizar un análisis forense en e vivo de estas máquinas o instancias en la nube, más concretamente como realizar un análisis de la memoria RAM de una instancia de AWS. Quizás en otra ocasión os cuente como realizar un análisis de tráfico de red de una máquina en la nube, pero de momento, nos vamos a centrar en el análisis de la memoria RAM.

 

Fig. Ejecución de htop en una máquina Ubuntu

 

Que la máquina a analizar sea un Ubuntu 16.04 no es fruto de la casualidad, en la parte anterior de este artículo ya os contaba que seleccioné un sistema operativo tipo Linux a propósito. Analizar la memoria RAM de un sistema Windows, no tiene mucha complicación, poco importa que la máquina se encuentre en la nube o delante de nuestros ojos, el procedimiento es prácticamente el mismo. Sin embargo, con Linux la cosa cambia bastante, no es que sea imposible realizar un análisis de la RAM de un sistema Linux, pero no hay un protocolo tan simple o intuitivo como puede ser con un Windows. Si utilizamos la herramienta Volatility nos daremos cuenta que prácticamente, por defecto, ya viene con todos los perfiles de los distintos sistemas Windows que tenemos en el mercado (XP, Vista, 7, 10… así como con sus distintos “Servipacks”), cosa distinta ocurre con los sistemas operativos Linux, en los cuales tendremos que compilar nosotros manualmente cada uno de los perfiles del sistema, para que Volatility “entienda” como funciona cada uno de los kernel de Linux. El problema es que la versiones de Windows prácticamente se cuentan con los dedos de la mano, si embargo el número de kernels de Linux existentes hoy en día, son prácticamente infinitos, ya que cada cual puede “engendrar” el suyo propio, lo que imposibilita que Volatility pueda incluir todos los perfiles de todos los kernel de Linux existentes.

Pero tampoco nos vayamos a asustar, que no venga incluido en Volatility un perfil por defecto, no quiere decir que no se pueda realizar un análisis de la memoria RAM de ese sistema, a continuación os detallaré cuales son los pasos necesarios para poder realizar este análisis, pasos que por cierto, no difieren mucho de un análisis físico a un análisis en la nube.

Explicado esto, ahora nos toca ponernos manos a la obra, en primer lugar, tendremos que saber cual es el Kernel de nuestra máquina Linux “victima”, para ello la teoría dice que ejecutando el comando ”uname -r” nos devuelve la versión del Kernel. Pero en este caso, vamos a hacer un poco de trampa. No nos interesa interactuar en exceso con nuestra máquina victima, digamos que ya sufrido lo suyo con el ciber ataque que recibió, como para seguir ejecutando comandos y procesos en ella.

 

Fig. Versión de Ubuntu 16.04 en AWS

 

Aprovechándonos de las ventajas de la computación en la nube, sabemos que nuestra máquina Linux victima es un Ubuntu 16.04 LTS. Lo que vamos a hacer, en vez de ejecutar el famoso “uname -r” sobre nuestra máquina victima, lo ejecutaremos sobre nuestra máquina forense que os conté como crear en el Apartado Anterior de este Artículo. Si recordáis, cuando desplegué la máquina forense en AWS, seleccioné el mismo tipo de máquina (Ubuntu 16.04 LTS) que la que había sufrido el ataque, esto tiene una explicación sencilla, de este modo, ahora apenas tendré que interactuar con la máquina victima, todo el proceso de generación de los módulos y perfiles de Volatility para realizar el análisis de la RAM los podré hacer con la máquina forense, ya que sé que al utilizar el mismo tipo de kernel que la máquina victima, estos serán totalmente compatibles con el dumpeado de memoria RAM de la máquina victima. Dicho, de otro modo, como ambas máquinas son iguales, en vez de utilizar la “configuración” de la máquina victima, utilizaré la configuración del Kernel de la máquina forense y así no tendré que instalar ni ejecutar tantas herramientas en la máquina victima, evitando de este modo, alterar en la medida de lo posible nuestra evidencia digital.

 

Fig. Ejecución del comando uname -r en Ubuntu AWS

 

Una vez ya sabemos que ambas maquinas disponen del mismo Kernel, ahora en nuestra máquina forense tan solo tendremos que instalar (si no lo hemos hecho ya), los programas: Volatility, Lime y dwarfdump. Mi recomendación es realizar la instalación desde los repositorios oficiales, así tendremos todo instalado en los directorios por defecto y nos será mas fácil realizar las configuraciones posteriores.

 

Fig Comprobación instalación Volatility y Dwarfdump

 

En el caso de la captura anterior, como ya tenía instalado en mi maquina forense tanto Volatility, como dwarfdump, simplemente muestro la confirmación de que se encuentra instalado correctamente.

Es importante recordar, que todos estos comandos los estamos ejecutando en la máquina forense, no en la máquina que ha sufrido el ataque. Ahora el siguiente paso, será compilar el módulo para que “Volatility” se entienda con el dumpeado de memoria que posteriormente vamos a recopilar. Para hacer esto, simplemente acudimos a la ruta de instalación correspondiente: “/usr/src/volatility-tools/linux/”, y ejecutamos el comando “make”. Si todo funciona correctamente, tendremos los ficheros: module.ko, module.dwarf (Configuración del Kernel) y system.map (Mapa con las instrucciones) generados correctamente y listos para usar.

 

Fig Generación de los modulos y el mapa del Kernel

 

El siguiente paso será empaquetar en un zip los ficheros que hemos generado, y almacenar este zip en el directorio de perfiles de Volatility. Como hemos utilizado la instalación desde los repositorios, todas las cosas estarán en su sitio y no nos costará nada generar este zip. Caso contrario, deberemos localizar las correspondientes rutas de funcionamiento de Volatility, para generar y guardar el zip con el perfil para el análisis en el lugar correcto.

 

Fig. Generación del perfil para Volatility

 

Una vez generamos el fichero zip, comprobamos con un simple ls que el perfil se almacenó correctamente en la ruta que nosotros le indicamos.

 

Fig. Comprobación de generación del perfil.

 

Pero para asegurarnos de verdad que todo está bien, y que Volatility “puede ver” el perfil, ejecutaremos el comando: “volatilty –info | grep Linux”, para comprobar que efectivamente nuestro perfil que hemos generamos, funciona adecuadamente.

 

Fig Comprobación de funcionamiento del perfil

 

De momento, todo está saliendo muy bien y los comandos funcionando correctamente, pero… ¡Nos falta lo mas importante de todo!, de poco vale haber creado un entorno idílico para realizar un análisis de un dumpeado de memoria RAM de un maquina Linux, si no tenemos ningún dumpeado para analizar. Eso es lo que nos toca realizar ahora, capturar la memoria RAM de la máquina victima. En algunos manuales y tutorial este proceso se explica mediante el uso de la herramienta LiME para Linux, yo no tenga nada en contra de LiME, es mas, me parece una herramienta estupenda para realizar estas tareas, pero en este caso, prefiero utilizar otro sistema que me permita realizar el dumpeado de la memoria interactuando lo mínimo indispensable con la maquina victima, por decirlo de otro modo, una herramienta que funciona a una capa por encima de LiME.

En este caso, usaremos la herramienta: “Margaritashotgun” desarrollada por Joel Ferrier, la cual podrás descargar desde su GitHub. Para instalarla, en nuestra máquina forense (si, en la forense), ejecutaremos el comando: “pip install margaritashotgun” (una instalación típica de Python).

Una vez instalada “Margaritashotgun” en nuestra máquina forense, tan solo tendremos que ejecutar el siguiente comando para comenzar el dumpeado de la RAM de la máquina victima: “margaritashotgun –server Dominio_Instancia_Victima_AWS –username Usuario_Instancia –key Fichero_Key.pem –module Modulo_Generado_Volatility.ko –filename Nombre_Captura_RAM”

 

Fig: Proceso de captura remota de la memoria RAM en AWS

 

Si todo va bien, comenzaremos a ver como comienza la captura de la memoria RAM de nuestra máquina victima, y esta se va almacenando en nuestra máquina forense (ojo con disponer de suficiente espacio para almacenar el fichero de dumpeado). Una vez terminado el proceso de captura, lo primero que haremos es calcular una firma digital del fichero tipo HASH.

 

Fig. Firma digital de la memoria RAM capturada

 

Llegados a este punto, el procedimiento será igual que cualquier análisis de memoria RAM con Volatility, ya sea en Windows o en Linux. Invocamos a volatility, le indicamos dónde se encuentra e fichero de dumpeado de la memoria RAM, configuramos el tipo de perfil que vamos a utilizar (en este caso, el que generamos nosotros mismos) y finalmente, seleccionamos lo que queremos hacer.

 

Fig. Uso habitual de Volatility

 

En el caso de la imagen, en primer lugar ejecutamos un “cpuinfo” para averiguar el tipo de CPU con el que esta operando la máquina afectada. El segundo comando”ifconfig”, nos dirá la configuración de red de la máquina victima y finalmente con: “linux_pslist” podremos averiguar todos los procesos que estaban corriendo en la máquina en el momento que hemos realizado la captura. Lógicamente, estos son solamente tres ejemplos aleatorios que se me han ocurrido ejecutar, ya que Volatility nos ofrece un mundo de posibilidades al realizar un análisis de memoria RAM.

¿Te ha gustado este artículo? Si quieres, puedes ayudarme a escribir el siguiente artículo de GLIDER invitándonme a un rico café.

 

Pulsa Aquí para invitarme a un café con hielo.

  Salu2.