# Exploit Chain > 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. - Skill: `roodlicht/exploit-chain` (Agent Skill) - Install (CLI): `npx skillmds@latest add roodlicht/exploit-chain` - Raw SKILL.md: https://api.skillmd.com/api/skills/roodlicht/exploit-chain/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: roodlicht (https://skillmd.com/u/roodlicht) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/roodlicht/exploit-chain --- # 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 — RoE: in scope | Components: [FIND-X, FIND-Y, FIND-Z] Goal: Prerequisites: Feasibility: <0–3, with rationale> Steps (pattern-level): 1. : → 2. ... 3. ... Disqualifiers: - - Impact: CVSS v3.1: () [CVSS v4.0: ()] Severity: Concrete: PoC: Lab execution: Reproduction: Defense: Which control breaks the chain: Which fix lowers impact: 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