sekura

Exploit Chain Analysis Catches What Scanners Miss

Single-vulnerability scanners miss the attacks that matter most. Real attackers chain low-severity findings into critical exploits. Here is how exploit-chain analysis finds paths that no scanner sees.

Scanners find findings. Attackers find paths.

The Single-Finding Trap

Most automated scanners evaluate each finding independently. They assign a severity score to each item. CVSS 3.2 for this CVE. Low risk for that configuration flag. Medium for that exposed endpoint.

That model is wrong in practice.

Real attacks are rarely single-step. An attacker rarely walks in through a critical-severity door. They find a low-severity information leak. They combine it with a medium-severity authentication bypass. They use that to pivot to an internal service. That pivot lets them read a secret. That secret gives them admin access.

None of those steps is critical on its own. Together, they are root.

What a Chain Looks Like

Here is a real example of a chain we find regularly. Each finding in isolation would score as low or medium.

  1. A /metrics endpoint exposed without authentication (low severity: no direct sensitive data, just Prometheus metrics).
  2. The metrics reveal internal service names and IP addresses (informational: just configuration data).
  3. One internal service runs on port 9200 with no auth (medium: Elasticsearch, no external access).
  4. The Elasticsearch instance stores plaintext API tokens (high severity, but only reachable from inside).

Scanner A reports finding 1. Scanner B reports finding 3. Scanner C flags finding 4.

No scanner connects them. No scanner says: "an unauthenticated user can reach finding 4 in four steps starting from the public internet."

Here is what that attack path looks like:

sequenceDiagram participant Attacker participant PublicAPI as Public API (/metrics) participant InternalSvc as Elasticsearch (9200) participant Secret as Plaintext API Tokens Attacker->>PublicAPI: GET /metrics (no auth) PublicAPI-->>Attacker: Exposes internal host list Attacker->>InternalSvc: Query via SSRF pivot InternalSvc-->>Attacker: Returns index with API tokens Attacker->>Secret: Extracts admin credentials

The chain is what matters. The individual findings are noise.

Why Isolation Fails as a Model

Scanners are built around finding detection. They score individual findings. They do not model how findings compose.

I think this is the most important gap in vulnerability management right now. A scanner that finds 400 items and scores them all has not answered the question you care about: can someone breach this system?

Here are three reasons isolation fails:

  1. Severity scoring is local. CVSS scores a finding in isolation. It does not account for network topology, chaining potential, or what else is running in the environment.
  2. Triage happens in the wrong frame. When you triage 400 individual findings, you are solving the wrong problem. The question is not which findings are severe. The question is which paths reach sensitive assets.
  3. Attackers do not respect severity thresholds. A patient attacker chains what is available. Low plus low plus medium can equal critical if the topology supports it.

We built Sekura's exploit-chain analysis phase specifically for this. It does not score findings. It builds attack graphs. Then it tries to synthesize a working exploit for every viable path.

What Exploit-Chain Analysis Actually Does

After the dynamic probing phase identifies candidate findings, the exploit-chain analysis agent constructs an attack graph. Every finding is a node. Directed edges represent reachability and composability.

The agent asks: given what we know about this system's topology and trust model, which sequences of findings produce a viable attack path?

Then it tries to exploit each viable path, not each finding. If it cannot produce a working exploit for a path, that path is not reported.

flowchart TD A["/metrics exposed, no auth"] --> B[Internal host list extracted] B --> C[SSRF to Elasticsearch:9200] C --> D[API tokens in plaintext] D --> E[Admin access confirmed] E --> F{Chain viable?} F -- Yes --> G[Proof-of-exploit generated] F -- No --> H[Path dismissed, not reported]

A single low-severity finding that is a critical link in a viable chain gets elevated. A medium finding that leads nowhere stays medium and is summarized, not escalated.

You get a proof for the chain, not a score for each node. That is a different product.

The Cost of Missing Chains

When a chain goes undetected, the consequence is not a missing finding on a report. It is an unpatched attack path.

I believe most production breaches in the past several years involved at least two chained findings. Neither was individually critical. Together they were sufficient.

The fix for each link in the chain is usually simple. An auth check on /metrics. An authentication layer on Elasticsearch. Neither is hard. But neither gets fixed if it is never flagged as part of a coherent attack path.

Isolated findings get triaged, deprioritized, and aged out of the backlog. Chains get fixed, because they carry proof.

Security posture is not the average severity of your open findings. It is whether there is a viable path to your most sensitive assets. To see how we model those paths in your own environment, start with a proof-of-concept scan.