Skip to main content
Platform · Attack Chain Analysis

A breach is a sequence, not a severity

Almost nobody gets breached by a single critical. They get breached by an information disclosure that reveals an endpoint, an access control gap that endpoint allows, and a credential sitting behind it, none of which looked urgent on its own.

Deep Mode tests those sequences. Not by drawing lines between findings, but by running the next step.

Request accessTalk to a Security Engineer

Scope verified before any test runs · Destructive actions off by default

A left-to-right chain of linked stages glowing orange over a dark dotted world map: a bug caught under a magnifying glass, a radar sweep, an opened padlock, a rack of servers, a hooded intruder and a database cylinder, each wired to the next by one bright line running the length of the sequence. The breach is that sequence, not any single step scored on its own.
Multi-step
Chained exploitation tested in Deep Mode
4–24 hrs
Deep assessment window
Race conditions
Tested, not inferred

Why severity lists miss the thing that gets you

A findings list is a set of independent facts. An attack is a dependent sequence. Those are different shapes, and the first one cannot represent the second.

Severity is calculated in isolation

Every scoring system rates a finding on its own merits. That is what makes scores portable and comparable, and it is also why the sum of four mediums is always four mediums, no matter how neatly they line up. An attacker does not read your queue top-down. They look for the shortest sequence from where they are to what they want, and they are entirely indifferent to how any individual step was rated.

The dangerous finding is usually not the worst one

The step that makes a chain possible is often unremarkable in isolation. A verbose error message. A user enumeration weakness. An endpoint that leaks an internal hostname. Rated alone, correctly, each is a low or a medium. Rated as the thing that turns a locked door into an open one, they are the most important items in the queue.

Fixing one link breaks the chain

This is the useful half of the same idea. A sequence needs every step. Remove any one and the path closes, which means chain analysis does not add work to a remediation backlog. It reorders it. A team that fixes the right medium this week may have closed more real exposure than one that spent the week on three criticals nothing can reach.

What AIPTx does about it

Deep Mode tests multi-step attack chains directly, running the next step rather than inferring that a next step exists. Where a sequence can be carried out, the exploitation evidence for each step is captured as it happens. That is the distinction this page rests on, and it is worth stating plainly: a chain that was executed is a different object from a chain that was diagrammed.

Testing that understands what connects to what

To test a sequence, an agent has to hold more than a list. It needs a model of the environment: what the entry points are, which components trust each other, which roles reach which data, and what a foothold in one place makes possible somewhere else.

Entry points

Everything reachable from outside: application endpoints, API surfaces, exposed services, authentication flows. Reconnaissance establishes these first, because a path that begins nowhere is not a path.

Trust boundaries

The lines an attacker has to cross: unauthenticated to authenticated, user to administrator, application to database, tenant to tenant, service to service. A chain is best understood as a series of boundary crossings, and the interesting question at each one is what made it crossable.

Roles and reach

The same environment looks different from different privilege levels. Testing across the roles you supply is what makes it possible to see that a low-privilege session reaches something it should not, which is where a large share of real chains begin.

What sits behind each step

The value of a foothold is determined by what it touches. A component's reach is what turns access into consequence, and it is the difference between a chain that ends in an inconvenience and one that ends in a disclosure.

A vulnerability is a fact about a component. A chain is a fact about an architecture.

What a chain looks like in practice

The clearest way to explain a chain is to walk one. This is a composite example built from common, well-understood weaknesses, not a customer engagement.

Four findings, none of them critical

Impact: Illustrative example, not a customer account: public error message to downstream system access

critical · 4 hops
  1. Hop 1

    Verbose error disclosure · Low

    A malformed request to a public endpoint returns a stack trace. It includes an internal service hostname and a framework version. On its own: a hardening item. Somewhere in the backlog. Nobody's Tuesday.

  2. Hop 2

    An internal service answering · Medium

    The disclosed hostname resolves and responds. It was built for service-to-service calls and was never meant to be reachable from the application tier in the way it now is. On its own: a network finding. Real, unexciting, three months old.

  3. Hop 3

    Missing authorisation on an internal API · Medium

    The internal service trusts its callers. It was designed on the assumption that anything talking to it is already authorised, a reasonable assumption when it was written, and no longer true. On its own: a design weakness with a mitigating context. Frequently accepted.

  4. Hop 4

    A credential in a configuration response · Medium

    One endpoint on that service returns a configuration object. It contains a service account token for a downstream system. On its own: bad practice. Rotate it, add it to the hygiene list.

Public error message → internal hostname → unauthenticated internal API → service credential → downstream access.

This is why "we have no criticals open" is a weaker statement than it sounds.

Sequenced

Four findings, none rated higher than medium, three of which a reasonable team would defer. The sequence is a data breach.

And one fix closes it

Any single step. Suppress the stack trace, or segment the internal service, or add authorisation, or remove the credential from the response. The chain needs all four.

Which one you choose is now an engineering decision about cost and timeline, but it is being made with the knowledge that it closes a path, rather than that it clears a medium.

The patterns that turn findings into paths

Chains are not arbitrary. A relatively small set of relationships accounts for most of them, and knowing the patterns is what makes an individually-minor finding legible as a first step.

Information disclosure

The most common opening move, and the most consistently underrated finding class. Error messages, debug output, verbose headers, exposed metadata, predictable identifiers. Disclosure rarely causes harm directly. It tells an attacker where to go next, which is why it appears at the start of so many sequences.

Opening

Credential reuse

A credential recovered in one place that works in another. Service accounts shared between environments, tokens with a broader scope than the component needs, keys in configuration that outlive the system they were issued for. Credential reuse is the mechanism that turns a local problem into a lateral one.

Middle

Trust relationships

Components that trust each other because they were built at the same time by the same team under the same assumption. Internal APIs without authentication, services that accept any caller from a given network, admin tooling that trusts the front end to have checked. Trust is a design decision that ages badly and is rarely revisited.

Middle

Privilege inheritance

A component running with more privilege than it needs. Compromise it and you inherit whatever it holds, which is why over-provisioned service accounts and broad IAM roles convert a modest foothold into a serious one.

Terminal

Environment bleed

Staging that reaches production. Test credentials that work against live systems. A development instance carrying a real database snapshot. Non-production environments attract less scrutiny and often carry production reach.

Middle

Session and authentication handling

Tokens that do not rotate on privilege change, sessions that survive logout, authentication that is enforced at the interface but not at the API. These weaknesses tend to sit in the middle of chains, the boundary crossing that turns access into elevated access.

Middle

Network adjacency

What a compromised component can reach. Segmentation that was designed correctly and has since been worked around, or was never enforced beyond the diagram. Adjacency determines how far any single foothold travels.

Middle

Third-party and integration edges

SSO flows, OAuth grants, vendor integrations, webhook endpoints. The trust extended to an external party is a path into the environment, and it sits outside the scope of most scheduled testing precisely because it belongs to someone else.

Opening

What changes when you can see the sequence

The same finding set, read as paths rather than a list, changes what gets fixed first, what gets argued about, and what a quiet queue is telling you.

You stop mistaking a quiet queue for a safe position

"No open criticals" describes a severity list, not an exposure. Chain analysis is what turns a queue of mediums into a statement about whether anything can actually be reached.

Remediation gets cheaper, not more expensive

Breaking a chain requires fixing one step, not all of them. Knowing which step is the cheapest to close is a scheduling advantage, not extra work.

Mediums get triaged on their function, not their score

A medium that opens a path and a medium that leads nowhere are the same number and different problems. Sequence is the only thing that separates them.

The severity conversation with engineering gets easier

"Fix this medium" is a hard argument. "Fix this medium because it is step two of a tested path to the customer database, and closing it costs an afternoon" is not an argument at all.

Architectural weaknesses become visible

Individual findings describe defects. Recurring chain patterns describe design problems: a trust model that assumes too much, an environment boundary that does not hold. Those are worth more to fix than any single item they produce.

Testing depth becomes a decision you can make deliberately

Deep Mode exists because chained exploitation takes time. Knowing that Quick and Standard modes do not cover it is what lets you schedule depth where it matters rather than assuming every scan looked for everything.

What chain testing can and cannot establish

Testing has a boundary, and you draw it

Chains are found by testing, which means they are bounded by scope. A path that leaves your defined scope is not followed. That is correct behaviour, and it means the paths you see are the paths inside the boundary you set.

An absence of chains is not an absence of paths

It means none were found within the scope, the time and the modes you ran. Deep Mode covers complex multi-step chains; Quick Mode does not attempt them and Standard Mode covers them at a basic level. A clean Quick Scan says nothing about chains at all.

Some steps are not safe to prove

Not every step can be safely executed. Where proving the next step would require destructive action, it is not performed. Those sequences are incomplete by design, and an incomplete chain should be read as unproven beyond this point rather than as stops here.

Evidence and hypothesis are not the same thing

A tested chain is evidence. An untested chain is a hypothesis. Both can be useful. They should never be presented as the same thing, and if the product ever infers adjacency it has not tested, the interface should say which is which.

FAQs

Attack chain questions

What is an attack chain?

A sequence of steps that gets an attacker from an entry point to something worth having. Each step is usually a separate finding, and each is often rated low or medium on its own. The chain is what makes them consequential: an information disclosure that reveals an internal service, an authorisation gap on that service, a credential behind it, and the downstream system that credential opens.

Do you find chains automatically?

Deep Mode tests complex multi-step attack chains as part of the assessment. Standard Mode covers chaining at a basic level, and Quick Mode does not attempt it. A Quick Scan is built for a pull request gate and chain testing needs session state, multiple roles and time. Choose the mode according to whether the question you are asking is "did this change break something" or "what can be reached from here".

Are these real paths or inferred ones?

Chain testing is exploitation-based: the next step is attempted rather than assumed. Where a step cannot be safely executed, the chain is incomplete beyond that point and should be read as unproven rather than as ending there.

We have no open criticals. Do we need this?

That is the situation chain analysis exists for. A queue of mediums with nothing critical in it is a statement about how findings were scored individually, not about what an attacker can reach. Most real breach paths run through findings that were correctly rated medium and correctly deprioritised on their own merits.

How long does chain testing take?

Deep Mode runs 4–24 hours depending on the size of the attack surface and the depth of the authenticated application. Chained exploitation is inherently sequential: each step has to succeed before the next can be attempted, which is why it does not compress into a Quick Scan.

Does this cover lateral movement between hosts?

Chain testing covers multi-step exploitation within the scope you define, with each step proven against the systems in that scope. Host-to-host lateral movement, privilege escalation chaining and post-exploitation pivoting are not currently described in AIPTx documentation, so this page does not claim them. If that is the question you need answered, ask us directly rather than reading it into the word chain.

How does a chain affect prioritisation?

Findings are ranked using weighted factors including exploitability, impact, asset value and exposure. A finding that forms part of a proven path is a different proposition from one that leads nowhere, even at identical severity. The AI Risk Engine page sets out how those factors are weighted and combined.

Which step do we fix to break the chain?

Any proven step, which is the useful property of a chain: it is a sequence, so removing one link ends the path whether it was the first step or the last. That turns remediation into a choice rather than a list of four fixes, and the cheapest link is often the one a severity queue had ranked lowest. Two things are worth weighing before choosing: a step that appears in several chains is worth more than one that appears in a single path, and a fix is only a hypothesis until the sequence is attempted again.

We fixed one step. How do we know the chain is closed?

By running it again. A merged fix is a hypothesis about the chain until the sequence is attempted against the deployed application, and the step that looks broken in a diff is not always the step that was carrying the path. Re-testing is the same exploitation-based process, so a chain that no longer completes is recorded as failing at a named step rather than quietly disappearing from the queue.

Can we see the chain in a report?

Reports include the technical detail for each finding with its exploitation evidence, plus executive summary and remediation guidance. Where the chain relationships themselves appear (dashboard, export, or both) is worth confirming with us for the format you need, rather than assuming a graph survives into a PDF.

The rest of the platform

Chains are assembled from what the other three produce.

Autonomous Pentesting

AI agents that map, exploit and prove. The validated exploitation is what makes a tested chain possible rather than a diagram.

See how testing runs

Vulnerability Discovery

Seven vulnerability classes, 245+ tests. The findings that become the steps.

See what gets found

AI Risk Engine

Weighted scoring across exploitability, impact, asset value and exposure, the layer that decides what a chain means for your queue.

See how risk is scored

Find out what your mediums add up to

Run a Deep assessment and see which findings connect, with the exploitation evidence captured at every step. No credit card required.

Request accessTalk to a Security Engineer

Scope verified before any test runs · Destructive actions off by default