Search Results for: análisis forense

El concepto Cadena de Custodia (también referenciado en la literatura como CdC) no es algo que solamente se utilice en el entorno del Análisis Forense informático, sino que es un concepto ligado al ámbito legal y judicial, y es algo que incumbe a la recopilación de evidencias de cualquier tipo.

Para entender su importancia pongamos como ejemplo un caso que, desgraciadamente, está a la orden del día: un caso de corrupción.

[Read more…]

En multitud de ocasiones, cuando se habla de las actuaciones de un forense informático se remarca la necesidad de no alterar “la escena”. Se nos recuerda que debemos ser muy cuidadosos para no alterar nada, no conectar nada, no ejecutar nada. Aunque en la práctica, en mi opinión, esto no siempre es del todo así.

A la cabeza me viene el Principio de incertidumbre de Heisenberg, que se puede resumir de una manera muy sencilla en su aplicación práctica como que cuando se quiere medir la posición de una partícula subatómica ésta se altera, por lo que nuestra medición ya no será la real. En definitiva, si queremos medir la posición o características de un electrón, alteraremos su estado. O en nuestro caso, si queremos recopilar información, seguro que alteraremos algo.

[Read more…]

(Para evitar confusiones que pueda haber creado la anterior entrada, comentar que este post no trata de ser una guía paso a paso de un análisis forense, sino que consiste en proporcionar información que el auditor debe conocer a la hora de realizarlo e información que deberá utilizar según las necesidades del caso. Tanto vierito5 como Román Ramírez hacen apreciaciones muy interesantes en los comentarios de la primera parte de esta serie, que recomiendo encarecidamente leer.)

Después de haber obtenido todas las características principales del sistema a analizar, debemos averiguar qué ha podido pasar o qué acciones se han podido llevar a cabo. Para esto, Linux dispone de una serie de registros (logs) que nos facilitarán el obtener este tipo de información. Con la siguiente lista, se pretende hacer una breve introducción a algunos de los más importantes:

• /var/log/boot.log: En este registro podremos encontrar información que se almacena durante el arranque del sistema.
• /var/log/dmesg: Guarda los mensajes que lanza el kernel. Entre otros datos, almacena los mensajes sobre dispositivos hardware que el kernel detecta durante el arranque del sistema.
• /var/log/cron: En este registro se guardarán las acciones realizadas por “cron” (automatizador de tareas en sistemas Unix). Aunque en algunos sistemas este log viene desactivado por defecto, podemos obtener la información del mismo de /var/log/syslog con la siguiente instrucción: zgrep -i cron /var/log/syslog”.



• /var/log/apache2 (o /var/log/httpd): En este directorio encontraremos el registro de logs del servicio apache a través de los archivos access.log y error.log.



• /var/log/lastlog y /var/log/wmtp: El primero muestra cuando fue el último acceso de cada usuario al sistema, y el segundo un registro de los accesos del usuario al sistema. Para poder visualizarlos es necesario hacerlo a través de los comandos lastlog (para el primero) y last (para el segundo), ya que no se tratan de archivos de texto ASCII.



• /var/log/btmp: En este archivo podemos encontrar la lista de accesos fallidos al sistema. Como en el caso anterior, el archivo no se encuentra en ASCII, por lo que para visualizarlos utilizaremos el comando lastb.
• /var/log/mail.log, /var/log/mail.err, /var/log/mail.warn y /var/log/mail.info: Contienen los registros del servidor de correo que haya en el sistema. Entre otros datos, podremos encontrar información sobre los e-mails enviados.
• /var/log/messages: Este registro almacena los principales mensajes del sistema.
• /var/log/auth.log: Guarda información sobre el sistema de autorización de usuarios y permisos del mismo.



• /var/log/samba/: En este directorio se almacenan los logs relacionados con el servicio samba, el cual permite conectar equipos Windows con Linux.
• .bash_history: El archivo lo podemos encontrar en el directorio home de cada usuario. En él encontraremos el historial de comandos realizados por el usuario en cuestión. Además de accediendo al propio fichero, también puede accederse a su contenido a través de la instrucción history.

Para concluir el artículo, comentar que existen muchos más logs que podrían ser de interés dependiendo de los hallazgos realizados o de las acciones realizadas por el atacante. Por este motivo es muy importante prestar atención a cada uno de ellos y saber hacía donde dirigir el análisis forense para obtener el mejor resultado posible a medida que éste se va realizando.

Con esta serie de dos artículos se pretende hacer una pequeña descripción sobre algunos comandos y registros de logs que deben analizarse cuando nos encontramos ante un análisis forense en un sistema Linux.

(Añadido 29.05, 16h)

Para realizar esta serie de posts, se ha cargado la imagen del sistema afectado en una máquina virtual, por lo que ante cualquier modificación realizada, siempre se puede volver al sistema “original”.

[Read more…]

En un post anterior Ximo nos habló de los análisis forenses de memoria RAM en Linux y dentro de esta entrada hizo mención a dos herramientas para el análisis de memoria RAM en entornos Windows, que son Mandiant Memoryze y Mandiant AuditViewer.

En esta entrada vamos a ver funcionalidades de la herramienta para conocerla un poco y que sirva como presentación para los que no la conocen. Las pruebas para esta entrada las hemos hecho sobre los ficheros de memoria del reto DFRWS 2005 Forensics Challenge. Por si alguien quiere probar la herramienta los ficheros de memoria son memory1 y memory2. Para profundizar os aconsejamos la guía de usuario que ofrecen los autores y donde están todas las opciones detalladas.

Con todo listo pasamos a cargar el fichero “memory1” en la herramienta AuditViewer, con el wizard de la herramienta. Resumiendo la configuración para la carga del fichero y su análisis, marcaríamos todo menos la adquisición de procesos y drivers; además, para este caso concreto recopilamos la información de todos los procesos. Hay que tener en cuenta que en este caso el fichero de memoria RAM es de 128 MB, por lo que da más pie a marcar todas las opciones y en un corto periodo de tiempo obtener los resultados. En el caso de tener un fichero de memoria más grande, el tiempo de análisis por parte de la herramienta será más largo, ¿obvio no? :), viéndonos obligados a ser más finos en la configuración, sobretodo si no contamos con mucho tiempo. Añadir que esta entrada no intenta resolver el reto, sino que únicamente usa esas imágenes para mostrar funcionalidades de la herramienta.

Una vez cargado el fichero tendremos la siguiente imagen, donde se destaca en color ROJO uno de los procesos que hay en memoria que UMGR32.EXE:

Si miramos la documentación veremos que esto significa que se ha detectado algo sospechoso en ese proceso. Lo primero que nos debemos preguntar nosotros es: ¿Qué es UMGR32.exe? ¿Es un proceso malicioso o es un proceso legítimo y habitual en el sistema operativo? Si realizamos una búsqueda rápida en Google, vemos que todo apunta a que se trata de “Back Orifice 2000”, partiendo del nombre del proceso, dato no determinante.

Con lo que hemos encontrado en Google, decidimos empezar nuestro análisis por este proceso. Es por esto que vamos a ver la información recopilada sobre ese proceso en las diferentes pestañas que nos ofrece la herramienta:

Iremos viendo la información y analizando, intentando encontrar respuestas a las preguntas que pretendemos responder con nuestro análisis. Una de las opciones más interesantes, como suele ser habitual, es Strings, que nos mostrará las cadenas del proceso. En nuestro ejemplo veremos cosas cómo:

En las imágenes anteriores se ven cadenas bastante sospechosas, como metasploit.exe, como cadena de apertura de sockets en el puerto 44444, etcétera.

Además, si vamos a la pestaña de puertos vemos como tiene a la escucha el proceso el puerto 44444. Hecho que suele ser sospechoso, ¿no? :). Con lo que se requiere analizar en profundidad.

El proceso que ha detectado como sospechoso y por eso lo ha marcado en rojo, es porque tiene código inyectado en memoria y esto requiere un análisis especial. La herramienta de una manera muy visual y sencilla nos ofrece muchas posibilidades para analizar la memoria RAM y generar un informe de manera automática en diferentes formatos. Añadir que la herramienta tiene ciertos mecanismos que ayudan a detectar anomalías, como es el caso de Mandiant Malware Rating Index (MRI), así como la posibilidad de cargar reglas de Snort que transforma en plugins para buscar en la memoria (no he probado esta funcionalidad).

Mi impresión al utilizar la herramienta ha sido buena y os animo a los que no la conozcan a probarla y como siempre a darnos su opinión. Como siempre esperamos que os sea de utilidad.

Cada vez más las tecnologías de virtualización están más extendidas y prácticamente no se suelen encontrar servidores físicos dedicados. Es por ello que a la hora de gestionar un incidente que requiera de análisis forense detallado es necesario conocer el funcionamiento de cada tecnología de virtualización existente para poder tomar las evidencias necesarias para el estudio del caso.

Normalmente, dentro del grupo de gestión de incidentes solemos encontrarnos con casos donde la tecnología de virtualización empleada es VMWare o Hyper-V. Pero en otras ocasiones, como la que veremos a continuación, nos encontramos con otro tipo de tecnología de virtualización que no es tan común. Para esta entrada explicaremos de forma sencilla y resumida los pasos necesarias para tomar las evidencias del sistema de ficheros de un entorno de virtualización XEN, el cual presenta la particularidad de disponer de volúmenes lógicos LVM.

En primer lugar, es necesario exportar la máquina virtual desde Xen Server mediante la orden “xe vm-export”, almacenándola en un disco duro externo:

Una vez copiada la máquina virtual debemos crear la suma de comprobación para la cadena de custodia:

Ya en el laboratorio de análisis forense de nuestra empresa debemos extraer los discos duros de la máquina virtual Xen. Para ello desempaquetaremos en primer lugar la máquina, generándose un fichero XML y un directorio Ref:XX que contiene el disco duro:

En el siguiente paso se deberá emplear un script que permita crear el disco duro de la máquina virtual a partir del directorio Ref:XX. Este paso es delicado puesto que si empleamos la herramienta xenmigrate.py nos generará la imagen del disco duro sin tener en cuenta los ficheros sparse (copia en escritura), muy comunes en la virtualización. Esto funciona para discos duros con particiones estándar pero no en particiones LVM, donde al intentar montar los volúmenes lógicos, nos dará un error de entrada/salida.

Debido a este problema es necesario emplear una herramienta que soporte los ficheros sparse, de tal forma que al detectar un fichero de este tipo rellene con 0 el espacio que realmente tiene asignado. Mi compañero Raúl encontró un script sencillo en bash, por supuesto hecho por un mago :) que permitía esta función:

xenmigrate.sh: 

#!/bin/bash 

dd if=/dev/zero of=blank bs=1024 count=1k 
test -f image.img && rm -f image.img 
touch image.img 

max=`ls ???????? | sort | tail -n1` 
 
for i in `seq 0 $max`; do 
        fn=`printf "%08d" $i` 
        echo -n "$fn of $max" 
        if [ -f "$fn" ]; then 
                echo " - appending chunk" 
                cat $fn >> image.img 
        else 
                echo " - filling blank" 
                cat blank >> image.img 
        fi 
done 

rm -f blank 

echo "Done."

Podemos proceder a la extracción del disco duro de la máquina virtual empleando el script anterior:

Como resultado se obtiene una imagen de 20GB, que en nuestro caso coincide con los asignados al disco duro virtual frente a los 6GB que ocupan los datos. Por tanto confirmamos que se han rellenado los ficheros sparse con datos (ceros); una vez obtenida la imagen comprobamos que realmente se ha extraído correctamente:

El siguiente paso consiste en obtener la partición boot y la partición LVM:

A continuación se debe ya tratar la partición LVM como si de una partición raw LVM se tratara, creando por tanto los volúmenes lógicos:

Como vemos, las unidades lógicas del volumen VolGroup00 se han creado en el sistema de ficheros:

# pvdisplay 
  --- Physical volume --- 
  PV Name               /dev/loop0 
  VG Name               VolGroup00 
  PV Size               19,89 GiB / not usable 19,49 MiB 
  Allocatable           yes (but full) 
  PE Size               32,00 MiB 
  Total PE              636 
  Free PE               0 
  Allocated PE          636 
  PV UUID               XXXXX-XXXX-XXXX-XXXX-XXXX 
# ls -l /dev/mapper/ 
total 0 
brw-rw----. 1 root disk 253,   1 jul 12 18:04 VolGroup00-LogVol00 
brw-rw----. 1 root disk 253,   2 jul 12 18:04 VolGroup00-LogVol01

A partir de aquí activamos las unidades lógicas para poder hacer el volcado:

# vgchange -ay 
  2 logical volume(s) in volume group "VolGroup00" now active

Obtenemos las particiones contenidas en la unidad LVM:

# dd if=/dev/VolGroup00/LogVol00 bs=512 of=sda2 
# dd if=/dev/VolGroup00/LogVol01 bs=512 of=swap

Una vez extraídas las particiones ya podemos desmontar la unidad lógica LVM:

# vgchange -a n /dev/loop0 
# kpartx -d /dev/loop0 
# losetup -d /dev/loop0

Por fin disponemos de las particiones en raw de la máquina virtual para poder usar las herramientas de análisis forense o montar el entorno en solo lectura para su tratamiento. Por tanto a partir de ahora ya podremos comenzar a analizar, desde un punto de vista forense, las particiones sda1, sda2 y swap de la máquina virtual extraída.

(N.d.E. Hemos tenido algunos problemillas esta mañana con el blog. Esperamos que todo haya vuelto ya a la normalidad)

Durante el inicio de un incidente, el grupo encargado de su gestión debe comprobar primeramente si el incidente ha ocurrido. En caso afirmativo el primer paso a realizar sobre él o los entornos afectados es el volcado de la memoria RAM, puesto que es la pieza más crítica al ser la parte más volátil, y por ello, la que más fácilmente puede ser alterada durante el incidente.

Para ello se suelen emplear tanto herramientas libres como privadas, principalmente winXXdd o memoryze para entornos Windows y Memdump para entornos Linux. Esa captura debe ser copiada a otro entorno y nunca en el sistema de ficheros del entorno afectado, para ello se puede emplear NetCat (nc) o Samba (CIFS).

Pero es el análisis posterior donde radica la dificultad. Debemos de ser capaces, de dado el fichero en crudo de la memoria RAM, poder obtener información importante como qué programas se estaban ejecutando, qué puertos escuchando, qué ficheros abiertos, qué usuarios conectados, qué rutas ARP, qué configuración de las interfaces de red, etc.

En caso de tratarse de entornos Windows existen varias herramientas como Memparser para Windows 2000, Volatility para Windows XP SP2 y 3, o la herramienta por excelencia que consiste en la combinación de la captura de la memoria mediante Mandiant Memoryze y su posterior análisis con Audit Viewer.

[Read more…]