Pivoting, Tunneling and Port Forwarding
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
Qué es: Técnica para moverse entre redes a través de un host comprometido.
Objetivo: Acceder a segmentos de red aislados usando una máquina intermedia.
Ejemplo: Un host tiene dos interfaces de red (dual-homed), una hacia la red empresarial y otra hacia una red operacional. Usamos ese host para pivotear entre ambas.
Alias comunes: Jump Host, Foothold, Proxy, Beachhead, etc.
Qué es: Subconjunto del pivoting que consiste en encapsular tráfico en otros protocolos (como HTTP o HTTPS) para evadir detecciones.
Ejemplo: Instrucciones C2 ocultas en peticiones HTTP GET/POST disfrazadas como tráfico legítimo.
Aplicaciones comunes: VPN, proxys SOCKS, HTTPS sobre SSH, etc.
Qué es: Técnica para moverse horizontalmente dentro de la misma red.
Objetivo: Acceder a más máquinas usando credenciales válidas, comúnmente con fines de escalamiento de privilegios.
Ejemplo: Usar credenciales de administrador local para conectarse a otras máquinas dentro de la misma red.
Port Forwarding
El reenvío de puertos (Port Forwarding) es una técnica que nos permite redirigir una solicitud de comunicación de un puerto a otro. El reenvío de puertos utiliza TCP como capa de comunicación principal para proporcionar comunicación interactiva para el puerto reenviado. Sin embargo, se pueden usar diferentes protocolos de capa de aplicación como SSH o incluso SOCKS (no de capa de aplicación) para encapsular el tráfico reenviado. Esto puede ser efectivo para evadir firewalls y utilizar servicios existentes en el host comprometido para pivotar hacia otras redes.
Tomemos como ejemplo la imagen de abajo.
Scanning the Pivot Target
Tenemos nuestro host atacante (10.10.15.x) y un servidor Ubuntu de destino (10.129.x.x), que ya hemos comprometido. Escanearemos el servidor Ubuntu con Nmap para buscar puertos abiertos.
El resultado de Nmap muestra que el puerto SSH está abierto. Para acceder al servicio MySQL, podemos hacer SSH al servidor y acceder a MySQL desde dentro, o reenviar el puerto a nuestro localhost en el puerto 1234 y acceder localmente. Una ventaja de acceder localmente es que si queremos ejecutar un exploit remoto contra MySQL, no podríamos hacerlo sin reenviar el puerto, ya que el servicio solo está expuesto localmente en el puerto 3306 del servidor Ubuntu.
Executing the Local Port Forward
Así que usaremos el siguiente comando para reenviar nuestro puerto local (1234) vía SSH al servidor Ubuntu:
La opción -L le indica al cliente SSH que solicite al servidor SSH reenviar todos los datos enviados por el puerto 1234 a localhost:3306 en el servidor Ubuntu. Al hacer esto, deberíamos poder acceder al servicio MySQL localmente desde el puerto 1234.
Confirming Port Forward with Netstat
Confirming Port Forward with Nmap
Forwarding Multiple Ports
Si queremos reenviar múltiples puertos desde el servidor Ubuntu a nuestro localhost, podemos hacerlo añadiendo más argumentos -L al comando SSH:
A diferencia del escenario anterior donde sabíamos qué puerto debíamos acceder, en nuestro escenario actual no sabemos qué servicios están del otro lado de la red. Por eso, podemos escanear rangos pequeños de IPs dentro de la red (172.16.5.1-200) o el subnet completo (172.16.5.0/23). No podemos hacer este escaneo directamente desde nuestro equipo atacante porque no tiene rutas hacia la red 172.16.5.0/23. Para lograrlo, tendremos que realizar un dynamic port forwarding y pivotear nuestro tráfico de red a través del servidor Ubuntu comprometido.
Esto se conoce como SSH tunneling usando un SOCKS proxy. SOCKS significa Socket Secure, un protocolo que permite comunicarse con servidores cuando existen restricciones impuestas por un firewall. A diferencia de la mayoría de los casos donde iniciamos una conexión hacia un servicio, en el caso de SOCKS, el tráfico inicial es generado por un cliente SOCKS, que se conecta al servidor SOCKS (controlado por nosotras) para acceder a servicios desde el lado del cliente. Una vez establecida la conexión, el tráfico de red puede ser redirigido a través del servidor SOCKS en nombre del cliente conectado.
Esta técnica se usa frecuentemente para evadir restricciones impuestas por firewalls, permitiendo que una entidad externa acceda a un servicio que se encuentra dentro de un entorno protegido. Otro beneficio de usar un SOCKS proxy para pivotear y reenviar datos es que permite pivotear incluso desde redes NAT creando rutas hacia servidores externos. Existen dos tipos de proxies SOCKS: SOCKS4 y SOCKS5. SOCKS4 no ofrece autenticación ni soporte para UDP, mientras que SOCKS5 sí los incluye.
Tomemos como ejemplo la imagen de abajo donde tenemos una red enmascarada con NAT (172.16.5.0/23) a la que no podemos acceder directamente.
En la imagen anterior, el attack host inicia el cliente SSH y solicita al servidor SSH que le permita enviar datos TCP a través del ssh socket. El servidor SSH responde con una confirmación, y el cliente SSH comienza a escuchar en localhost:9050. Cualquier dato que se envíe allí será retransmitido a toda la red (172.16.5.0/23) mediante SSH. Podemos usar el siguiente comando para realizar este dynamic port forwarding:
El argumento -D solicita al servidor SSH que habilite el dynamic port forwarding. Una vez habilitado, necesitaremos una herramienta que pueda enrutar los paquetes de cualquier herramienta a través del puerto 9050. Podemos hacer esto usando proxychains, que es capaz de redirigir conexiones TCP a través de servidores proxy TOR, SOCKS, y HTTP/HTTPS, y además permite encadenar múltiples proxies.
Usando proxychains, también podemos ocultar la dirección IP del requesting host, ya que el receiving host sólo verá la IP del pivot host. Proxychains se utiliza a menudo para forzar que el tráfico TCP de una aplicación pase a través de proxies como SOCKS4/SOCKS5, TOR, o HTTP/HTTPS.
Checking /etc/proxychains.conf
Para indicarle a proxychains que debe usar el puerto 9050, debemos modificar el archivo de configuración ubicado en /etc/proxychains.conf. Podemos agregar socks4 127.0.0.1 9050 en la última línea si aún no está presente.
Using Nmap with Proxychains
Ahora, cuando ejecutemos Nmap con proxychains usando el siguiente comando, todos los paquetes de Nmap se enviarán al puerto local 9050, donde nuestro cliente SSH está escuchando. Este a su vez reenviará todo el tráfico por SSH hacia la red 172.16.5.0/23.
Esta parte de empaquetar todos los datos de Nmap usando proxychains y reenviarlos a un servidor remoto se llama SOCKS tunneling. Otro punto importante a tener en cuenta es que solo podemos realizar un escaneo completo de conexión TCP (full TCP connect scan) a través de proxychains. Esto se debe a que proxychains no puede interpretar paquetes parciales. Si enviamos paquetes parciales, como en un escaneo de tipo half-connect, devolverá resultados incorrectos.
También debemos ser conscientes de que las comprobaciones de host activo (host-alive checks) pueden no funcionar contra objetivos Windows, ya que el firewall de Windows Defender bloquea las solicitudes ICMP (pings tradicionales) por defecto.
Un escaneo completo de conexión TCP sin ping sobre un rango de red completo tomará mucho tiempo. Por eso, en este módulo, nos enfocaremos principalmente en escanear hosts individuales o rangos pequeños de hosts que sabemos que están activos, como en este caso: una máquina Windows en 172.16.5.19.
Enumerating the Windows Target through Proxychains
Realizaremos un escaneo remoto del sistema con el siguiente comando:
Ya hemos visto el reenvío de puertos local, donde SSH puede escuchar en nuestro equipo local y reenviar un servicio del host remoto a nuestro puerto, y el reenvío de puertos dinámico, donde podemos enviar paquetes a una red remota a través de un pivot host. Pero, a veces, también podríamos querer reenviar un servicio local hacia un puerto remoto.
Imaginemos el escenario en el que podemos hacer RDP hacia el host Windows Windows A. Como se puede ver en la imagen de abajo, en nuestro caso anterior pudimos pivotar hacia el host Windows a través del servidor Ubuntu.
Pero ¿qué pasa si intentamos obtener una reverse shell?
La conexión saliente del host Windows está limitada solo a la red 172.16.5.0/23. Esto se debe a que el host Windows no tiene ninguna conexión directa con la red en la que se encuentra el attack host. Si iniciamos un listener de Metasploit en nuestro attack host e intentamos obtener una reverse shell, no lograremos una conexión directa porque el servidor Windows no sabe cómo enrutar el tráfico que sale de su red (172.16.5.0/23) hacia la 10.129.x.x (nuestra red de atacante).
En estos casos, debemos encontrar un pivot host, que sea un punto de conexión común entre nuestro attack host y el servidor Windows. En nuestro caso, el pivot host sería el servidor Ubuntu, ya que puede conectarse tanto a nuestro attack host como al objetivo Windows.
Para obtener una shell Meterpreter en Windows, crearemos un payload Meterpreter HTTPS usando msfvenom, pero la configuración de la conexión reversa para el payload tendrá como IP destino la del servidor Ubuntu (172.16.5.129). Usaremos el puerto 8080 en el servidor Ubuntu para reenviar todos los paquetes de la reverse shell hacia el puerto 8000 de nuestro attack host, donde estará escuchando Metasploit.
Creating a Windows Payload with msfvenom
Configuring & Starting the multi/handler
Transferring Payload to Pivot Host
Una vez que hayamos creado nuestro payload y tengamos el listener configurado y ejecutándose, podemos copiar el payload al servidor Ubuntu usando el comando scp, ya que ya tenemos las credenciales para conectarnos al servidor Ubuntu por SSH.
Starting Python3 Webserver on Pivot Host
Después de copiar el payload, iniciaremos un servidor HTTP con python3 en el servidor Ubuntu, en el mismo directorio donde se encuentra el payload.
Downloading Payload on the Windows Target
Podemos descargar este backupscript.exe en el host Windows usando un navegador web o el cmdlet de PowerShell Invoke-WebRequest.
Using SSH -R
Una vez descargado el payload en el host Windows, usaremos reenvío de puertos remoto por SSH para reenviar conexiones desde el puerto 8080 del servidor Ubuntu hacia el servicio listener de nuestra msfconsole en el puerto 8000. Usaremos el argumento -vN en el comando SSH para hacerlo más detallado y evitar que se abra una shell interactiva.
El argumento -R le indica al servidor Ubuntu que escuche en <targetIPaddress>:8080 y reenvíe todas las conexiones entrantes a nuestro listener en 0.0.0.0:8000 del host atacante.
Después de crear el reenvío remoto SSH, podemos ejecutar el payload desde el objetivo Windows. Si el payload se ejecuta correctamente y trata de conectarse de vuelta a nuestro listener, podremos ver los logs de conexión desde el host pivot.
Viewing the Logs from the Pivot
Meterpreter Session Established
Nuestra sesión de Meterpreter debería mostrar que la conexión entrante proviene del propio host local (127.0.0.1), ya que estamos recibiendo la conexión a través del socket local SSH, el cual creó una conexión saliente hacia el servidor Ubuntu. Ejecutar el comando netstat puede mostrarnos que la conexión entrante proviene del servicio SSH.
La siguiente representación gráfica ofrece una manera alternativa de entender esta técnica.
Ahora consideremos un escenario en el que ya tenemos acceso a una shell de Meterpreter en el servidor Ubuntu (nuestro host de pivoteo) y queremos realizar escaneos de enumeración a través de él, aprovechando las funcionalidades que ofrece Meterpreter. En estos casos, podemos crear un pivote usando la sesión de Meterpreter sin depender del reenvío de puertos por SSH.
Podemos generar una shell de Meterpreter para el servidor Ubuntu con el siguiente comando, que nos devolverá una shell en nuestro host atacante a través del puerto 8080:
Creating Payload for Ubuntu Pivot Host
Configuring & Starting the multi/handler
Antes de copiar el payload, podemos iniciar el multi/handler en Metasploit, también conocido como Generic Payload Handler.
Executing the Payload on the Pivot Host
Copiamos el binario backupjob al servidor Ubuntu (host pivote) vía SSH y lo ejecutamos:
Meterpreter Session Establishment
Debemos asegurarnos de que la sesión de Meterpreter se establezca correctamente tras ejecutar el payload.
Ping Sweep
Sabemos que el objetivo (Windows) se encuentra en la red 172.16.5.0/23. Suponiendo que el firewall del host Windows permita tráfico ICMP, lo siguiente que queremos hacer es un ping sweep desde nuestra sesión de Meterpreter. Para ello, podemos usar el módulo ping_sweep, el cual generará tráfico ICMP desde el host Ubuntu hacia esa red.
También podemos realizar un ping sweep (barrido de red con ping) utilizando un bucle for directamente en el host pivot comprometido, que enviará pings a todos los dispositivos dentro del rango de red que especifiquemos. Aquí tienes dos one-liners muy útiles, dependiendo del sistema operativo del host pivot:
Ping Sweep For Loop on Linux Pivot Hosts
Ping Sweep For Loop Using CMD
Ping Sweep Using PowerShell
Nota: Es posible que un ping sweep no devuelva respuestas exitosas en el primer intento, especialmente cuando se comunica entre diferentes redes. Esto puede deberse al tiempo que tarda un host en construir su caché ARP. En estos casos, es recomendable repetir el barrido al menos dos veces para asegurarnos de que la caché ARP se haya construido correctamente.
Configuring MSF's SOCKS Proxy
También pueden existir escenarios en los que el firewall de un host bloquee el ping (ICMP), por lo que no obtendremos respuestas exitosas. En estos casos, podemos realizar un escaneo TCP sobre la red 172.16.5.0/23 utilizando Nmap.
En lugar de usar SSH para el port forwarding, también podemos utilizar el módulo de post-explotación socks_proxy de Metasploit, el cual nos permite configurar un proxy local tipo SOCKS en nuestra máquina atacante.
Se configurará el proxy SOCKS en su versión 4a, el cual iniciará un listener en el puerto 9050 y redirigirá todo el tráfico recibido a través de nuestra sesión de Meterpreter.
Confirming Proxy Server is Running
Adding a Line to proxychains.conf if Needed
Después de iniciar el servidor SOCKS, configuraremos proxychains para redirigir el tráfico generado por otras herramientas como Nmap a través de nuestro pivote en el host Ubuntu comprometido.
Podemos añadir la siguiente línea al final del archivo proxychains.conf ubicado en /etc/proxychains.conf si no está presente.
Nota: Dependiendo de la versión del servidor SOCKS que estemos usando, en ocasiones necesitaremos cambiar socks4 por socks5 en el archivo de configuración.
Creating Routes with AutoRoute
Finalmente, debemos indicar al módulo socks_proxy que redirija todo el tráfico a través de nuestra sesión de Meterpreter. Para esto, podemos utilizar el módulo post/multi/manage/autoroute de Metasploit para añadir rutas hacia la subred 172.16.5.0 y enrutar el tráfico de proxychains correctamente.
También es posible agregar rutas con autoroute directamente desde la sesión de Meterpreter ejecutando el siguiente comando:
Listing Active Routes with AutoRoute
Una vez agregadas las rutas necesarias, podemos usar la opción -p para listar las rutas activas y confirmar que nuestra configuración se haya aplicado correctamente.
Testing Proxy & Routing Functionality
Como podemos ver en la salida anterior, la ruta hacia la red 172.16.5.0/23 ha sido añadida correctamente. Esto nos permite ahora utilizar proxychains para enrutar nuestro tráfico de Nmap a través de la sesión de Meterpreter.
También podemos lograr el port forwarding utilizando el módulo portfwd de Meterpreter. Este módulo nos permite redirigir tráfico desde nuestro host atacante hacia una máquina remota a través de una sesión activa de Meterpreter.
Portfwd options
Creating Local TCP Relay
El comando anterior le indica a la sesión de Meterpreter que inicie un listener en el puerto local 3300 de nuestro host atacante (-l 3300) y reenvíe todos los paquetes a la máquina remota 172.16.5.19 en el puerto 3389 (-r 172.16.5.19 -p 3389), utilizando la sesión activa de Meterpreter como canal de comunicación.
Connecting to Windows Target through localhost
Una vez establecido el port forwarding, podemos ejecutar el siguiente comando para iniciar una sesión RDP desde nuestra máquina.
Netstat Output
Podemos usar netstat para ver información sobre la sesión que acabamos de establecer. Desde una perspectiva defensiva, netstat también es útil si sospechamos que un host ha sido comprometido, ya que nos permite ver todas las sesiones activas que ese host ha establecido.
Al igual que con los local port forwards, Metasploit también puede realizar reverse port forwarding con el siguiente comando. Esto es útil cuando queremos escuchar en un puerto específico del servidor comprometido y redirigir todas las conexiones entrantes desde el servidor Ubuntu hacia nuestro attack host.
En este caso, vamos a iniciar un listener en un nuevo puerto de nuestra máquina para recibir una Windows shell, y solicitaremos al servidor Ubuntu que redirija todas las solicitudes que reciba en el puerto 1234 hacia nuestro listener en el puerto 8081.
Reverse Port Forwarding Rules
Podemos crear este reverse port forward en la shell que ya teníamos abierta desde el escenario anterior con el siguiente comando:
Configuring & Starting multi/handler
Generating the Windows Payload
Ahora podemos crear un reverse shell payload que, al ejecutarse en el host Windows, envíe una conexión de vuelta a nuestro servidor Ubuntu (172.16.5.129:1234). Una vez que el servidor Ubuntu reciba esta conexión, la redirigirá al attack host en el puerto 8081, como lo configuramos anteriormente con reverse port forwarding.
Establishing the Meterpreter session
Una vez que ejecutamos el payload en el host Windows, deberíamos recibir una Meterpreter shell a través del Ubuntu pivot host, redirigida hacia nuestro listener en el attack host:
Podemos iniciar el listener de Metasploit en nuestra máquina atacante usando el mismo comando mencionado en la sección anterior, y luego lanzar socat desde el servidor Ubuntu para establecer el canal de redirection.
Starting Socat Listener
Socat escuchará en localhost en el puerto 8080 y redirigirá todo el tráfico hacia el puerto 80 de nuestra máquina atacante (10.10.14.18). Una vez que tengamos configurado nuestro redirector, podemos crear un payload que se conecte de vuelta a ese redirector, el cual está corriendo en el servidor Ubuntu.
También iniciaremos un listener en nuestra máquina atacante, porque en cuanto socat reciba una conexión desde el objetivo, redirigirá todo ese tráfico hacia el listener de nuestra máquina atacante, donde recibiremos la shell.
Creating the Windows Payload
Ten en cuenta que debemos transferir este payload al host Windows. Podemos usar algunas de las mismas técnicas vistas en File Transfer.
Starting MSF Console
Configuring & Starting the multi/handler
Establishing the Meterpreter Session
Podemos probar esto ejecutando nuevamente nuestro payload en el host Windows, y esta vez deberíamos ver que la conexión de red proviene desde el servidor Ubuntu.
Similar a nuestro redirector de Socat con reverse shell, también podemos crear un redirector de bind shell con Socat.
Esto es diferente de las reverse shells que se conectan de vuelta desde el servidor Windows hacia el servidor Ubuntu y que luego se redirigen hacia nuestra máquina atacante. En el caso de las bind shells, el servidor Windows iniciará un listener y se enlazará a un puerto específico.
Podemos crear un payload de bind shell para Windows y ejecutarlo en el host Windows. Al mismo tiempo, podemos crear un redirector Socat en el servidor Ubuntu, el cual escuchará conexiones entrantes desde un handler de Metasploit configurado como bind y las redirigirá al payload de bind shell en el objetivo Windows
La figura de abajo explica mucho mejor el proceso de pivoting en este escenario.
Creating the Windows Payload
Podemos crear una bind shell usando msfvenom con el siguiente comando:
Starting Socat Bind Shell Listener
Podemos iniciar un listener con Socat que escuche en el puerto 8080 y redirija los paquetes al servidor Windows en el puerto 8443:
Configuring & Starting the Bind multi/handler
Finalmente, podemos iniciar un handler de Metasploit configurado para bind, el cual se conectará al listener de socat en el puerto 8080 (en el servidor Ubuntu).
Establishing Meterpreter Session
Podemos ver que un bind handler se ha conectado a una solicitud de stage que ha sido pivoteada a través del listener de socat tras ejecutar el payload en el objetivo Windows.
Plink, abreviatura de PuTTY Link, es una herramienta SSH por línea de comandos para Windows que viene incluida en el paquete de PuTTY cuando se instala. Al igual que ssh, Plink también permite crear reenvíos de puertos dinámicos (Dynamic Port Forwarding) y proxies SOCKS.
Antes de finales de 2018, Windows no incluía un cliente SSH de forma nativa, por lo que los usuarios debían instalar uno por su cuenta. La herramienta preferida por muchos administradores era PuTTY, que incluía plink.
Ese es solo un posible escenario donde Plink resulta útil. También podríamos utilizarlo si estamos usando una máquina Windows como host de ataque principal en lugar de una basada en Linux.
En la imagen de abajo, tenemos un host de ataque basado en Windows.
El host de ataque en Windows inicia un proceso de plink.exe con los siguientes argumentos en la línea de comandos para establecer un dynamic port forward a través del servidor Ubuntu. Esto inicia una sesión SSH entre el host de ataque en Windows y el servidor Ubuntu, y luego plink comienza a escuchar en el puerto 9050.
Using Plink.exe
Después de configurar el SOCKS server con la IP 127.0.0.1 y el puerto 9050, podemos iniciar directamente mstsc.exe (el cliente de escritorio remoto de Windows) para establecer una sesión RDP con un objetivo Windows que permita conexiones RDP.
Sshuttle es una herramienta escrita en Python que elimina la necesidad de configurar proxychains. Sin embargo, esta herramienta solo funciona para pivotar sobre conexiones SSH, y no ofrece opciones para hacerlo a través de TOR o servidores proxy HTTPS. Aun así, puede ser muy útil ya que automatiza la ejecución de reglas de iptables y el enrutamiento necesario para establecer pivotes a través del host remoto.
Una ventaja interesante de sshuttle es que no necesitamos usar proxychains para conectarnos a los hosts remotos. Basta con establecer la sesión SSH y sshuttle se encargará del resto.
Podemos instalar sshuttle en el host pivot Ubuntu y configurarlo para que enrute el tráfico hacia el host Windows y conectarnos vía RDP:
Installing sshuttle
Running sshuttle
Para usar sshuttle, especificamos la opción -r para conectarnos a la máquina remota con un nombre de usuario y contraseña. Luego necesitamos incluir la red o IP que queremos enrutar a través del pivot host, que en nuestro caso es la red 172.16.5.0/23.
Traffic Routing through iptables Routes
Con este comando, sshuttle crea una entrada en nuestras iptables para redirigir todo el tráfico destinado a la red 172.16.5.0/23 a través del pivot host.
Gracias a esto, ya podemos utilizar cualquier herramienta directamente sin necesidad de usar proxychains, como en el ejemplo con Nmap, donde escaneamos el puerto 3389 de la IP 172.16.5.19 de forma totalmente transparente.
Podemos iniciar nuestro servidor SOCKS proxy de rpivot con el siguiente comando para permitir que el cliente se conecte al puerto 9999 y escuchar en el puerto 9050 para conexiones de pivoteo vía proxy.
Cloning rpivot
Installing Python2.7
Alternative Installation of Python2.7
Running server.py from the Attack Host
Luego de instalar Python 2.7, podemos lanzar el servidor de rpivot con server.py para aceptar conexiones desde el cliente ubicado en el servidor Ubuntu comprometido.
Transfering rpivot to the Target
Antes de ejecutar client.py, necesitamos transferir el directorio de rpivot al objetivo comprometido. Podemos hacerlo con el siguiente comando SCP:
Running client.py from Pivot Target
Esto establecerá una conexión inversa desde el host comprometido (Ubuntu) hacia nuestra máquina atacante.
Confirming Connection is Established
Luego, configuramos proxychains para usar el servidor SOCKS que levantamos con rpivot en 127.0.0.1:9050.
Browsing to the Target Webserver using Proxychains
Finalmente, podremos acceder al servidor web interno (en la red 172.16.5.0/23) apuntando al 172.16.5.135:80, usando proxychains y navegando con Firefox desde nuestra máquina atacante.
En estos casos, rpivot permite añadir una opción adicional de autenticación NTLM proporcionando un usuario y contraseña válidos del dominio.
Connecting to a Web Server using HTTP-Proxy & NTLM Auth
Encontrar rutas.
Ver la configuración del firewall.
Añadir proxies.
Crear reglas de reenvío de puertos.
Tomemos como ejemplo el siguiente escenario, donde el host comprometido es una estación de trabajo con Windows 10 perteneciente a un administrador de TI (IPs: 10.129.15.150, 172.16.5.25). Hay que tener en cuenta que, durante un pentest, es posible acceder al equipo de un empleado mediante técnicas como ingeniería social o phishing. Esto nos permitiría pivotar más dentro de la red a la que pertenece esa estación de trabajo.
Using Netsh.exe to Port Forward
Podemos usar netsh.exe para reenviar todo el tráfico recibido en un puerto específico (por ejemplo, el 8080) hacia un host remoto en un puerto remoto. Esto se puede hacer con el siguiente comando:
Verifying Port Forward
Connecting to the Internal Host through the Port Forward
Después de configurar el portproxy en nuestro host pivot basado en Windows, intentaremos conectarnos al puerto 8080 de ese host desde nuestra máquina atacante usando xfreerdp. Una vez que se envíe una solicitud desde nuestra máquina, el host Windows redirigirá nuestro tráfico según la configuración del proxy definida con netsh.exe.
Normalmente, en entornos corporativos con dominios Active Directory, existe un servidor DNS que resuelve nombres de host a direcciones IP y redirige las consultas a servidores DNS externos. Sin embargo, con Dnscat2, la resolución de nombres se solicita desde un servidor externo controlado por el atacante. Cuando el DNS interno intenta resolver una dirección, en realidad se está exfiltrando información camuflada como una consulta DNS.
Este método es altamente sigiloso y puede evadir mecanismos de detección tradicionales, como los firewalls que inspeccionan conexiones HTTPS, ya que aprovecha la naturaleza "inocente" del tráfico DNS.
Cloning dnscat2 and Setting Up the Server
Si dnscat2 aún no está configurado en nuestra máquina atacante, podemos instalarlo y dejarlo listo con los siguientes comandos:
Starting the dnscat2 server
Luego de instalar y preparar el entorno, podemos iniciar el servidor de dnscat2 ejecutando el siguiente comando:
Cloning dnscat2-powershell to the Attack Host
Además, el servidor generará una clave secreta (--secret) para cifrar la comunicación entre el cliente y el servidor. Esta clave debe usarse también en el cliente para establecer el canal C2.
Para el cliente, podemos usar:
El cliente original de dnscat2 (./dnscat)
Lo recomendable es clonar el repositorio que contiene el cliente en nuestra máquina atacante, y luego transferirlo al host comprometido para ejecutarlo y establecer el túnel DNS.
Importing dnscat2.ps1
Una vez que el archivo dnscat2.ps1 esté en el equipo comprometido, podemos importarlo en PowerShell con el siguiente comando:
Confirming Session Establishment
Después de importarlo, usaremos el módulo para establecer un túnel hacia nuestro servidor atacante que ya está ejecutando dnscat2. Podemos enviar una sesión de shell tipo cmd con este comando:
Listing dnscat2 Options
Es importante que el valor de -PreSharedSecret coincida con el generado por el servidor para que la conexión se establezca de forma correcta y cifrada.
Si todo está configurado correctamente, veremos una nueva sesión activa en el servidor dnscat2 de nuestra máquina atacante.
Interacting with the Established Session
Podemos listar las opciones disponibles en dnscat2 escribiendo ? en la consola del servidor.
Esto indica que la sesión está cifrada y autenticada correctamente (gracias al pre-shared key). Desde ahí, cualquier comando que escribamos se enviará al cliente Windows comprometido. Por ejemplo:
Hay muchas ocasiones durante una auditoría de Pentest en las que tener únicamente una conexión por escritorio remoto no es suficiente. Podemos necesitar subir o bajar archivos (cuando el portapapeles del RDP está deshabilitado), usar exploits o interactuar con APIs de bajo nivel de Windows mediante una sesión de Meterpreter, lo cual no es posible usando solo.
es una herramienta de relay bidireccional que permite crear sockets tipo pipe entre dos canales de red independientes, sin necesidad de usar SSH tunneling. Actúa como un redirector, escuchando en un host:puerto y redirigiendo ese tráfico hacia otra dirección IP y puerto.
Otra herramienta basada en Windows llamada puede usarse para iniciar un túnel SOCKS a través de la sesión SSH que creamos. Proxifier es una herramienta para Windows que crea una red tunelizada para aplicaciones cliente de escritorio, permitiendo que funcionen a través de un proxy SOCKS o HTTPS, y también permite hacer proxy chaining. Es posible crear un perfil donde podamos proporcionar la configuración para nuestro SOCKS server iniciado por Plink en el puerto 9050.
es una herramienta de reverse SOCKS proxy escrita en Python para el SOCKS tunneling. Rpivot vincula una máquina dentro de una red corporativa a un servidor externo y expone el puerto local del cliente en el lado del servidor. Tomaremos el siguiente escenario, donde tenemos un servidor web en nuestra red interna (172.16.5.135) y queremos acceder a él usando el proxy rpivot.
Similar al proxy de pivoting anterior, puede haber escenarios en los que no podamos pivotar directamente hacia un servidor externo (nuestra máquina atacante en la nube). Algunas organizaciones tienen proxies , configurados con el Controlador de Dominio (DC).
es una herramienta de línea de comandos de Windows que puede ayudarnos con la configuración de red de un sistema Windows en particular. Estas son algunas de las tareas relacionadas con red que podemos realizar con Netsh:
es una herramienta de tunelización que utiliza el protocolo DNS para enviar datos entre dos hosts. Usa un canal C2 (Command and Control) cifrado y envía la información dentro de los registros TXT del protocolo DNS.
O bien, , una versión en PowerShell compatible con Windows.
