Proxy SOCKS como VPN para Windows

Para ejecutar herramientas ofensivas basadas en Windows en otras redes, entre otras locuras.

Introducción

Me pasa muy seguido que en actividades de Red Team, pentesting o actividades de análisis en general, termino con algún SOCKS proxy en mis manos. Esto puede ser por Chisel, SSH o algún implante de algun C2 framework conocido. No siempre puedo comprometer credenciales de VPN con tanto 2FA y protección que le ponen, así que hay que saber moverse sin un acceso así.

Es bastante común la utilización de herramientas basadas en Windows para la fase de reconocimiento e incluso para la explotación de vulnerabilidades. Es cosa de ver la cantidad inmensa de herramientas en C# que utilizan el contexto de sesión de usuario (que se puede abusar con runas /netonly, Pass-the-Ticket o Pass-the-Hash). Algunos ejemplos serían: Rubeus, SharpUp, SharpSCCM, entre muchos más. Es sabido que existen alternativas de estas herramientas basadas en el framework Impacket (en Python), en donde sólo requerirías de un SOCKS proxy, además de otra información como IP y NETBIOS de algunos servidores o controladores de dominio, pero hay que saber trabajar en cualquier escenario.

Hay que hacer una mención igual a herramientas como “Proxifier”. Las que te permiten enrutar el tráfico de red de un programa a través de un proxy SOCKS o HTTP mediante la redirección a través de la API de red de Windows. Personalmente he tenido problemas al usar Proxifier con algunas herramientas ofensivas, por lo que el óptimo es atajar este problema de raiz; es decir, en la capa de red.

tun2socks

Vagando por Internet me pillé con Outline VPN 1, algo que usa bastante es la herramienta shadowsocks 2, que básicamente es un SOCKS proxy pero con muchas técnicas de ofuscación para evitar censura. Pero ahora me surge otra duda, ¿Cómo convierten ese SOCKS en una VPN? Según su código, usan una librería de Golang llamada tun2socks 3.

De pura coincidencia, estuve navegando por el Internet por otro rato más y encontré otro programa con el mismo nombre. Este tun2socks 4 es un binario hecho en Golang que permite crear un dispositivo de red TUN que enruta el tráfico que le envies, redireccionandolo hacia un proxy SOCKS. Esto permite crear una interfaz de red nueva, en donde si le asignas una IP, puedes generar rutas en tu computador para acceder de forma nativa a las IPs que coloques en las rutas. En el escenario que imaginamos en este post, aquí irían el rango de direcciones IP de la víctima.

Hice un par de pruebas con la herramienta y me permitió acceder a direcciones IP privadas que pertenecían a la red interna del proxy SOCKS al que tenía acceso. Por lo que era efectivo.

No conozco las diferencias entre los 2 “tun2socks”, tampoco hice una revisión para compararlos, pero éste último es el que he utilizado en varias actividades por lo simple que considero su uso.

dns2tcp

No obstante, se me apareció otro problema en frente, el cliente DNS de mi computador -y el de la mayoría supondré- manda peticiones DNS sólo a través de UDP y, según lo que conozco, no todas las implementaciones de proxies SOCKS permiten UDP. Por ejemplo, OpenSSH no permite UDP en los proxies que creas al utilizar los parámetros “-D” o “-R”. Siendo esta la alternativa que comúnmente uso, tuve que buscar como arreglarmelas.

La mayoría de servidores de DNS que conozco, que vendrían siendo Windows DHCP Server y dnsmasq, exponen DNS en el puerto 53 para ambos protocolos, UDP y TCP. Por lo que si tengo alguna forma de hacer un puente entre UDP de mi máquina Windows y el servidor TCP de la red de mi víctima, podría acceder a los DNS de la red de mi víctima directamente.

Busqué “dns2tcp golang” en Google y accedí a la primera opción que me salió: https://github.com/denisix/dns2tcp. Descargué este programa en una VPS y la compilé para Windows 64-bit. Luego, creé un archivo de configuración en donde coloco un servidor DNS “upstream” y al ejecutarlo se puso en escucha un socket en el puerto 53/udp. Bastante útil.

La Magia

Escenario ficticio

Soy un atacante. Tengo una máquina Windows con herramientas ofensivas en .NET y un proxy SOCKS en mi dirección local 127.0.0.1:1337. Este proxy apunta a la red interna de mi víctima. Mi víctima tiene servidores en los rangos de direcciones IP 10.8.0.0/24 y 10.4.0.0/16. Su servidor DNS está en la direccion IP 10.8.0.1 y el dominio local es “.vpn”.

Bajamos nuestro kit de herramientas en la máquina Windows:

Creación de la interfaz

Con las herramientas a mano y en una ventana con permisos elevados, se ejecuta tun2socks con la siguiente línea:

tun2socks-amd64.exe -proxy socks5://127.0.0.1:1337 -device hehe

test

Y así de simple, ya creamos la interfaz. Ahora, faltaría crear rutas de red para que podamos apuntar los rangos de direcciones IP 10.8.0.0/24 y 10.4.0.0/16 hacia la interfaz de red recién creada. Para esto, hay que:

  1. Configurar una IP a la interfaz TUN que creamos (de nombre “hehe”)
  2. Crear una ruta persistente o temporal hacia las redes internas de la víctima y que pasen por la IP definida en la interfaz TUN

Para el paso 1, accedemos a las interfaces de red y configuramos una dirección IP manualmente en la interfaz con el nombre asignado. En este caso, la IP 1.3.3.7 con una máscara 255.255.255.255 para el dispositivo “hehe”.

test

Validamos la asignación tirando un “route PRINT” en una consola. Se ve que se creó esta nueva ruta.

test

Para el paso número 2, usamos las siguientes líneas para el escenario en el que nos encontramos

Para el rango 10.8.0.0/16: route ADD 10.8.0.0 MASK 255.255.255.0 1.3.3.7

Para el rango 10.4.0.0/16 route ADD 10.4.0.0 MASK 255.255.0.0 1.3.3.7

Volvemos a mirar las rutas y observamos que se crearon correctamente.

test

Configuración de DNS

Ahora, para el tema de los DNS, hay que generar un archivo “dns2tcp.conf” al lado de “dns2tcp.exe” con la siguiente info:

bind 127.0.0.1:53
ns 10.8.0.1:53
ttl-absent 3600
timeout 100
retry 30
gc-interval 1800

Notar que “10.8.0.1:53” es el DNS en el puerto TCP dentro de la red interna de la víctima.

Ejecutamos dns2tcp con privilegios elevados (para escuchar en el puerto 53)

test

Y listo, el chiste acá es que redirecciona el 53/udp a otro server a través de TCP. Como 10.8.0.1 pasa justo por la interfaz de red TUN gracias a la ruta que creamos antes, “automáticamente” pasa por el proxy y así obtenemos respuestas a peticiones DNS directamente desde la red interna.

Lo último sería configurar la interfaz que tenemos de internet con el nuevo DNS server. Al igual que antes, usando la interfaz gráfica para modificar su red principal (en mi caso, es la red WiFi)

test

Resultados

Para validar la efectividad de nuestro súper tunel, probamos “nslookup” a un DNS que se expone solo dentro de la red interna.

Probamos “nslookup” a un DNS que se expone solo dentro de la red interna.

test

Y para finalizar, intentamos acceder a un panel web de la red de la víctima que expone un servidor Proxmox.

test

Carga bien, saludos.

Con toda esta magia, se puede consultar DNS y acceder a la red de la víctima usando las direcciones IPs reales de los servidores. Esto es como estar con tu propio computador en la misma red interna de tu víctima. Todo esto a través de un proxy SOCKS expuesto por una interfaz TUN en nuestro computador de ataque.