Imported from enderphan94/pentest-kit (skills/exploit-scan/SKILL.md). Install upstream with npx skills add enderphan94/pentest-kit --skill exploit-scan. Copyright stays with the author.

Exploit Scan — POC Development & Final Report

Purpose

Transform verified findings and discovered chains into actionable output:

Write POC code for every Critical, High, and chainable finding
Document full attack narratives — entry point through final impact
Compile the Final Report — executive summary, findings, chains

Goal: make every finding actionable. A finding without a POC is just a claim. A finding with working POC code and a clear attack narrative is a defensible assessment.

All POC code is written to local assets/ files only. Nothing is submitted to the target. POC code demonstrates the vulnerability but uses safe payloads (alert boxes, canary strings, localhost callbacks — never destructive payloads).

Scan Progress Checklist

Exploit Development Progress:
- [ ] Step 0:  Load verified findings + chain analysis
- [ ] Step 1:  POC code for Critical findings
- [ ] Step 2:  POC code for High findings
- [ ] Step 3:  POC code for chain attacks
- [ ] Step 4:  Full attack narratives (Mythos method)
- [ ] Step 5:  Remediation roadmap
- [ ] Step 6:  Final report compiled (JSON + Markdown in reports/final/)

Step 0 — Load Inputs

Accept two report paths:

exploit-scan --report reports/report_escalated_*.json --chains reports/report_chains_*.json

If not provided, auto-detect the most recent of each
From escalated report: load all findings (verified + unverified)
From chain report: load all discovered chains
Check OUT_OF_SCOPE_VULNS in scope.txt. If set, exclude any findings and chains whose vulnerability class matches an out-of-scope entry. Do NOT write POCs, narratives, or report sections for excluded vulnerability classes.

Print:

[exploit-scan] Findings: N (X verified, Y unverified)
[exploit-scan] Chains:   N (C Critical, H High, M Medium)
[exploit-scan] POCs to write: <count of Critical + High + all chain components>

Step 1 — POC Code for Critical Findings

For each Critical-severity finding, create assets/poc_<finding_id>.md:

# POC: <Finding Title>

**Finding ID**: <ESC-001>
**Status**: Verified
**Severity**: Critical
**CVSS**: <score> (<vector>)
**Affected URL**: <url>

## Attack Scenario
<Plain-English description: who is the attacker, what do they do, what happens>

## Prerequisites
- <What the attacker needs: unauthenticated / valid account / specific browser / etc.>
- <Network conditions: same network / internet / specific ISP>

## Steps to Reproduce
1. `curl -sI <url>` → observe: <what confirms the issue>
2. <next verification step>
3. <final confirmation>

## POC Code (LOCAL ONLY — NEVER SUBMIT TO TARGET)

### <Language: Python / JavaScript / HTML / Bash>
```<language>
<working proof-of-concept code>
<uses safe payloads: alert(1), canary strings, localhost callbacks>
<includes comments explaining each step>

Expected Result

Impact

Data at risk: <what data is exposed/modifiable>
Users affected: <all users / authenticated users / admin only>
Business consequence: <regulatory, financial, reputational>

Remediation

Priority: Immediate <specific, actionable fix with code examples>


### POC Templates by Vulnerability Class

#### XSS POC
```html
<!-- poc_xss_<id>.html — LOCAL ONLY -->
<!-- Tests if reflected payload executes in browser context -->
<html>
<body>
<h3>XSS POC — Finding <ID></h3>
<p>Open this file locally, then click the link below:</p>
<a href="<affected_url>?<param>=<script>alert('XSS-POC-<ID>')</script>">
  Test XSS Reflection
</a>
<p>If an alert box appears, the vulnerability is confirmed.</p>
</body>
</html>

CORS POC

<!-- poc_cors_<id>.html — LOCAL ONLY -->
<!-- Tests if cross-origin credentialed request succeeds -->
<html>
<body>
<h3>CORS POC — Finding <ID></h3>
<script>
fetch('<affected_url>', {credentials: 'include'})
  .then(r => r.text())
  .then(data => {
    document.getElementById('result').textContent =
      'CORS Exploitable — Response length: ' + data.length;
  })
  .catch(e => {
    document.getElementById('result').textContent = 'Blocked: ' + e;
  });
</script>
<pre id="result">Waiting...</pre>
</body>
</html>

SSRF POC

# poc_ssrf_<id>.py — LOCAL ONLY
# Tests if server-side request can reach attacker-controlled host
import requests

TARGET = "<affected_url>"
PAYLOAD = "http://localhost:8080/ssrf-canary"  # safe local callback
PARAM = "<vulnerable_param>"

resp = requests.get(TARGET, params={PARAM: PAYLOAD}, timeout=10)
print(f"Status: {resp.status_code}")
print(f"Response length: {len(resp.text)}")
# If callback server receives request, SSRF is confirmed

SQLi POC

# poc_sqli_<id>.py — LOCAL ONLY
# Tests error-based SQL injection (identification only — no data extraction)
import requests

TARGET = "<affected_url>"
BASELINE = requests.get(TARGET, params={"<param>": "1"}, timeout=10)
PAYLOAD  = requests.get(TARGET, params={"<param>": "1' AND '1'='1"}, timeout=10)
ERROR    = requests.get(TARGET, params={"<param>": "1' AND '1'='2"}, timeout=10)

print(f"Baseline length: {len(BASELINE.text)}")
print(f"True condition:  {len(PAYLOAD.text)}")
print(f"False condition: {len(ERROR.text)}")
# If True ≈ Baseline and False ≠ Baseline, blind SQLi confirmed

IDOR POC

#!/bin/bash
# poc_idor_<id>.sh — LOCAL ONLY
# Tests if changing object ID returns different user's data
# WARNING: only test with IDs you are authorized to access

BASELINE_ID="<your_own_id>"
TARGET_ID="<adjacent_id>"  # e.g., your_id + 1

echo "=== Your data ==="
curl -s -H "Authorization: <your_token>" "<affected_url>?id=$BASELINE_ID" | head -20

echo "=== Adjacent ID data ==="
curl -s -H "Authorization: <your_token>" "<affected_url>?id=$TARGET_ID" | head -20

# If both return data and the second shows different user info, IDOR confirmed

Step 2 — POC Code for High Findings

Same format as Step 1, applied to all High-severity findings. Adjust POC complexity based on the finding:

Simple findings (missing header, exposed path): shell one-liner POC
Medium findings (CORS, clickjacking, open redirect): HTML POC file
Complex findings (JWT weakness, race condition, SSRF chain): Python script

Step 3 — POC Code for Chain Attacks

For each chain from chain-scan, create assets/poc_chain_<chain_id>.md:

# Chain POC: <Chain Title>

**Chain ID**: CHAIN-001
**Severity**: Critical
**Exploitability**: 4/5
**Findings Involved**: ESC-001 + ESC-007 + ESC-012

## Chain Overview
<One paragraph: what this chain achieves and why it matters>

## Step-by-Step POC

### Step 1: <First vulnerability exploitation>
```<language>
<POC code for step 1 — e.g., extract data via info disclosure>

Expected result: <what data/access this provides>

Step 2: <Use step 1 output to exploit second vulnerability>

<POC code for step 2 — e.g., use leaked data to bypass auth>

Expected result:

Step 3: <Use step 2 access to exploit third vulnerability>

<POC code for step 3 — e.g., use admin access to exfiltrate data>

Expected result:

Combined Impact

Automated Chain Script (LOCAL ONLY)

#!/usr/bin/env python3
# chain_poc_<chain_id>.py — LOCAL ONLY — NEVER RUN AGAINST TARGET
# This script demonstrates the full attack chain in sequence
# All payloads are safe (canary strings, localhost callbacks)

# Step 1: ...
# Step 2: ...
# Step 3: ...


---

## Step 4 — Full Attack Narratives (Mythos Method)

For every **Critical chain** and every **Critical standalone finding**,
write `assets/narrative_<id>.md`:

```markdown
# Attack Narrative: <Title>

**ID**: CHAIN-001 / ESC-001
**Severity**: Critical
**CVSS**: <score>

## 1. Entry Point
How the attacker begins. Be specific:
- Is this unauthenticated? From the internet?
- Does it require phishing? Social engineering?
- Does the attacker need a valid account?

## 2. Reconnaissance
What the attacker learns before the main attack:
- What public information reveals the vulnerability exists
- What error messages / headers / JS files leak useful data
- How the attacker identifies the exact injection point / endpoint

## 3. Exploitation Steps
Numbered steps with exact commands/requests:
1. Attacker sends: `curl -X POST ...` → receives: `<response showing vulnerability>`
2. Attacker extracts: `<specific data from response>`
3. Attacker uses extracted data to: `<next exploitation step>`
4. ...
5. Final step: Attacker achieves `<final impact>`

## 4. Security Controls Bypassed
For each step, what security control is defeated:
| Step | Control Bypassed | Why It Failed |
|------|-----------------|---------------|
| 1 | Input validation | No server-side validation on parameter X |
| 2 | Authentication | JWT alg:none accepted by server |
| 3 | Authorization | No ownership check on resource ID |

## 5. Final Impact
Specific, measurable impact:
- **Data**: N records of type X accessible (PII / credentials / financial)
- **Actions**: What the attacker can DO (modify data, delete accounts, transfer funds)
- **Persistence**: Can the attacker maintain access? (backdoor, persistent XSS, cloud key)
- **Detection**: Would the target know they were compromised?

## 6. Complexity Assessment
- **Overall**: Low / Medium / High
- **Time to exploit**: Minutes / Hours / Days
- **Skill required**: Script kiddie / Intermediate / Advanced
- **Automation potential**: Fully automatable / Partially / Manual only

## 7. Detection Likelihood
- **Logging**: Are the affected endpoints logged? Would the requests look anomalous?
- **WAF/IDS**: Would any payload trigger WAF rules?
- **Monitoring**: Would the data access pattern trigger alerts?
- **Overall**: Low / Medium / High detection risk for the attacker

## 8. Real-World Comparable Incidents
Reference similar real-world breaches or CVEs (if applicable):
- "<Company> suffered a similar breach in <year> via <similar chain>"
- CVE-XXXX-XXXXX demonstrates the same class of vulnerability

Step 5b — Auto-Generate Nuclei Templates

For each verified Critical, High, or Medium finding, generate a Nuclei regression template:

# Batch mode — processes all verified findings from the escalated report
python3 skills/exploit-scan/scripts/nuclei_template_gen.py \
  --batch "$(ls -t reports/report_escalated_*.json | head -1)" \
  --output "templates/custom/"

Validate YAML syntax:

for tpl in templates/custom/*.yaml; do
  python3 -c "import yaml; yaml.safe_load(open('$tpl'))" 2>/dev/null \
    && echo "[OK] $tpl" || echo "[INVALID] $tpl"
done

Run regression scan if nuclei is installed:

if command -v nuclei &>/dev/null; then
  nuclei -t templates/custom/ -u "$TARGET_URL" -H "$AUTH_HEADER" \
    -silent -json \
    -o "reports/nuclei_regression_$(date +%Y%m%d_%H%M%S).json" 2>/dev/null
else
  echo "[skip] nuclei not installed — templates saved to templates/custom/"
  echo "[install] go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest"
fi

Print:

[exploit-scan] Nuclei templates generated: N
  Location: templates/custom/
  Reuse: nuclei -t templates/custom/ -u <TARGET> on future assessments of this target

Step 5 — Final Report

Generate reports/final/FINAL_REPORT_<YYYYMMDD_HHMMSS>.md and reports/final/FINAL_REPORT_<YYYYMMDD_HHMMSS>.json.

Final Report Structure

# Penetration Test Report

**Target**: <target URL/host>
**Assessment Date**: <date range>
**Report Generated**: <timestamp>
**Conducted Using**: HexStrike Pipeline (stress-recon, stress-scan, front-end-scan,
                     escalate-scan, chain-scan, exploit-scan)
**Report Classification**: CONFIDENTIAL

---

## Executive Summary

<2-3 paragraph non-technical summary for management>
- Overall risk rating: Critical / High / Medium / Low
- Number of findings by severity
- Number of attack chains discovered
- Most impactful finding(s) in plain English
---

## Scope
<Target URLs, domains, what was tested and what was excluded>

---

## Methodology
| Phase | Skill | Purpose | Duration |
|-------|-------|---------|----------|
| 1 | stress-recon | Asset discovery & URL pool building | Xs |
| 2 | stress-scan | 7 parallel vulnerability agents | Xs |
| 3 | front-end-scan | Client-side security assessment | Xs |
| 4 | escalate-scan | Finding verification & CVSS scoring | Xs |
| 5 | chain-scan | Multi-vulnerability chain discovery | Xs |
| 6 | exploit-scan | POC development & final reporting | Xs |

---

## Findings Summary

### By Severity
| Severity | Count | Verified | Chained |
|----------|-------|----------|---------|
| Critical | N | N | N |
| High | N | N | N |
| Medium | N | N | N |
| Low | N | N | N |
| Info | N | N | N |

### Findings Table
| ID | Title | Severity | CVSS | Verified | Chain | URL |
|----|-------|----------|------|----------|-------|-----|
| ESC-001 | ... | Critical | 9.8 | ✓ | CHAIN-001 | ... |

---

## Attack Chains

### [CHAIN-001] <Chain Title>
**Severity**: Critical
**Exploitability**: 4/5
**Findings**: ESC-001 + ESC-007

<Attack path diagram>
<Combined impact>
<Link to full narrative: assets/narrative_CHAIN-001.md>
<Link to chain POC: assets/poc_chain_CHAIN-001.md>

---

## Detailed Findings

### [ESC-001] <Finding Title>
**Severity**: Critical
**CVSS**: 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
**Verified**: ✓
**Affected URL**: <url>
**Discovery**: stress-scan Agent 1 (Injection)
**Chain**: Part of CHAIN-001

#### Description
<Technical description>

#### Evidence
<raw curl output / response snippet>

#### Business Impact
<CIA assessment + business consequence>

#### POC
<Link to assets/poc_ESC-001.md — key code snippet inline>

---

## Appendix A — False Positives / Unverified
<findings that could not be verified>

## Appendix B — Out-of-Scope Observations
<notable observations outside scope>

## Appendix C — Unchained Findings
<verified findings not part of any chain>

## Appendix D — Tool & Methodology References
- OWASP Testing Guide v4.2
- OWASP API Security Top 10 (2023)
- CVSS 3.1 Scoring Guide
- HexStrike Methodology

JSON structure

Follow templates/report_schema.json with additional fields:

chains: full chain list from chain-scan
narratives: list of narrative file paths
pocs: list of POC file paths

Completion

=== PIPELINE COMPLETE ===
  Target:      <target>
  Findings:    N total (X verified)
  Chains:      N attack paths discovered
  POCs:        N proof-of-concept files written
  Final report: reports/final/FINAL_REPORT_<timestamp>.md

  This report is confidential and intended only for authorized personnel.
======

Safety Rules (Non-negotiable)

NO execution of POC code against the target — code is written locally only
NO submission of payloads to the target
NO requests to the target — exploit-scan works entirely on findings data
All POC code uses safe payloads: alert(1), canary strings, localhost callbacks
All POC code is clearly labeled "LOCAL ONLY — NEVER SUBMIT TO TARGET"
All files saved to assets/ and reports/final/ only
The final report must include: "This report is confidential and intended only for authorized personnel"

exploit-scan

About