Pentestas / help

Attack chains

A single MEDIUM-severity finding usually isn't a fire drill. Two MEDIUMs that combine into an account takeover absolutely is. Attack chains are where Pentestas surfaces that combinatorial risk.

This page documents the rule + LLM narration path — chains inferred from the findings list, presented as a description of how an attacker would walk the bugs. For chains the engine actually executes against the target (logging in as admin via default creds, exfiltrating AWS keys via SSRF, dumping the users table via SQLi → app login), see Exploitation chains. The two are complementary: this article describes potential paths, the orchestrator demonstrates real impact.

What a chain looks like

An ordered sequence of stages. Each stage:

  • Stands alone as a finding (or a known behaviour of the target).
  • Creates the precondition for the next stage.
  • Ends at a concrete impact — account takeover, RCE, data exfil, admin escalation.

Example chain:

File upload accepts SVG       → SVG embeds <script>               → stored XSS
stored XSS fires on profile   → executes on admin's session       → cookie exfil via SSRF-safe channel
admin cookie sent to attacker → attacker posts /admin/users/X     → arbitrary user promotion

Three separate findings (unrestricted file upload / stored XSS / missing cookie flag), individually MEDIUM, combine into a CRITICAL account-takeover chain.

How Pentestas builds them

Two mechanisms run side by side:

Rule-based synthesis

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

  • Checks preconditions (e.g. "there's a file upload finding AND a stored-XSS finding").
  • Emits a chain with a stage template explaining the escalation.
  • Computes the combined severity (usually one step above the max of its parts).

Examples of the rules:

  • Default creds → takeover
  • Path traversal → SSH keys → lateral movement
  • SSRF → cloud metadata → IAM credential theft
  • Open redirect → credential phishing
  • Mass assignment → admin promotion
  • IDOR → bulk PII scrape
  • RCE → persistence (cron, systemd timer, startup script)
  • Stale privileged-account takeover (Azure / Entra ID) — Pentestas cross-references the list of privileged role holders against the list of stale accounts (no recent sign-in, MFA never registered, password not rotated). When the same display name appears on both sides, the chain emits a CRITICAL finding naming the user and their role(s). This is a literal overlap query, not LLM speculation: every name on the chain corresponds to two underlying findings the rule pulled from the same scan.

LLM synthesis (Pro+)

Claude reads the full findings list + app context and proposes chains the rules missed. Output is validated (each stage must reference an actual finding) before publishing.

Where chains appear

  • Scan detail page — mindmap view at the top. Click any node to jump to the finding.
  • Executive reports (PDF) — each chain gets a dedicated page.
  • API — GET /api/scans/{id}/graph returns the chain list.

Mindmap controls

  • Click a node to expand + reveal the next stage.
  • Drag the background to pan.
  • Scroll + shift to scroll horizontally.
  • Click a leaf to open the finding.

Severity of a chain

The chain's severity is derived from:

  • The max severity across its stages.
  • Whether the impact is a widely-understood "pwn" (RCE, account takeover, arbitrary DB access) — bumps by one level.
  • Whether the chain requires authentication to start (bypasses requiring no auth are higher severity).

Most chains end up at CRITICAL or HIGH — that's by design. If a chain would only land at LOW, the rule engine typically doesn't bother publishing it (LOW chains add noise without informing action).

Chain score (0–100)

Beyond severity, every chain carries an explicit score from 0 to 100 — a deterministic, pure-function value the platform computes from the chain's shape. The score drives the executive summary's ordering: chains are sorted by descending score so the highest-impact chain leads the report.

Composition (no LLM — auditable):

  • Severity floor: 80 (CRITICAL), 60 (HIGH), 40 (MEDIUM), 20 (LOW), 10 (INFO).
  • +10 per additional step beyond the first — chain depth multiplier.
  • +15 if any step is verified by the Accuracy Gate's external-replay verifier — exploitability boost.
  • +10 if the chain spans ≥3 distinct MITRE ATT&CK techniques — cross-tactic spread.

A confirmed three-step SSRF → IMDS → IAM-token theft chain with three distinct ATT&CK techniques scores ≥ 95. A single-step "chain" (one rule fired, no real sequence) scores ~ 40-50. Sort the chain panel by score and the report's exec summary leads with the chain most likely to actually matter.

MITRE ATT&CK chain ribbon

Every persisted chain carries the ordered list of MITRE ATT&CK techniques along its path. The chain detail view renders these as a ribbon: T1190 → T1552.005 → T1078.004 — visible at a glance, useful for ATT&CK-coverage mapping in the SOC's threat-coverage spreadsheet.

Persisted chains and retest

Chains aren't just in-memory — every chain identified during a scan is persisted as a first-class artefact (attack_chains table). When you retest the scan, the chain-detector re-evaluates and refreshes the rows; chains whose underlying findings have been remediated drop out, new ones land, and the score gets recomputed. The engagement detail page (see Engagements) lists every chain across every scan in the engagement, deduplicated by name and ordered by score.

When there are no chains

Not every scan produces chains — it means the findings don't combine into known escalation patterns. Don't interpret "no chains" as "you're safe"; individual HIGH findings still matter. The chain view is additive, not a replacement for the severity-ordered findings list.

See also