Ser curioso NO es una opción (#USBOblivion ¿Una herramienta #Antiforense?) Parte I

Hola secuaces:

Comenzamos con la serie de entradas dedicada a mi primera vez, a la charla de este Rookie, (Espero que no sea la última), en #CONPilar17 y en #EastMadH4ck.

¿Por qué una serie de entradas? ¿Por qué no compartir directamente la presentación? Porque considero que es mejor así, donde puedo explicar todo, con todo lujo de detalles, y responder dudas de una forma más cómoda, en el supuesto caso en que las hubiera. Sin más.

Y ¿De qué hablé? Pues de lo único que tengo: la curiosidad. Del hecho de que ser curioso NO es una opción; De que la curiosidad NO es una opción.

El ser humano es curioso por naturaleza, aunque no todos lleven esa curiosidad a la práctica, o no siempre la llevemos a cabo. Porque seamos sinceros: muchas veces se nos olvida.

En el campo Forense por el que me muevo, cabe, más aún, demostrar ser más curiosos. Porque la curiosidad es una premisa fundamental: es una necesidad. El Forense, cuando ve algo que no conoce, (Un proceso, un fichero prefetch, una extensión, una cabecera, …), debe investigar y saber su procedencia, y debe saber cómo funciona el software que ha sido ejecutado en una máquina.

Seamos sinceros, nuevamente ¿Cuántas veces hemos ejecutado una herramienta sin saber qué hace realmente?¿Cuántas veces hemos actuado por pura inercia? Por ejemplo, Se ha perdido ‘X’ información. Nos limitamos a recuperarla por inercia, y punto. ¿Y la curiosidad? ¿Por qué pasan las cosas? ¿Cómo funciona esto o aquello? ¿A qué huelen las nubes? Muchas veces, la curiosidad nos puede allanar el camino. Y sobre todo, aprenderemos de ella, y con ella.

La exposición trataba sobre la realización de un análisis forense de un hipotético caso en el que se empleaba una herramienta antiforense muy específica, (USBOblivion), en su versión 1.11.2.0. Y el caso que expuse fue, que un Administrador de Sistemas, llegó a su puesto de trabajo antes de su jornada laboral, (Muy habitual esto, ¿A que sí?), y observó cómo otro empleado de la empresa estaba haciendo un uso indebido del equipo de su encargado: Una estación de trabajo que corría sobre un Sistema Windows 7, con un usuario con privilegios de administración, y sin contraseña, (porque claro, es Jefe). ¿Os suena? Por ese motivo, el Administrador de Sistemas, que es un tío muy curioso, y que se preocupa por saber y por el buen hacer, procedió a adquirir las evidencias oportunas, dado que sospechaba que hubiera extraído algún tipo de información.

Para ello, primero adquirió la memoria RAM del Sistema, usando la herramienta DumpIt.

Una vez se aseguró de que la imagen del volcado de memoria se generó de manera satisfactoria, desconectó el Sistema directamente del cable de alimentación y procedió a la adquisición en bruto del disco duro, usando para ello la herramienta Guymager.

Una vez hubo completado este proceso de adquisición del disco duro, se aseguró de que las dos imágenes generadas, (Volcado de memoria y Disco Duro), estuvieran correctas.

El objetivo, el alcance del análisis nos lo dejaron claro: Averiguar todos los dispositivos conectados al sistema, descubriendo cuál fue el último en hacerlo, justo antes de la intervención de este Administrador de Sistemas.

Os adelantaré que, para simular este caso, conecté estos ocho dispositivos de la imagen de abajo. Primero conecté los seis Pendrives. Antes de la intervención, que se hizo con el disco duro blanco Intenso, procedí a conectar el disco duro negro Toshiba, (Con el que me llevé del sistema un fichero de imagen), por lo que va a ser ese el que nos interese identificar.

Y una vez que tenemos las imágenes en nuestro poder, (además de hacer un par de copias de más), ¿Qué tenemos que hacer? Siempre hay que comenzar identificando y comprobando las evidencias.

Para ello, usamos ‘file’ con ellas. Simplemente porque las apariencias engañan, (Pueden estar los datos corruptos, no ser lo que dicen que son, …). Este comando ‘file‘ detecta el tipo y formato del fichero, analizando su encabezado. Calculamos su huella digital, su firma hash, que debemos cotejar con la que nos entreguen.

file IncidenteFuga.dd

sha1sum IncidenteFuga.dd

cat IncidenteFuga.info | grep 6b492eecb4d007e5bde7884f8f58736c10503b3e

Con el volcado de memoria, hacemos lo mismo. Primero le pasamos el comando ‘file’ al fichero de imagen. Después, usamos Volatility, (Existen varias opciones para instalar este Framework),  e identificamos tanto su sistema, a través de ‘imageinfo‘, como su fecha de adquisición.

sudo apt-get install volatility

file VIRTUALBOX-20161216-060955.raw

vol.py -f VIRTUALBOX-20161216-060955.raw imageinfo

Las fechas son un factor crítico, bajo mi punto de vista. Y siempre, también bajo mi punto de vista, tiene que ser la fecha del volcado de memoria, anterior al de la adquisición del disco duro.

Podríamos decir que ya tenemos identificadas las evidencias pero, para mí, aún no lo están como debieran. Para seguir con este paso de identificación, se hace necesario montar el fichero de imagen del Disco Duro en el laboratorio forense, usando el comando ‘mount‘.

Para ello, usamos el comando ‘fdisk‘, que nos mostrará toda la información relativa al disco duro, (Tamaño del disco, tamaño de los sectores, número de sectores, particiones, …). De estos resultados, nos queramos con el tipo de partición que presenta el disco, el tamaño del sector y el comienzo de la partición que vayamos a montar.

fdisk -l IncidenteFuga.dd

¿Por qué? Porque a la hora de montar el fichero de imagen, debemos especificar, entre otros parámetros, la dirección exacta del punto de montaje, que se calcula multiplicando el sector de inicio de la partición por el tamaño del sector.

sudo mount -t ntfs-3g -o ro,offset=105906176 IncidenteFuga.dd /mnt/windows_mount

También podemos emplear esta otra línea, en lugar de calcular antes el punto de montaje

sudo mount -t ntfs-3g -o ro,offset=$((512 * 206848)) IncidenteFuga.dd /mnt/windows_mount

En cualquier caso, tened muy en cuenta que, siempre se deberá montar la imagen en modo de sólo lectura.

ls /mnt/windows_mount

Y una vez que tenemos montada la imagen del disco duro, y como soy muy desconfiado, quiero terminar la identificación de los ficheros como se merecen, para comprobar que realmente ese volcado se corresponde al Sistema que contiene la imagen del disco duro, tomando un valor que considero único: La fecha de instalación.

Podréis decir… ¿Y si la empresa usa sistemas clonados?¿Si usa maquetas, por ejemplo? Pues tomaríamos otros datos como referencia. Por ejemplo, la fecha de creación de un usuario, la fecha de último login de un usuario, … Fechas.

Para ello, vamos a hacer uso de RegRipper.

git clone https://github.com/keydet89/RegRipper2.8.git

Vamos a usar el plugin ‘winver’, sobre el fichero del Registro de Windows ‘Software’, de la máquina que hemos montado. De esta forma obtenemos la fecha de instalación del Sistema.

perl rip.pl -r /mnt/windows_mount/Windows/System32/config/SOFTWARE -p winver

Para el volcado de memoria, usamos Volatility, primeramente con su plugin ‘hivelist’, que nos lista los Registros disponibles en el volcado, y usamos después ‘printkey’ junto con el ‘offset’, (La dirección), de la clave que queremos que nos muestre.

La fecha que nos aparece está en formato Unix, pero la convertimos con el comando ‘date’.

vol.py -f VIRTUALBOX-20161216-060955.raw –profile=Win7SP0x64 hivelist

vol.py -f VIRTUALBOX-20161216-060955.raw –profile=Win7SP0x64 printkey -o xfffff8a000206010 -K «Microsoft\Windows NT\CurrentVersion» | grep InstallDate

Las fechas de un sitio y de otro, deben de ser las mismas. En caso contrario… ya sabéis.

También podemos otras herramientas, o servicios online para realizar la conversión, como este: http://www.onlineconversion.com/unix_time.htm

 

Os pongo por aquí, como el que no quiere la cosa, el vídeo a mi exposición 😉

Esto es todo, por ahora. Nos leemos en la siguiente entrada. Se despide este minion, entregado y leal, de vosotros… por ahora.

Marcos @_N4rr34n6_