Exploit Chain

---
name: exploit-chain
description: Exploit-chain assembly methodology — combining multiple medium-impact findings into one high-impact path (Open Redirect + OAuth = ATO, SSRF + cloud-metadata = creds, IDOR + privilege escalation, prototype pollution + downstream gadget). Pattern-level, with chain-aware CVSS scoring and MITRE ATT&CK mapping.
---

# Exploit Chain Composer

> **Scope-only**: chains are written at pattern level, not as ready-to-run exploit sequences against specific production versions. PoC execution belongs in a lab or in a customer-provided sandbox, with explicit RoE sign-off per step. A smoothly working chain has great demo value and equally real damage potential if played outside scope.

## When to use

Many pentest reports are lists of unrelated mediums. The value often sits in the chain: bug A on its own is medium, chained with B it becomes a blocker. This skill helps make those paths explicit.

Triggers on:

- A question like "can we chain these three findings", "what is the worst path through this system", "is open-redirect plus OAuth account takeover", "how do I score a chain in CVSS".
- A reporting phase where individual findings have already been triaged via `web-exploit-triage` and you want to see which are combinable.
- Bug-bounty submissions that are only relevant as a chain (a stand-alone self-XSS has no value, but self-XSS + open redirect + OAuth flow has potential ATO).
- Red-team engagement where chain-thinking is the entire methodology.
- A defensive exercise: showing a dev team why their "only low findings" still adds up to critical.

### When NOT (handoff)

- Per-finding class triage → `web-exploit-triage`. This skill leans on that output, it does not repeat it.
- Concrete payload construction within a single class → `payload-crafter`.
- Post-exploitation activity after the first foothold → `post-exploit`.
- Final report with CVSS vector and remediation → `pentest-reporter`. This skill produces chain rationale; that one builds the report.
- Reconnaissance input → `recon-agent`.
- AD-specific chains (Kerberos delegation + DCSync, etc.) → `ad-attacks`.
- Threat model at design level (preventive) → `threat-modeler`. An attack tree there is conceptually related but for the design phase; this skill is for the post-finding phase.

## Approach

Seven phases. Phase 2 (adjacency) is the creative core; phases 3–4 are the discipline that keeps the chain from being overstated.

### 1. Component-finding inventory

Before you start chaining, inventory what you have.

- **Per finding**: ID, class, location, auth context, impact on its own. Output of `web-exploit-triage`.
- **Per finding context**: who can reach it (anonymous / authenticated / specific role), which data does it touch, which privilege boundary does it touch.
- **Inventory format**: a table where you can place two findings next to each other and compare them horizontally.
- **Inclusion criterion**: only findings within RoE scope. "Just to see if we can pivot via this other application" is a scope violation.

The inventory is not a value judgment; informationals belong here too. A chain often turns out to be "Information Disclosure (low) + Username Enumeration (low) + Password Reset Flow (medium)" → "Account Takeover (high)" — three lows suddenly become a blocker.

### 2. Adjacency analysis: which findings are chainable

Two findings are chainable when the **output** of one can be used as **input** for the other.

A question row to walk through for each pair:

- Does finding A produce something (data, session, movement, privilege) that finding B needs?
- Does finding A lower a precondition of finding B (auth requirement, rate-limit countermeasure, observability)?
- Does finding A precede finding B in time or trust chain (e.g. domain takeover for cookie scope, then session fixation)?
- Are they caused by the same root cause (e.g. missing centralized auth check) so that fixing one impacts both?

**Common chain patterns** (class level, not per organization):

- **Open Redirect → OAuth Account Takeover**. Open redirect on a trusted domain + OAuth flow with non-strict redirect-URI matching = stealing the auth code/token via a redirect hop.
- **SSRF → Cloud Metadata → Cred leak**. SSRF that does not block DNS resolution to `169.254.169.254` (AWS) or `metadata.google.internal` (GCP) = IAM temporary-credentials extraction.
- **Subdomain Takeover → Cookie Scope → Session Hijack**. Abandoned subdomain under cookie scope (`*.example.com`) = attacker serves content on behalf of the trusted domain, reads session cookies.
- **Stored Self-XSS + CSRF + Admin functionality → Admin Compromise**. Self-XSS by itself unusable, plus CSRF on an endpoint that shows admin data, plus an admin who visits the poisoned page = XSS in admin context.
- **IDOR + Vertical Privilege Escalation**. IDOR on a user resource + role-assignment endpoint without an authZ check = lateral + vertical.
- **Prototype Pollution + Downstream Gadget → RCE**. Pollution by itself is data tampering; a downstream library that reads the polluted property in a sink (e.g. spawn with polluted defaults) = RCE class.
- **Cache Poisoning + XSS via header**. Unkeyed-input cache poisoning + header-reflection XSS = persistent XSS for all visitors.
- **Race Condition + State Transition** in financial flows. Atomic-step bypass + double-spend.

The list is not exhaustive; use it as a brainstorm prompt, not as a checklist.

### 3. Pattern-level chain construction

Write the chain out as stylized steps, not as an execute-sequence.

Format per chain:

- **Goal**: what the chain is trying to achieve (account takeover, RCE, mass data exfil, persistence).
- **Prerequisites**: which conditions are needed up front (anonymous attack possible? specific browser version? specific time window?).
- **Steps**: numbered pattern steps, each with (a) the finding ID used, (b) what you put in, (c) what you get back.
- **Disqualifiers**: what breaks this chain. Compensating controls, framework defaults, patched versions. Document here why you do not consider the chain trivial.

Pattern level means: "Step 2 sends an SSRF payload to an endpoint that performs outbound HTTP and retrieves cloud-metadata credentials" — not the exact working `gopher://` URL for target X version Y.

### 4. Feasibility and impact assessment

A chained path on paper is not the same as a verified attack route. Score each pair on:

- **Feasibility (0–3)**: 0 = theoretical but disqualifiers in production, 1 = likely feasible but untested, 2 = pattern-level verified in lab/sandbox, 3 = end-to-end validated within the RoE.
- **Stealth**: does the chain leave detectable signals? Which logs would a blue team see?
- **Impact on success**: what does the attacker actually obtain (data, persistence, privilege).

Chain-aware CVSS via the FIRST calculator: usually Attack Complexity (AC), Privileges Required (PR), and Scope (S) shift. A chain that is anonymous pre-auth and ends at S:C / C:H / I:H is a blocker. Document the vector.

### 5. PoC discipline and lab development

If a PoC is needed:

- **Lab-only**: containerized lab with the same framework versions, or a customer-provided sandbox. No experiments on production without an RoE clause covering it.
- **Reproducible**: setup documented so the dev team can repeat it after the fix. A chain that only works under unexplainable conditions is not finding-quality evidence.
- **Redaction**: if you use real data fragments (even in the lab), redact them in screenshots/exports before delivery.
- **Cleanup**: chains that create state (test accounts, audit events) need a clean-up step in the PoC doc.

### 6. Documentation and handoff

Per chain:

- **Name**: short, non-cryptic identifier (e.g. "ATO via redirect+OAuth").
- **Components**: link to underlying finding IDs (from `web-exploit-triage` output).
- **Description**: 2–3 sentences for execs, technical detail in the steps.
- **Defense side**: which control(s) would cut the chain — input for the `pentest-reporter` remediation roadmap.
- **Detection opportunity**: which log event at which layer could have caught the chain — handoff to `detection-engineer` (blue bundle) and `purple-ops`.
- **MITRE ATT&CK mapping** where relevant: T-IDs per step, tactical progression visible.

### 7. Verification-loop

Layer 1: scope (chain stays within RoE? no "we could pivot via Y" if Y is out of scope?), assumptions (feasibility score grounded or optimistic?), gaps (compensating controls explicitly considered, not omitted out of pessimism?). Layer 2: chain steps reference real finding IDs, no invented CVE-or-version anchors, MITRE T-IDs are real, CVSS vector internally coherent.

## Output

```
Chain — <name>
RoE: in scope | Components: [FIND-X, FIND-Y, FIND-Z]

Goal:           <what the attacker achieves>
Prerequisites:  <pre-auth | specific condition>
Feasibility:    <0–3, with rationale>

Steps (pattern-level):
  1. <finding used>: <what goes in> → <what comes out>
  2. ...
  3. ...

Disqualifiers:
  - <compensating control that breaks the chain>
  - <framework default that closes the pattern>

Impact:
  CVSS v3.1:    <score> (<vector>)
  [CVSS v4.0:   <score> (<vector>)]
  Severity:     <Critical | High | Medium>
  Concrete:     <what the attacker holds after success>

PoC:
  Lab execution: <yes/no, location, redacted video link>
  Reproduction:  <numbered, redacted>

Defense:
  Which control breaks the chain:  <list>
  Which fix lowers impact:         <list>

Detection opportunity (handoff to detection-engineer):
  Step | log source | event shape | rule shape

MITRE ATT&CK:
  T-IDs per step

Verification-loop: ...
```

## References

- **OWASP ASVS v4** — [https://owasp.org/www-project-application-security-verification-standard/](https://owasp.org/www-project-application-security-verification-standard/). Helps think in trust chains rather than separate controls.
- **PortSwigger Web Security Academy** — [https://portswigger.net/web-security](https://portswigger.net/web-security). Lab environments for class-level chain verification, the best public source.
- **MITRE ATT&CK** — [https://attack.mitre.org/](https://attack.mitre.org/). Tactic + technique chain as a framework.
- **MITRE D3FEND** — [https://d3fend.mitre.org/](https://d3fend.mitre.org/). Defensive countermappings — use to back up disqualifiers.
- **HackerOne Hacktivity** — [https://hackerone.com/hacktivity](https://hackerone.com/hacktivity). Publicly disclosed chains with their feasibility rationale; a good learning source if read in context.
- **OWASP Top 10 2021** — [https://owasp.org/Top10/](https://owasp.org/Top10/). Mapping basis.
- **FIRST CVSS v3.1 calculator** — [https://www.first.org/cvss/calculator/3.1](https://www.first.org/cvss/calculator/3.1). For chain-aware vector building.
- **CWE** — [https://cwe.mitre.org/](https://cwe.mitre.org/). Per-component classification.

## Categories

- pentest