exploit-chain-analysis

name	exploit-chain-analysis
description	Analyze authorized exploit chains by combining tracked findings, confident or proofed issues, and de-escalated leads into higher-impact vulnerability hypotheses. Use when Codex needs to correlate findings, model preconditions and postconditions, consider de-escalated leads as conditional chain edges, create chain packets, update finding-tracker, or send chain findings through triage-verifier.

Exploit Chain Analysis

Use this skill after engagement-scope has established the authorized target, scope evidence, allowed test environment, impact tolerance, and desired deliverable. This skill does not replace individual vulnerability validation; it connects validated or partially validated leads into a higher-impact chain and tracks that chain as a normal finding.

Each exploit chain must use the same finding-tracker states as regular findings:

• discovered: plausible chain hypothesis.
• confident: evidence shows the links compose and the escalated impact is reachable or exploitable.
• proofed: successful triage-verifier run for the combined chain.
• de-escalated: the chain is debunked, duplicate, out of scope, or does not create new impact.

2026 Agent Research Bias

Recent vulnerability-research agents point toward a few durable practices:

• Tool-grounded loops beat free-form reasoning. Keep each chain step tied to code, browser, debugger, request, crash, or tracker evidence.
• Explicit state matters. Long-horizon agents succeed more often when they keep durable memory, preconditions, postconditions, and failed attempts instead of re-discovering the same leads.
• Multi-agent and CRS systems decompose work into planning, exploration, dynamic execution, proof, and patch/report roles. Mirror that separation by keeping chain ideation separate from proofing.
• Failed attempts are useful evidence. A de-escalated lead may describe a guard, assumption, or blocked vector that another finding can bypass.
• Most failed exploit attempts come from misunderstood semantics or unmet preconditions. Do not compose links unless one link's postcondition satisfies the next link's precondition.

When To Use

Use this skill when:

• Multiple tracked findings might combine into cross-tenant access, privilege escalation, account takeover, sandbox escape, RCE, data exfiltration, supply chain compromise, persistence, or control-plane impact.
• A confident or proofed finding creates a new capability that may unlock another bug.
• De-escalated leads contain useful negative evidence, blocked paths, guard assumptions, or near misses that may become reachable after another step.
• A report or bounty needs chain-level impact rather than isolated bug impact.
• Work has plateaued on individual findings and correlation may reveal a higher severity path.

Do not use this skill to interrupt productive source review, reversing, debugging, fuzzing, or web testing that is still producing direct evidence. Return here at a natural milestone or handoff point.

When the user explicitly requests subagents for chain analysis, use subagent-orchestration to separate mapper, chain-candidate auditor, skeptical debater, deduper, and prover roles. Keep chain synthesis in the parent agent so preconditions, postconditions, impact escalation, and tracker state do not split across competing narratives.

Chain Model

Normalize every lead into this shape:

Actor + starting privileges
Preconditions that must already be true
Action or bug primitive
Postcondition gained after the step
Evidence supporting the transition
Controls or assumptions that may block it

Only propose a chain when a postcondition from one step satisfies a meaningful precondition of another step. Do not chain findings merely because they share a target, component, CWE, or route.

Common postconditions:

• Read another user's object, token, secret, file, log, queue message, or internal response.
• Write attacker-controlled content into a trusted location.
• Trigger server-side request, deserialization, command execution, script execution, or parser invocation.
• Gain a stronger role, tenant context, origin, API key, file handle, process capability, sandbox permission, or network reachability.
• Bypass a rate limit, CSRF check, origin check, object ownership check, signature check, path canonicalization, or egress rule.

De-escalated Leads

Include de-escalated leads in the inventory. Treat them as conditional evidence, not revived findings.

Use a de-escalated lead when it shows:

• A guard exists but depends on state another finding can alter.
• A path is blocked only before authentication, tenant pivot, role escalation, network pivot, file write, or configuration change.
• A sink was unreachable until another primitive creates the required object, feature flag, import, callback, archive, symlink, token, or request context.
• Negative controls identify exactly which chain link must change.

Do not promote a de-escalated standalone bug without new evidence. If the chain works, track the chain as its own finding and relate the de-escalated lead by ID.

Helper Script

Use scripts/chain_packet.py to create a concise chain analysis packet under data/exploit-chains/. The packet is a working artifact for reasoning, handoff, and later triage verification.

python3 <skill-dir>/scripts/chain_packet.py \
  --title "Stored upload path plus admin import reaches SSRF sink" \
  --target "admin.example.com" \
  --finding F-0003 \
  --finding F-0007 \
  --de-escalated-lead F-0002 \
  --hypothesis "Low-privileged upload controls an import URL after admin review." \
  --step "F-0003 writes attacker-controlled import metadata into a tenant object." \
  --step "F-0007 admin import job fetches that metadata server-side." \
  --precondition "Attacker has standard tenant account and upload permission." \
  --postcondition "Internal fetch reaches metadata endpoint from admin network." \
  --impact "Potential internal metadata exposure through admin import SSRF." \
  --evidence "tracker F-0003 request logs; tracker F-0007 import trace" \
  --gap "Need combined run showing upload output reaches import fetcher." \
  --constraint "Authorized lab tenant only."

The packet does not proof the chain. It organizes the hypothesis so the chain can be tracked and later verified.

Workflow

1. Load current findings with finding-tracker; include de-escalated. Search for existing chain findings before adding a new one.
2. Build an inventory of each useful lead: ID, state, target, actor, boundary, primitive, preconditions, postconditions, evidence, blockers, and confidence.
3. Convert candidates into step cards. Keep each card small enough that one command, request, test, debugger trace, or code path can validate it.
4. Compose candidate chains only when the transitions line up. Prefer short chains with clear state changes over long speculative chains.
5. Check impact escalation. The chain should create materially greater impact, a different affected boundary, stronger privilege, better reachability, or a more reportable proof than the individual findings alone.
6. Check scope and safety. Keep work in authorized lab accounts, local binaries, local repos, owned test data, or explicitly approved systems.
7. Create or update a chain packet. Record gaps, negative controls, constraints, and next actions.
8. Track the chain as a normal finding with category exploit-chain, related finding IDs, and duplicate-search evidence.
9. Move to confident only after the combined path is evidenced, not merely because individual links are plausible.
10. Send the chain through triage-verifier when it is confident and the current research chain has reached a natural stopping point.

Tracking Rules

Before adding a chain finding:

python3 <finding-tracker-dir>/scripts/findings.py search \
  --title "Upload metadata to admin import SSRF chain" \
  --target "admin.example.com" \
  --category "exploit-chain" \
  --related F-0003 \
  --related F-0007

Add a discovered chain only after duplicate search:

python3 <finding-tracker-dir>/scripts/findings.py add \
  --title "Upload metadata to admin import SSRF chain" \
  --target "admin.example.com" \
  --category "exploit-chain" \
  --related F-0003 \
  --related F-0007 \
  --related F-0002 \
  --summary "Upload metadata primitive may feed admin import SSRF sink." \
  --evidence "data/exploit-chains/upload-admin-import-ssrf-chain.md"

Use milestones to record composition attempts, negative controls, failed links, and impact changes. If a chain is debunked, set it to de-escalated; do not delete it.

Confidence And Proof

A chain can be confident when:

• The actor, starting privileges, and target environment are clear.
• Each link has evidence or an explicit proof gap.
• At least one end-to-end transition is reproduced or strongly proven.
• The chain impact is materially greater than the individual findings.
• Known blockers, mitigations, and negative controls have been tested or named.

A chain is proofed only after triage-verifier accepts the combined chain. Individual proofed findings are useful, but they do not automatically proof the chain. The verifier must be able to see that the links compose.

Verification Expectations

For chain proof, prepare:

• Finding IDs and chain packet path.
• End-to-end reproduction or undeniable evidence that the combined path works.
• Step-by-step preconditions and postconditions.
• Negative controls for broken links: patched guard, wrong tenant, wrong role, absent state change, blocked egress, safe input, or missing object.
• PoC rewritten as a minimal chain validator, not a bundle of unrelated scripts.
• Cleanup and blast-radius notes.
• Explanation of why the chain is not just duplicate impact from an existing finding.

De-escalation Triggers

De-escalate the chain when:

• A required link cannot be reached or controlled.
• A mitigation blocks the transition in the authorized environment.
• The chain relies on out-of-scope assumptions, destructive steps, production data, or unauthorized targets.
• The final impact is no greater than an already tracked finding.
• Evidence shows it is a duplicate of another chain or root cause.
• The required preconditions are unrealistic for the engagement.

Keep useful failed-link evidence in milestones so future agents do not retest the same path blindly.

Output Format

Exploit chain: <title>
Tracker ID: <chain finding ID or pending>
Related findings: <IDs and states, including de-escalated leads>
Actor: <starting role/context>
Steps: <precondition -> primitive -> postcondition per link>
Evidence: <chain packet, requests, traces, code paths, debugger output>
Impact: <escalated impact and why it exceeds individual findings>
Gaps: <specific proof gaps or blockers>
State decision: <discovered / confident / proofed / de-escalated>
Tracker update: <search/add/update/milestone performed>
Verifier handoff: <needed now / later / not yet, with reason>

Handoff

Use finding-tracker for state and duplicate control. Use triage-verifier as the only path to proofed. Return to web-app-security-inspection, code-vulnerability-review, binary-debugging, binary-reversing, fuzz-harness-builder, or cve-research when a chain gap needs more evidence from the underlying vulnerability class.