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

Target-side route checks where available

# Target-side route checks where available
nc -vz LHOST LPORT
curl -v --connect-timeout 5 http://LHOST:LPORT/

PowerShell commands

# Baseline
Test-NetConnection LHOST -Port LPORT -InformationLevel Detailed

Observe Kali while triggering

# Observe Kali while triggering
sudo tcpdump -ni any tcp port LPORT

Reproduce a harmless direct command in the exact vulnerable or user context.

Confirm file/request integrity, final path and consumer.

Identify every parser, interpreter and loader.

Match target OS, process architecture, artifact format and runtime dependencies.

Verify permissions, working directory, execution policy and application-control evidence.

Start the correct listener/handler and prove its bind.

Prove the target-to-listener route separately.

Inspect concrete antimalware, application-control and process-failure evidence.

Repair session I/O only after a connection exists.

A. Document delivered, no callback

# A. Document delivered, no callback
Observed: document exists
Unknown: opened, macro permitted, child command, network route
Test: MOTW/policy → harmless marker → child process/download → callback route
Action: repair first failed gate; do not regenerate the payload first

# B. Executable disappears after transfer
Observed: transfer response succeeded
Test: destination listing/hash → Defender detection/resource/event
Interpretation: transfer success is not retention; quarantine requires evidence
Action: choose a justified alternate execution form or native route, within scope

# C. PowerShell says scripts are disabled
Observed: explicit execution-policy error
Test: Get-ExecutionPolicy -List and GPO precedence
Action: use a process-scoped invocation if allowed; do not call this an AMSI result

# D. Connection reaches Netcat but there is no shell
Observed: TCP connection
Test: generated payload name
Interpretation: staged payload may have reached a raw listener
Action: use exact multi/handler or generate a compatible stageless command shell

# E. Binary exists but returns “not found” on Linux
Observed: path and file exist
Test: file, readelf interpreter, ldd, shebang
Interpretation: loader/interpreter dependency may be missing
Action: build/choose a compatible artifact; do not change callback settings

# F. Metasploit module reports completion, no session
Observed: module ran
Test: exact target profile, payload, callback route, handler output and service state
Interpretation: completion is not verified execution/session
Action: preserve module output and diagnose the first missing state

# F. Metasploit module reports completion, no session
artifact/request
→ delivered to intended consumer
→ required user/trigger action
→ parser/interpreter/loader
→ process or bounded side effect
→ network connection
→ handler protocol
→ usable session

Boundary Decisive evidence Does not prove
Delivery Expected bytes, request, document or shortcut arrives intact It was opened or parsed
Trigger Intended user/service/parser consumed it Child process started
Execution Harmless marker, process or command output Callback route works
Connection Expected peer reaches listener Payload and handler agree
Session Commands return; host and identity verified Stability or privilege

Verify → Use command proof, packet evidence and actual channel behavior to identify the first failed boundary.

If it fails → A timeout alone is inconclusive. Return to the original trigger if execution is unproved; use handler/TTY repair only after the prior state is confirmed. More detail ↓

If → then

A pivoted exploit reaches its target but its shell/download cannot return → 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 payload connects without a session, or a handler/session exits unexpectedly → Pair staged payloads with the correct handler and session lifecycle
Needs: Exact payload/architecture/transport pairing, correct listener binding, reachable staging path and suitable job/session configuration
A working shell lacks job control, terminal signals or interactive program support → Repair a limited Linux terminal
Needs: A working channel and available PTY mechanism; correct local-terminal control sequence

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

Explanation & examples

Diagnose connection direction, listener and session failures in order

USE WHEN: Command execution or payload delivery exists but the expected usable channel does not
STARTING ACCESS: A recorded delivery/execution chain with the expected consumer and effect
RESULT: The first failed delivery/execution/transport/session boundary and a targeted next test

Recognize the clue

Return to the last observed execution proof, inspect listener bind/address and compare actual packet arrival with the expected direction.

ss -lnt
ip route get TARGET
sudo tcpdump -ni INTERFACE tcp port PORT

SYNTHETIC EXAMPLE OUTPUT

Execution proof: confirmed
Listener: bound on EXPECTED_PORT
Packet observation: no target SYN

Means: The channel failed before an observed connection; investigate trigger/advertised route/egress before terminal repair.

Confirm: Name the process initiating the connection and its actual destination address/port. Check the listener bind and each route/pivot leg; if delivery works but no callback arrives, repair the return path before changing payload bytes.

After validation: The correct packet/session path works and identity is verified: use the resulting channel.
Ruled out in this context: The advertised address is unreachable and not forwarded: reject that callback topology.
Still inconclusive: No packets without prior execution proof cannot distinguish a failed trigger from network failure.

Troubleshooting: A timeout alone is inconclusive. Return to the original trigger if execution is unproved; use handler/TTY repair only after the prior state is confirmed.

Delivery: prove the request/file/argument reaches the intended consumer.
Execution: prove id/whoami, hostname or a bounded side effect in the exact context.
Parser: verify quoting, encoding, interpreter, working directory and length.
Payload: confirm OS, architecture, format, staged/stageless type and dependencies.
Listener: start it first and verify the bound address and port.
Route: test target-to-listener reachability from the execution context.
Security control: use concrete errors, quarantine, logs or process behavior.
Session: repair TTY, buffering, encoding and job control after connection.

Target-side route checks where available:

Observe Kali while triggering:

Interpretation:

Observation	Next decision
No SYN reaches Kali	Wrong execution, LHOST, route, egress or earlier parser layer
SYN arrives; no listener response	Wrong bind/interface/port or local firewall
TCP handshake then immediate close	Payload/handler mismatch, crash or security control
Connection stays but no commands	Staged/raw mismatch, buffering or I/O/session issue

Reproduce a harmless direct command in the exact vulnerable or user context.
Confirm file/request integrity, final path and consumer.
Identify every parser, interpreter and loader.
Match target OS, process architecture, artifact format and runtime dependencies.
Verify permissions, working directory, execution policy and application-control evidence.
Start the correct listener/handler and prove its bind.
Prove the target-to-listener route separately.
Inspect concrete antimalware, application-control and process-failure evidence.
Repair session I/O only after a connection exists.

If step 1 fails, this is not yet a payload problem. Return to the exploit, input parser or execution primitive.

A. Document delivered, no callback

B. Executable disappears after transfer

C. PowerShell says scripts are disabled

D. Connection reaches Netcat but there is no shell

E. Binary exists but returns “not found” on Linux

F. Metasploit module reports completion, no session

Boundary	Decisive evidence	Does not prove
Delivery	Expected bytes, request, document or shortcut arrives intact	It was opened or parsed
Trigger	Intended user/service/parser consumed it	Child process started
Execution	Harmless marker, process or command output	Callback route works
Connection	Expected peer reaches listener	Payload and handler agree
Session	Commands return; host and identity verified	Stability or privilege

Do not replace the artifact, payload, listener and route simultaneously. Record the last confirmed boundary and test the next one.

Why it works

No packets, rejected packets, accepted connection and unstable shell are different states. Reverse callbacks and target downloads need routes independent of the initiating exploit.

Worked example · hypothetical

Observation: the payload executes but no SYN reaches the listener. Test: check advertised address and target route before changing handlers. Illustrative output: the callback uses a non-routed Kali interface. Interpretation: provide the reachable address/forward and retest the same verified primitive.

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

Study guide ↗Full procedure ↗Cheatsheet ↗