Multi-Step Attack Chain Simulation: Why Single-Vulnerability Scanning Isn't Enough
The Ivanti Cloud Service Appliances breach in late 2024 wasn't caused by a single critical vulnerability. Attackers chained four moderate vulnerabilities together: an admin bypass, a SQL injection flaw to steal credentials, and two remote code execution vectors. No individual vulnerability rated critical. Together, they gave attackers full system control.
This pattern repeats across nearly every major breach. Attackers don't exploit a single flaw — they chain multiple weaknesses into an attack path that moves from initial access to data exfiltration. Yet most security testing tools evaluate vulnerabilities in isolation. They'll tell you that you have a medium-severity information disclosure bug and a separate medium-severity authorization flaw. What they won't tell you is that combining them gives an attacker a path to your production database.
Multi-step attack chain simulation closes this gap. Instead of testing individual vulnerabilities, it models how a real attacker would chain multiple weaknesses — across different endpoints, services, and vulnerability classes — into a complete exploitation path. The result is a fundamentally different view of your actual security posture.
Penetrify — AI-powered penetration testing
What Is Multi-Step Attack Chain Simulation?
Multi-step attack chain simulation is a security testing approach that replicates how real attackers operate: discovering an initial weakness, leveraging it to gain additional access or information, then using that foothold to exploit further vulnerabilities until reaching a high-value objective.
Unlike traditional vulnerability scanning, which tests each endpoint or configuration independently and produces a flat list of findings, attack chain simulation maps the relationships between vulnerabilities. It answers the question: "If an attacker exploits vulnerability A, what does that unlock? And what can they reach from there?"
The concept maps directly to established frameworks. Lockheed Martin's Cyber Kill Chain describes seven stages an attacker progresses through, from reconnaissance to actions on objectives. MITRE ATT&CK catalogs specific tactics, techniques, and procedures (TTPs) attackers use at each stage. Multi-step attack chain simulation operationalizes these frameworks by actually executing the attack sequences — not theoretically, but against your live systems.
The distinction from breach and attack simulation (BAS) tools is worth noting. Traditional BAS tools typically replay known attack scenarios against your defenses to test detection and response capabilities. Multi-step attack chain simulation goes further: it discovers novel attack paths specific to your application by combining vulnerabilities it finds during testing, rather than replaying pre-scripted sequences.
Why Single-Vulnerability Testing Creates a False Sense of Security
Most security programs rely on vulnerability scanners, SAST tools, and periodic penetration tests that evaluate findings individually. Each finding gets a CVSS score, a severity label, and a place in the remediation queue. The problem is that this approach fundamentally misrepresents risk.
Severity Scores Don't Account for Context
A CVSS 5.0 information disclosure vulnerability on an endpoint that leaks internal API routes is medium severity in isolation. A CVSS 4.0 authorization bypass on an admin endpoint is also medium severity in isolation. But if the first vulnerability reveals the admin endpoint that the second vulnerability can bypass, the combined path is critical — full administrative access from an unauthenticated starting point.
Vulnerability scanners report both findings independently. Neither gets escalated to critical priority. The remediation team works through the backlog by CVSS score, and both sit behind the queue of "real" critical findings. Meanwhile, an attacker who discovers either vulnerability will naturally test for the other.
Flat Lists Hide Attack Paths
A security report with 200 findings, sorted by severity, is a list. What it doesn't show is the topology: which vulnerabilities connect to which, which findings are prerequisites for exploiting others, and which combinations create paths to high-value assets.
Multi-step attack chain simulation transforms this flat list into an attack graph. Suddenly the 200 findings aren't 200 independent risks — they're a smaller number of attack paths, each with a clear starting point, progression, and objective. This changes remediation strategy entirely: instead of fixing 200 individual bugs, you identify the five chokepoints that break the most critical attack chains.
Automated Scanners Can't Reason About Behavior
Traditional scanners work by matching patterns. They send known-malicious payloads and check for expected responses. This approach catches injection flaws, misconfigurations, and known CVEs effectively. But it cannot reason about application behavior.
Consider a multi-tenant SaaS application where a race condition in the session management allows an attacker to briefly access another tenant's session token. That token alone doesn't grant useful access — the application validates tenant context on most endpoints. But one legacy reporting endpoint doesn't check tenant context, allowing cross-tenant data access when combined with the stolen session token. No pattern-based scanner would discover this chain because each component behaves "correctly" in isolation.
Real-World Attack Chains: How Breaches Actually Happen
Understanding the attack chain model is easier with concrete examples from recent incidents.
The Ivanti CSA Chain (2024)
In September 2024, CISA and the FBI disclosed active exploitation of Ivanti Cloud Service Appliances through a chain of four vulnerabilities. The attackers began with CVE-2024-8963, an admin bypass that allowed initial access. They then exploited CVE-2024-9379, a SQL injection flaw, to steal credentials stored in the database. With those credentials, they leveraged CVE-2024-8190 and CVE-2024-9380 for remote code execution, achieving persistent access to the target systems.
The critical insight: none of these vulnerabilities individually would have achieved the attacker's objective. The admin bypass alone didn't provide useful data. The SQL injection required the access the bypass provided. The RCE vulnerabilities required the credentials the SQL injection extracted. Only the full chain — bypass → credential theft → code execution — produced a breach.
The Craft CMS Zero-Day Chain (2025)
Observed in active exploitation starting February 2025, attackers chained CVE-2025-32432 (RCE in Craft CMS) with CVE-2024-58136 (a vulnerability in the underlying Yii framework). The first exploit established initial code execution. The second leveraged the Yii framework to send malicious JSON payloads and execute PHP code through session files, enabling installation of a persistent file manager for ongoing system compromise.
This chain illustrates how attackers exploit relationships between an application and its framework — a connection that vulnerability scanners testing Craft CMS or Yii independently would miss.
The SaaS Vulnerability Chaining Pattern
A recurring pattern in SaaS breaches combines information disclosure with authorization flaws. In one documented case, an API endpoint leaked internal user IDs through verbose error messages (low severity). A separate endpoint had a broken object-level authorization flaw that allowed access to any user's data when provided their internal ID (medium severity). The chain: harvest IDs from error messages, then use those IDs to access arbitrary user data. Neither finding alone was alarming. Together, they exposed the entire user database.
How Multi-Step Attack Chain Simulation Works
Modern attack chain simulation combines several techniques to discover and validate exploitation paths.
Phase 1: Reconnaissance and Surface Mapping
The simulation begins by mapping the complete attack surface — every endpoint, every authentication mechanism, every data flow, every external integration. This goes beyond what's documented in API specifications. Shadow endpoints, legacy routes, and undocumented admin interfaces are all discovered through active probing and traffic analysis.
The goal is to build a graph of the application's topology: what endpoints exist, how they're connected, what data flows between them, and what authentication and authorization controls protect each one.
Phase 2: Individual Vulnerability Discovery
Next, each component in the topology is tested for individual vulnerabilities using multiple techniques: SAST for code-level flaws, DAST for runtime vulnerabilities, dependency scanning for known CVEs, and configuration analysis for misconfigurations.
This phase produces the same findings a traditional scanner would. The difference is that these findings are mapped to the application topology rather than collected as a flat list. Each vulnerability is tagged with its location in the graph, the preconditions required to reach it, and the access it could potentially provide if exploited.
Phase 3: Attack Path Discovery
This is where multi-step attack chain simulation diverges fundamentally from traditional testing. The simulation engine analyzes the vulnerability graph to identify chains — sequences of vulnerabilities that, exploited in order, create a path from an entry point to a high-value objective.
The engine considers questions like: if vulnerability A leaks credentials, can those credentials be used to authenticate to a service where vulnerability B exists? If vulnerability B provides code execution on an internal service, can that service reach an internal database that vulnerability C leaves unprotected?
AI-powered simulation engines go further by testing chains that aren't obvious from static analysis. They exploit the first vulnerability in a potential chain and observe what access it actually provides, then use that real access to test for the next link — just as a human penetration tester would follow leads during an engagement.
Phase 4: Validation and Impact Assessment
Discovered attack chains are validated through actual exploitation — not just theoretical analysis. The simulation executes each chain end-to-end to confirm that it produces the predicted outcome. This eliminates theoretical chains that don't work in practice and provides concrete proof-of-concept for chains that do.
Each validated chain receives an impact assessment based on the objective it achieves (data exfiltration, privilege escalation, service disruption), the starting access required (unauthenticated, authenticated user, insider), and the number of steps involved. This assessment drives remediation priority: a three-step chain from unauthenticated access to production database exposure gets higher priority than a six-step chain requiring insider access to reach a non-sensitive service.
Phase 5: Chokepoint Identification
The most valuable output of attack chain simulation isn't the list of chains — it's the chokepoint analysis. Chokepoints are individual vulnerabilities or controls that appear in multiple attack chains. Fixing a single chokepoint might break five or ten attack chains simultaneously, making it the highest-leverage remediation action.
This changes the remediation conversation from "we have 200 findings to fix" to "fixing these three chokepoints eliminates 80% of our critical attack paths." Security teams that prioritize by chokepoint impact rather than individual CVSS scores resolve more risk with less effort.
Multi-Step Attack Chain Simulation vs. Other Testing Approaches
Understanding how attack chain simulation relates to other security testing methods helps you position it within your security program.
vs. Vulnerability Scanning
Vulnerability scanners find individual weaknesses. Attack chain simulation finds how those weaknesses combine into exploitation paths. Scanners tell you what's broken. Attack chain simulation tells you what an attacker can actually do with what's broken. Both are necessary — scanners provide breadth, attack chain simulation provides depth and context.
vs. Traditional Penetration Testing
Manual penetration testers naturally think in attack chains — following leads, chaining exploits, and building complete attack paths. Attack chain simulation automates this reasoning. It doesn't replace skilled pentesters, but it runs continuously (rather than quarterly), covers the full surface systematically (rather than selectively based on time constraints), and documents every path it discovers reproducibly.
vs. Breach and Attack Simulation (BAS)
BAS tools replay pre-scripted attack scenarios against your defenses. They answer: "Would this known attack succeed in our environment?" Attack chain simulation answers a different question: "What attack paths exist in our specific application, including chains nobody has documented before?" BAS validates defense coverage. Attack chain simulation discovers application-specific risk.
vs. Red Teaming
Red team exercises simulate adversary behavior with broader scope — social engineering, physical access, lateral movement across the network. Attack chain simulation focuses specifically on application-layer exploitation paths. Red teaming happens annually due to cost and scope. Attack chain simulation runs continuously as part of your CI/CD pipeline.
The Role of AI in Attack Chain Discovery
Traditional attack path analysis relies on predefined rules: "if vulnerability A exists on the same host as vulnerability B, flag the chain." This approach finds known chain patterns but misses novel combinations.
AI-powered multi-step attack chain simulation changes the model. Instead of matching predefined chain patterns, AI reasons about what each vulnerability enables and explores connections dynamically. When it exploits an information disclosure flaw and discovers an internal API route, it doesn't just log the finding — it probes the discovered route for additional vulnerabilities, tests whether leaked data grants access to other services, and builds exploitation chains in real time.
This adaptive approach mirrors how skilled human penetration testers work: they follow leads, adjust tactics based on what they find, and build a comprehensive picture of what's achievable from a given starting point. The difference is scale and consistency — AI-powered simulation does this across every endpoint, on every deployment, without fatigue or time constraints.
The MITRE ATT&CK framework provides the tactical vocabulary. AI-powered simulation maps each step of a discovered chain to specific ATT&CK techniques — initial access, credential access, lateral movement, exfiltration — giving security teams a standardized way to understand, communicate, and respond to discovered attack paths.
Implementing Multi-Step Attack Chain Simulation
Adding attack chain simulation to your security program doesn't require replacing your existing tools. It layers on top of them, consuming their findings and adding chain analysis.
Start with Your Existing Vulnerability Data
If you already run SAST, DAST, or SCA tools, you have the raw material for chain analysis. Feed your existing findings into an attack chain simulation engine that maps relationships between them. The initial output will show you chains you've been sitting on — combinations of known findings that create critical exploitation paths.
Integrate into CI/CD for Continuous Coverage
Attack chain simulation should run on every significant deployment, not just periodically. As your application changes, new chains emerge and existing chains break. A new endpoint might create a bridge between two previously disconnected vulnerable components. A fixed vulnerability might break a chain without you realizing the chain existed.
Pipeline integration ensures that attack chain analysis stays current with your application. Fast scans on every PR test whether changes create new chain connections. Deep scans on a schedule explore the full graph for complex multi-step paths.
Prioritize by Chokepoint Impact
When reviewing results, resist the urge to fix chains end-to-end. Instead, identify chokepoints — the individual findings that appear in the most chains — and fix those first. A single well-chosen remediation can eliminate multiple attack paths simultaneously.
Track your chokepoint coverage as a metric: what percentage of critical attack chains are disrupted by your current remediation plan? This gives leadership a more meaningful security metric than "we fixed 47 vulnerabilities this quarter."
Validate with Manual Testing
Use attack chain simulation results to guide manual penetration testing engagements. Instead of a broad-scope quarterly pentest, focus your manual testers on the most critical chains the simulation discovered. Human testers can validate the chains, assess business impact more deeply, and explore variations that the simulation might not have considered.
This focused approach makes manual testing more efficient and more valuable — testers spend their time on confirmed high-risk areas rather than rediscovering findings your automated tools already reported.
Measuring Attack Chain Simulation Effectiveness
The metrics for attack chain simulation differ from traditional vulnerability management metrics because the unit of analysis is a path, not an individual finding.
Critical chain count tracks the number of validated attack chains that reach high-value objectives from an unauthenticated or low-privilege starting point. This number should decline over time as chokepoints are remediated.
Mean chain length measures the average number of steps in your critical chains. Longer chains generally indicate better segmentation and access controls — attackers need more steps to reach objectives. A sudden decrease in mean chain length signals a configuration change that shortened an attack path.
Chokepoint coverage measures what percentage of critical chains would be disrupted by your current remediation plan. This is the actionable metric for sprint planning: it tells you how much risk reduction each planned fix delivers.
Time to chain discovery tracks how quickly new attack chains are identified after a deployment introduces them. With CI/CD-integrated simulation, this should be hours, not weeks.
FAQ
How is multi-step attack chain simulation different from a vulnerability scanner?
Vulnerability scanners find individual weaknesses and report them independently. Attack chain simulation maps how multiple weaknesses combine into exploitation paths — showing what an attacker can actually achieve by chaining them together. A scanner might report ten medium-severity findings. Attack chain simulation shows that three of them combine into a critical path to your production database.
Does attack chain simulation require access to source code?
No. Attack chain simulation can work with black-box testing (DAST-style probing of running applications), white-box testing (analyzing source code for vulnerability connections), or a hybrid approach. Black-box simulation discovers chains through actual exploitation, while white-box analysis can identify potential chains faster by analyzing code paths.
How long does a full attack chain simulation take?
Fast scans that check for new chain connections from recent changes complete in 2–5 minutes — suitable for CI/CD integration. Comprehensive simulations that explore the full attack graph take 30–90 minutes and typically run on a nightly or weekly schedule.
Can attack chain simulation find business logic vulnerabilities?
Yes — this is one of its key advantages over pattern-based scanners. By reasoning about application behavior rather than matching known vulnerability signatures, AI-powered attack chain simulation can discover logic flaws like race conditions, workflow bypasses, and access control edge cases that only manifest when multiple steps are executed in a specific sequence.
Do we still need manual penetration testing?
Yes, but attack chain simulation makes manual testing more focused and efficient. Use simulation results to direct manual testers toward the highest-risk chains, where human creativity and domain expertise add the most value. Most organizations find they can reduce manual testing frequency while improving security outcomes.