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/. Helps think in trust chains rather than separate controls.
• PortSwigger Web Security Academy — https://portswigger.net/web-security. Lab environments for class-level chain verification, the best public source.
• MITRE ATT&CK — https://attack.mitre.org/. Tactic + technique chain as a framework.
• MITRE D3FEND — https://d3fend.mitre.org/. Defensive countermappings — use to back up disqualifiers.
• HackerOne 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/. Mapping basis.
• FIRST CVSS v3.1 calculator — https://www.first.org/cvss/calculator/3.1. For chain-aware vector building.
• CWE — https://cwe.mitre.org/. Per-component classification.

Categories

• pentest