Introduction
In penetration testing and red teaming, you often compromise a public-facing server and discover it has access to an internal network that you cannot reach directly from your attacking machine. To attack these internal systems, you need a way to route your traffic through the compromised server. This technique is known as "pivoting."
Pivoting is really about changing vantage point. You are no longer testing only from your original machine's network position; you are using a compromised host as a new observation and access point.
One of the most powerful and common pivoting techniques involves using SSH Dynamic Port Forwarding to create a SOCKS proxy, combined with a tool called proxychains. This combination allows you to route almost any external network tool (like Nmap, Nikto, or Metasploit) seamlessly through the compromised host.
In this lab, we will simulate a scenario where you have SSH access to a dedicated pivot host running in a Docker container. A second container on the same private Docker network hosts a hidden internal web service. The service is not exposed to the LabEx VM directly, so you must reach it through the SSH pivot host. You will learn how to set up an SSH dynamic port forward, configure proxychains, and use it to access that hidden service through the pivot host.
Set up SSH Dynamic Port Forwarding (-D)
In this step, you will establish an SSH connection to the containerized pivot host and create a local SOCKS proxy.
Dynamic port forwarding allows you to specify a local port on your attacking machine. The SSH client will listen on this port, and whenever an application connects to it, the connection is forwarded over the secure SSH channel to the SSH server. The SSH server then acts as a proxy, forwarding the traffic to its final destination.
This is more flexible than single-port forwarding because the SOCKS proxy can carry many different destination requests through one tunnel.
To set this up, we use the -D flag in our SSH command. We will also use a few other flags to make the connection run smoothly in the background.
The setup created a private key for you at ~/project/pivot_key and exposed the pivot host's SSH service on local port 2222. Run the following command in your terminal to create a SOCKS proxy on local port 9050:
ssh -f -D 9050 -q -C -N \
-o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null \
-i ~/project/pivot_key -p 2222 pivot@127.0.0.1
Let us break down the flags used in this command. The -D 9050 flag specifies dynamic port forwarding and sets the local listening port to 9050. The -q flag stands for quiet mode, which suppresses warning and diagnostic messages. The -C flag requests compression of all data, which can speed up the connection. The -N flag instructs SSH not to execute a remote command, making it useful when you are only forwarding ports. The -f flag sends the SSH client into the background after authentication, so you can continue using the same terminal session. The -o StrictHostKeyChecking=no and -o UserKnownHostsFile=/dev/null options prevent first-connection host key prompts from interrupting the lab workflow. The -i flag tells SSH which private key to use, and -p 2222 tells it to connect to the pivot host container rather than the LabEx VM's default SSH service.
After running the command, you can verify that the port is open and listening by using the ss command, which dumps socket statistics.
ss -tuln | grep 9050
You should see an output similar to this, indicating that your machine is now listening on port 9050:
tcp LISTEN 0 128 127.0.0.1:9050 0.0.0.0:*
tcp LISTEN 0 128 [::1]:9050 [::]:*
Configure Proxychains (/etc/proxychains.conf)
In this step, you will inspect the configuration for proxychains.
While you now have a SOCKS proxy running on port 9050, most command-line tools (like Nmap) do not natively know how to route their traffic through a SOCKS proxy. This is where proxychains comes in. It is a tool that forces any TCP connection made by a given application to follow through a proxy.
In practice, proxychains is what extends the tunnel from one manual test into a reusable operator workflow across many tools.
The configuration file for proxychains is located at /etc/proxychains4.conf. For this lab, the proxy entry should point to a SOCKS5 proxy on 127.0.0.1 port 9050, which matches the SSH dynamic port forward we just created.
Let us view the bottom of the configuration file to confirm this setting. Use the tail command to print the last 10 lines of the file:
tail -n 10 /etc/proxychains4.conf
You should see output similar to the following:
[ProxyList]
## add proxy here ...
## meanwile
## defaults set to "tor"
socks5 127.0.0.1 9050
The [ProxyList] section is where proxies are defined. The line socks5 127.0.0.1 9050 tells proxychains to route traffic through the local port 9050. Since our SSH -D command created a proxy on this exact port, no further configuration is needed after updating the protocol type.
If you ever need to use a different port or a different type of proxy, you would edit this file using a text editor like nano.
Test the SOCKS Proxy
In this step, you will test if your proxy setup is working correctly by accessing the hidden internal web service.
Remember that there is a web service running on a hidden internal container at 172.30.0.20:80. In a real-world scenario, this represents an internal intranet site that cannot be accessed directly from the outside internet.
To use proxychains, you simply prepend the command proxychains4 to the tool you want to run. Let us use curl to fetch the web page.
Run the following command:
proxychains4 curl http://172.30.0.20
When you execute this, proxychains intercepts the network request made by curl and tunnels it through the SSH SOCKS proxy on port 9050. The pivot host then makes the request to 172.30.0.20:80 on the internal Docker network and returns the result.
You should see output similar to this:
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.14
[proxychains] Strict chain ... 127.0.0.1:9050 ... 172.30.0.20:80 ... OK
Secret Internal Data: You have successfully pivoted
The OK message indicates that the proxy connection was successful, and the final line displays the secret data from the internal web server.
Run External Tools through Pivot
In this final step, you will use a more advanced external tool, Nmap, to scan the internal network through your established pivot.
When using proxychains with Nmap, there are important technical limitations to understand. SOCKS proxies only support full TCP connections. They do not support ICMP (ping) or half-open SYN scans (which Nmap uses by default when run with sudo).
Therefore, when running Nmap through proxychains, you must force it to use a full TCP Connect scan and disable ping discovery.
Run the following Nmap command to scan the internal web service on port 80:
proxychains4 nmap -sT -Pn -p 80 172.30.0.20
Let us break down the Nmap flags used here. The -sT flag forces a TCP Connect scan, which is mandatory because SOCKS proxies cannot handle raw packets or SYN scans. The -Pn flag disables host discovery (ping); since SOCKS proxies cannot route ICMP echo requests, Nmap would incorrectly assume the host is down if this flag were omitted. Finally, the -p 8080 flag specifies the exact port to scan.
You will see proxychains logging the connection attempts, followed by the Nmap scan results:
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.14
Starting Nmap 7.91 ( https://nmap.org ) at 2024-01-01 12:00 UTC
[proxychains] Strict chain ... 127.0.0.1:9050 ... 172.30.0.20:80 ... OK
Nmap scan report for 172.30.0.20
Host is up (0.0020s latency).
PORT STATE SERVICE
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds
This confirms that you can successfully route complex security tools through a compromised host to interact with internal network segments.
Summary
Congratulations! You have successfully completed the Dynamic Port Forwarding with Proxychains lab.
In this lab, you learned how to create a local SOCKS proxy using SSH dynamic port forwarding (-D). You also learned how to understand and inspect the configuration of proxychains. Furthermore, you successfully routed basic HTTP requests through the proxy to access hidden internal services. Finally, you adapted advanced scanning tools like Nmap to work through a SOCKS proxy by utilizing TCP Connect scans (-sT) and disabling ping discovery (-Pn).
These pivoting techniques are essential skills for navigating complex network environments during penetration tests and security assessments.
