No serious breach is a single event. It is a sequence. An attacker rarely finds one flaw that hands them everything. They find a small opening, use it to reach a slightly better position, use that to reach a better one still, and repeat until they are standing on your customer database.
Each step is modest. The path is catastrophic. That sequence has a name. It is the attack chain, and understanding it is the difference between a security program that counts findings and one that stops breaches.
This guide walks the whole chain, the frameworks that map it, a real breach step by step, and the single shift in thinking that actually breaks it.
The core problem this article is about: most security tools rate findings one at a time, and no attacker breaches you one finding at a time. CodeAnt AI is built around the chain rather than the finding, with agents that link individually low-severity weaknesses into the complete path an attacker would actually walk. This piece explains the concept that idea rests on.
What Is an Attack Chain in Cybersecurity?
An attack chain is the ordered series of steps an attacker takes to move from their first point of access to their final objective, such as stealing data or disrupting a system.
The defining property is dependency. Each stage builds on the one before it. An attacker cannot move laterally through a network they have not entered, and cannot exfiltrate data they have not reached. Break any single link and, in principle, the whole chain stops there. That property is also the defender's opportunity. You do not have to catch the attacker at the first step.
You have to catch them at any step, before they reach the last one. A breach is a race along a chain, and every link is a place to intervene. The word that matters is combine. A single weakness is often harmless on its own.
An exposed staging server with no sensitive data is a low-severity finding. A read-only API with no authentication is a medium one. A secret in a JavaScript bundle is a routine cleanup ticket. Chain those three together and you have write access to an identity system. Severity lives in the chain, not in the link.
Attack Chain vs Cyber Kill Chain vs MITRE ATT&CK
These three terms are 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. It is descriptive and framework-agnostic.
The Cyber Kill Chain is a specific model of an attack chain, developed by Lockheed Martin in 2011, that breaks a network intrusion into seven fixed phases. It is the classic, linear framing, and it is where the idea is usually first encountered.
MITRE ATT&CK is a third model, a large and living knowledge base of real-world adversary tactics and techniques, organised into tactic categories. It is not linear, it is far more granular, and it reflects how attack paths actually branch and loop rather than marching in a straight line.
Cyber Kill Chain | MITRE ATT&CK | Attack chain (general) | |
|---|---|---|---|
What it is | A fixed 7-phase model | A knowledge base of tactics and techniques | The underlying concept |
Shape | Linear, sequential | Branching, non-linear | Either |
Origin | Lockheed Martin, 2011 | MITRE, ongoing | Descriptive term |
Granularity | High-level phases | Hundreds of specific techniques | Variable |
Best for | Explaining the concept | Mapping real observed activity | Talking about paths in general |
The practical takeaway. 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. And use "attack chain" to talk about the specific path through your environment that matters to you.
What Are the Stages of an Attack Chain?
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 their first foothold, through a phishing email, an exposed service, a leaked credential, or a public-facing exploit. This is covered in depth in our 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 the subject of our 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 our guide to lateral movement in cyber security.
6. Collection and exfiltration. The attacker locates the target data and moves it out, often over a channel designed to look like normal traffic. This is covered in our guide to data exfiltration.
Seeing all of these as one connected graph, rather than a checklist, is its own discipline, covered in our guide to attack path analysis.
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. They found that 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. They discovered that 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 our analysis of that incident.
Now notice the crucial thing. Of the links in that chain, most were third-party bugs the target inherited. But 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.
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.
This is why a defense that fixates on one stage fails. Blocking the phishing vector does nothing about the exposed credential in a public repository.
The attacker simply takes the path you left open. Real defense requires controls at multiple stages, because the attacker only needs one complete path and you have to close all of them.
Why Security Tools Miss Attack Chains
Here is the core problem, and it is not a shortage of tools. A typical program owns plenty of them.
A typical security program spreads coverage across separate products. One for code, one for cloud, one for the network, one for attack surface, one for secrets, plus an annual penetration test. Each one is competent at its slice. And each one 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. This is the fragmentation that lets chains survive. The secrets scanner flags the exposed key. The API scanner flags the missing authentication. The attack surface tool lists the staging host.
Three tools, three tickets, three unrelated severities, and not one of them says that together these three findings reach write access on the identity system. The chain is invisible precisely because it crosses tool boundaries. Each individual finding looks like routine backlog. The breach only appears when the hosts, the code, and the data sit in the same model, and no siloed tool builds that model.
How to Break an Attack Chain: Defense at Every Stage
The strategic principle is simple to state. You do not need to catch the attacker at the first stage. You need to catch them at any stage before the last one, and you need 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.
Stage | The control that breaks it |
|---|---|
Reconnaissance | Attack surface management, minimising what is externally visible |
Initial access | Secret scanning, patching exposed services, phishing resistance |
Privilege escalation | Least privilege, scoped credentials, IAM hygiene |
Lateral movement | Network segmentation, zero trust, identity monitoring |
Exfiltration | Egress control, data loss prevention, anomaly detection |
But 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 in the context of what it enables at the next.
That is the shift. 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.
How CodeAnt AI Detects and Validates Attack Chains
This is where the concept becomes a product decision, and CodeAnt's is specific.
Rather than rating findings in isolation, CodeAnt builds one model of the company from the inside and the outside, then runs agents that chain individual weaknesses into complete, validated attack paths.
In our own words, our agents construct and validate attack chains, sequences of findings that individually appear low severity but combine into critical exploit paths. That is the exact problem this article describes, addressed directly.
It sees both sides of every link. The defensive analysis layer reads the 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 positioned to see both ends of it.
It chains, then proves. More than 500 exploit agents do not run isolated checks. They 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 full method is in our writeup of 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.
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.
An Attack Chain Only Matters If You Can Break It
A breach rarely starts with a critical vulnerability. It starts with one weakness that gives an attacker a foothold, another that lets them move further, and another that finally puts something valuable within reach. Individually, those findings can look manageable. Chained together, they can become the breach.
That is why security teams cannot afford to look at vulnerabilities one ticket at a time.
The question is not just “How severe is this finding?”
It is “What can an attacker reach by chaining it with everything else?”
CodeAnt AI is built to answer that question. Its AI agents connect vulnerabilities across your code, infrastructure, cloud, identities, and attack surface to uncover and validate complete attack paths, so you can see how an attacker could actually move from entry point to impact. Find the chain before an attacker does.
