exploit-chain-analysis

name	exploit-chain-analysis
description	Actively hunt for and compose exploit chains that turn multiple smaller issues into high-impact (especially critical) findings. Use aggressively: during code review, after new leads appear in finding-tracker, and whenever one primitive unlocks another. Red-team focused — chains are how you turn "a bunch of medium findings" into something that actually pays.
metadata	{"short-description":"Red-team exploit chain hunter — compose findings into higher-impact attacks","category":"vulnerability-research","priority":"critical"}

Exploit Chain Analysis (Red Team Edition)

This skill is about multiplication of impact.

Your job is to look at the set of leads, confident findings, and even de-escalated notes, and find ways to combine them into something significantly more dangerous than any individual piece.

Chains are how you win on hard targets. A single medium bug is often worth $X. The same bug as the first link in a chain is often worth 5–10x.

Red Team Philosophy

• Hunt for chains proactively, not just at the end of research.
• A "de-escalated" finding is often the most valuable thing in the tracker for chain work — it usually means "this would be bad if only we could reach this state."
• Do not wait for everything to be individually confident before looking for composition opportunities.
• A chain does not need to be fully proven to be worth tracking and developing. It just needs a plausible, high-upside path.

Core Model (Keep Using This)

Every potential link should be thought of as:

Actor + starting state
→ Precondition (what must already be true)
→ Primitive / Bug (what the attacker can do)
→ Postcondition (what new capability or state they gain)
→ Evidence + Blockers

Only real chains are those where the postcondition of one step satisfies a meaningful precondition of another step.

When to Actively Look for Chains

• After every significant session of code-vulnerability-review
• Whenever a new lead appears in finding-tracker
• When you see a de-escalated finding that feels "one primitive away" from being useful
• When reviewing access control, crypto protocols, or complex state machines (these are chain goldmines)
• When a new capability (e.g. arbitrary file write, SSRF, deserialization, role escalation) appears

Workflow (Aggressive Version)

1. Pull active + de-escalated findings from finding-tracker.
2. Inventory useful primitives and their postconditions.
3. Look for "unlock" relationships (one finding removes a blocker for another).
4. Build the chain as a sequence of precondition → primitive → postcondition.
5. Assess whether the final impact is materially higher (different boundary, higher privilege, realistic attacker reachability, etc.).
6. Create or update a chain packet using chain_packet.py.
7. Track the chain in finding-tracker as its own exploit-chain entry with --related links.
8. Keep developing the chain across multiple /goal iterations until it either dies or gets proofed.

Using De-escalated Leads

De-escalated findings are extremely high value for chains. Treat them as "almost" findings.

Common patterns:

• "This would let us write attacker-controlled data... if only we could reach the write as an admin."
• "This deserialization sink is dangerous... if only we could control the class name from a privileged context."
• "This check is missing for tenant B... if only we could become tenant A first."

These are not failures. These are missing links that other findings might provide.

Chain Quality Bar

A good chain should feel like:

• The combination creates a realistic attack path that a motivated attacker would actually use.
• The final impact is clearly higher than any single component (cross-tenant, key material, full RCE, etc.).
• There is at least one non-obvious composition step.

Weak chains (just stringing together unrelated medium bugs) should be killed early.

Tooling

Use the helper:

python3 .grok/skills/exploit-chain-analysis/scripts/chain_packet.py \
  --title "..." \
  --target "COIN-004" \
  --finding F-00XX \
  --finding F-00YY \
  --de-escalated-lead F-00ZZ \
  --hypothesis "..." \
  --step "..." \
  --precondition "..." \
  --postcondition "..." \
  --impact "..." \
  --gap "..."

Store packets under data/exploit-chains/ or inside the target's poc/ directory.

Tracking

Always create the chain as its own entry in finding-tracker with category: "exploit-chain" and use --related for every component finding (including de-escalated ones).

Update the chain's state in the tracker as it develops (discovered → confident → proofed).

Handoffs

• Once a chain reaches confident and research has plateaued → send to triage-verifier for final proof.
• Strong chains that are proven → report-writer.
• Gaps in individual links → send back to code-vulnerability-review, web-app-security-inspection, etc.

Bottom Line

In red team mode, your job is not to be conservative about chaining.

Your job is to find the combinations that turn a bunch of "medium" or "de-escalated" issues into something the target actually has to pay real money to fix.

Chains are leverage. Use them.