solución al reto forense #5 de Sans

El día 1 de Abril, Sans organizó un nuevo concurso forense desde la página http://forensicscontest.com/2010/04/01/ms-moneymanys-mysterious-malware. El concurso consiste en responder una serie de cuestiones que se nos plantean desde la organización, ofreciendo una captura de red como evidencia. Al final, después del plazo estipulado, el ganador se lleva un premio, en este caso un portátil. El concurso, además, valora por encima de todo el escrito final y si se han programado utilidades para poder solventarlo. Una vez acaba el concurso, se publican los nombres de todos los participantes que respondieron correctamente y las soluciones y scripts de los semifinalistas y finalistas.

Comenzando el reto

En esta ocasión, el reto consiste en averiguar una serie de cuestiones sobre una máquina infectada por alguna clase de malware:

The puzzle:

It was a morning ritual. Ms. Moneymany sipped her coffee as she quickly went through the email that arrived during the night. One of the messages caught her eye, because it was clearly spam that somehow got past the email filter. The message extolled the virtues of buying medicine on the web and contained a link to the on-line pharmacy. “Do people really fall for this stuff?” Ms. Moneymany thought. She was curious to know how the website would convince its visitors to make the purchase, so she clicked on the link.

The website was slow to load, and seemed to be broken. There was no content on the page. Disappointed, Ms. Moneymany closed the browser’s window and continued with her day.

She didn’t realize that her Windows XP computer just got infected.

You are the forensic investigator. You possess the network capture (PCAP) file that recorded Ms. Moneymany’s interactions with the website. Your mission is to understand what probably happened to Ms. Moneymany’s system after she clicked the link. Your analysis will start with the PCAP file and will reveal a malicious executable.

A grandes líneas, el texto nos introduce en el contexto de nuestra investigación. Una persona curiosa decide pinchar en un enlace a una página de venta de productos farmacéuticos. Después de un tiempo esperando, parece que la web no se muestra, por lo que decide seguir con su vida. Sin saberlo, esa web contiene un código malicioso que acaba de infectar su puesto. Para averiguar lo que ha pasado realmente, se dispone de una captura de red.

Lo primero que se va a realizar es la descarga de la captura y comprobar la huella digital:

Figura 1. Comprobando el MD5 de la evidencia

Una vez se ha asegurado que la captura tiene el mismo hash, se examina un poco la captura para tener más datos del entorno que tenemos que investigar. Se comienza por graficar los flujos de paquetes para identificar las máquinas involucradas. Para esto, se ha programado un pequeño script que obtiene los datos desde tshark y crea la gráfica, dándole mayor tamaño a aquellas ips con más tráfico:

Figura 2. Gráfica de flujos

Se puede observar que las dos ips con más tráfico son 192.168.23.129 y 59.53.91.102. También que tódo el tráfico tiene como punto en común la ip interna, por lo que se deduce que esa debe ser la ip de la máquina infectada. Para terminar, se decide poner en el punto de mira la ip 59.53.91.102 porque es la que más tráfico ha intercambiado y por lo tanto, podría ser el origen de la infección.

El script utilizado es el siguiente:

#!/usr/bin/perl

use GraphViz;

my %ips;
my %flows;
my $g = GraphViz->new();
my $count=0;

my $out = qx/tshark -r infected.pcap -Tfields -Eseparator=, -e ip.src -e ip.dst/;

@data = split(/\n/,$out);

foreach my $line (@data) {

my ($src, $dst) = split(/,/,$line);
$ips{$src}++;
$ips{$dst}++;
my $hash = "$src:$dst";
$flows{$hash}=1;
$count++;
}

foreach my $flow (keys %flows) {

my ($src,$dst) = split(/:/,$flow);
my $weight = $ips{$src} * 0.005;
my $weight2 = $ips{$dst} * 0.005;

$g->add_node($src, height => $weight, width => $weight, style => 'filled', shape => 'rectangle');
$g->add_edge($src,$dst);
}

$g->as_png("graph.png");

Pregunta nº 1: Buscando applets

1. As part of the infection process, Ms. Moneymany’s browser downloaded two Java applets. What were the names of the two .jar files that implemented these applets?

Cómo se decía en el enunciado, Ms. Moneymany ha visitado una web maliciosa. Al parecer y según la pregunta, lo que contiene esa web son dos applets (.jar) de java. Para encontrarlos dentro del tráfico, se recurre a la utilidad de consola tshark. tshark permite mostrar información relevante sobre una captura o capturar en vivo. Es el complemento ideal a wireshark cuando se quiere profundizar en el contenido de un volcado:

Figura 3. Buscando los applets

Como se ha visto en el análisis previo, la máquina de nuestra víctima tiene la ip 192.168.23.129 y el servidor del ataque la ip 59.53.91.102. En este caso, ese era el único tráfico web que hay, pero nunca está de más asegurarse y tomar buenos hábitos.

Pregunta nº 2: Conocer el usuario de la víctima

2. What was Ms. Moneymany’s username on the infected Windows system?

Se conoce desde dónde sale el tráfico y se filtran los paquetes para ver si pueden dar una idea del usuario:

forensics@blueliv:~$ tshark -R "ip.src == 192.168.23.129" -r infected.pcap

Figura 4. Buscando los applets

Ahí tenemos una posible conversación que podría contener el nombre de usuario (/11111/gate.php?guid=ADMINISTRATOR!TICKLABS-LZ!1C7AE7C1&ver=10084&stat=ONLINE&ie=8.0.6001.18702&os=5.1.2600&ut=Admin&cpu=92&ccrc=5A4F4DF7&md5=5942ba36cf732097479c51986eee91ed). También cabe destacar que el campo md5 tiene la misma terminación que el md5 del malware (que se nos preguntará más adelante). Esta vez hay suerte de que la petición fuera tan clara, pero se podría usar un método alternativo para encontrar nombres de usuarios. Por ejemplo, usando ngrep:

forensics@blueliv:~$ ngrep -I infected.pcap -i user 'ip src 192.168.23.129'

Figura 5. ngrep nos permite buscar por expresiones regulares

Aunque aquí se tiene suerte de nuevo y muestra el paquete porque contenía User-Agent.

Pregunta nº 3: La url

3. What was the starting URL of this incident? In other words, on which URL did Ms. Moneymany probably click?

Listando todas las conexiones de la víctima, se muestra la primera referencia:

Figura 6. Lista de paquetes con peticiones desde el cliente

Para mayor comodidad, vemos el paquete dentro de wireshark:

Figura 7. Wireshark muestra la respuesta en su formato original

Por desgracia, Wireshark no puede descodificar la conversación por lo que se recurre a usar tshark (de nuevo) para que muestre la respuesta sin comprimir:

forensics@blueliv:~$ tshark -r infected.pcap -R 'frame.number==13' -Tfields -Ttext | tr -s ' ' | grep -v ' \\n'

Figura 8. Contenido incompleto pero válido para hacerse una idea

Tshark ha truncado el contenido, pero vale para determinar que este parece ser el origen, un javascript ofuscado desde la ip sospechosa.

Pregunta nº 4: Extrayendo el malware

4. As part of the infection, a malicious Windows executable file was downloaded onto Ms. Moneymany’s system. What was the file’s MD5 hash? (Hint: It ends on “91ed”.)

En esta ocasión se usa NetworkMiner para poder capturar los ficheros que hayan pasado por la red:

Figura 9. NetworkMiner detecta el ejecutable y lo extrae

Después de obtener el fichero file.exe, comprobamos su MD5. Como pista, el enunciado de la pregunta se decía que tenía que acabar en "91ed" y el fichero tiene el MD5 5942ba36cf732097479c51986eee91ed.

Figura 10. MD5 del fichero extraído

Pregunta nº 5: Malware empaquetado

5. What is the name of the packer used to protect the malicious Windows executable? Hint: This is one of the most popular freely-available packers seen in “mainstream” malware.

Usando una herramienta como PeID o Rdg Packer Detector, podemos determinar el packer que usa nuestra muestra de malware. Esta vez, nos vuelven a dar una pista, indicándonos que se trata de uno de los packers más comunes en este tipo de software. En este caso, se trata del packer UPX:

Figura 11. Rdg identifica el packer utilizado

Pregunta nº 6: Desempaquetando el malware

6. What is the MD5 hash of the unpacked version of the malicious Windows executable file?

Habitualmente, suele ser normal que los escritores de malware, hagan pequeñas modificaciones en el packer de tal forma que no pueda ser desempaquetado por el programa original. Pero esta vez, la propia utilidad upx permite extraer el fichero original:

Figura 12. Extrayendo el fichero original

Figura 13. MD5 final del fichero

En esta parte, se podría comprobar que el ejecutable cargara sin problemas en alguna máquina virtual de nuestro laboratorio forense, siempre tomando las precauciones necesarias ante este tipo de software malicioso.

Pregunta nº 7: Conexión hacia alguna parte

7. The malicious executable attempts to connect to an Internet host using an IP address which is hard-coded into it (there was no DNS lookup). What is the IP address of that Internet host?

La pregunta final pide que se averigüe a dónde conecta nuestro malware. Como pista, se dice que la ip esta dentro del código del programa, por lo que suponemos que tiene que ser una ip de la que no se haya hecho ninguna resolución. En los comentarios del concurso, uno de los organizadores comenta que la mejor forma de solventar esta prueba no es mediante el reversing. La pieza de malware, una vez quitado el packer, sigue estando ofuscada, la tabla de importaciones no presenta ninguna función que pueda ser usada para comunicarse hacia fuera. Así que suponemos que debe construirse su propia tabla de importaciones con alguno de los métodos comunes. En cualquier caso, siguiendo las indicaciones de la organizacioń, vamos a seguir extrayendo conclusiones de la captura. Del análisis previo se tiene un listado de ips únicas. Suponemos que el malware tiene que conectarse a alguna dirección en Internet para comunicarse, así que se eliminan las ips del rango privado:

Figura 14. Listado de ips, en rojo ips privadas.

Después se buscan las ips que se hayan obtenido mediante resolución DNS:

Figura 15. Ips resultas vía consulta DNS

Figura 16. Nuestra tabla de ips, con dos menos

Al final, después de eliminar ips internas e ips resultas, nos quedan dos ips:

Figura 17. Posibles ips a las que se conecta el malware

Para poder determinar cuál de estas dos ips pertenece al malware, tendremos que investigar el contenido de los paquete. Antes, se localizan las ips geográficamente (al menos lo más posible) por si pudieran dar alguna pista:

Figura 18. Geolocalización de las ips usando MaxMind

Una ip localizada en Namibia (213.155.29.144) y otra en EE.UU. (65.55.195.250). También la pista de que esta última ip, pertenece a Microsoft, aunque no se da por hecho. A priori, la ip sospechosa parece ser 213.155.29.144:

Figura 19. Lista de paquetes entre nuestra víctima y 213.155.29.144

Según tshark, el puerto de destino pertenece al protocolo SNPP. Según las especificaciones de este protocolo, la comunicación no tiene ningún tipo de cifrado y se basa en comandos simples de texto (PAGE, MESS, SEND,...). Sin embargo, viendo el contenido de cualquiera de los paquetes, se aprecia que no parece seguir ese esquema:

Figura 20. El paquete no contiene ningún dato textualmente leíble

Casi seguro que nuestro malware se comunicaba con la ip 213.155.29.144. Pero falta la puntilla para terminar de rematarlo. Podríamos ejecutar el malware y monitorizarlo con alguna herramienta como maltrap o sysanalizer, enviar la muestra a alguna sandbox online que nos la analice (como anubis) o buscar por internet cualquier de los hashes que obtuvimos en nuestros análisis previos. Buscando el hash original, se obtiene un análisis de The Threat Expert dónde nos responden a nuestra pregunta:

Figura 21. Análisis de la muestra de ThreatExpert

Como veis, parece que en sus pruebas, el malware se conectó a nuestra ip sospechosa por lo que se descarta cualquier duda de que esa es la ip que buscamos y de que esa es la respuesta a la pregunta final.

Conclusiones

El área de forensics abarca un basto campo de acción, donde cualquier evidencia tiene que ser exprimida al máximo para determinar lo más exáctamente posible la cadena de hechos. Este reto supone un ejemplo cristalino de la importancia de cualquier evidencia para llevar a cabo una investigación. Hemos partido de un escenario donde nuestro "cliente" tenía una sospecha y hemos basado la investigación en una sola evidencia. De ahí hemos ido obteniendo una fotografía más exacta de cada uno de los actores implicados, un dibujo de la red interna, información geográfica de los sospechosos, archivos implicados en el ataque, el punto de partida y la propia muestra de malware. Siempre sin perder el enfoque neutro del análisis, llegando un poco más allá del simple hecho e investigando todo aquello que tomamos por cierto para sustentarlo con pruebas.

Reconstrucción de sucesos mediante múltiples fuentes de evidencias digitales

Como en cualquier investigación, las digitales también requieren de en una reconstrucción de los hechos, donde un investigador dispone de una piezas de puzzle que deberá encajar para poder determinar qué ha pasado. Es por ello que, en numerosos casos, nos podemos encontrar investigaciones digitales en las que tan solo la recogida de una sola evidencia no es suficiente, siendo necesaria la recogida de evidencias adicionales desde otras fuentes.

Supongamos que en una Organización ocurre un incidente de seguridad, pudiendo ser tipificado en un caso de intrusión o bien un uso fraudulento de los activos informáticos. Obviamente, para iniciar cualquier investigación, primero deberemos detectar el incidente, por lo que se requieren mecanismos de Detección de Incidentes de seguridad. Dichos mecanismos serán esenciales no solo para detectar incidentes, sino que también serán una pieza fundamental para la reconstrucción de nuestro puzzle.

¿Qué mecanismos nos serán útiles para detectar incidentes? Disponemos de varias formas complementarias que nos ayudarán a detectar incidentes, como son:

• Network Intrusion Detection Systems (NIDS): Los sistemas de detección de intrusiones a nivel de red inspeccionan el tráfico que fluye a través de ellos, en busca de anomalías o indicadores de actividad maliciosa.
• Host Intrusion Detection Systems (HIDS): Los Host IDS operan supervisando el comportamiento del sistema o dispositivo en el cual se encuentran instalados. De los Host IDS, podemos extraer información, y concretamente tiempos para la generación de un timeline, de logs de sistema y firewall, integridad de ficheros, procesos en ejecución, actividad de red y chequeo de rootkits.
• Honeynets / Honeypots: Se definen como aquellos recursos cuyo valor reside en ser atacados o accedidos. Los honeypots de baja interacción, como honeyd, son excelentes sistemas de detección de intrusos ya que no son sistemas que se encuentran en producción.

Como se puede observar, en una investigación puede ser de vital importancia disponer de tal minería de datos, pudiendo llegar a correlar los eventos recolectados de las diferentes fuentes anteriormente comentadas.

Por ejemplo, supongamos un hipotético caso en que nuestro IDS de red detecta un típico patrón de escaneo de puertos mediante la herramienta nmap; el IDS de sistema detecta un aumento en el perfil de actividad de red del sistema afectado, junto con el aumento de la carga de CPU. Instantes después se efectúan nuevos registros en nuestros logs de sistema, y por otro lado detectamos que el chequeo de integridad de los ficheros no coincide con el habitual. ¿ Qué pasa si además todo esto lo podemos correlar con un análisis temporal (timeline) postmortem del sistema de ficheros ?

En una investigación no solo serán importantes los datos e información digital, supongamos un caso de fraude interno en una Organización, en la que se investigan las acciones realizadas por un empleado, ¿por qué no correlar la información extraída de los dispositiovos de detección, el ordenador personal, registros y alertas de sistemas DLPs (Data Protection Loss), o incluso de la agenda diaria de la persona que se está investigando? Destacar que si la Organización dispone de mecanismos DLP, permitirá de una manera mucho más rápida identificar posibles fugas de información y desde dónde se están produciendo, señalando a los potenciales infractores y facilitando o acotando las tareas de análisis forense posteriores.

De ésta manera, damos mucha más información al investigador, pudiendo obtener datos previos a que suceda el incidente, siendo de ésta manera una investigación mucho más concluyente y objetiva.

Saludos,