Análisis Forense de Memoria RAM III. Interfaz gráfica para análisis de memoria Ram (Evolve).

El fin de la trilogía “Volátil”

Muy buenas a todos/as. Esto tenía que llegar amigos, había que poner un fin al análisis de volcados de RAM y este post es una buena manera de hacerlo, vamos a aprender a analizar un volcado de RAM con interfaz gráfica.

En este camino, hemos aprendido a realizar un volcado de RAM en Linux (aquí), después aprendimos a crear un profile en Linux para poder analizar ese volcado de memoria y comenzamos a analizarlo tirando de terminal (aquí), ahora vamos a analizarlo desde una interfaz gráfica.

La pregunta es ¿y para qué necesito hacerlo así? Obviamente, esto no es ni preciso, ni necesario, pero por experiencia propia, os aseguro que si tenéis que ir a sala a exponer lo hallado a personas no formadas en estas materias, el hacerlo desde una interfaz gráfica lo hace lógicamente, mucho más fácil de asimilar y entender. De modo que a vuestra elección lo dejo, yo os indico el camino, vosotros elegís la dirección.

Empecemos, Evolve es un proyecto que está disponible para descarga en github en la siguiente url: https://github.com/JamesHabben/evolve.

La verdad es que está un poquito sin actualizar, pero lo cierto es que funciona muy bien a día de hoy. ¿Qué es evolve? Es una interfaz web para análisis de volcados de memoria. Una GUI web, así de simple. ¿Para qué puede servirnos? Para muchas cosas, al margen de lo comentado anteriormente nos permite realizar varios scripts y guardar los resultados para continuar en otro momento si fuera preciso.

¿Cómo guarda los resultados? De una manera muy elegante, en el mismo directorio donde esta la imagen del volcado de RAM queda un archivo en formato sqlite con los resultados de las búsquedas que realicemos nosotros.

Requisitos

Muy pocos, tan solo instalar ciertas librerías :

Una vez está hecho y con volatility instalado ya en nuestro equipo y las librerías ya instaladas…

Nos bajamos evolve…

Entramos dentro…

Tan solo quedar correr la siguiente línea:

Con –p indicamos el puerto por el que nos conectaremos (en este caso 8080), con –f le indicaremos la imagen que queremos que analice y con –profile le decimos que profile debe usar.

Este, amigos míos, es el resultado…

Elegimos en el árbol de la izquierda que queremos analizar, por ejemplo historial de bash y…

En el árbol de la izquierda se puede ver las posibles opciones de los plugins. Una vez se selecciona un plugin, este se pone a desempeñar su labor y una vez la acaba, pasa de run a show. ¡Y se produce el milagro! (Demasiado bíblico ¿verdad?)

Más ejemplos de uso…

Una vez se ha acabado el análisis, en el mismo directorio donde está el archivo de memoria volcada, queda un archivo sqlite con los resultados de todo aquellas consultas que hemos realizado.

Para muestra un par de ejemplos:

Por dar ideas y líneas de investigación, volatility está escrito en Python, evolve está escrito en Python y desde python es muy, muy fácil trabajar con sqlite. Imaginad cuantas posibilidades de trasteo y automatización.

¡Hasta la próxima!

 

 

Análisis Forense de Volcado de Memoria RAM en Linux con Volatility. Parte II

Una vez hemos realizado la adquisición de la memoria RAM y hemos aplicado todos los pasos del protocolo de adquisición (cadena de custodia, calcular hash del archivo, copia para custodia si procediera…etc). Vamos a realizar el análisis en si mismo, que es lo que realmente quieres ver, ¿a qué si?

El hecho es que tenemos ya la memoria volcada y se la pasamos a la herramienta volatility. Ahora es cuando vamos a descubrir que pasaba en esa máquina… ¡Pues no! Esto no va así señores, además seria demasiado fácil, no se disfrutaría igual.

Yo te explico tranquilo, mira, volatility para su funcionamiento, se basa en perfiles de cada sistema a analizar. Con esos perfiles localiza, en el volcado que hemos obtenido, los diferentes elementos que estructuran la memoria de los sistemas a analizar, y es por  ello que, si no disponemos del perfil correspondiente al origen del volcado, debemos generarlo previamente para poder analizarlo, así de simple.

Es evidente que hay muchas menos versiones de Windows,  que Kernels de Linux, por este motivo, en la versión 2.5 de volatility, que es con la que se va realizar este post, vienen ya preinstalados todos los perfiles de Windows, incluido Windows 10 y no viene ninguna de Linux o de Mac.

Solución: creamos un perfil de la versión de Linux que nos interese, lo importamos a Volatility y a funcionar.

Antes de empezar con el proceso, podéis probar a instalar Volatility en por ejemplo Ubuntu o Debian, ya sabéis “sudo apt-get install volatility” y ya está. Una vez instalado vais a esta dirección: /usr/lib/python2.7/dist-packages/volatility/plugins/overlays/

Ahí vais a ver algo así:

/Users/Diego/Dropbox/overlays.jpg

En esas tres carpetas están los profiles por defecto de las tres plataformas.

Veamos como esta la de Windows…

/Volumes/NO NAME/post/profiles_windows.jpg

Podéis ver las diferentes versiones de profiles de Windows

Ahora vemos la de Linux…

/Users/Diego/Dropbox/plugins_linux.jpg

Solo esta la de Linux Centos que es la que he importado yo para ese análisis, de no ser por ese profile, estaría vacío de ellos. Con estas imágenes espero que hayáis pillado ya la idea.

Una vez puestos en contexto pasemos a las trincheras que es lo que nos gusta.

Primer paso, necesitamos, al igual que con Lime, una máquina igual a la que tenemos que analizar para generar el profile que luego importaremos y usaremos para analizar la memoria volcada extraída. En esa máquina descargaremos e instalaremos dwarfdump esto es fácil ¿verdad que si? Pues no, el motivo es que en otras distros es relativamente fácil hacerlo pero esto es Cent0s y aunque es una gran distro que uso muy a menudo, para según que cosas toca un poco las narices. He realizado esto con otras distros (debían, ubuntu, suse) y da menos problemas, aunque es perfectamente realizable.

Obviamente necesitaremos lo típico (headers, gcc, ncurse, ncurse-devel, en este caso:

yum groupinstall “Development Tools” ). Si usáis la máquina en la que habéis compilado antes Lime, seguro que tendréis ahí todas las dependencias.

Aclarado esto, vamos al lío, descargamos esa librería de:

http://pkgs.fedoraproject.org/repo/pkgs/libdwarf/libdwarf20130207.tar.gz/64b42692e947d5180e162e46c689dfbf/

Despúes la descomprimimos:

/Users/Diego/Desktop/Captura de pantalla 2016-10-07 a las 20.28.41.png

Después toca lo de siempre…

/Users/Diego/Desktop/Captura de pantalla 2016-10-07 a las 20.27.57.png

Entramos dentro de la carpeta descomprimida y :

./configure && make && make install

Una vez compilado entramos en la carpeta dwarfdump y volvemos a compilar…

/Users/Diego/Desktop/Captura de pantalla 2016-10-07 a las 20.27.31.png

Y ya está hecho todo lo necesario para crear el profile, ahora necesitamos instalar volatility en esa máquina para que en conjunción con esa librería nos cree el perfil.

Bajamos volatility…

wget http://downloads.volatilityfoundation.org/releases/2.5/volatility_2.5.linux.standalone.zip

Una vez descomprimida, lo instalamos

/Users/Diego/Desktop/Captura de pantalla 2016-10-07 a las 20.26.32.png

Una vez esta instalado en esa máquina tan solo nos queda ejecutar la siguiente orden:

zip <nombre_del_profile.zip> module.dwarf /boot/System.map –uname –r

¡Y ya esta creado el perfil!

/Users/Diego/Desktop/Captura de pantalla 2016-10-07 a las 20.25.09.png

En este caso se creo un profile con el nada ingenioso nombre “Profile_1.zip” (luego le cambié el nombre por el otro mucho mas pro, tranquilos). Esta imagen es a modo de ejemplo.

Luego lo bajas del server o equipo analizar y te lo llevas a tu maquina de trabajo, donde lo analizas

En este caso, en la máquina de trabajo al ser una distro Ubuntu, la ruta donde se debe importar el archivo profile es:

/usr/lib/python2.7/dist-packages/volatility/plugins/overlays/linux

Por tanto :

Sudo cp Cent0s72.zip /usr/lib/python2.7/dist-packages/volatility/plugins/overlays/Linux

Perfecto ya tenemos el profile, creado, compilado y en su ubicación, ahora, finalmente podemos comenzar al análisis en si.

Comencemos averiguando el tipo de Linux que es:

../../../Volumes/NO%20NAME/post/prime

La orden es: volatility imageinfo –f (ubicación de la ram volcada)

Ahí lo tenemos , perfecto, parece que esto comienza a funcionar, veamos que podemos extraer, para saber las opciones que nos da la herramienta escribimos la siguiente orden:

volatility –info | grep –i linux

Resultado…

../../../Volumes/NO%20NAME/post/opciones

Hay unas cuantas cosillas para mirar ¿verdad?

Abramos una consola dentro la imagen:

../../../Volumes/NO%20NAME/post/linux

Ahí está, expliquemos la instrucción:

  1. -f es la ubicación de la imagen a analizar
  2. -Linux_volshell le indicamos que nos abra una Shell dentro de la imagen
  3. –profile=LinuxCent0s72x64 le indicamos en perfil de Linux que debe usar

Veamos ahora los hilos que tiene esa máquina…

../../../Volumes/NO%20NAME/post/hilos

Resultado:

../../../Volumes/NO%20NAME/post/hilos_l

Ahora veamos el history de los comandos de bash usados en esa máquina analizada:

../../../Volumes/NO%20NAME/post/linu

Y así podríamos seguir mucho tiempo. Pero mi intención no es enseñar todas las posibilidades que tiene esta maravillosa herramienta, tan solo mostrar el camino que debéis seguir. Os animo a que la exploréis porque os aseguro que tiene unas posibilidades enormes, podréis ver conexiones, podréis ver sockets, módulos del kernel cargados…etc.

Un mundo de posibilidades que os ayudarán a realizar un gran trabajo.

Y esto es todo por hoy, no os quiero aburrir mas que ya vale, en la siguiente os enseñare a analizar estas imágenes de la RAM usando una interfaz gráfica. Os anticipo algo con esto…

../../../Volumes/NO%20NAME/post/ev

Hasta la próxima…

¡Ups! Se me olvidaba algo…

Si vais algo justos de tiempo hay una repo en github donde se han creado ya unos cuantos profiles de diferentes sistemas Unix, tanto Mac como Linux que se pueden usar perfectamente.

Captura%20de%20pantalla%202016-10-08%20a%20las%2014.09.32.png

Esta es la url de la descarga:

https://github.com/volatilityfoundation/profiles.git

Estos son algunos de los profiles que tienen:

../../../Volumes/NO%20NAME/post/prof

../../../Volumes/NO%20NAME/post/prof

Selecionamos Centos y seguimos…

../../../Volumes/NO%20NAME/post/prof

Entramos en 64 bits

../../../Volumes/NO%20NAME/post/prof

Yo he hecho pruebas con algunos, no con todos lógicamente y me han dado un resultado perfecto. De modo que si queréis ahorrar tiempo y las versiones os coinciden podéis usar estos tan tranquilamente.

Se me había pasado hasta ahora contar esto, perdonadme, pero mi intención era que aprendáis a hacerlo a mano antes de dar algo que os haga el trabajo a vosotros. Estos profiles están geniales, pero no hay de todos los necesarios, por tanto, una vez sabéis hacerlo a mano, esto os agilizará el trabajo y os permitirá avanzar mas rápido.

Ahora si, un saludo…

Guía Hardening – Hardware, habilitar y deshabilitar.

Hoy volvemos con una entrada centrada en intentar controlar el hardware de nuestras maquinas, esta entrada esta orientada al uso personal, primero recomiendo pasarse por el capitulo 2º de la guía de Hardening, en el que hablamos de la BIOS y algunos aspectos de su configuración para continuar después con esta entrada, pues puede ser que algunas de las opciones que indicamos en este capitulo se puedan ejecutar de una manera mas sencilla y rápida en la BIOS, aunque como siempre decimos, no esta mal saber antes como hacer cualquier tarea en modo manual, que con una bonita GUI y el proceso automatizado.

MODULOS DEL KERNEL LINUX

Los módulos en el Kernel Linux son los encargados de cargar los controladores de dispositivos de hardware, y podemos habilitar o deshabilitar estos módulos para mejorar la seguridad de nuestras maquinas, y si en nuestra BIOS no disponemos de estas opciones, gracias a comandos como modprobe podemos quitar o añadir dichos módulos, pero antes debemos conocer como obtener información de los módulos que tenemos cargados y saber cuales son innecesarios para nuestra maquina.

LSMOD, LSPCI, MODINFO, MODPROBE

Para esta tarea disponemos de varios comandos ¿pero que buscamos?
En nuestro caso y teniendo en cuenta que hemos instalado nuestra Debian en una portátil o computadora de sobremesa, tendremos en cuenta que dichas maquinas disponen de hardware integrado, ya sean puertos USB, unidades de CD o una webcam en el caso de los portátiles, y en muchas ocasiones y según la utilidad que le busquemos a nuestras maquinas pueden ser innecesarios.

LSMOD nos mostrara en varias columnas la información de los módulos cargados ,dicha información proviene del archivo /proc/modules, la primera columna muestra el nombre del modulo, la segunda columna el tamaño del modulo en bytes, y la tercera columna muestra si el modulo depende de otro modulo para funcionar.

[simterm]root@debian:~#lsmod
Module                  Size  Used by
nls_utf8               12456  0 
btrfs                 863535  0 
xor                    21040  1 btrfs
raid6_pq               95238  1 btrfs
ufs                    73443  0 
qnx4                   13036  0 
hfsplus               101391  0 
hfs                    53845  0 
minix                  31387  0 
ntfs                  194605  0 
vfat                   17135  0 
msdos                  17046  0 
fat                    61986  2 vfat,msdos
.....[/simterm]

LSPCI muestra la información detallada de los buses PCI y dispositivos en el sistema,

[simterm]root@debian:~#lspci

00:00.0 Host bridge: Intel Corporation 440FX – 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:02.0 VGA compatible controller: InnoTek Systemberatung GmbH VirtualBox Graphics
Adapter
00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller
(rev 02)
00:04.0 System peripheral: InnoTek Systemberatung GmbH VirtualBox Guest Service
00:05.0 Multimedia audio controller: Intel Corporation 82801AA AC’97 Audio
Controller (rev 01)
00:06.0 USB controller: Apple Inc. KeyLargo/Intrepid USB
00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)
00:0d.0 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 02)[/simterm]

Para obtener más información sobre algún dispositivo PCI puedes utilizar -vs, si te fijas al final de la información nos indica el modulo que utiliza (e1000).

[simterm]root@debian:~#lspci -vs 00:03.0
00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller
	Subsystem: Intel Corporation PRO/1000 MT Desktop Adapter
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
	Memory at f0000000 (32-bit, non-prefetchable) [size=128K]
	I/O ports at d010 [size=8]
	Capabilities: [dc] Power Management version 2
	Capabilities: [e4] PCI-X non-bridge device
	Kernel driver in use: e1000[/simterm]

MODINFO muestra información sobre un modulo que le indicamos, esta información se muestra en formato “campo: valor” para una mejor lectura.
[simterm]root@debian:~#modinfo e1000

filename:       /lib/modules/3.16.0-4-amd64/kernel/drivers/net/ethernet/intel/e1000/e1000.ko
version:        7.3.21-k8-NAPI
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     C2E6003E8479D0EA4A71DDB
alias:          pci:v00008086d00002E6Esv*sd*bc*sc*i*
alias:          pci:v00008086d000010B5sv*sd*bc*sc*i*
alias:          pci:v00008086d00001099sv*sd*bc*sc*i*[/simterm]

MODPROBE añade o quita un modulo del kernel seleccionado por nosotros, con los pasos seguidos anteriormente para obtener información del modulo a quitar, debes tener en cuenta que una vez quitado el modulo para su posterior uso debes volver a cargarlo en el Kernel.

Con modprobe -r [ nombre modulo] lo quitamos.

[simterm]root@debian:~#modprobe -r e1000[/simterm]

Si ahora haces un “lsmod | grep e1000″ veras que el modulo ya no aparece en la lista, y para volver a cargarlo debemos hacerlo con modprobe [ nombre modulo ].

[simterm]root@debian:~#modprobe e1000[/simterm]

Esta tarea la podemos realizar con cualquier modulo, nosotros hemos elegido una tarjeta de red como ejemplo, pero también puedes hacerlo con el CDROM puertos USB o cualquier otro dispositivo que no se utilice y pueda ser un vector de ataque fisico a nuestro sistema.

Extracción memoria ram en Linux, Parte I.

 

Esta semana me he encontrado en la situación de tener que realizar una adquisición de memoria RAM de un server linux para realizar un análisis ante la posibilidad mas que real (como al final fue) de que estuviera owneada por un delincuente.

Esto me puso en la siguiente disyuntiva:

1.- En el caso de tener que hacerlo en sistemas Windows, es relativamente sencillo ya que hay muchas herramientas, tanto libres como  comerciales, para hacerlo, debido a que simple y llanamente, hay un predominio total de de ese sistema (lo que nos indica que aún nos queda mucho trabajo por delante).

2.-Pero, ¿qué pasa en Gnu/Linux? Pues de ello, amigo mio, va este post…

En Linux, hay muchas menos herramientas libres. Están mantenidas y actualizadas por la comunidad.

Además, debemos tener en cuenta que cada kernel, en cada distro , es dintinto uno de otro. Esto  nos obliga a realizar un montón de procesos previos para poder hacer la adquisición de la memoria, que “alterarían” el sistema a analizar, de realizarlo en el y de paso, alarga considerablemente el proceso. Pero ya veréis como es relativamente sencillo, para ello vamos a usar LIME (https://github.com/504ensicslabs/lime). Os recomiendo encarecidamente la lectura de la documentación de este proyecto, os aclará muchas dudas que os puedan surgir.

 

Planteamiento: Necesitamos obtener, como parte de un análisis la memoria ram de una máquina presuntamente vulnerada. Esto nos plantea una serie de dilemas a la hora de extraerla en Linux.A la hora de extraerla no es como en Windows con su dumpit y sus 50000 de herramientas de botón y tal… No, aquí esto es Linux y las cosas se hacen en condiciones, se supone que somos profesionales ¿no?…

A lo que vamos, los pasos a realizar son estos:

 

1.- Podría hacerlo de manera mucho mas sencilla y menos liosa, pero no lo voy a hacer así y os diré el motivo. Es muy factible que de una acción así, salga una asistencia a juicio, por ello el proceso debe ser impecable y las modificaciones que realicemos sobre la máquina a analizar deben ser las mínimas posibles a fin de que no nos lo puedan echar atrás en el proceso, alegando alteración de la evidencia original. Si se genera suficiente duda nos lo puedan “tumbar”. Es por ello que a fin de no modificar la máquina origen de la investigación, tenemos que crear otra máquina, que en este caso será virtual, con exactamente el mismo kernel que la máquina a analizar y compilar ahí nuestra herramienta. Y ¿por qué hacerlo así? Por muchos motivos, entre ellos no contaminar la máquina a analizar por ejemplo y de tener que hacerlo que sea la mínima modificación y contaminación posible. También podemos tener en cuenta que podríamos “pisotear” cualquier rastro que hubiera al compilar. De este modo al hacerlo en otra máquina con el mismo kernel “ensuciamos” la otra modificando lo mínimo aquella que nos interesa analizar.  Una vez hecho todo esto

2.- Una vez compilado en el mismo kernel pero en otra máquina, lo instalamos en la máquina destino y lo “ejecutamos” ahí.

3.- En ese mismo momento se producirá el volcado de memoria y ya podremos analizar la ram con total tranquilidad con volatility (o la herramienta que tu prefieras).

 

Una vez explicado el contexto nos vamos a preparar el terreno, tenemos una máquina cent0s en virtualbox, para extraer su ram nos aseguramos cual es su versión de kernel y crfeamos otra máuina con el mismo kernel. Que es una máquina reciente y tiene el último kernel de cent0s, pues genial y si no lo es, vemos cuál es y procedemos a instalarle el kernel que nos interesa.

Comencemos

Hay que instalar las librerías necesarias para compilar…

captura-de-pantalla-2016-09-29-a-las-10-01-52

Y empezamos…

captura-de-pantalla-2016-09-29-a-las-10-02-09

El que deseamos es exactamente este….

captura-de-pantalla-2016-09-29-a-las-10-47-54

Si fuera otro, pues nada, a buscar y listo…

captura-de-pantalla-2016-09-29-a-las-10-48-48

Por falta de kernels va a ser…

 

Copiamos la dirección y con un wget lo solucionamos…

captura-de-pantalla-2016-09-29-a-las-13-43-42

Una vez descargado lo descomprimimos  con un tar –Jxf Linux(versión que corresponda…)…

captura-de-pantalla-2016-09-29-a-las-13-46-57

Entramos dentro de la carpeta descomprimida  y … bueno, lo típico vaya..

Antes de compilarlo, hay que generar una configuración en el kernel. Para hacerlo de manera gráfica, podemos ejecutar el siguiente comando:

 

make menuconfig

captura-de-pantalla-2016-09-29-a-las-10-15-09

¿A que esto ya os suena?

Si deseas que el nuevo kernel quede con la configuración del anterior y  deseas aceptar todas las respuestas en “si” (podría ser oye…), ejecutas el siguiente comando:

# sh -c ‘yes “” | make oldconfig’ 

Después de esto, ahora sí podemos compilar el kernel. Esto llevará un rato (según la potencia de la máquina, la conjunción de los astros  y todoesto…):

 

# make

 

Consejo: Tómate un café, escribe un libro, ten un hijo, planta un árbol y luego vuelves a ver que tal va la cosa…

 

Después toca instalar  el kernel y sus módulos:

# make modules_install install 

captura-de-pantalla-2016-09-29-a-las-11-42-48

captura-de-pantalla-2016-09-29-a-las-11-44-48

AVISO PARA NAVEGANTES:

En versiones anteriores de  Cent0s, había que ir a /boot/grub/grub.conf  y editar cierto parámetro para que al arrancar de nuevo cargara el nuevo kernel, en cent0s 7 debes ir a otro lugar  /boot/grub2/ y ahí editar y hacer últimos ajustes, (a ver, esto no es necesario tan solo queremos obtener un archivo que usaremos en otra máquina y esto no seria necesario, pero ya que nos ponemos a enseñar…).

captura-de-pantalla-2016-09-29-a-las-13-56-56

Se ve donde ir ¿no? Luego…

captura-de-pantalla-2016-09-29-a-las-11-54-02

Después de todo esto lo reiniciamos y…

captura-de-pantalla-2016-09-29-a-las-11-59-09

Nos ha cogido bien el kernel y ya arranca desde ahí, los pasos previos se han realizado…

captura-de-pantalla-2016-09-29-a-las-12-00-18

 

Perfecto, vamos a descargarnos en el equipo la herramienta en cuestión:

La url es: https://github.com/504ensicsLabs/LiME

captura-de-pantalla-2016-09-29-a-las-12-00-41

Descargando desde su repo…

captura-de-pantalla-2016-09-29-a-las-12-29-21

Después de hacerlo lo descomprimimos (no hace falta explicar cómo ¿verdad?).

captura-de-pantalla-2016-09-29-a-las-12-31-16

Le he cambiado el nombre y lo he puesto como LiMe (caprichos de uno).

Después  se escribe src;make y ya está preparada la herramienta¡ ¿Tanto jaleo para esto?

Pues si hijos míos, esto lo que toca.

Nos ha creado un pequeño archivo de nombre lime-3.18.42.ko. Esto es lo que tenemos que subir a la máquina a analizar, o llevarlo en un usb… Como prefieras, en este caso, al ser un laboratorio, podemos permitirnos ciertas licencias. Usaremos el nunca suficientemente explotado comando  scp:

captura-de-pantalla-2016-09-29-a-las-12-36-16

Me lo bajo a la máquina host (no olvidemos que hablamos de máquinas virtualizadas).

captura-de-pantalla-2016-09-29-a-las-12-50-28

Ya está subido en la máquina analizar, ahora toca usarlo…

Llegados a este punto conviene que nos demos cuenta de algo, esto es un entorno de laboratorio, todas las librerías necesarias para la compilación en la primera máquina estaban instaladas, no olvidéis que vais a necesitar instalar cabeceras, gcc…etc para que compile a la primera. En la documentación de cada distro encontraréis información mas que de sobra para que todo vaya bien, pero no lo dejéis sin revisar. No se ha puesto aquí por no alargarlo innecesariamente y porque tampoco aporta nada nuevo, pero cada uno de vosotros en vuestro puesto tendréis unas necesidades distintas.

Asimismo también quiero que tengáis en cuenta que estas son máquinas instaladas en virtualbox y que, de haberlo querido hubiera podido extraerlas así:

 

Vboxmanage debugvm “nombre de la máquina virtual”  dumpvmcore –filename mem.elf

 

Y ya estaría solucionado, pero lo que he pretendido al hacerlos de esta manera, ha sido que fuera lo más realista posible, motivo por el cual os he dado toda esta chapa. Para hacer pruebas y ahorrar un buen rato podéis hacerlo así, pero en entorno real sería como os lo indico yo ¿de acuerdo?

 

Retomemos donde lo habíamos dejado, había subido todo a la máquina a investigar y ahora toca ejecutar…

captura-de-pantalla-2016-09-29-a-las-12-52-12

 

Ahí lo tenemos, ya hemos adquirido la memoria de esa máquina… Tan solo queda bajarlo de esa máquina y analizarlo con volatitlity…

captura-de-pantalla-2016-09-29-a-las-12-54-44

Archivo bajado a mi escritorio

De aquí en adelante toca analizar, pero eso, amigos míos, ya será otra batalla. Espero que os sean útiles estas líneas y que os hayáis aburrido mucho..

 

Un saludo…

 

P.D: Como anticipo de lo siguiente, mucha gente cree que solo se puede usar volatility desde la línea de comandos, ¿verdad?

evolve

 

¡Hasta la próxima!