Discover pivot interfaces, routes and internal service context

Needs: A usable pivot process/identity and explicit scope; both forward and return directions must be understood

Client commands / example output

# Baseline
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

Linux

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

Windows

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

PowerShell selected endpoints

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

Shell commands

An interface or route proves a possible network position, not destination reachability. Validate one justified socket from the pivot before building a tunnel.

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

PowerShell commands

# Baseline
Test-NetConnection INTERNAL_HOST -Port INTERNAL_PORT

Kali/Linux

Need Baseline Choose when Main limitation
One TCP service through an SSH pivot SSH local forward Kali can initiate SSH to pivot One destination socket per forward
Many TCP destinations through SSH pivot SSH dynamic forward Kali can initiate SSH to pivot SOCKS/client compatibility
Pivot can connect outward but inbound access is blocked SSH remote or remote-dynamic forward Pivot has OpenSSH client and can reach Kali SSH Kali SSH policy; OpenSSH version for remote dynamic
SSH hop directly to internal SSH ProxyJump Both pivot and destination provide SSH SSH-only path
Simple Linux TCP relay Socat Binary already exists and listener can be exposed Clear TCP relay; no authentication/encryption
Transparent selected subnets through SSH sshuttle Suitable SSH server with Python; local privileges TCP/DNS-oriented, local firewall changes
Windows SSH-based forward Built-in ssh.exe or Plink Compatible client exists and outbound SSH works Server policy and credential/host-key handling
Windows native fixed TCP relay netsh interface portproxy Elevated token; target modification acceptable TCP only; firewall/IP Helper/stateful cleanup
Outbound HTTP/WebSocket-shaped tunnel Chisel Pivot can run matching binary and reach server Client/server compatibility and proxy/client transport limits
Routed access for ordinary clients Ligolo-ng Agent can reach proxy and TUN/route setup is possible Userland stack is not identical to direct raw networking
DNS is the only viable egress dnscat2 DNS path plus authoritative/direct server control Slow/noisy, infrastructure and client required

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

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

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. More detail ↓

If → then

One reachable pivot can connect to one internal TCP destination → Relay a single TCP service through a fixed forward
Needs: A bindable pivot listener, source-to-listener access and pivot-to-destination connectivity
SSH reaches a server that can access the needed internal service → Forward a selected service through an SSH client-side listener
Needs: Accepted SSH identity and forwarding policy; local listener availability and SSH-server-to-destination route
A pivot can make outbound HTTP/WebSocket connections to the tunnel server → Use a reverse Chisel SOCKS or fixed TCP tunnel
Needs: Compatible reviewed client/server, server reverse mode, reachable server port and pivot-to-destination access
Several protocols/subnets require a route-style interface through an agent → Route a selected internal subnet through Ligolo-ng
Needs: Compatible proxy/agent, permitted local interface/route management, reachable carrier and selected assigned subnet
Only the pivot can initiate SSH, but several client-selected internal destinations are needed → Expose a server-side SOCKS proxy through remote dynamic SSH forwarding
Needs: A supporting OpenSSH client, allowed remote forwarding, listener binding and SOCKS-compatible tool clients
Multiple internal TCP destinations need transparent application access over SSH → Route a selected subnet through sshuttle
Needs: Working SSH/Python environment, local routing/firewall privileges and explicitly selected supported traffic/subnets
The pivot is Windows and available networking utilities constrain the route → Forward from Windows with OpenSSH, Plink or Netsh
Needs: Compatible OpenSSH/Plink authentication or administrative Netsh/IP Helper context; correct listener and destination paths
The assessment-side client can reach a pivot-side tunnel server → Use forward Chisel SOCKS and version-supported UDP routing
Needs: Compatible client/server roles, reachable carrier, correctly placed SOCKS listener and explicitly supported UDP-aware mode when required
A second internal network is reachable only from a later foothold → Compose multiple pivots and validate every connection leg
Needs: A working first route, explicit second carrier/listener directions and correct per-hop DNS/return paths

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Discover pivot interfaces, routes and internal service context

USE WHEN: A foothold exposes an interface/subnet or a loopback-only service
STARTING ACCESS: A pivot identity/process or reachable SSH service and a drawn source-to-destination path
RESULT: A route diagram identifying listener, initiator, pivot destination and protocol

Recognize the clue

On the foothold inspect interfaces/routes and local listeners, then test an explicitly assigned destination from that host.

ip addr
ip route
ss -lntup

SYNTHETIC EXAMPLE OUTPUT

INTERFACE_A: current network
INTERFACE_B: assigned internal network
Listener: 127.0.0.1:PORT

Means: A second network or loopback listener supplies a new vantage candidate; forwarding is not automatically enabled.

Confirm: Read interfaces/routes/listeners on the pivot and probe the internal destination from that host. Draw both legs and the initiator; only choose SSH/SOCKS/Ligolo after the destination leg works.

After validation: The pivot reaches the needed endpoint and a supported tunnel can carry the client: choose that route.
Ruled out in this context: The new subnet is outside assigned scope: do not use it as an attack route.
Still inconclusive: Interface/route presence alone does not prove destination/firewall access.

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

Record:

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

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

Linux:

Windows:

PowerShell selected endpoints:

An interface or route proves a possible network position, not destination reachability. Validate one justified socket from the pivot before building a tunnel.

Need	Baseline	Choose when	Main limitation
One TCP service through an SSH pivot	SSH local forward	Kali can initiate SSH to pivot	One destination socket per forward
Many TCP destinations through SSH pivot	SSH dynamic forward	Kali can initiate SSH to pivot	SOCKS/client compatibility
Pivot can connect outward but inbound access is blocked	SSH remote or remote-dynamic forward	Pivot has OpenSSH client and can reach Kali SSH	Kali SSH policy; OpenSSH version for remote dynamic
SSH hop directly to internal SSH	`ProxyJump`	Both pivot and destination provide SSH	SSH-only path
Simple Linux TCP relay	Socat	Binary already exists and listener can be exposed	Clear TCP relay; no authentication/encryption
Transparent selected subnets through SSH	sshuttle	Suitable SSH server with Python; local privileges	TCP/DNS-oriented, local firewall changes
Windows SSH-based forward	Built-in `ssh.exe` or Plink	Compatible client exists and outbound SSH works	Server policy and credential/host-key handling
Windows native fixed TCP relay	`netsh interface portproxy`	Elevated token; target modification acceptable	TCP only; firewall/IP Helper/stateful cleanup
Outbound HTTP/WebSocket-shaped tunnel	Chisel	Pivot can run matching binary and reach server	Client/server compatibility and proxy/client transport limits
Routed access for ordinary clients	Ligolo-ng	Agent can reach proxy and TUN/route setup is possible	Userland stack is not identical to direct raw networking
DNS is the only viable egress	dnscat2	DNS path plus authoritative/direct server control	Slow/noisy, infrastructure and client required

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:

Windows:

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.

Why it works

A dual-homed host can connect networks without forwarding packets for arbitrary clients. Select fixed forward, application proxy or routed tunnel according to the required protocol and permissions.

Worked example · hypothetical

Observation: a foothold can reach an internal service absent from Kali's route. Test: verify the destination from that host and draw the connection direction. Illustrative output: the pivot reaches TCP/445. Interpretation: choose the smallest compatible route for the intended client.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗