¿Quieres montar tu propio laboratorio de adquisición de evidencias DFIR?¿Estás cansado de utilizar clonadoras para generar imágenes de discos duros?. Sigue leyendo, quizás te interese lo que te voy a contar en este nuevo artículo de GLIDER.es

Comencé el primer artículo de esta serie sobre clonados diciendo: que para realizar un clonado o una imagen forense del disco duro de un ordenador, simplemente cogemos el disco duro, lo conectamos a un dispositivo de adquisición, botón siguiente, siguiente y ya tenemos nuestra imagen forense preparada… Pero… ¡Oh, wait!, ya vimos que esto no era tan fácil como a priori podía parecer, ya solo el hecho de llegar al disco duro de un ordenador, en algunos casos, puede ser una tarea del todo imposible, por no hablar de algunos tipos de sistemas de almacenamiento que van prácticamente soldados a las placas bases de ordenadores portátiles ultra-finos, tipo de ordenadores que por cierto, cada vez abundan mas. La opción de no actuar sobre este tipo de ordenadores por no poder acceder a su disco duro, está descartada. El trabajo de un forense informático no solo debe ser limitarse a pulsar el botón “siguiente”, “siguiente” en una máquina o un software que cuesta varios miles de euros, como ya dije mucha veces, un forense, tiene que tener muchas cualidades: técnica, conocimiento, objetividad, no apasionamiento, y también, un poco de artesano. Artesanía que en numerosas ocasiones se necesita para llegar un poco mas allá del camino marcado, solo así podremos llegar a obtener conclusiones que permitan alcanzar el fin de todo procedimiento forense, que es ni mas ni menos:  la búsqueda de la verdad.

 

 

Fig.1 Artesano en su materia.

 

Pero volviendo al problema de los discos duros y los ordenadores ultrafinos. ¿Qué hacemos con ellos?. Una opción sería arrancar el ordenador en cuestión, y a través de métodos de análisis directo sobre un sistema iniciado, tratar de extraer la máxima información posible del mismo, esta opción la dejaré para futuros artículos. Hoy vamos a ver como poder realizar una imagen forense, de esos dispositivos a los que no podemos acceder de ninguna forma tradicional a su disco duro. El método que vamos a utilizar no va a ser otro que usar un sistema Live, estos sistemas nos permiten arrancar el dispositivo en modo seguro y así realizar la adquisición sin modificar la evidencia, pero ¡OJO!, aunque esto puede parecer una tarea simple, vamos a ver como complicarla para poder exprimir al máximo el sistema y así adquirir un mayor número de evidencias en el menor tiempo posible.

 

Fig.2 4 horas en las que podremos tomar 8 cafés con leche.

 

Hoy en día un forense no solo tiene que ser eficaz en su trabajo, también tiene que ser eficiente. Imaginemos una oficina de cualquier empresa, en la que puede haber,  entre ordenadores de sobre mesa, portátiles, teléfonos y tablets, unos mil equipos informáticos. La opción de ir ordenador por ordenador, desmontando la torre, extrayendo el o los discos duros, conectándolos a una “clonadora” y realizar la adquisición, se puede antojar cuanto menos prolongada en el tiempo. Ha llegado el momento de comenzar a utilizar el hardware del propio ordenador “evidencia” para realizar la adquisición de esta, y no solo el ordenador, si no que también, llegó el momento de aprovecharnos de toda la infraestructura de red que dispongamos a nuestro alcance.

 

 

Fig.3 Típico armario de comunicaciones.

 

Aquí es dónde entran las capacidades de inventiva, pensamiento lateral y artesanía que un forense debe tener (¿Solo un forense?), para poder convertir en pocos minutos una red informática de una empresa, que por ejemplo ha recibido un ciber ataque, en una red de laboratorio preparada para realizar una adquisición de información de forma masiva, y sobre todo, de forma adecuada.

¿Vamos a ello?

Volvamos al ejemplo anterior, empresa con unos 400 empleados, en la que cada uno de ellos dispone de un ordenador de sobremesa conectados a la red corporativa, y algunos incluso disponen de un ordenador portátil que sacan de las instalaciones de la empresa. Por el momento, de teléfonos y tablets no vamos a hablar. Esta empresa ha sufrido un ciber ataque, en el que al menos, uno de los equipos informáticos conectados a la red corporativa, ha sido infectado con un ransomware y este ha infectado al resto. Pero no saben desde cual, nuestra misión será realizar la adquisición de todos esos ordenadores, para que en un posterior análisis determinar cual ha sido el vector de ataque y poder bloquearlo.

 

   

Fig.4 Ransomware WannaCry

 

Como todos los ordenadores de la empresa están conectados a un red corporativa LAN que opera a 1 Gbps, nos aprovecharemos de este recurso para agilizar las tareas de adquisición. Los switches con los que operan para interconectar distintos departamentos no disponen de conexiones de fibra, es decir, el limite lo tenemos en la red a 1Gbps. Como los switches si son configurables, desplegaremos una nueva VLAN, a la que iremos conectando los ordenadores para realizar la adquisición de sus discos, si, lo haremos por red. Lógicamente, esta VLAN será a nivel de switch para aislar la red corporativa de la red de adquisición. Configurando la red de esta manera, no solo, no tendremos que manipular ningún ordenador: cambiándolo de sitio o llevándolo a otras instalaciones, si no que los podremos ir adquiriendo sin apenas alterar el funcionamiento del resto de equipos.

 

 

Fig.5 Croquis de 3 VLAN

 

Además, aprovecharemos la configuración de los switches ya instalados, para exprimir sus capacidades al máximo, ya que no nos conformaremos con las velocidades por defecto de 1 Gbps. Por ejemplo, podemos desplegar bocas en modo “agregación” o “teaming”, esta es una tecnología que permite sumar la velocidad de transferencia de varias bocas de por ejemplo un switch pero que a nivel de red, opera como una sola boca. De este modo se pueden mover grandes volúmenes de datos mas rápidamente. – ¿Pero si he dicho que los ordenadores de la empresa solo funciona a 1Gbps para que necesitamos enlaces a 2 o 4 Gbps?. – Muy fácil, para conectar nuestras cabinas de almacenamiento o NAS, las cuales, normalmente disponen de mas de un adaptador físico de red. De este modo, ya estamos logrando realizar la adquisición en la mitad de tiempo, ya que aunque un solo equipo puede llegar a transferir datos a 1 Gbps, lo que realmente nos debe de preocupar es la velocidad a la que las cabinas de almacenamiento estén conectadas, ya que si las logramos conectar a por ejemplo 2Gbps a través de una agregación, podremos volcar información de muchos más equipos contra un sola cabina, todo esto, sin tener un cuello de botella a nivel de switch, el cuello lo tendremos a nivel de velocidad de escritura de disco, pero eso ya es cuestión de gastarnos los cuartos y montar cabinas con discos de estado solido tipo SSD.

 

 
Fig.6 Teaming en un sistema Windows

 

Por otro lado, si los ordenadores que hay que adquirir (¡Que no es comprar!), disponen de dos tarjetas de red, aunque solo estén utilizando una, se puede configurar la segunda de ellas en “teaming”, y así poder adquirir el disco duro el doble de rápido (lógicamente, siempre teniendo en cuenta las limitaciones físicas de escritura y lectura de los discos duros). Con estos sencillos consejos, ya nos hemos montando un laboratorio de adquisición DFIR, prácticamente sin gastarnos un duro. Y aún encima de forma elegante, ya que nos hemos evitado llenarnos de polvo al tener que desmontar 400 ordenadores, además de reducir notablemente el tiempo de adquisición de evidencias. Por no decir, que no necesitaremos 400 discos duros de destino y otras tantas “clonadoras”.

 

 

Fig.7 NAS con dos tomas de red.

 

Pero tampoco seamos temerarios, si la infraestructura de red de la empresa dispone de varios switches, vamos a realizar la adquisición por sectores, es decir, desplegaremos estaciones de almacenamiento en cada segmento físico de la red, así los datos no tendrán que pasar por toda la red. Por ejemplo, si 40 equipos de un departamento están conectados a un mismo switch, conectaremos la cabina o NAS a ese switch y realizaremos la captura, así no sobrecargaremos el resto de red, ya que meterle 400 equipos al mismo tiempo a un único NAS, no creo que sea muy eficiente 😉 .

Las empresas tienen la mala costumbre de necesitar mantener la producción para seguir ganando dinero, si se corta la producción, se corta el dinero, cada segundo que se puede ahorrar en la tarea de adquisición, será un segundo que la empresa pueda estar produciendo. – ¿Y se puede agilizar todavía mas?, – Si la tecnología nos lo permite, si. Por ejemplo, como sabemos que lo que vamos a transferir contra las cabinas de almacenamiento son imágenes forenses, es decir, grandes volúmenes de datos, podemos activar los “jumbo frames” en la red, de este modo estaremos moviendo mas “chicha” y menos “estorbo”. Esto ya es un tema mas de redes, pero para enviar un datagrama (paquete de información) en una red normal, una parte de los datos transferidos contienen la cabecera del mensaje y el resto ya es el mensaje que queremos enviar. Si lo que necesitamos es mover un volumen grande de datos grandes (valga la redundancia), podemos forzar a que las tramas sean mas grandes de lo normal, así por cada trama podemos enviar mas contenido. Para mover un par de Gigabytes, esta configuración ni se nota, pero cuando se trata de cientos de Terabytes, optimizar un 40% cada uno de los paquetes enviados, nos ahorrará mucho, mucho tiempo.

 

 

Fig.8 Datagrama TCP 

 

 

Fig.9 Croquis de un Jumbo Frame

 

Como comenté, en una red los paquetes se llaman “frames” y su tamaño lo determina el MTU ( Maximum Transmission Unit o Unidad Máxima de Transmisión). Teóricamente cuanto mayor sea el tamaño de los “frames” mayor será la velocidad de transmisión, ya que por una parte la información no se troceará en tantas partes, ademas, nos ahorraremos sobrecargar la red con los encabezados que cada frame lleva a su comienzo. Por ejemplo, el tamaño estándar de MTU de un frame es de 1500 bytes, si modificamos este valor, por ejemplo por el valor máximo de un MTU de 9000 bytes, a nivel 2 (Ethernet) lograremos ahorrarnos enviar 5 cabeceras de frame por cada jumbo frame, ya que con una sola cabecera, podemos enviar cerca de 9000 bytes. ¡OJO! Si estáis pensando hacer esto en vuestras casas para aumentar la velocidad de Internet, siento deciros que no va a funcionar, al estar a un nivel de capa 2, de poco sirve que nosotros pongamos un MTU a 9000 en nuestro ordenador, si el resto de red sigue operando a 1500. Lógicamente, la activación de los jumbo frames, la hay que hacer en toda la electrónica de red por la que pase la comunicación desde origen a destino, y solo merecerá la pena esta configuración, cuando tengamos que mover grandes volúmenes de datos por mucho tiempo, y hasta aquí la clase de redes TCP de hoy 😉

 

 
Fig.10 MTU 9000 vs 1500 (foto naseros.com)

 

Con la parte de red, ya hemos terminado, ahora nos vamos a poner con la parte mas importante, los equipos a los que le hay que adquirir sus discos duros. Por ejemplo, el primero de ellos será un Asus Zenbook ultraplano (Si, ese es mi ordeandor personal, ¿No pensareis que estos artículos los hago con datos reales?). El plan no es otro que arrancar el ordenador portátil ultraslim, con un sistema forense, del tipo live, es decir, que se puede ejecutar desde un pendrive o CD. Estos sistemas forenses nos permiten utilizar los recursos informáticos del ordenador, sin necesidad de iniciar o manipular el sistema operativo del host. Básicamente, el sistema operativo live forense, se carga en memoria RAM desde el USB o CD.

 

 
Fig.11 Pendrive con Deft Linux

 

Una vez cargado, el disco duro que tiene instalado el sistema operativo del host (Windows, Linux…), pasara de ser el disco principal del sistema, a ser un disco mas. Detalle importante, es que el sistema operativa live sea forense, esto no es que lo haya que operar con bata blanca, un sistema forense, es el que esta configurado por defecto para que no monte las unidades de disco duro secundarias (las que están conectadas al ordenador a analizar) en modo escritura, lo ideal, es que el sistema live: o no monte por defecto ninguna unidad, o que en el caso de que las monte, que las monte en modo solo lectura. De este modo estamos garantizado que no se realiza ninguno tipo manipulación sobre la evidencia. Aunque no me gusta hablar de marcas o sistemas concretos, dos buenos sistemas operativos, ideales para ser lanzados en modo live son: Paladin de SUMURI y Deft Zero, el segundo de ellos, ocupa escasos 500 Mb, por lo que apenas nos costará ejecutarlo en un ordenador con pocos recursos, eso sí, ¡OJO! con intentar bootear el sistema Live desde un pedrive, hay que prestar especial atención al tipo de BIOS o UEFI que tenga el ordenador, así como, al tipo de formato que le tendremos que dar a nuestro pendrive, ya que para según que sistemas tendrá que ser GPT y para otros MBR.

 

 

Fig.12 Croquis GPT vs MBR

 

Esto aunque parezca una tontería, nos puede dar muchos dolores de cabeza, ya que los “nuevos” sistemas UEFI, a veces son muy pejigueros a la hora de permitir bootear desde un unidad USB. Si se nos complica mucho la cosa, siempre los podemos bootear desde un CD o DVD en el que hemos grabado previamente nuestro sistema Live.

 

 

Fig.13 Una BIOS Old School

 

Una vez tengamos el sistema live inIciado (y no la hayamos liado a la hora de pulsar la tecla de la BIOS / UEFI para seleccionar la unidad de booteo de nuestro sistema live y no la de booteo del sistema operativo del anfitrión, ya que si esto ocurre, hemos alterado la evidencia al haberse iniciado el sistema operativo que no tocaba). Ya con el sistema live iniciado correctamente, podremos conectar al ordenador un disco duro y comenzar a almacenar la imagen que vamos a crear.

 

 

Fig.14 Selección de arranque en Deft.

 

Pero en este caso no almacenaremos la imagen del disco duro en otro disco duro conectado por USB, si no que, a través de por ejemplo un protocolo SMB, enviaremos en directo, todos los bits de esa imagen a través de la red del propio emplazamiento (que ya hemos preparado para que funcione en modo “full equip” bonding + jumbo frames), hasta un sistema de almacenamiento tipo NAS, en el que se irán guardando los ficheros de todas la imágenes que están ejecutando al mismo tiempo. El programa utilizado para realizar la adquisición de los discos duros de la evidencia puede ser por ejemplo Guymager, como ya expliqué en la primera parte de esta serie de artículos: https://glider.es/el-clonado-ya-no-se-lleva-parte-i/ podremos utilizar cualquier otro, ya que si lo hacemos correctamente, el resultado tiene que ser siempre el mismo.

 

 

Fig.15 Discos mapeados en red.

 

Si ya lo que queremos es rizar el rizo y no nos preocupa en exceso que la información no viaje cifrada a través de la red, podemos realizar las capturas con Netcat + dd. Este método nos permitirá realizar la adquisición de un disco duro a través del comando de Linux DD y luego enviarla por la red a través de Netcat a otra máquina que tendremos a la escucha con este mismo programa. Pero si no nos queremos complicar, simplemente mapeamos un disco duro en red (el de nuestro NAS) y ya volcamos tranquilamente las evidencias contra ese disco mapeado en nuestro sistema live forensic.

 

 

Fig.16 Cacharreando con NetCat

 

Incluso, si nos venimos arriba, y disponemos de una WAN lo suficiente rápida, podríamos realizar la adquisición contra un datacenter que ni tan siquiera se encuentre en el lugar de la adquisición, pero eso ya para otro día.

Muchas veces, cuando hablamos de métodos DFIR, nos vamos a que si triage, timelines, análisis dinámico o estático de malware, interrelación de información y otros menesteres, pero nos olvidamos de lo principal, que no es otra cosa, que el hacer la adquisición de información. En entornos grandes, está adquisición no resulta sencilla, lo que obliga al técnico forense, a disponer de todos cuantos recursos estén a su alcance para agilizar este proceso. La idea de este artículo era precisamente esa, enfocar el mundo del DFIR desde otro punto de vista distinto, un punto de vista real, explicando los problemas que tendrá que solucionar cualquier analista que se tenga que enfrentar a este tipo de trabajos. Artículos sobre “triage”, ya hay muchos 😉 . Por otra parte, mi idea era también explicar la forma de poder montar nuestro propio laboratorio para adquisición de evidencias a través de red, dejando a un lado, siempre que sea posible, las viejas prácticas de utilizar clonadoras «físicas» para adquirir un disco y volcarlo en otro disco conectado a la misma clonadora (Si no te quieres deshacer de tu vieja clonadora, siempre la puedes conectar por red, y realizar las adquisiciones con la clonadora, pero contra una unidad de red). Centralizado todas las imágenes en un único almacenamiento, no solo el proceso de adquisición será mas eficaz, si no que, una vez  la imagen se encuentre almacenada, sin necesidad de volver a copiarla a otro sitio, ya se podrá comenzar el análisis de la misma.

Si te ha gustado este artículo, no dejes de leer los dos artículos anteriores de la misma serie:

 

1º: El clonado ya no se lleva. Parte I

2º: El clonado ya no se lleva. (Mini historia)

 

Salu2

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