Peritaje II Análisis de memoria
El caso del HoneyPot fallido
Objetivos
• Seguir el proceso forense.
• Realizar un análisis forense de un incidente.
o Seleccionar las herramientas más adecuadas.
• Dar respuesta a las cuestiones planteadas.
o Correlacionar eventos utilizando múltiples indicios.
• Realizar un informe forense siguiendo las indicaciones de la unidad “Informe Forense”.
Descripción del Caso
El 10 de agosto de 2003 un sistema Linux Red Hat 7.2 fue comprometido. Dentro del sistema se
ejecutaba un honeypot orientado a recopilar información de los atacantes. Sin embargo, se cree
que un atacante logro sobrepasar el honeypot y comprometer todo el sistema. Por suerte el
sistema Linux en cuestión se ejecuta en una máquina virtual de VMWare. Una vez se detectó
que se había comprometido el sistema, se suspendió la imagen. Afortunadamente, este sistema
se consideraba propenso a ser comprometido y se calcularon los hashes MD5 de todos los
archivos antes de que el sistema fuera desplegado.
Vuestra misión es analizar el sistema comprometido. Los técnicos nos han hecho llegar una
imagen de la máquina comprometida. De nuestro análisis se espera que explique el impacto de
nuestras acciones como forenses en las pruebas.
Desarrollo
Seguiremos el ciclo más sencillo de cualquier análisis forense: preparación, adquisición, análisis
e informe. A continuación, os guiamos en todos los pasos.
Preparación
Vamos a trabajar con una máquina virtual probablemente comprometida. Por ello debemos
crear una máquina virtual forense que vamos a denominar laboratorio forense. Podemos utilizar
cualquier distribución forense disponible como SIFT Workstation (https://digital-
forensics.sans.org/community/downloads) o bien DEFT
(http://na.mirror.garr.it/mirrors/deft/zero/). En este caso vamos a trabajar con VirtualBox como
plataforma de virtualización. Pero el proceso sería similar con VMWare Player.
Y debemos comprobar que esas distribuciones tienen las herramientas forenses necesarias para
trabajar. En concreto la suite Sleuth Kit (https://www.sleuthkit.org/sleuthkit/).
Adquisición
Para poder analizar el sistema contamos con varios ficheros. Primero antes de suspender la
máquina virtual obtenemos los siguientes indicios:
• Comprobamos el estado de la tarjeta de red del equipo con la orden ifconfig. Nos indica
que la IP del equipo es 192.168.1.79 y la red se encuentra en estado promiscuo. Este
hecho se suele considerar un indicio de compromiso. El equipo donde se almacenan las
evidencias tiene la dirección IP 192.168.1.100 y se usa el puerto 9000 para recibir el
Peritaje II Análisis de memoria
resultado mediante netcat. Debemos tenerlo en cuenta a la hora de analizar los ficheros
obtenidos en vivo.
• Se ha ejecutado la orden netstat -na y se ha guardado la salida en el fichero
netstat.na.txt.
• Se ha ejecutado la orden nmap -sS -p 1- 192.168.1.79 y guardado la salida en el fichero
nmap.txt
• Se ha ejecutado la orden lsof -n y almacenado la salida en el fichero lsof.n.txt.
Por otra parte, tenemos a nuestra disposición el disco duro de la máquina virtual victima
(linux.vmdk). Para trabajar con la menor modificación posible agregamos el disco duro en la
configuración de nuestra máquina virtual laboratorio forense:
Una vez arrancada la máquina forense podemos comprobar que tenemos disponible el disco
duro con la orden fdisk -l:
Peritaje II Análisis de memoria
Vemos claramente que /dev/sdb1 es nuestro objetivo. En este punto podemos crear un fichero
.dd para trabajar con la imagen:
Ya tenemos un fichero captura.dd listo para trabajar. No se debe olvidar de calcular el valor MD5
de la partición y la captura.
Alternativamente podemos usar la herramienta quemu-img de Windows (disponibles en
https://cloudbase.it/qemu-img-windows/) para obtener una imagen dd para trabajar:
Por último, tenéis a vuestra disposición una captura Linux.dd para realizar el ejercicio. El hash
MD5 de este fichero es cdbc933377335d6bb365536a8226e859. Este fichero es una captura de
todo el disco duro: debemos obtener igual que antes las particiones correspondientes.
Análisis
La primera cuestión que debemos contestar es si el sistema ha sido o no comprometido por el
atacante. Para ello vamos a localizar indicios que nos permitan determinar si ha sido o no
comprometido.
Línea temporal y datos ocultos
Antes de realizar cualquier otra actividad debemos obtener una línea temporal de los eventos
sucedidos en nuestro sistema. Para ello recurrimos a la combinación de fls y mactime.
Peritaje II Análisis de memoria
Guardamos nuestra línea de tiempo en un fichero línea_temporal.txt.
También podemos concentrarnos en localizaciones sospechosas, como por ejemplo el directorio
/dev/. Para ello primero seleccionamos mediante grep en nuestro fichero fls.txt aquellas
entradas que contengan dicha carpeta y luego generamos nuestra línea de tiempo para esos
ficheros.
Los ficheros normales (o regulares) muestran un ‘-‘ en lugar de ‘c’ ó ‘b’. Usando esta
característica obtenemos una lista de sospechosos.
¿Qué ficheros aparecen creados o borrado en ese periodo que puedan resultar sospechosos?
Otra alternativa es buscar por ficheros que comienzan por ‘.’. Luego volvemos a jugar con fls,
grep y mactime restringiéndonos a los días sobre los que ocurre en incidente:
Analiza ambas líneas temporales y realiza una lista de los ficheros y directorios sospechosos que
cumplen estas características en el día del problema (10 de agosto de 2003).
¿Existen indicios de información oculta en algún directorio/fichero en el sistema?
Localizar ficheros de interés especial
Vamos a intentar localizar ficheros que tengan habilitado los bits de SUID y GUID activados así
como ficheros ejecutables.
Para ello, lo primero debemos montar nuestra captura en algún punto de montaje del sistema
respetando que no se van a producir modificaciones en su acceso con el comando mount.
Una vez montada la unidad, vamos apoyarnos en el comando find para localizar los ficheros que
tienen estos bits activos. Podemos localizarlos con la orden find /mnt/casohoney \( -perm -
004000 -o -perm -002000 \) -type f –ls.
Para dar con los ficheros ejecutables de la captura también vamos a usar la opción “-executable”
de find de la siguiente manera: sudo find /mnt/casohoney/ -executable -type f > ejecutables.txt.
Peritaje II Análisis de memoria
¿Existe algún fichero extraño en esa lista?
Ficheros y ejecutables añadidos o borrados
Una ventaja con la que contamos es con un listado de los valores de hash de los principales
ejecutables del sistema en el documento host79-2003-08-06.txt. Así que podemos realizar una
búsqueda para determinar que ficheros existían en el momento de realizar ese cálculo y cuáles
no están en nuestra captura.
1. Extraemos del fichero los ficheros del sistema operativo: host79-2003cat host79-2003-
08-06.md5 | cut –c 35- | sort > ficheros-antes
2. Creamos un fichero que contiene los ficheros de la captura: find /mnt/casohoney –
perm 0000 –type f | sort > ficheros-captura.txt.
3. Comparamos ambos listados con la orden diff: diff ficheros-antes.txt ficheros-
captura.ext > cambios.txt. Los ficheros que no aparecen en el primer fichero tendrán al
inicio de línea el símbolo “>”. Y los que no aparecen en el segundo fichero tendrán
delante el símbolo “<”. Luego los nuevos ficheros añadidos desde el cálculo están
precedidos de “>” y los ficheros borrados son aquellos que tienen “<”.
4. Vamos a extraer los ficheros añadidos de nuevo usando el comando cut: cat
cambios.txt | grep “>” | sort > ficheros_añadidos.txt
5. Y por último vamos a lograr la lista de ficheros borrados con el siguiente comando: cat
cambios.txt | grep “<” | sort > ficheros_borrados.txt
¿Se han añadido muchos ficheros?¿Se han borrado ficheros?¿Alguno de ellos podría ser
relevante desde la perspectiva de ocultar una intrusión?
Por último, debemos localizar si existen ficheros que pertenecen a usuarios desconocidos. Para
ello volvemos a apoyarnos en el comando find: find /mnt/casohoney –uid 48 –type f >
usuario_desconocido.txt. Estos ficheros son relevantes porque son importados de otros
sistemas.
En todo momento debemos justificar el impacto de nuestras acciones en el sistema. ¿Qué
impacto ha tenido hasta ahora todas las acciones orientadas a localizar una posible
intrusión?.
Procesos en ejecución
Cómo os describimos en el inicio del caso práctico, antes de apagar el sistema, se ejecutaron
una serie de comandos cuya salida se encuentra recogida en los siguientes ficheros:
• Se ha ejecutado la orden netstat -na y se ha guardado la salida en el fichero
netstat.na.txt.
• Se ha ejecutado la orden nmap -sS -p 1- 192.168.1.79 y guardado la salida en el fichero
nmap.txt
• Se ha ejecutado la orden lsof -n y almacenado la salida en el fichero lsof.n.txt.
Peritaje II Análisis de memoria
Usa la información en el fichero lsof.n.txt para completar la siguiente tabla (usa tantas filas
como creas necesario):
Proceso PID Puerto Puerto por Ficheros asociados Descripción
defecto en
Red Hat
En el fichero lsof.n.txt no todos los procesos tienen asociados un puerto. Debes usar algún
mecanismo para filtrar la información como por ejemplo el comando GREP. Esto nos permite
identificar los procesos sospechosos que tienen abierto un puerto. Además, podemos averiguar
qué ficheros tienen abiertos.
Ahora vamos a concentrar nuestra atención en si existen conexiones de red activas. Si existe una
queremos saber con qué dirección IP se conectan y el proceso asociado. Para ello vamos a
analizar la información contenida en el fichero netstat.na.txt. Vamos a recoger toda esta
información en la siguiente tabla (usa tantas filas como creas necesarias):
Proceso IP Puerto IP Puerto Servicio Descripción
origen Origen destino destino remoto
¿Podrías identificar el país de origen de las conexiones relacionadas con procesos
sospechosos?
Vamos a intentar obtener más información al respecto de estos procesos sospechosos. Para ello
podemos usar los ficheros que aparecen en la lista de ejecutables y que están asociados a los
procesos. Para ello podemos usar el comando stat para intentar obtener más información sobre
los ejecutables que no conocemos. Por ejemplo, vemos que en uno de los directorios ocultos
/lib/.x aparece un fichero xopen:
Peritaje II Análisis de memoria
También podemos usar la orden strings para ver que tipo de fichero se trata:
O por ejemplo tenemos en /usr/bin/ el fichero smbd -D:
Averigua lo que puedas de los ejecutables sospechosos en la lista.
¿Qué tipo de servidor parece representar este fichero?¿existen otros ejecutables asociados a
este servicio en la máquina?¿qué posibles consecuencias puede tener para la seguridad?
Apóyate en la línea temporal para establecer una correlación entre ellos y ver el posible
camino de la intrusión.
Análisis de registros
Visita los siguientes ficheros de actividad para poder determinar que actividad ha existido en la
máquina concentrándonos en el día del evento:
• /var/log/boot.log: nos va mostrar entradas del arranque y parada de la máquina así
como de algunos servicios como HTTP.
• /var/log/cron: va a indicarnos las tareas programadas del sistema.
• /var/log/maillog: nos va a informar de los correos enviados y recibidos. Algunos
rootkits pueden usar el correo electrónico para enviar o recibir información.
Peritaje II Análisis de memoria
• /var/log/secure puede incluir información de eventos fallados relacionados con
permisos y la seguridad del equipo.
Procesa estos eventos y añade los indicios que te proporcionan a tu investigación.
Información borrada
Vamos a usar la herramienta blkls incluida en la suite Sleuth Kit para localizar ficheros
borrados. Para ello podemos usarla de la siguiente manera: blkls captura.dd > no_borrado.txt.
Dentro de ese fichero podemos realizar búsquedas, por ejemplo, del comando wget que suele
usarse para descargar ficheros desde internet. Probamos a ver si localizamos peticiones:
strings no_borrado.txt | grep wget > peticiones_wget.txt.
¿Has podido localizar la descarga de algún ejecutable que hayas podido encontrar
sospechoso en preguntas anteriores?
En esa lista de descarga, ¿alguno de los ficheros se encuentra en la lista de los ficheros de
usuarios desconocidos?.
Información adicional
Usa los indicios localizados junto con cualquier otra información que puedas recuperar con
otros comandos para completar tu informe.
Informe
Revisa la documentación disponible en el módulo para realizar el informe forense y realiza uno
para presentar los resultados de tu análisis.
Sube este documento a la plataforma como respuesta a esta tarea.
