Forense en Babia. Parte 2

Si en el artículo anterior: “Forense en Babia. Parte 1” os contaba solamente la parte teórica de los sistema de computación en la nube, en esta segunda y tercera parte nos meteremos hasta la cabeza en el barro y pasaremos a la parte práctica del análisis forense en la nube. Como ya os imaginareis, cada vez son más las infraestructuras informáticas que operan en la nube, es decir, en un tercer lugar fuera del alcance físico de los administradores de sistemas y también de los analistas forenses informáticos, lo que implica que tanto para unos como para otro, su labor diaria cambie drasticamente. Los administradores de sistemas ganaran en tranquilidad al no tener que estar preocupados por fallos de hardware, ya que de estos fallos se encargan otro, los “dueños” de la nube. Pero para los analistas forenses la cosa cambia, la costumbre ancestral de todo lo que se “volcaba”, “clonaba” y “analizaba”lo podíamos ver y tocar con nuestras manos cambiará con el análisis forense en la nube, ya que la nubes no se tocan, solo se huelen 😉 .Para este cambio de paradigma tendremos que disponer de una mente abierta que nos permita adaptarnos a estas nuevas técnicas y modalidades de análisis, aunque si bien es cierto que los protocolos se basan en las técnicas tradicionales que llevamos años y años ejecutando, habrás ciertas peculiaridades como las que hoy os voy a contar, que harán que este tipo análisis sea un poco mas complejo.

Vamos al lío, en esta ocasión nos tocará analizar una instancia de un Ubuntu 16.04 de 64bits, sin interfaz gráfico, la cual está desplegada en los servidores de Irlanda de Amazon Web Services (AWS), la cual ha sufrido un ciber ataque, en el que alguien ha podido tomar el control remoto de esta instancia, para desplegar una servidor oculto en la Dark Web para vender droga a través de TOR, lógicamente, todo ello sin el permiso de los dueños de la instancia de AWS.

El primer paso, será acceder al panel de administración de la instancia afectada para de este modo poder determinar las características técnicas de la misma. En la siguiente imagen podremos ver toda esta información, como por ejemplo: Nombre de la Instancia (VPS IRLANDA); Dominio público con el que está operando (ec2-34-244-248-204.eu-west-1.compute.amazonaws.com) ; Tipo de Instancia (t2.micro); Zona de operación (eu-west-1c); Estado (Running / Stopped..); Identificador único de la instancia (i-09d357…); Grupos de Seguridad y las IP publicas y privadas de la instancia (172.31.21.174 y 34.244.248.204). Toda esta información la deberemos registrar debidamente.

 

Fig 1 Panel con las características de una Instancia AWS

 

También deberemos anotar las Keypass asociadas a la instancia (NambCORE), esto es la “key” que nos permite establecer una conexión remota segura a través de SSH con la instancia en cuestión, es decir, para poder administrar la instancia deberemos tener acceso a este fichero, si sospechamos que alguien se ha podido conectar de forma fraudulenta a nuestra instancia, significará o que han tenido acceso a nuestra “key” secreta, o que nos han generado una nueva para establecer una nueva conexión, por eso es importante listar todas las keypass generadas para una misma instancia. En esta ventana también podremos ver que tipo de instancia se trata (ubuntu-xenial-16.04-amd64-server-20170811 ); las tarjetas de red habilitadas (eth0); el tiempo que la máquina lleva encendida (51 horas) o los volúmenes de almacenamiento disponibles (/dev/sda1).

 

Fig 2 Características técnicas de la instancia 

 

Otra comprobación rutinaria, pero no menos importante será comprobar la configuración de las reglas del firewall que han sido habilitadas, en este caso, nada relativamente sospechoso (Un 80 y un 22).

 

Fig 3 Reglas Firewall

 

Llegados a este punto deberemos tomar una decisión muy importante: mitigar el ciber ataque cortando por lo sano, apagando la máquina afectada o “desconectándola” de Internet, o dejándola lanzada para analizar todas las comunicaciones que establece. En todo caso no hay una respuesta concreta, todo ello dependerá de cada caso y de la importancia del recursos afectado, así como de la información que contenga o de la disponibilidad que necesite. No hay que olvidar que ahora mismo el principal problema que tenemos, es la falta de control absoluto sobre la totalidad de los elementos afectados, en realidad solo tenemos un acceso web y en el mejor de los casos una conexión SSH a una máquina física que se encuentra a miles de kilómetros de nosotros y en la que verdaderamente está ocurriendo el ciber ataque. No podemos desconectar cables, no podemos conectarnos a una pantalla del Hypervisor, no podemos tirar del enchufe, no podemos sacar los discos duros… – ¿Y que podemos hacer?. – Vamos a verlo.

Lo primordial será salvaguardar la evidencia, para ellos crearemos un snapshot de la instancia afectada:

 

Fig. 4 Proceso de creación del Snapshot 

 

Fig. 5 Snapshot terminado

 

Ahora con el snapshot que acabamos de crear, generamos un volumen lógico del mismo.

 

Fig. 6 Creación de un Volumen desde un Snapshot 

 

En este momento ya disponemos una “copia forense” del disco duro del servidor afectado, pero tenemos un pequeño problema, la “la copia forense” se encuentra a varios miles de kilómetros de distancia de nosotros, y lo que es peor, de nuestro laboratorio forense. Por desgracia AWS, no dispone de un sistema 100% que nos permita “descargar” o “traernos” esa copia forense de una forma sencilla. Por eso que si la montaña no va a Mahoma, tendrá que ser Mahoma quien vaya a la montaña. – ¿Y como va a ir Mahoma a esa montaña?, o lo que es lo mismo: – ¿Como vamos a llevar un laboratorio forense a los servidores de Amazon Web Service de Irlanda?. – Muy fácil, ¡llevándolo!.

Tranquilos, no tendréis que comenzar desconectar vuestras pantallas de 40 pulgadas ni vuestros equipos forenses del laboratorio para llevarlo todo a Irlanda, esta vez será un poco mas fácil. Básicamente la idea es levantar una nueva instancia de Ubuntu en la misma zona de AWS (eu-west-1a), instalar las herramientas forenses de SIFT – Sans para así convertir el Ubuntu en una máquina forense y después asignarle el volumen lógico (disco duro) que hemos creado sobre la maquina afectada, y así poder analizarlo todo ello en remoto. Para ellos seguiremos los siguientes pasos:

Generamos una nuevo usuario “administrador” a nuestro AWS.

 

Fig 7 Generación de usuario 

 

Descargamos el fichero .pem para poder establecer la conexión remota SSH a nuestra máquina forense.

 

Fig. 8 Descarga del fichero 

 

Creamos una nueva instancia, la cual se convertirá en nuestra máquina forense. Aunque en un principio podrá ser perfectamente un Windows, veremos en las próxima parte de este artículo, que si levantamos una instancia exactamente igual a la afectada, podremos matar dos pájaros de un tiro y así ser un poco mas eficientes a la hora de realizar el análisis.

 

Fig. 9 Levantamos un Ubuntu 16.04

 

Como ya dije anteriormente, nuestra nueva instancia forense, deberá estar obligatoriamente en la misma zona de AWS (eu-west-1a) que el volumen que hemos generado anteriormente (no en la misma zona que la instancia afectada), ya que si no, no podremos “conectar” ambos elementos.

Fig. 10 Zona del volumen creado (no de la instancia)

 

Fig. 11 Zona de la nueva máquina forense

 

Fig. 12 Ambos elementos en la misma zona

 

Ahora solo nos queda conectar nuestra “copia forense” a la maquina Ubuntu de análisis. Cuando listamos todos los volúmenes que tenemos, veremos que uno de ellos está sin asignar, el que está sin asignar.

 

Fig. 13 Volumen sin asignar 

 

Como os podréis imaginar, el volumen que está sin asignar es el que hemos creado hace unos minutos, por lo que este será el que asignaremos a nuestra maquina forense

 

Fig. 14 Asignando Volumen a Instancia 

 

Hay que prestar especial atención a los ID de los distintos volumen, snapshots e instancias, para no confundirnos con las asignaciones. Finalmente le asignaremos una letra a la unidad.

 

Fig. 15 Volumen asignado

 

Cuando terminemos de configurar nuestra máquina forense, quedará tal que así, por un lado la maquina forense y por otro la máquina afectada.

 

Fig. 16 Máquinas disponibles

 

Antes de iniciar la maquina forense, comprobaremos que aparece asignado a la misma el volumen de la “copia forense”.

 

Fig. 17 Dos volúmenes de datos

 

Ahora, con el dominio de nuestra maquina forense, que acabamos de generar y el fichero PEM con la clave secreta que descargamos hace un momento, ya nos podemos conectar vía SSH a nuestro laboratorio de Irlanda. En caso que necesitemos utilizar Putty y no el cliente SSH de nuestro Linux, deberemos convertir nuestra clave tipo PEM de AWS a PPK, esto lo haremos con PuttyGen.

 

Fig. 18 Conversión de claves SSH 

 

Una vez convertida la clave a PPK, ya nos podremos conectar de forma remota a nuestro laboratorio forense de Ubuntu.

Fig. 19 Conexión SSH

 

Si todo va bien, tendremos una bonita shell de nuestro Ubuntu Forense.

 

Fig. 20 Ubuntu Forense 

 

Lo primero sera montar el volumen lógico de nuestra maquina victima en la maquina forense. Si no estamos seguro del volumen a montar, nos podremos ayudar de un:“fdisk -l

 

Fig. 21 Fdisk -l 

 

Una vez localizado el volumen a montar, con un simple mount lo podremos montar en nuestra máquina forense, ¡eh! pero “semos forenses”, siempre en solo lectura -ro (read only)

 

Fig. 22 Montando un volumen en Linux

 

Ya podemos bichear lo que hay en ese disco, y lanzar todas cuantas herramientas forenses gustemos de ejecutar contra el mismo, pero eso ya, lo dejamos para la siguiente parte de este artículo. – ¿O preferís que os lo cuente ya?, venga bah, seguimos un poco mas 😉

Venga, vamos allá, por ejemplo si se trata de una incidente de ciberseguridad que está relacionado con un servidor web creado de forma fraudulenta, lo primero que deberemos comprobar es la ruta: /var/www/html. Si se trata de un servidor Apache, será ahí dónde encontremos todos los ficheros de la web creada de forma ilegal. De no estar en esa ruta, visitaremos “sites-available” para comprobar el lugar exacto en el que estarán los ficheros que nos interesan. Para este caso concreto, al acudir a la ruta indicada, rápidamente descubrimos que esta maquina estaba ofreciendo un servicio oculto en la red TOR, determinando de este modo, cual es el dominio .onion del servicio oculto. Por supuesto, también obtendremos la clave privada del servicio.

 

Fig. 23 Ficheros www

 

Eso si, como hemos sidos precavidos montando el volumen en modo solo lectura (-ro) da igual lo manazas que seamos, no podemos liar ninguna.

 

Fig. 24 -Read Only 

 

Mas cosas… Si solo nos interesa los logs (¿Qué haría un forense sin sus logs?), algo rápido e indoloro: como la mayor parte de los logs de un sistema Ubuntu se encuentran en la ruta /var/log, ejecutando un simple “zip -r” podremos empaquetar todos esos logs en un solo fichero, de este modo, lo podremos descargar a nuestra máquina de ningún tipo de complicación.

 

Fig. 25 Empaquetado de logs 

 

Eso si, como buenos forenses que somos, le calcularemos una bonita firma digital HASH a nuestro fichero ZIP, para que de este modo, garantizar en todo momento que el fichero que hemos generado será el mismo durante todo el procedimiento, si alguien lo manipula, el hash cambiará, si o si.

 

Fig. 26 Calcular de la firma digital HASH 

 

Si necesitamos descargar el fichero var_log.zip que acabamos de generar a nuestra máquina local (España), podremos utilizar el protocolo SCP, de este modo no tendremos que que abrir ningún otro puerto como el del FTP en la instancia de AWS.

 

Fig. 27 Var_log vía SCP 

 

Lógicamente, vía SCP también podremos navegador directamente por los distintos ficheros y carpetas del “disco duro” analizado, aunque es un tanto “bruto” hacerlo de este modo, si solamente necesitamos comprobar una serie de ficheros concretos, podremos utilizar este método. No hay que olvidar que el volumen sigue estando bloqueado contra escritura, por lo que no podremos modificar ninguno de los ficheros que visionemos.

 

Fig. 28 Análisis SCP a los bruto

 

Pero no hemos montado toda esta parafernalia para simplemente hacer un zip de un par de ficheros. Así que vamos a subir un poco el listón y desplegar nuestro propio laboratorio forense en la nube, para ello tan solo necesitaremos instalar un SIFT de SANS en nuestro flamante Ubuntu 16.04

 

Fig. 29 Descarga del script de de SIFT 

 

Fig. 30 Instalación de SIFT

SIFT es una distribución forense open source poderosa y libre de SANS. Esta formada por un grupo de herramientas (gratuitas) de código abierto diseñado para realizar exámenes forenses digitales en una variedad de entornos. Se puede utilizar a través de distintos entornos, como por ejemplo un appliance de VMware, o como el caso que ahora nos ocupa, a través de una instalación limpia de Ubuntu.

Ya con nuestro SIFT en la nube, el limite será nuestra imaginación, así que con este despliegue podremos realizar las mismas tareas que hubiéramos ejecutado en nuestro laboratorio local.

En algunas ocasiones, necesitaremos realizar una imagen forense local del disco duro afectado, por ejemplo, en caso de que sea necesario clausurar la cuenta de AWS, ya que si no hay cuenta, tampoco habrá acceso a la máquina forense Ubuntu, y mucho menos, a la “copia forense” que hemos realizado. Como ya dije anteriormente, AWS no ofrece muchas posibilidades a la hora de descargar volúmenes a nuestro equipo local. Sin embargo, con esta infraestructura que hemos desplegado, por ejemplo a través de un simple “dd” podremos realizar una imagen del disco duro afectado (EW si queremos ser un poco mas «pros»), almacenarla en la máquina forense y de ahí, descargarla a nuestra máquina local.

 

Fig. 31 Generación DD 

 

Una vez generada la imagen, nos la podremos descargar a nuestra máquina local, previo calculo de su correspondiente firma digital HASH. Una vez en nuestros dominios, ya es como si tuviéramos la instancia afectada por el ciber ataque en nuestra propia casa, por si el tema del forense en la nube no os acaba de convencer.

 

Fig. 32 Descarga de la imagen a través de SCP 

 

En este artículo no me voy a meter mucho en explicar protocolos forenses, ya que al fin y al cabo, la idea de hoy, es explicaros como desplegar nuestra infraestructura forense en la nube, una vez desplegada correctamente, el procedimiento es idéntico a un análisis forense tradicional en nuestro laboratorio local.

¿Qué mas cosas podemos hacer?. Por ejemplo podremos hacer carving al volumen afectado, y así recuperar ficheros eliminados que nos pudieran ser de interés. Eso si, personalmente en este caso prefiero el software Photorec antes que Foremost, digamos que Foremost por SSH se queda anomalamente “quajado”, mientras que Photorec suele funcionar correctamente. Aunque también lo podríamos hacer en local con nuestra imagen forense que nos acabamos de generar y descargar.

 

Fig. 33 Carving Foremost 

 

Fig. 34 Carving Photorec 

 

Una vez terminado la recuperación de ficheros eliminados mediante carving. ¿Qué hacemos?, si… Un hash de todo de todos los ficheros recuperados, a poder ser ya lo almacenamos en un text para ahorrarnos trabajo.

 

Fig. 35 Ficheros recuperados 

 

Al final aunque la nube nos imponga un poco de respeto, ya veis que es todo bastante sencillo y siguiendo unos simples pasos, podréis realizar todo un análisis forense en la nube.

La próxima parte de este artículo, será cuanto menos ¡un poco mas viva!. No trataremos una imagen muerta, si no que trabajaremos con un sistema vivo a través de la memoria RAM de la maquina Linux que ha sido atacada en la nube.

 

Continúa leyendo la Tercera parte de: Forense en Babia 3.  PULSANDO AQUÍ.

 

¿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.

Manuel Guerra

Mi nombre es Manuel Guerra. Investigador especializado en: [eCrime] | [Forensic] && [Hacking]. Editor de GLIDER.es

Navegación de la entrada


Comentarios

  • Carlos F

    Gracias Manuel, me están gustando los tips que proporcionas.

  • Josep

    Muy interesante i revelador Manuel, muchas gracias por el post. Hay una cosa que no se si he entendido bien. La base es trabajar sobre el disco duro en producción (en solo lectura), excepto cuando se indica la posibilidad de clonar via dd. ¿És así? En tal caso, mientras se realiza el anàlisis siguen en vivo el sistema y por tanto pueden haber variaciones, incluso inducidas por el atacante si detecta nuestra presencia. Siendo así, se puede estar jugando al gato y el ratón, aunque se vayan revertiendo instantáneas. ¿como lo ves?

    • Manuel Guerra

      Muchas gracias Josep.

      En cuanto a lo que comentas, existen varios escenarios, en función a la necesidad de recopilación de evidencias que se necesite, se debe jugar mas o menos con un entorno en plena producción. En este artículo concreto, la idea es «copiar» el disco duro de la máquina que ha sido victima del ataque y asignárselo a otra nueva máquina a la cual solamente se puede acceder desde las nuevas credenciales que hemos generado, aunque las anteriores pudieran haber sido robadas, ya no son validas para acceder a la máquina forense (es el fichero PEM del que hablo).

      Un saludo.

      • Josep

        Aclarado, gracias de nuevo por compartir tus conocimientos.

  • inginformatico

    Buenas Manolo y enhorabuena por tus posts.

    Sobre este análisis forense sobre una máquina en AWS me surgen ciertas dudas.

    El post describe muy detalladamente la respuesta ante un incidente, pero si pensamos en el trabajo de un Perito Informático destinado a un procedimiento judicial, ahí comienzan mis dudas.

    Los Peritos debemos ser lo mas «limpios» posibles para no contaminar los entornos analizados y para preservar las evidencias. Ni se nos ocurre arrancar la maquina objetivo si está parada y lo primero es clonar el sistema sin alterarlo.

    Pero según el procedimiento que nos presentas, partes de acceder al panel de control de AWS (usando las claves de acceso del propietario claro), de crear un volumen en el mismo, una máquina nueva, etc.

    ¿No crees que todo esto supone cierta contaminación del entorno de análisis? ¿Crees que esta contaminación es inevitable?

    • Manuel Guerra

      Hola. Bueno hoy en día esa idea de que los sistemas no se pueden arrancar o iniciar ya está pasando un poco de moda, por ejemplo, en telefonía móvil es preciso arrancar el sistema para poder realizar una extracción de la información que contiene. Incluso para algunos ordenadores portátiles ultrafinos, también es necesario arrancarlos, lógicamente tomando las medidas de seguridad precisas.

      En cuanto al artículo, hay dos puntos diferentes, el primero es el acceso a la cuenta de AWS que nada tiene que ver con la instancia, desde al cuenta de AWS es desde dónde se realiza el copiado integro del volumen de la instancia afectada, pero este proceso no altera el contenido del volumen, ya que estamos operando a una capa superior.

      Un saludo.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puede usar las siguientes etiquetas y atributos HTML:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>