duriandurino/exploit-phase-essentials

Exploitation Phase Essentials

Use this skill to make exploitation controlled, evidence-backed, and operationally disciplined. This is a methodology layer for the exploitation phase, not a replacement for concrete exploit tooling.

When to Use

✅ USE this skill when:

• "Which exploit path has the best chance of working?"
• "How do I confirm this safely before exploiting?"
• "Why did this exploit fail?"
• "How should I structure the exploitation phase?"
• "How do I minimize blast radius during impact validation?"
• "How should I use KEV/EPSS/CVSS and exploit reliability here?"
• A sub-agent needs stronger exploitation-phase discipline before acting

When NOT to Use

❌ DON'T use this skill when:

• Still discovering services or ports → use enum
• Still proving applicability / CVE matching → use vuln
• Doing post-access work after access is established → use post
• Teaching whole-pentest basics → use pentest-essentials
• Writing the final report only → use reporting
• Running the concrete exploit actions without methodology framing → use exploit

Core Rules

1. Exploitation confirms, it does not guess

   • Start from validated findings and explicit exploit preconditions.
   • Do not run exploit candidates just because a public PoC exists.

2. Preconditions dominate reliability

   • Match exact version/build/config/auth/topology requirements.
   • Most exploit failures come from mismatched assumptions.

3. Use the least risky proof that proves the point

   • Prefer passive or safe active validation where possible.
   • If impact is already decisively shown, do not over-escalate.

4. Reliability beats theatrics

   • Prefer stable, controlled, high-confidence methods over flashy or fragile ones.
   • Production-like sensitivity should push you toward lower-crash, lower-side-effect paths.

5. Evidence and cleanup are part of exploitation

   • Capture what changed, what proved impact, and how to restore state.
   • Cleanup means restoring agreed state, not hiding activity.

Workflow

Follow this order:

1. confirm ROE, timing window, stop conditions, and rollback path
2. consolidate candidate findings from vuln phase
3. derive explicit exploit preconditions
4. choose the lowest-risk validation method that can prove the claim
5. execute controlled exploitation only when justified
6. demonstrate impact with minimal side effects
7. capture evidence, cleanup, and residual risk notes
8. hand off to post-exploitation or reporting clearly

Exploit Candidate Record

Before acting, normalize each candidate into:

Asset
Service / interface
Fingerprint confidence
Suspected vulnerability
Required version / build range
Required config conditions
Auth boundary
Exploit candidate family
Reliability expectation
Blast radius expectation
Validation plan
Rollback / stop condition

Validation Ladder

Use the smallest sufficient step:

Level 1 — Fingerprint / version only

Use for triage only.

Level 2 — Config + version correlation

Use vendor advisories / NVD / known requirements to tighten confidence.

Level 3 — Safe active validation

Use a minimal, non-destructive behavior check that proves the vulnerable condition.

Level 4 — Controlled exploitation

Use when business or engagement goals require direct proof of impact and ROE allows it.

Level 5 — Production exploitation

Use only when explicitly authorized, time-boxed, monitored, and rollback-ready.

Selection Criteria

Score candidates on:

• Match — does the environment match the exploit requirements?
• Reliability — how stable is the exploit path likely to be?
• Maturity — is there real-world evidence or high exploit likelihood?
• Blast radius — what can go wrong operationally if this misfires?

Rule of thumb:

• high match + high reliability + manageable blast radius = best next candidate

Reliability and Prioritization Inputs

Use these signals together:

• CVSS → technical severity context
• EPSS → near-term exploitation likelihood
• KEV / known exploitation evidence → urgency signal
• exploit-framework reliability / maturity cues → practical execution confidence
• business criticality → whether the risk is worth the operational cost

Do not use any of these as blind permission to exploit.

Failure Analysis

When an exploit fails, check:

• wrong version or backported fix
• missing required config/feature toggle
• different auth state or privilege boundary
• network path or reachability mismatch
• protocol mismatch visible in packet traces
• exploit assumptions that do not match the target topology

Use instrumentation first:

# Example validation aids
nmap -sV <target>
# packet capture / protocol observation as permitted

Stability Principles

Use these guardrails:

• prefer higher-reliability exploit classes when possible
• avoid memory-corruption style approaches if a safer proof exists
• stop immediately on instability indicators
• keep rollback and notification path ready before action
• record any tester-introduced artifacts for later cleanup

Evidence Standards

Capture:

Why the exploit candidate was chosen
What preconditions were confirmed
Exact validation or exploit method used
Timestamped evidence of impact
Observed side effects
Artifacts introduced by the tester
Cleanup / rollback actions taken
Residual risk after test completion

Cleanup Rules

Ethical cleanup means:

• remove temporary accounts/files/tools you introduced if agreed
• restore the environment to agreed state where feasible
• preserve reporting evidence and timestamps
• never hide activity or tamper with logs to erase visibility

Report-Ready Exploit Output

Your exploit handoff should include:

Exploit candidate chosen
Reason for selection
Preconditions confirmed
Validation level used
Result: success / failed / partial
Impact demonstrated
Operational side effects observed
Cleanup performed
Residual risk
Recommended next step

Anti-Patterns

Avoid:

• treating public exploit availability as permission
• exploiting before verifying preconditions
• choosing fragile/high-crash techniques when safer validation exists
• assuming CVSS alone means “exploit now”
• running payloads without rollback/stop conditions
• calling cleanup "covering tracks"

Sub-Agent Guidance

When a pentest sub-agent uses this skill, it should:

• work from validated findings, not loose scanner output
• document preconditions before acting
• justify exploit candidate choice explicitly
• prefer safe proof over maximal impact
• capture evidence and cleanup notes as part of the same workflow

References

Load on demand:

• references/examples.md — trigger phrases and expected use
• references/validation-ladder.md — safest-to-strongest validation model
• references/candidate-record.md — exploit candidate record template
• references/evidence-checklist.md — minimum exploit-phase evidence and cleanup checklist