Hola a tod@s!
Este es el primer solucionario que vamos a publicar sobre el reto número 4 de SANS, enmarcado bajo el título Network Forensics Puzzle Contest.
Antes de continuar con el solucionario, tanto Pedro como yo, queremos dar la enhorabuena a todos los participantes del mismo. Allá vamos!
Lo primero que haremos antes de analizar cualquier evidencia, será comprobar la autenticidad de la misma. Para ello, el reto nos adjunta como argumento una firma MD5 que corresponde con el fichero original de captura. Para verificar la evidencia, utilizaremos la herramienta md5sum, con el siguiente argumento:
md5sum evidence04.pcap
Esto nos devuelve como resultado lo siguiente:
804648497410b18d9a7cb1d4b2252ef7 *evidence04.pcap
El siguiente paso a seguir será examinar el archivo de captura con un analizador de protocolos. Para este reto usaremos una herramienta ampliamente conocida. Esta herramienta es Wireshark. Utilizaremos esta herramienta por su versatilidad y eficiencia, así como por su potencia bajo línea de comandos.
Al abrir el archivo de captura lo primero que vemos es lo siguiente:
Imagen 1.- Evidencia en Wireshark
Según el supuesto, nos relata que el SR X, al infiltrarse en la subnet propiedad de ANFRF, realiza un reconocimiento de la Red. Para ello, supuestamente realiza un escaneo de la Red, cometiendo un grave error al no ocultar sus pasos. Así que lo primero que haremos será extraer las direcciones IP, tanto de origen como destino, implicadas en el caso.
Wireshark permite realizar esta tarea bajo línea de comandos utilizando para ello su herramienta Tshark. Para ello, utilizaremos el siguiente comando:
Tshark -r evidence04.pcap -T fields -E separator=, -e ip.src -e ip.dst > \Users\Silverhack\IP.txt
De esta lista se extraen el conjunto de direcciones implicadas en el caso forense, las cuales son las siguientes:
Imagen 2.- Direcciones IP implicadas
Una vez extraída esta información, necesitamos conocer los equipos que han tenido contacto entre ellos. El problema que se presenta es la gran cantidad de paquetes transmitidos y enviados y al número de direcciones IP implicadas. Para solucionar este problema, elaboraremos una estadística de conversaciones por dirección IP, y mostraremos el resultado de forma gráfica y por pantalla. Gracias a ello, nos permitirá comprobar, a través de dos formatos, el contacto de estos equipos entre sí.
Para construir una fotografía de las conexiones, necesitaremos hacer uso de librerías gráficas y scripts que permitan la creación de ficheros que relacionen estos datos. Para ello, utilizaremos la colección de scripts llamados AfterGlow. Esta colección de scripts facilitará la tarea a la hora de generar la gráfica.
Una vez descargado el conjunto de Scripts, y haciendo uso del comando anterior (Tshark), podemos tunelizar los datos de salida hacia el script, generando un nuevo fichero de gráficos.
Tshark -r evidence04.pcap -T fields -E separator=, -e ip.src -e ip.dst | Perl afterglow.pl > IPGraph.dot
Una vez generado el nuevo fichero, podemos utilizar cualquier aplicación válida para representar este fichero en un archivo gráfico. En el caso que nos ocupa, hemos utilizado la aplicación neato, incluida en la suite Graphviz.
Neato -Tgif -o IPGraph.gif ./IPGraph.dot
El resultado de aplicar los comandos anteriores es la siguiente imagen:
Imagen 3.- Mapa de direcciones IP
Según este gráfico, podemos extraer que el único equipo que ha tenido comunicación con el resto de participantes de la red ha sido la dirección IP 10.42.42.253. Gracias a este gráfico, podemos determinar con exactitud la dirección IP que ha realizado el descubrimiento de equipos.
Otra forma de llegar a esta conclusión es elaborar estadísticas por pantalla. Tshark permite la inclusión de este tipo de características en sus consultas. Un comando válido para ello sería el siguiente:
Tshark -r evidence04.pcap -q -z conv,ip,ip.src==10.42.42.25
Este comando, elaborará una estadística de conversaciones aplicando un filtro por dirección IP. En este caso, sólo muestra las conversaciones de la dirección IP 10.42.42.25
Imagen 4.- Estadísticas Tshark
Tan sólo necesitaríamos elaborar una estadística por cada dirección IP, y comprobar resultados.
El próximo punto a cubrir, será averiguar el tipo de fabricante que se esconde detrás de cada dirección MAC. Gracias al identificador único que poseen estas direcciones, unido al control que se tienen sobre ellas, y mediante listas actualizadas, se puede averiguar con cierta facilidad el fabricante de las mismas. El propio Wireshark, contiene una lista actualizada de estos fabricantes, aunque esta lista también puede ser consultada en la Web de IEEE. http://standards.ieee.org/regauth/oui/oui.txt
Una vez consultadas estas listas, el resultado es el siguiente:
Imagen 5.- Relación IP & MAC
El siguiente punto a cubrir será relacionar cada dirección IP con un sistema operativo.
Llegados a este punto, y gracias a la cantidad de paquetes que se encuentran en la evidencia, podemos realizar un fingerprinting del sistema operativo. Este fingerprint se puede llevar a cabo gracias a que principalmente, cada sistema operativo implementa la pila tcp/ip de forma diferente. El tamaño de la ventana, así como la cantidad de nops incluidos en el paquete, son pistas para averiguar el tipo de implementación de la pila, y, por consiguiente, el tipo de sistema operativo. Existen numerosas herramientas capaces de realizar un fingerprint pasivo en base a un archivo de captura. Una de ellas es NetworkMiner, que, entre otras cosas, posee las firmas de P0f y satori para realizar un fingerprint de sistemas operativos.
Imagen 6.- Network Miner
Una vez analizado la evidencia con esta herramienta, ésta es capaz de devolver el siguiente resultado:
Imagen 7.- Relación IP & MAC & OS
Antes de intentar averiguar el tipo de escaneo que se ha realizado, nos detendremos en averiguar si el escaneo descubrió algún tipo de puerto abierto en alguna de las máquinas. Para realizar esta tarea, se pueden emplear varios métodos. En una comunicación orientada a conexión entre dos equipos, como es el caso de la comunicación vía TCP, la comunicación se establece bajo una negociación en tres pasos. El cliente enviará un paquete con el flag SYN activo a un servidor. Si el puerto estuviese abierto, el servidor respondería con un paquete y los flags SYN y ACK activos. Si el puerto estuviese cerrado, el servidor enviaría un paquete con el flag RST activo. Un método lógico de búsqueda de puertos abiertos, es averiguar qué equipos respondieron a una llamada con un paquete y los flags SYN y ACK activos. Gracias a que estos flags tienen un valor asignado, se pueden rastrear con Wireshark de una forma sencilla. Los valores que tienen estos flags son los siguientes:
Imagen 8.- Tabla de asignación Flags
En Wireshark y Tshark, en su versión línea de comandos, es muy fácil filtrar esta información. Un comando válido en Tshark para esta tarea sería el siguiente:
Tshark -r evidence04.pcap tcp.flags==18 -T fields -E separator=, -e ip.src -e tcp.srcport
Este comando nos devuelve que el equipo que tiene puertos abiertos es el mostrado en la siguiente tabla:
Imagen 9.- Relación puertos abiertos
Llega el punto, una vez analizados todos los datos anteriores, de intentar averiguar qué tipo de escaneo utilizó el atacante para realizar el descubrimiento de puertos. Como ya sabemos la dirección IP que propició el escaneo (10.42.42.253), podemos aplicar un filtro en Wireshark que muestre sólo lo referente a esta dirección IP.
Imagen 10.- Filtro dirección IP en Wireshark
Analizando el archivo de captura de forma visual, notamos que bajo esta dirección IP, hay numerosas conexiones con el flag SYN activo. Además se observa que se intentan conexiones a diferentes puertos con este mismo procedimiento. Este procedimiento es común en escaneos de tipo TCP SYN o de TCP Connect. A continuación mostramos un cuadro comparativo de tipos de escaneo con respecto a flags activos.
Imagen 11.- Relación Flags con tipos de scan
Para confirmar el tipo de escaneo y la herramienta utilizada, podemos utilizar algún sistema de detección de intrusos y visualizar el log posterior. Para este reto, utilizaremos snort, debido a que tiene muchas firmas relativas a escaneo de puertos. Para ello, el comando utilizado es el siguiente:
snort.exe -A full -v -r c:\evidence04.pcap -c c:\Snort\etc\snort.conf
Analizando el log de salida, podemos visualizar numerosas entradas con la siguiente información:
[**] [1:2009582:1] ET SCAN NMAP -sS window 1024 [**]
[Classification: Attempted Information Leak] [Priority: 2]
02/03-00:43:10.186883 10.42.42.253:36020 -> 10.42.42.25:3389
TCP TTL:44 TOS:0x0 ID:19276 IpLen:20 DgmLen:44
******S* Seq: 0x113F23CF Ack: 0x0 Win: 0x400 TcpLen: 24
TCP Options (1) => MSS: 1460
Según Snort, parece claro que la herramienta NMAP es la causante del escaneo, así como que el tipo de escaneo es SYN Scan (-sS).
Aunque este tipo de escaneo pueda ser interpretado como TCP SYN Scan, nos decantamos por TCP Connect Scan, debido principalmente a varias características que a continuación exponemos:
La primera es que examinando el TimeLine de los paquetes, nos encontramos con que la primera respuesta recibida es un paquete con los flags RST+ACK. Esto demuestra que se ha establecido con éxito un intercambio a 3 vías o Three Way HandShake. Un escaneo del tipo TCP SYN SCAN no llega nunca a completar la conexión, de ahí a que sus creadores marquen este escaneo como STEALTH (Oculto).
Otro punto a destacar, típico de este tipo de escaneos, es la cantidad de paquetes necesarios para el descubrimiento de un puerto, llegando a intentar conectar desde varios puertos origen.
Imagen 12.- Connect Scan
En la captura de datos, la fragmentación de paquetes no es visible, por lo que este tipo de opción, también incorporada en NMAP, parece ser que no fue establecida en el escaneo.
Otro punto interesante, es el referente al tiempo de escaneo. En esta captura, se han intentado varias conexiones a un mismo puerto de destino, pero desde diferentes puertos origen. Analizando la captura, hemos encontrado, al menos, dos intentos de conexiones a un mismo puerto de destino, desde diferentes puertos origen. Este comportamiento es común en varios casos. Cuando se intenta realizar un fingerprint del sistema operativo, y cuando se ajusta las condiciones de Timing en NMAP, al parámetro INSANE. Este parámetro, indica a NMAP que intente una conexión tan rápido como sea posible.
Esperamos que os guste este primer solucionario!
Saludetes!
El diario de Juanito 