Key Takeaways
- An attack chain is a linked sequence of small weaknesses that add up to a full compromise, not one dramatic hack.
- Red teams plan attack chains using frameworks like the Cyber Kill Chain and MITRE ATT&CK to keep the work structured and repeatable.
- The chain typically moves through recon, initial access, execution, privilege escalation, lateral movement, and finally the objective itself.
- A chain is only as strong as its weakest, quietest link. Attackers look for the boring stuff: a stale password, an open port, a forgotten service account.
- Annual red team tests only catch the chain that existed on test day. Your environment changes every week, so the chain does too.
In July 2025, attackers didn’t need a zero-day to walk out with data on 1.4 million people. They talked their way into a third-party CRM platform through a simple social engineering trick. A few weeks later, a nearly identical story played out at another company, this time hitting 4.4 million records. Neither business got hit by one massive exploit. They got hit because a handful of small, unremarkable weaknesses lined up just right.
That lineup is called an attack chain. And building one on purpose, safely and with permission, is exactly what a red team does for a living.
What Is an Attack Chain, Exactly?
An attack chain is the full path an attacker takes from their first foothold to their final goal. It’s rarely one clever trick. It’s a series of smaller steps, each one opening the door to the next.
Picture it like a set of dominoes. A weak password by itself might not matter much. But that password gets an attacker into an email account. That email account has access to a shared drive. That drive has a spreadsheet with admin credentials someone forgot to delete. Now the attacker owns the domain. No single step looks scary on its own. Together, they’re a breach.
Red teams build this same kind of chain, minus the actual damage, to answer one question for a company: if a real attacker started here, how far could they actually get?
Attack Chain vs. Kill Chain: Are They the Same Thing?
Mostly, yes. “Kill chain” comes from military language and was adapted for cybersecurity as the Cyber Kill Chain, a seven-stage model: recon, weaponization, delivery, exploitation, installation, command and control, and actions on objectives. “Attack chain” is the more general term for the same idea, the connected sequence of steps an attacker follows. Some teams also use the Unified Kill Chain, an 18-stage model that folds in more of what happens after the initial break-in. Whichever label you use, the point stays the same: attacks are chains, not single events.
How Red Teams Actually Build an Attack Chain, Step by Step
Here’s what the process looks like in practice, based on how most professional red team engagements are actually run.
Five steps. One full compromise.
No single link looks dangerous on its own — that’s the point. Here’s the path a red team (and a real attacker) follows from first contact to final objective.
Reconnaissance
LinkedIn profiles, exposed subdomains, forgotten test servers, and vendor integrations — 20–30% of the whole engagement.
Initial Access
Phishing, an exposed app, an abused VPN, or a soft entry through a third-party connection. Just one working foothold.
Execution & Persistence
A scheduled task or small backdoor, so the foothold survives a reboot or password change.
Privilege Escalation & Lateral Movement
Misconfigured permissions, cached credentials, and weak segmentation turn one small win into a real chain.
Actions on Objectives
Domain admin, customer records, or financial systems — the scoped goal, documented step by step.
Step 1: Reconnaissance
Before anyone touches a keyboard against the live target, the team gathers intelligence. This is often the most time-consuming phase, sometimes 20 to 30 percent of the whole engagement. They’re looking for:
- Public employee information (LinkedIn, company bios, conference talks)
- Exposed subdomains, cloud storage buckets, and forgotten test servers
- Technology stack clues from job postings and DNS records
- Third party vendors and integrations that might offer a softer way in
Good recon isn’t glamorous. It’s mostly reading. But it decides everything that comes next. Teams that skip it end up guessing.
Step 2: Initial Access
This is the first real foothold. Common entry points include:
- Phishing or spear phishing emails
- Exploiting an internet-facing application
- Abusing exposed remote access tools like VPNs or RDP
- Compromising a third party or supply chain connection
The goal at this stage is small. Get one working credential, one running shell, one foot in the door. Nothing more.
Step 3: Execution and Persistence
Once inside, the red team needs to make sure that foothold survives a reboot or a password change. This might mean creating a scheduled task, planting a small backdoor, or setting up a way to reconnect later. Real attackers do the same thing because losing access after all that recon work is a waste of their time too.
Step 4: Privilege Escalation and Lateral Movement
A single low-level account rarely gets an attacker to the goal. So the chain grows. Teams look for:
- Misconfigured permissions that let a regular user act like an admin
- Cached credentials sitting in memory
- Trust relationships between systems that let one compromised machine reach another
- Weak segmentation between departments, cloud accounts, or environments
This is where a single weakness turns into a real attack chain. One small win opens access to the next system, and the next.
Step 5: Actions on Objectives
Every engagement is scoped around a specific goal set with the client ahead of time. That might mean reaching a database with customer records, gaining domain admin, or proving access to financial systems. The red team documents exactly how they got there, what worked, what got flagged, and what didn’t.
Why MITRE ATT&CK Matters for Building an Attack Chain
A red team engagement that isn’t mapped to a real framework produces a story. One that is mapped produces something you can actually reuse: a checklist your SOC can retest, prioritize, and automate against.
That’s where MITRE ATT&CK comes in. It’s a public knowledge base of real adversary tactics and techniques, built from actual observed attacks rather than theory. Instead of vague terms like “hacked in,” ATT&CK gives every action a specific label. Credential dumping from a system’s memory is T1003.001. Spearphishing with a malicious attachment is T1566.001. That specificity means a finding from one engagement can be compared directly to another, six months later, run by a completely different tester.
Here’s roughly how a red team uses it to plan a chain:
From vague story to reusable checklist
ATT&CK gives every action a specific, comparable label instead of a vague “hacked in.” Here’s how a red team uses it to plan a chain.
Pick a realistic adversary
Anchor the scenario to a documented threat group with known, mapped behavior.
Extract known techniques
Pull the specific, labeled techniques that group uses from initial access to objective.
Build the emulation plan
String those techniques into a believable order — this is the part automation still can’t do alone.
Run, log, report
Execute the emulation and hand the defensive team a report mapped directly to ATT&CK.
Why it matters: a finding logged this way can be compared directly to another engagement, six months later, run by a completely different tester.
Open-source tools like MITRE CALDERA and Atomic Red Team help automate parts of this, running individual ATT&CK techniques as repeatable tests. However, these tools require significant expertise to configure, interpret results, and avoid disrupting production environments. But stringing those individual tests into a full, believable chain still takes a skilled operator who understands how one technique sets up the next.
Why a One-Time Attack Chain Test Isn’t Enough Anymore
Here’s the part most companies get wrong: they run a red team engagement, get a clean report, and file it away for the year. But a typical four-week penetration test only reaches approximately 15 to 30 percent of an organization’s real attack surface. The other 70 to 85 percent sits untested until the next scheduled engagement, whenever that is.
And your environment doesn’t sit still while you wait. Say your team passes a red team test in March. By June, you’ve shipped forty new releases, spun up a few new cloud services, and onboarded three new SaaS tools. Every one of those changes could open a new link in a new attack chain, and nobody has tested it yet.
Your environment changes weekly. Your testing shouldn’t wait a year.
Secure.com’s Infrastructure Security (Cloud) Teammate keeps testing running between engagements, not just once a year.
- Continuously monitors your environment for new deployments, segmentation changes, and new cloud accounts.
- Tests every change automatically to see whether it opens a new attack path — no waiting for the next scheduled pentest.
- Maps every finding to MITRE ATT&CK, so your SOC gets business-impact context, not just a failed scan.
- Frees your red team for the harder work — the creative, business-context chaining automation still can’t replicate.
This is exactly the gap that continuous, automated red teaming with human oversight closes. Instead of waiting on a fixed yearly calendar, Secure.com’s Infrastructure Security (Cloud) Teammate monitors your environment for changes (new deployments, segmentation modifications, new cloud accounts) and tests whether those changes introduce new attack paths. Findings map to MITRE ATT&CK techniques, providing your SOC with context on which attack techniques are viable and their business impact, not just that “something failed a scan.” Continuous, ATT&CK-aligned testing augments human red teamers. It handles the repeatable, technique-based layer so your offensive security team can spend their time on the creative, business-context work that automation still can’t fully replicate.
FAQs
Is a red team the same as a penetration test?
Can building an attack chain be automated?
How long does it take a red team to build a full attack chain?
What’s the difference between an attack chain and a kill chain?
The Bottom Line
Attackers rarely need a brilliant exploit. They need a handful of small, unremarkable gaps that happen to line up. Building an attack chain, whether you’re the one testing it or the one trying to stop it, comes down to the same discipline: understand the individual techniques, map them to something structured like MITRE ATT&CK, and test the full path regularly enough that you’re not finding out about a broken link the same week an actual attacker does.
