Ya hemos hablado en el blog sobre la herramienta on-the-fly. Hoy queríamos mostrar algunos casos de uso dónde on-the-fly ofrece posibilidades y entender bien el trabajo de los ‘jobs’ de la herramienta y cómo se pueden ir ‘apilando’ las funciones pequeñas y conseguir una función grande. Por ejemplo, si queremos hacer un DNS Spoofing con un ARP Spoofing y a la vez ir capturando el tráfico que pasa por nosotros pues podemos ir configurando tres módulos (serán tres jobs) que van trabajando de forma conjunta. 

La herramienta será presentada por Luis Eduardo Álvarez en BlackHat Europe y esperamos que guste a la gente y vean el potencial que creemos que tiene esta forma de hacer las cosas. No hay que olvidar que el foco de la herramienta es ataques de red para el Ethical Hacking en el mundo TI, IoT e ICS.

Figura 2: Libro de Ethical Hacking 2ª Edición

En el artículo de hoy veremos algunas cosas que se pueden ir haciendo con on-the-fly. Además, invitamos a cualquier a realizar un módulo para la herramienta, aunque dejamos para más adelante el poder hacer un plugin para la herramienta, lo cual no es complejo como se verá.

¿Qué haremos? Lo primero es colocarnos en medio de la comunicación con el módulo arp_spoof muy común en los ataques en redes de datos IPv4 & IPv6. Hay que recordar que este módulo es ‘apilable’ a otros, es decir, este funciona como base para que otros puedan construir por encima.

Para este artículo, comenzaremos usando el módulo spoof/arp_spoof de la herramienta. Tendremos una máquina ‘target’, la cual es una máquina Windows y un ‘gateway’ que en este caso es una máquina macOS. Nos colocamos en medio de la comunicación entre ambas máquinas a través de la técnica ARP Spoofing.


Ahora toca realizar tareas de sniffing que son necesarias en muchos ámbitos y vamos a utilizar en ataques de evaluación en el mundo IT, IoT o ICS. 

La herramienta on-the-fly dispone, actualmente, de cuatro módulos de sniffing. Uno orientado a sniffing en general, donde el usuario puede configurar los filtros que quiere aplicar (filtros BPF), donde almacenar la captura, si generar un PCAP o no, qué información mostrar por pantalla, etcétera. Además, la herramienta tiene módulos de sniffing ‘dedicado’, es decir, módulos que ya vienen filtrados para detectar y guardar cierto tipo de tráfico. 

Configuramos el módulo para probar, tocando algunos parámetros. Aplicamos un filtro y todo lo que almacenaremos en el fichero PCAP estará filtrado a tráfico ICMP. Por otro lado, si queremos ver las conexiones y comunicaciones tenemos la opción de verlo con el parámetro verbose.


El fichero PCAP que obtenemos tiene todo el tráfico ICMP que haya pasado por nosotros. Solo tenemos que abrir el fichero PCAP, por ejemplo, con Wireshark y verlo tranquilamente.


Aplicar un filtro siempre es algo bueno, ya que evita que nuestra captura se llene de tráfico y protocolos que no nos interesen para el pentesting.

Pivoting con SOCKS4

Una de las intenciones de on-the-fly es ser como una navaja suiza en temas de red. Aún le queda mucho recorrido y por eso la herramienta es un proyecto colaborativo donde todos pueden aportar con sus módulos. Dentro de los módulos de pivot, podemos encontrar un par: proxy_socks4 y tcp_forwarding.

El primero lo veremos en detalle, mientras que el segundo es una forma de hacer forward de tráfico a través de un puerto TCP (un clásico). En el caso de proxy_socks4 podemos decir que el módulo presenta pocos atributos y que su configuración es sencilla. La idea es convertir la máquina donde se ejecuta on-the-fly en una máquina con un proxy SOCKS4. Se puede estudiar la implementación de un SOCKS5, ya que no es complejo teniendo la versión 4. Vamos a ver los atributos del módulo:

Bien, una vez ejecutado el módulo, si observamos los puertos a la escucha en nuestra máquina (donde se ejecuta on-the-fly) veremos el puerto 1080 activo por cualquier interfaz de red. El protocolo SOCKS4 es sencillo, es una manera de poder enviar tráfico a cualquier puerto a través de un ‘pivote’ que será nuestro proxy.


Ahora, desde otra máquina pasaremos el tráfico por el proxy SOCKS4. Como se puede ver en la imagen, haciendo uso de proxychains (hay que tener en cuenta el fichero de configuración de proxychains para que apunte a la máquina dónde está on-the-fly).

Como se puede ver en la imagen, el tráfico se inicia en la máquina Ubuntu, pasa por la Kali Linux y llega a la Windows. La máquina Windows recibe la petición desde la máquina Kali, por lo que registra la conexión desde ella, pero realmente la conexión viene de la máquina Ubuntu.


Bien, con este ejemplo finalizamos el artículo de hoy. Hay que indicar que si ejecutamos el comando ‘jobs’ veremos los trabajos en background que tenemos activos en este caso. Sin duda, la posibilidad de ir apilando funciones de manera sencilla proporciona flexibilidad y potencia a la herramienta. 

Para eliminar o parar un módulo, simplemente hay que ejecutar: job -k [ID Job]. Mientras que si se quieren detener todos los módulos: Jobs -K. Por último, os dejamos un video de uso de la herramienta con el ejemplo de proxySOCKS4.

Figura 13: PoC ProxySOCKS