Forensic Analysis of a Network Scan

¡Hola! Volvemos a la carga con una vieja asignatura que teníamos aparcada desde hace tiempo: Análisis Forense. En el día de hoy hemos cogido un sencillo reto “for beginners” de los muchos existentes en los “scan of the month” del honeynet Project. En el mismo nos proporcionan un fichero binario con un tcpdump de varios megas que incluye una serie de tráfico TCP/IP que deberemos analizar para averiguar que ocurrió, el reto incluye la respuesta a varias preguntas de creciente dificultad. En este “mini-reto” utilizaremos herramientas tan comunes como Wireshark (también vale Ethereal o el sniffer que a vosotros os guste) y nmap. Vamos para allá:

1.- What is a binary log file and how is one created?

Una teórica para empezar, un fichero binario no es más que un archivo generado por el NIDS (Network Intrussion Detection System) Snort que, apoyándose en las habituales librerías Libpcap / Winpcap es capaz de depositar el tráfico exactamente igual que circula por la red en un fichero. La presencia de copias exactas de los paquetes nos garantiza que nada es modificado, ¡el requisito más importante en cualquier investigación! Esto nos lleva a la siguiente cuestión.

2.- What is MD5 and what value does it provide?

Bueno, creo que esto lo sabéis todos ya, lo vimos en esta entrada. El MD5 no es más que un algoritmo de un solo camino que calcula un valor hash, ese valor es único para cada entrada, o eso se supone. Existe un verdadero debate (el cual me está dando una idea para una futura entrada) acerca de la validez de un hash como mecanismo que garantiza que una evidencia no ha sido comprometida, debate acrecentado a medida que se descubren colisiones en los principales algoritmos: MD5 y SHA1. Cuando nos descargamos los archivos del reto nos piden que confirmemos el hash, en este caso lo hemos hecho:

3.- What is the attacker’s IP address?

Se acabó la literature, tenemos que averiguar la dirección IP del atacante, para ello (y dado que no es un fichero grande) examinaremos todas las IP origen y destino con Wireshark. Rápidamente podemos observar que aparecen las siguientes IP source:

192.168.0.9, 192.168.09.9, 192.168.0.254, 192.168.0.199, 192.168.0.1

Y las siguientes IP de destino (IP.dst):

192.168.0.9, 192.168.0.99

En la siguiente captura hacemos filtrado para asegurarnos que no hay otras IP.dst:

De forma curiosa, la regla no filtra aquellos destinos inalcanzables (¡pero eso es una pista!), ahora bien, ¿Cómo sabemos la IP del atacante a partir de esta información? Deberemos examinar los paquetes, no obstante algo huele a chamusquina cuando el 99% del tráfico procede de 192.168.0.9 y tiene de destino 192.168.0.99. No obstante nos aseguramos comprobando el tráfico que sale de 192.168.0.99 y eliminando el que tiene de destino 192.168.0.9 (genera demasiado ruido), obteniendo que no hay tráfico de estas características. Lo cual quiere decir que no hay respuesta de 192.168.0.99 hacia otros destinos distintos de 192.168.0.9, en este caso la ausencia de evidencia es la evidencia de que el atacante (¿supuesto atacante?) proviene de 192.168.0.9, probablemente por que el resto de destinos no existían (¿IP spoofing?).

4.- What is the destination IP address?

Como hemos hecho nuestro trabajo bien en la anterior cuestión, sabemos que la IP que estaba respondiendo a todas las peticiones era la 192.168.0.9. Parece que vamos bien ;-)

5.- We scanned de honeypot using five different methods. Can you identify the five different scanning methods, and describe how each of five works?

Comienza a subir la dificultad del análisis, nos piden averiguar las distintas tácticas de escaneo utilizadas. Vayamos por partes, nada más comenzar la captura se observa un ping hacia 192.168.0.99, justo después (Time 10.346091) comienzan a hacerse peticiones de tipo SYN desde el puerto origen 52198 hacia puertos fuera del rango reservado, el host escaneado responde con trazas [RST, ACK], lo que significa que se ha llegado al puerto pero no hay nadie escuchando, este podría ser nuestro primer tipo de escaneo:

Correspondiente a un nmap –sS (TCP SYN Scan) 192.168.0.99, el cliente debería responder con un ACK pero no lo hace, se queda a medio camino (half-open scanning).

En el Time 148007 se vuelve a producir un ping hacia 192.168.0.99, en ese momento se arranca otro tipo de escaneo, el wireshark nos cambia los colores, lo que ayuda ya que es muy llamativo:

Parece que se están tratando de hacer fingerprinting del sistema operativo, es decir, detectar que tipo de máquina hay detrás, en este caso el escaneo se concentra en los puertos habituales de servicios Windows. Por ahora parece que no tiene suerte nuestro atacante :) sin embargo poco tiempo después, línea de tiempo 150563 comienzan a aparecer paquetes ACK duplicados (el Wireshark los pinta de un negro terrorífico), que tienen su cumbre en el 150626, donde se comienza a recibir [SYN-ACK] en servicios habituales de Windows, lo que parece un nmap –sX (Xmas scan) bastante exitoso:

Ahora bien, justo después (se puede apreciar en la imagen anterior) el atacante trata de establecer conexiones al puerto SSH, pero con todos los flags TCP sin determinar, esto significa que estamos delante de un “Null Scan”, también llamado nmap –sN, si pinchamos en cualquier paquete veremos esta información dentro de los flags del protocolo de control de transmisiones:

Terminamos con un último ataque, se llama decoy scanning y sirve para que el host remoto no sepa identificar (a priori) quien es el host destino, decoy significa señuelo en inglés y lo que hace es realizar la misma petición desde varias IP inexistentes como las que vimos en 3), está muy bien para pasar desapercibidos aunque obviamente no tiene sentido en un entorno como el que estamos viendo:

Puede reproducirse con nmap y la opción –D. Y con esto hemos repasado los escaneos que se han realizado, como vemos es importante conocer los tipos de escáneres que permiten las herramientas, para ello podemos acudir por ejemplo a las técnicas que explican en la página del escáner más famoso.

6) Which scanning tool was used to scan our honeypot? How were you able to determine this?

Bien, en el punto anterior vimos que opciones de nmap había que habilitar para cada ataque, pero eso no significa ni mucho menos que haya sido esta herramienta, ¿verdad? Necesitaremos utilizar un NIDS para analiza las trazas y verificar si detecta algún ataque y por parte de qué, para ello no hay nada como Snort, que nos devolverá algo parecido a esto:

[**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] - 22539

[**] [111:9:1] spp_stream4: STEALTH ACTIVITY (NULL scan) detection [**] - 3996

[**] [111:12:1] spp_stream4: NMAP FINGERPRINT (stateful) detection [**] - 9

[**] [1:628:1] SCAN nmap TCP [**] - 9

Luego ahí tenemos a nuestro principal sospechoso.

7) What is the purpose of port scanning?

Bueno, la razón de realizar un escáner de puertos es bastante sencilla. Identificar todos los servicios y puertos abiertos que el host “víctima” está ofreciendo. O dicho de otro modo, identificar los posibles puntos de entrada a su sistema. Es una definición algo tosca pero nos vale :)

8) What ports are open on our honeypot?

Tal y como vimos en 5) los mecanismos para establecer una conexión TCP/IP incluyen el famoso saludo “a 3 bandas” o 3-way handshake, de tal forma que cuando hay un puerto abierto y dependiendo del ataque lo podemos identificar de varias formas. A grandes rasgos para no extender la entrada en demasiado he recolectado todos los paquetes emitidos por 192.168.0.99 con [SYN,ACK], es decir donde hay servicios, con ello he identificado los puertos:

- 22 / SSH

- 53 / DNS

- 80 / HTTP

- 443 /HTTPS

- 111 / SUNRPC

- 32768 / FILENET

9) Bonus Question: What operating system was the attacker using?

Esta cuestión puede parecer a priori la más difícil de responder, obtener el sistema operativo origen a partir de unas trazas TCP/IP podría ser un problema si no fuese por herramientas como p0f, Ettercap o Network Miner, las mismas utilizan técnicas de fingerprinting pasivo a raíz de los valores TTL, el tamaño de la ventana, type of service, (TOS) etc. Se puede profundizar en estas técnicas aquí. Yo he escogido Network Miner, la cual nos podría haber facilitado el trabajo desde el principio (pero entonces no habría sido tan divertido ;-) ) ya que es una herramienta de análisis forense en red. Ella nos muestra que tanto host atacante como host atacado eran Linux:

Y esto es todo por hoy, el análisis forense es magnífico para repasar y profundizar en los habituales conocimientos de redes, sistemas operativos, etc.

Buen fin de semana :)

NdA: Estoy teniendo bastantes problemas para escalar las imágenes sin perder detalle, así que se ven bastante pequeñas, siento el inconveniente.