/pivoting-tunneling

name: pivoting-tunneling
description: >
  Network pivoting, port forwarding, and tunneling through compromised hosts
  to reach internal networks.
keywords:
  - pivot
  - tunnel
  - port forward
  - SOCKS proxy
  - proxychains
  - access internal network
  - double pivot
  - SSH tunnel
  - ligolo
  - chisel
  - sshuttle
  - reach another subnet
  - lateral movement networking
  - I can't reach the internal network
  - set up a proxy
  - route traffic through
tools:
  - SSH
  - Ligolo-ng
  - Chisel
  - sshuttle
  - socat
  - proxychains
  - plink
  - netsh
  - dnscat2
  - iodine
  - FRP
opsec: medium

Pivoting and Tunneling

You are helping a penetration tester pivot through compromised hosts to reach internal networks. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[pivoting-tunneling] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• At least one compromised host with access to the target network
• Know the target subnet or specific internal hosts to reach
• Know what's available on the compromised host (SSH, outbound connectivity,

installed tools, OS)

Privileged Commands

Claude Code cannot execute `sudo` commands. The following tools require root on the **attacker machine** and must be handed off to the user:

• **ssh -w** (VPN/tun mode) — creates tun device (requires `PermitTunnel` on both ends)
• **ip addr / ip link / ip route / ip tuntap** — network interface and route configuration
• **iptables** — NAT/masquerade rules for tunnel routing
• **sshuttle** — transparent proxy (needs root for iptables rules)
• **iodined / iodine** — DNS tunnel server/client (needs tun device)
• **hans** — ICMP tunnel (needs raw sockets)
• **ptunnel-ng** — ICMP tunnel (needs raw sockets)

**Handoff protocol:**

1. Present the full command including `sudo` to the user 2. For multi-step setups (e.g., create tun + add route + add NAT), batch all commands so the user can run them sequentially 3. Verify connectivity after the user confirms completion 4. Continue with proxychains configuration and tool usage

**Non-privileged commands** Claude can execute directly:

• SSH port forwarding: `ssh -L`, `ssh -R`, `ssh -D`, `ssh -J` (jump hosts)
• Chisel (client/server as user binary)
• Ligolo-ng agent (on pivot host)
• Socat port forwarding
• Plink (Windows SSH)
• Proxychains configuration and usage
• FRP client/server

**Note:** Ligolo-ng **proxy** setup requires root on the attacker machine (`ip tuntap add`, `ip link set`, `ip route add`). The **agent** on the pivot host runs unprivileged.

Tool Selection Decision Tree

Choose the right tool based on what's available:

What access do you have on the pivot host?
│
├─ SSH access (port 22 open to you)
│  ├─ Need to reach a single port? → SSH Local Forward (-L)
│  ├─ Need a full SOCKS proxy? → SSH Dynamic Forward (-D)
│  ├─ Need to expose a service back to you? → SSH Remote Forward (-R)
│  ├─ Need transparent subnet access? → sshuttle
│  └─ Need full layer-3 VPN? → SSH VPN (tun device)
│
├─ Shell access (no SSH, but have outbound connectivity)
│  ├─ Can upload tools?
│  │  ├─ Need full subnet routing? → Ligolo-ng
│  │  ├─ Need SOCKS proxy? → Chisel reverse SOCKS
│  │  └─ Need simple port forward? → Chisel or socat
│  └─ Cannot upload tools?
│     ├─ Bash available? → /dev/tcp relay
│     └─ Python available? → Python SOCKS proxy
│
├─ Only HTTP(S) outbound
│  ├─ Webshell on target? → reGeorg / neo-reGeorg
│  └─ Can upload binary? → Chisel (HTTP tunnel mode)
│
├─ Only DNS outbound
│  └─ dnscat2 or iodine
│
├─ Only ICMP outbound
│  └─ hans or ptunnel-ng
│
├─ Windows host (no SSH)
│  ├─ RDP access? → SocksOverRDP + Proxifier
│  ├─ Admin access? → netsh portproxy
│  └─ User access? → plink (PuTTY CLI), Chisel, or Ligolo-ng
│
└─ Through a corporate proxy (NTLM auth)
   └─ rpivot or cntlm + Chisel

Step 1: SSH Tunneling

SSH is the preferred pivoting tool — it's native, encrypted, leaves minimal forensic artifacts, and is already present on most Linux/macOS systems.

Local Port Forward (-L)

Forward a port on your attack machine to a service on/behind the pivot host.

# Forward local port 8080 to internal host 10.10.10.5 port 80 through pivot
ssh -L 8080:10.10.10.5:80 user@PIVOT_IP

# Then access: http://127.0.0.1:8080

# Forward to a service on the pivot host itself
ssh -L 3306:127.0.0.1:3306 user@PIVOT_IP

# Multiple forwards in one connection
ssh -L 8080:10.10.10.5:80 -L 445:10.10.10.5:445 -L 3389:10.10.10.10:3389 user@PIVOT_IP

# Background the tunnel (no interactive shell)
ssh -L 8080:10.10.10.5:80 -N -f user@PIVOT_IP
# -N = no remote command, -f = background after auth

**Use case:** Access a specific internal service (web app, database, RDP) through the pivot. Simple, reliable, no tools needed.

Dynamic SOCKS Proxy (-D)

Create a SOCKS proxy on your attack machine that routes traffic through the pivot.

# SOCKS5 proxy on local port 1080
ssh -D 1080 user@PIVOT_IP -N -f

# Then use with proxychains
proxychains nmap -sT -sV -p- 10.10.10.5
proxychains cu