Attack Path Analysis: How Breach Paths Reach Your Critical Data

Security is bought in pieces. Breaches happen in chains.

You already know which domains your company owns. You have a list of internet-facing hosts, open ports, and vulnerable software, plus a dashboard that scores it all and tells you what to fix first.

There is a harder question sitting underneath that list. Which of those exposures gives an attacker a working route to your most sensitive data?

Picture a forgotten preview application that holds no valuable data of its own. Its importance changes the moment the identity it runs under can read a production secret, and that secret unlocks a database full of customer records. The application is the entry point. The data is the objective. The connections between them are the problem.

Attack path analysis is the practice of mapping those connections. It traces an exposed entry point to a high-value target through the assets, identities, permissions, and weaknesses in between, then tests whether the route actually works.

What attack path analysis answers: an asset inventory shows what is exposed. An attack path shows what that exposure makes possible. The work is to find the routes that connect external exposure to critical data, prove which ones are real, and break them.

Security teams are usually organized by surface: application security, cloud security, identity, infrastructure, penetration testing. An attacker's objective does not respect that structure. They do not need to defeat every security product. They need one viable path to something valuable.

What an Attack Chain Is, Stage by Stage

An attack chain is a connected sequence of actions through which an attacker moves toward an objective. It can combine exploitable vulnerabilities, exposed credentials, excessive permissions, and legitimate system features to gain access, expand control, or reach sensitive data.

Every framework carves the chain slightly differently, but the underlying stages are consistent. Here is the unified version, with each stage linking to a deeper guide.

1. Reconnaissance. The attacker gathers information about the target, its infrastructure, its people, and its exposed surface. Nothing is touched yet.

2. Initial access. The attacker gets a first foothold, through a phishing email, an exposed service, a leaked credential, or a public-facing exploit. This is the subject of the guide to initial access.

3. Execution and persistence. The attacker runs their code and establishes a way to stay, so that a reboot or a closed session does not evict them.

4. Privilege escalation. The attacker turns a limited foothold into greater control, moving from a low-privilege account to an administrator or root. This is covered in the guide to privilege escalation.

5. Lateral movement. The attacker moves from the machine they landed on to other systems, hunting for the data or access they actually want. See the guide to lateral movement.

6. Collection and exfiltration. The attacker locates the target data and moves it out, often over a channel built to look like normal traffic. This is covered in the guide to data exfiltration.

Those stages map to objectives in the MITRE ATT&CK knowledge base. Not every attack uses every stage or follows the same order.

One distinction matters more than any other. Not every link in the chain is a software vulnerability. A vulnerable application might provide the first foothold. After that, permissions already granted to the application can open the next door, and the step after can be a legitimate API doing exactly what its access policy allows.

A few related terms travel together, and they are worth separating cleanly:

• Attack path is the route through assets, identities, permissions, and weaknesses that could let an attacker reach a target.

• Breach path is the same route named for its consequence, which is unauthorized access to sensitive data, critical systems, or privileged control.

• Attack graph is the representation of many possible routes and how they relate.

An attack chain describes the progression of actions. An attack path describes the route that makes those actions possible. Microsoft's exposure management documentation describes attack paths the same way, as connections between entry points and critical assets.

Seeing all of this as one connected graph, rather than a checklist, is the job of attack path analysis. The practical question stays constant. Can an attacker get from here to there, and what has to be true for that to happen?

Attack Chain, Cyber Kill Chain, and MITRE ATT&CK

These three terms get used interchangeably, and they are not the same thing. Getting the distinction right is the foundation for everything else.

The attack chain is the general concept, any ordered sequence of attacker steps toward a goal. The Cyber Kill Chain is Lockheed Martin's 2011 model that breaks an intrusion into seven fixed phases. MITRE ATT&CK is a large, living knowledge base of real-world adversary tactics and techniques, organized into tactic categories.

Use the Cyber Kill Chain to understand the shape of an attack. Use MITRE ATT&CK to map what an attacker actually did, technique by technique. Use "attack chain" to talk about the specific path through your environment that matters to you.

Why linear kill-chain thinking fails against modern attacks

The Cyber Kill Chain is a great teaching tool and an incomplete defensive one, because real attacks are not linear.

• Attackers skip stages. If a leaked credential grants direct access to a cloud console, there is no need for a phishing email or a persistence mechanism. Several stages collapse into one.

• Attackers loop back. Lateral movement often reveals a new credential, which triggers another round of privilege escalation, which enables more lateral movement. The chain is a cycle, not a line.

• Attackers take parallel paths. A capable adversary pursues several routes at once and uses whichever succeeds first. Blocking one does not stop the others.

A defense that fixates on one stage fails. Blocking the phishing vector does nothing about the exposed credential in a public repository. The attacker takes the path you left open. Real defense needs controls at enough stages that no complete path survives, because the attacker needs one complete path and you have to close all of them.

The Attack Surface Is the Starting Point, Not the Answer

Consider an attacker who starts with a company name and nothing else. No credentials, no architecture diagrams, no source code. Public information already reveals a lot: application entry points, technology details, API references, and hints about how systems talk to each other. OWASP's testing guidance includes reviewing page content, JavaScript, and frontend debug artifacts for exactly this kind of leakage.

External attack surface discovery pulls those observations together into domains, hosts, services, exposed applications, and candidate weaknesses. External penetration testing then examines what can actually be accessed or exploited from that starting position.

Discovery and compromise are different conclusions. A good way to read an inventory is to ask what each observation leaves unanswered.

These are questions to investigate, not conclusions to infer from a dashboard. An exposed service is not automatically a compromised service, and a vulnerability match is not automatically a breach path. The value comes from establishing which observations connect, under what conditions, and with what consequences.

A Real Attack Chain, Walked Step by Step

Abstract stages are easier to understand against a concrete example.

Consider the September 2026 attack on OpenAI's infrastructure, documented publicly by the researchers who performed it. It is a clean, real attack chain.

• Reconnaissance. The researchers examined OpenAI's public community forum and noticed it accepted image uploads, processed through a conversion pipeline.

• Initial access. The pipeline reached a vulnerable image library, libheif, with a memory bug. A crafted image, uploaded to the forum, gave them code execution on the forum server. That is the foothold.

• The pivot. A session token issued by the forum stayed valid for other OpenAI applications, ChatGPT and Codex. This is the link that turned a forum bug into a real breach.

• Lateral movement. Using that token, they reached an employee's Codex account, which was connected to OpenAI's internal GitHub.

• Objective. From that account, they had a path into OpenAI's internal code repository. They proved it by opening a harmless pull request, and stopped.

Six stages, under 72 hours, from a public forum to an internal monorepo. The full breakdown is in the analysis of that incident.

Now notice the crucial thing. Most links in that chain were third-party bugs the target inherited. One, the session token that stayed valid across applications, was the target's own reviewable code. Remove that single link and the chain stops at a compromised forum. The whole breach turned on one weakness that looked minor in isolation.

How the Same Chain Forms in the Cloud

The OpenAI chain moved through application tokens. The same logic runs through cloud identities and permissions. Here is a hypothetical cloud route, written as an attacker would travel it. A real assessment has to establish each transition rather than assume the whole route holds.

Public preview application → exploitable application flaw → workload identity → production secret → private database → sensitive records

A company runs an internet-facing preview application whose own database holds only test data. A vulnerable component allows code execution inside its runtime. Exploiting an internet-facing application is a recognized initial access technique, and in a cloud-hosted environment it can open the door to cloud resources.

Assume testing establishes execution as the application process. That proves a narrow fact. The attacker can act from the application's execution context. The next question is what that context can reach.

Assume the compromised process can use a workload identity meant to fetch application configuration, and that identity can also retrieve a production database secret. What matters is not the role's name or one permissive-looking policy. It is the identity's effective permissions. In AWS, identity policies, resource policies, permissions boundaries, and organization controls all affect whether a request succeeds, and an explicit deny overrides an allow. This kind of privilege escalation is where a narrow foothold turns into real reach.

Reading the secret takes more than knowing its name. AWS Secrets Manager decrypts through KMS under its own permissions. Holding the credential still does not grant database access. The workload needs a permitted network route, the database has to accept the credential, and the resulting database identity has to reach the records in question. Amazon RDS documents security-group access separately from database authentication.

Assume those conditions hold. The preview application holds no sensitive records, yet it now provides a route to a system that does. Compare two ways of writing up the same work.

Finding as a ticket: "The preview application contains a vulnerable dependency."

Finding as a path: "Compromise of the public preview application lets an attacker use its workload identity to retrieve a production credential and read a restricted database record."

The second version names the entry point, the enabling relationships, and the demonstrated consequence. It also hands defenders several places to break the path.

Some Breach Paths Are Much Shorter

A breach path does not require remote code execution, administrator privileges, or movement across several servers.

Public application → discoverable API → missing access control → sensitive records returned

The API is meant for an internal workflow, but the server never enforces that restriction. An unauthenticated caller can invoke functionality that should be limited to privileged users. OWASP files this under broken function-level authorization. A related failure happens after login. An API can verify who you are without checking whether you are allowed to see the specific record you asked for. That is broken object-level authorization, or BOLA, and it leaks one tenant's data to another.

The caller never compromises the database server. The application retrieves the data on their behalf. "Getting inside" is not only about crossing a network perimeter. NIST's zero trust guidance makes the same point: network location alone is not a basis for trust. An attacker can reach internal data through a public application without ever getting a network foothold. A two-step route to sensitive data is not less important than an eight-step one.

Why Isolated Findings Hide Connected Risk

The problem is rarely a shortage of tools. A typical program owns plenty of them, spread across code, cloud, network, attack surface, secrets, and an annual penetration test. Each is competent at its slice, and each produces findings against only its slice, rated by its own severity model.

None of them shares a picture of how the company can actually be breached. That fragmentation is what lets chains survive. The secrets scanner flags an exposed key. The API scanner flags a missing authentication check. The attack surface tool lists a staging host.

Three tools, three tickets, three unrelated severities, and not one of them says that together these findings reach write access on the identity system. The chain is invisible precisely because it crosses tool boundaries. The same gap shows up inside one company, team by team.

Every finding can be accurate. What goes missing is the relationship between them. This is not a claim that specialist tools are useless or that testers cannot chain weaknesses. Human-led testing is largely about investigating how weaknesses connect, and modern platforms add graph-based analysis on top. The distinction is between having findings and having evidence that explains their combined impact.

The breach appears only when the hosts, the code, and the data sit in the same model. Stop asking "how severe is this finding?" and start asking "what does this finding reach?" The first question rates a link. The second traces the chain.

Possibility and Proof Are Not the Same

A diagram can make a security story clear. It can also make an unproven story look convincing.

Drawing a line from a public host to a cloud identity, and another from that identity to customer data, does not establish that either hop is possible. An evidence-led graph answers a concrete question at every important connection: which identity acts, which permission allows it, which service is reachable, and which control could stop it.

A useful reporting convention separates three levels of evidence.

A solid line should mean something different from a dashed line. Deciding what counts as proof is involved enough to deserve its own treatment, covered in attack path validation.

One trap is worth naming. If one segment is validated anonymously and another needs administrator credentials the customer supplied, the two together do not prove that an unauthenticated outsider can walk the whole route. The report has to disclose the starting access and the permissions used for each segment.

Coverage shapes the result too. An incomplete inventory, missing identity context, or vague critical-asset definitions produce an incomplete graph. Microsoft's own documentation notes that missing or unrepresentative source data limits the paths it can show. "No path found" is a statement about the data available, not a guarantee that no path exists.

Prioritize the Path, Not Just the Score

Vulnerability severity is useful. It is not the whole prioritization problem.

• FIRST, the organization behind CVSS, states that a CVSS base score measures severity and should not be used alone to assess risk. Environmental and threat context are meant to adjust it.

• CISA recommends using its Known Exploited Vulnerabilities catalog as one input to prioritization. A catalog entry is evidence of exploitation in the wild, not proof of a working route through your specific environment.

Attack path analysis adds a different question. Does this weakness connect an accessible starting point to a high-impact outcome?

Where several paths share a relationship or asset, that shared point becomes a high-value fix. Microsoft calls these choke points, places where many routes converge. The business impact of a connected route is evaluated separately from the individual findings that compose it. Several medium findings do not simply add up to a critical.

How to Break an Attack Chain at Every Stage

You do not need to catch the attacker at the first stage. You need to catch them at any stage before the last one, with controls at enough stages that no complete path survives. That means mapping the chain the way an attacker would, then placing a control on every link.

A list of controls is not enough on its own, because the controls do not know about each other any more than the tools do. What ties them together is a model of the whole chain, so that a weakness at one stage is understood by what it enables at the next.

For the cloud example above, defenders could remove or patch the exposed application, restrict its identity's access to production secrets, correct unnecessary network connectivity, or reduce database privileges. The right move depends on the demonstrated route and the operational cost of each change.

A durable fix addresses the underlying cause. Fixing one endpoint is not enough when the same missing authorization check sits in a shared API layer. Rotating one credential is not enough when the replacement ships through the same leaky pipeline.

Make the verification question explicit. Can the same starting position still reach the same protected resource? Closing a ticket is an administrative event. Establishing that the route no longer works is a security result.

How AI Is Changing Attack Chains in 2026

The attack chain is an old concept, and 2026 changed the economics of walking it. AI coding agents let attackers develop exploits faster and cheaper. In the OpenAI breach above, one model version could not produce a working exploit, and the next, released the same evening, did it in hours, for a token cost under $3,000 across the whole campaign.

The tedious, skilled work of building each link in the chain is being automated. At the same time, AI multiplied the attack surface. More code shipped means more services, dependencies, and configurations, which means more potential links. The chain has more places to start and the attacker has cheaper tools to walk it.

The defensive implication is direct. When building each link gets cheaper for the attacker, the reviewable weaknesses in your own environment move back into scope. These are the ones that were technically exploitable but tedious enough that nobody bothered. The bar the attacker has to clear dropped, so the bar you have to clear on your own chain rose to meet it.

Where Attack Path Analysis Fits Across External and Internal Testing

External testing asks what an outsider can discover and reach. Internal context explains why an exposure exists, which identities and services sit behind it, and how far its impact extends. These perspectives should inform each other. External evidence guides the investigation of reachable systems. Authorized access to source code, cloud configuration, and identity relationships helps establish root causes and test the next relevant connection.

A workable operating model runs in one loop: discover exposure, investigate connections, validate impact, remediate root causes, retest. It repeats whenever conditions change. Adding assets, altering permissions, changing group membership, or adjusting segmentation all reshape the available paths.

How CodeAnt AI Detects and Validates Attack Chains

Rather than rating findings in isolation, CodeAnt AI builds one model of the company from the inside and the outside, then runs agents that chain individual weaknesses into complete, validated attack paths.

• It sees both sides of every link. The defensive layer reads code, dependencies, secrets, and cloud configuration from the inside. The offensive layer maps what is externally reachable. A link only matters when an outside exposure meets an inside weakness, and CodeAnt is built to see both ends of it.

• It chains, then proves. More than 500 exploit agents construct attack chains and validate them end to end, on the principle that a detected vulnerability is not a confirmed leak. The output is a proven path, not a finding queue. The method is described in the AI penetration testing pipeline.

• It scores by reachability, not raw severity. Every host, image, and permission is scored by the path it opens rather than the number it adds to a backlog, which is the operational form of "what does this reach?"

The proof that this finds what siloed review misses is public. CodeAnt discovered CVE-2026-29000, a CVSS 10.0 authentication bypass in the widely used pac4j library, undetected for six years. No single component was broken. The JWT specification allowed unsigned tokens, the library behaved correctly, and the null check was correct in isolation. Authentication disappeared only where those pieces met. That is the same failure class as an attack chain. Every link is fine alone, and the composition is the vulnerability.

The aim is to understand which weaknesses combine into routes to critical data, and which fixes interrupt those routes. The founder's account of running external and internal views as one model, including a proven breach path from a real assessment, is in Autonomous Preventive Security.

Where This Leaves You

An exposed host is a starting point. A vulnerability is a condition to investigate. A validated attack path explains what an attacker can actually accomplish. That is the shift worth demanding from any security program. Move from knowing that problems exist to understanding how they connect, what they endanger, and whether the fixes hold.

Security is bought in pieces. Breaches happen in chains. The job is to find the connections and break them. See which exposures connect to your critical data. Book an attack-path assessment with CodeAnt AI.