exploit-chain-building

name	exploit-chain-building
description	Escalate confirmed low/medium findings into high-impact exploit chains (A→B→C) with combined CVSS scoring
license	MIT
metadata	{"category":"web-security","locale":"en","phase":"v1"}

What this skill does

Guides a security researcher from a confirmed low or medium severity finding through a structured escalation process to discover multi-step exploit chains that demonstrate significantly higher impact. Uses a chain table of known A→B→C escalation paths, tests each link in the chain for exploitability, and produces a combined CVSS score and step-by-step proof-of-concept that reflects the full chain impact rather than individual finding severity.

When to use

• When a confirmed finding is rated Low or Medium but feels like it could enable more
• When a bug bounty report needs to demonstrate maximum impact to justify a higher payout
• During a penetration test to escalate a foothold into a more significant compromise
• When triage shows multiple low-severity findings that may combine into a critical chain
• Before finalizing a report — to check whether any finding enables a higher-impact chain

Prerequisites

• At least one confirmed, reproducible finding as a starting point
• curl installed for HTTP-based chain verification
• Burp Suite or equivalent HTTP proxy (recommended for interactive chain testing)
• Access to the target application with a test account
• Written authorization for all testing activities

Inputs

Variable	Required	Description
SECSKILL_INITIAL_FINDING	required	Description of the confirmed starting vulnerability (e.g. Self-XSS in profile bio field)
SECSKILL_TARGET_URL	required	Base URL of the target application
SECSKILL_AUTH_TOKEN	optional	Session cookie or Bearer token for the test account
SECSKILL_OUTPUT_DIR	optional	Directory to save chain evidence (default: ./output)

Workflow

Step 1: Confirm the initial finding

Before attempting escalation, verify the starting vulnerability is reliably reproducible. Document the exact steps, request, and response.

export TARGET="${SECSKILL_TARGET_URL:?Set SECSKILL_TARGET_URL}"
export FINDING="${SECSKILL_INITIAL_FINDING:?Set SECSKILL_INITIAL_FINDING}"
export OUTDIR="${SECSKILL_OUTPUT_DIR:-./output}"
export AUTH="${SECSKILL_AUTH_TOKEN:-}"
mkdir -p "$OUTDIR"

echo "[*] Starting finding: $FINDING"
echo "[*] Target: $TARGET"
echo "[*] Reproduce the finding and save evidence to: $OUTDIR/step1_initial_finding.txt"

Document the initial finding:

## Initial Finding

- **Vulnerability**: <type and location>
- **Severity (standalone)**: Low / Medium
- **Reproduction steps**: <numbered steps>
- **Request**: <HTTP request>
- **Response / Evidence**: <what proves it works>
- **What it enables**: <primitive unlocked — e.g. "execute JS in victim's browser context if they click a crafted link">

Step 2: Consult the chain escalation table

Use the table below to identify candidate escalation paths from the initial finding. Identify which B (second link) the initial finding enables, then which C (end goal) is reachable from B.

Reference: See REFERENCE.md for the full chain escalation table (15 rows covering Self-XSS, SSRF, IDOR, Open Redirect, Race Condition, SSTI, XSS, Subdomain Takeover, Deserialization, Path Traversal, CSRF, SQLi, XXE, and more).

Step 3: Test the second link (A → B)

For the identified escalation path, test whether the primitive from the initial finding (A) reliably enables the second link (B).

echo "[*] Testing chain link A → B"
echo "[*] Chain: $FINDING → <B>"
echo "[*] Save evidence to: $OUTDIR/step3_link_ab_evidence.txt"

Reference: See REFERENCE.md for fully worked chain demonstrations (Self-XSS→CSRF→Stored XSS and SSRF→Cloud Metadata→AWS Credential Extraction).

Step 4: Test the third link (B → C)

With B confirmed, test whether it reliably enables the end goal C.

echo "[*] Testing chain link B → C"
echo "[*] B achieved: <describe B primitive>"
echo "[*] Target end goal: <C>"
echo "[*] Save evidence to: $OUTDIR/step4_link_bc_evidence.txt"

Reference: See REFERENCE.md for worked B→C demonstrations (Cloud Creds→RCE via AWS SSM, OAuth Token Theft via Open Redirect).

Step 5: Verify end-to-end exploitability

Execute the full chain from A to C in a single demonstration, documenting each step with concrete evidence.

echo "[*] Full chain verification: A → B → C"
echo "[*] Document each step with HTTP requests, responses, and screenshots"

cat > "$OUTDIR/chain_poc_steps.md" << 'EOF'
## End-to-End Chain PoC

### Chain: <A> → <B> → <C>

**Step 1 (A)**: <reproduce initial finding>
- Request: <HTTP request>
- Evidence: <response / screenshot>

**Step 2 (B)**: <demonstrate B is achieved>
- Action taken: <what was done with A's primitive>
- Evidence: <what confirms B succeeded>

**Step 3 (C)**: <demonstrate end goal achieved>
- Action taken: <what was done with B's primitive>
- Evidence: <what confirms C — e.g. admin account taken over, data exfiltrated, RCE confirmed>

**Impact**: <who is affected, what data or access is at risk, what is the blast radius>
EOF

echo "[*] Fill in chain_poc_steps.md with actual evidence"

Step 6: Calculate combined CVSS and report the chain

A vulnerability chain should be reported as a single finding with the severity reflecting the end-goal impact, not the initial finding's standalone severity.

echo "[*] Assessing combined chain severity"

cat > "$OUTDIR/chain_report.md" << 'EOF'
## Exploit Chain Report

### Chain Summary

| Property | Value |
|----------|-------|
| Chain | <A> → <B> → <C> |
| Initial finding severity (standalone) | Low / Medium |
| Chain severity (combined) | Critical / High |
| Prerequisites | Attacker must be: <authenticated / unauthenticated / on same network / etc.> |
| User interaction required | Yes (victim must click a link) / No |
| Blast radius | <how many users/accounts/records affected> |

### Combined CVSS v3.1 Vector

Reassess against the end-goal impact:
- **Attack Vector**: Network
- **Attack Complexity**: Low (if chain is reliable) / High (if chain requires specific conditions)
- **Privileges Required**: None / Low / High
- **User Interaction**: None / Required
- **Scope**: Unchanged / Changed
- **Confidentiality Impact**: None / Low / High
- **Integrity Impact**: None / Low / High
- **Availability Impact**: None / Low / High

**CVSS Score**: <recalculate using https://www.first.org/cvss/calculator/3.1>

### Why This Chain Matters

<Explain why Low+Low or Medium+Medium = Critical when combined. Describe the realistic attack scenario, attacker motivation, and business impact.>

### Remediation

Address the weakest link in the chain — the one that is cheapest to fix:
1. **Fix A** (<initial finding remediation>) — breaks the chain at the first link
2. **Fix B** (defense in depth) — independent mitigation if A is not fixed immediately
3. **Fix C** (defense in depth) — damage limitation if both A and B are exploited

### References

- Initial finding report: <link or file>
- PoC evidence: <$OUTDIR/chain_poc_steps.md>
EOF

echo "[*] Chain report saved to: $OUTDIR/chain_report.md"

Done when

• The initial finding is confirmed reproducible with documented evidence
• An escalation path has been identified using the chain table
• Each link in the chain (A→B and B→C) has been individually confirmed exploitable
• The full end-to-end chain is reproducible in a single demonstration
• A combined CVSS score reflecting the chain's end-goal impact has been calculated
• The chain report includes step-by-step PoC, impact statement, and remediation priorities

Failure modes

Symptom	Cause	Resolution
B link fails — CSRF blocked by SameSite cookie	Cookie has SameSite=Strict or Lax	Test cross-site subresource requests; check if older browsers or non-cookie auth tokens are affected; try CORS misconfiguration as an alternative delivery
B link fails — open redirect blocked by allowlist	Redirect target validated	Test for parameter pollution, path traversal in redirect URL, or URL parser inconsistencies
SSRF reaches metadata but credentials are empty	IMDSv2 enforced (requires PUT token first)	Attempt IMDSv2 flow: PUT to /latest/api/token with X-aws-ec2-metadata-token-ttl-seconds: 21600, then use token in GET requests
C link fails — credentials obtained but insufficient permissions	IAM role has limited permissions	Enumerate accessible services with aws iam get-role-policy; document partial access as chain still demonstrates credential exfiltration
No chain path found in the table	Unusual initial finding type	Manually reason: what does this finding give the attacker? (read access, redirect, execution) — then search for targets that accept that primitive as input
Chain requires unlikely user interaction	Victim must perform a very specific action	Document as a realistic phishing scenario; include a convincing social engineering context to demonstrate feasibility

Notes

• Report the chain as a single finding at the highest-achievable severity, not as multiple low-severity items. Bug bounty programs and security teams respond to demonstrated impact, not theoretical escalation.
• The weakest link in the chain is the most cost-effective fix — identify and highlight it explicitly in the report.
• A Low + Low + Low chain that results in unauthenticated account takeover is a Critical. Severity must reflect the end state, not the individual steps.
• When demonstrating chains involving CSRF, always include the SameSite cookie attribute status of the target — it is the most common reason CSRF chains fail in modern browsers.
• For OAuth token theft chains via open redirect, verify whether the authorization server validates redirect_uri strictly or only checks prefix matching — prefix matching (e.g. startsWith) is a common bypass.
• Document all chain testing steps with timestamped HTTP request/response captures so the chain can be independently reproduced by a triage team.