Introduction
When security teams discuss vulnerabilities, they often focus on individual findings: a SQL injection here, a misconfigured S3 bucket there, an outdated library with a known CVE. But attackers don't think in terms of isolated vulnerabilities—they think in terms of attack paths.
An attack path is a sequence of actions and exploited vulnerabilities that allows an attacker to progress from an initial access point to a valuable target. Understanding attack paths is fundamental to effective security testing, because a chain of minor vulnerabilities can create a critical breach that wouldn't be apparent from examining any single weakness in isolation.
This guide explains what attack paths are, how they work, why traditional vulnerability scanning misses them, and how modern penetration testing identifies and documents these multi-step exploitation scenarios.
Defining Attack Paths
An attack path represents the journey an attacker takes from their starting point to their objective. It's composed of:
Entry Points: How the attacker initially gains access to your environment
- Public-facing web applications
- Exposed APIs
- Phishing campaigns targeting employees
- Compromised credentials from previous breaches
- Physical access to facilities
Pivot Points: Intermediate steps that expand access
- Privilege escalation vulnerabilities
- Lateral movement opportunities
- Credential harvesting from compromised systems
- Exploitation of trust relationships
Objectives: What the attacker ultimately wants to achieve
- Access to sensitive data (customer records, intellectual property)
- Financial gain (fraud, ransomware)
- Service disruption
- Persistence for ongoing access
A single vulnerability might seem minor in isolation—a low-severity information disclosure, for example—but if it enables an attacker to reach a higher-value target, it becomes part of a critical attack path.
Anatomy of an Attack Path: An Example Scenario
Consider this hypothetical but realistic attack path in a SaaS application:
Step 1: Information Disclosure (Low Severity)
The attacker discovers that the application's error messages reveal internal server paths and software versions. This is typically rated as a low-severity finding—it doesn't directly expose data or allow unauthorized access.
Traditional scanner verdict: Low priority, minimal risk.
Step 2: Credential Stuffing Using Exposed Information (Medium Severity)
Using the revealed software version, the attacker identifies a specific configuration vulnerability. They also notice that password reset tokens are predictable based on timestamp. They launch a credential stuffing attack against user accounts.
Traditional scanner verdict: Unrelated to Step 1 findings.
Step 3: Account Takeover (High Severity)
The attacker successfully compromises a low-privilege user account through the credential stuffing attack. They can now access authenticated areas of the application.
Traditional scanner verdict: Separate finding, not connected to infrastructure vulnerabilities.
Step 4: Privilege Escalation via IDOR (High Severity)
As an authenticated user, the attacker discovers an Insecure Direct Object Reference (IDOR) vulnerability. By modifying the user_id parameter in API requests, they can access administrative functions reserved for higher-privilege users.
Traditional scanner verdict: Application vulnerability, documented separately.
Step 5: Admin Panel Access and Data Exfiltration (Critical Severity)
With administrative access, the attacker exports the entire customer database, including names, email addresses, payment information, and personal data.
Traditional scanner verdict: This is the breach, but the path to get here wasn't documented.
The Attack Path Perspective
Individually, these findings might be prioritized and remediated in isolation. But when viewed as an attack path, the information disclosure in Step 1 becomes part of the chain that enabled the critical breach in Step 5.
The total risk isn't the sum of individual severities—it's the impact of what the attacker can ultimately achieve by chaining these vulnerabilities together.
Why Traditional Testing Misses Attack Paths
Vulnerability Scanners
Automated vulnerability scanners excel at identifying known vulnerabilities with specific signatures:
- CVEs in software libraries
- Missing security headers
- Outdated SSL/TLS configurations
- Common injection patterns
But scanners struggle with:
- Context: Understanding how one finding relates to another
- Business logic: Recognizing what actions are valuable in your specific application
- Multi-step scenarios: Chaining exploits across different vulnerabilities
- Stateful testing: Maintaining session context across complex workflows
Traditional Penetration Testing
Manual penetration testers can identify attack paths, but time constraints often limit how deeply they can explore:
- Fixed scoping (40 hours of testing regardless of application complexity)
- Point-in-time assessment (no ongoing visibility into attack paths)
- Documentation limitations (attack paths may be identified but not fully documented)
The Gap
The result is that organizations often remediate individual vulnerabilities without understanding the attack paths that make those vulnerabilities dangerous. A low-severity finding that's part of a critical attack path should be prioritized differently than the same finding in isolation.
How Attack Path Analysis Works
Effective attack path analysis requires:
Stateful Testing
The testing tool or methodology must maintain context across the assessment:
- Remembering discovered credentials
- Tracking session state
- Understanding user roles and permissions
- Following authentication flows
Contextual Reasoning
The testing must understand what's valuable in your environment:
- Which data is sensitive
- What actions have business impact
- Which systems are critical
- What trust relationships exist
Chaining Logic
The testing must be able to chain findings together:
- Using output from one exploit as input to another
- Maintaining access across multiple steps
- Tracking progress toward objectives
- Identifying alternative paths when one is blocked
Documentation
Attack paths must be documented clearly:
- Visual representation of the path
- Business impact of successful exploitation
- Remediation priorities based on path disruption
- Evidence for each step in the chain
Attack Path Examples by Category
Web Application Attack Paths
Credential Harvest to Data Exfiltration:
- XSS vulnerability in user profile
- Steal session cookies from victim
- Access authenticated areas as victim
- Exploit IDOR to access other users' data
- Export sensitive records
File Upload to Remote Code Execution:
- Upload malicious file through allowed file type
- Bypass file type validation via extension manipulation
- Access uploaded file, triggering execution
- Gain server-level access
- Pivot to database containing sensitive data
Network Attack Paths
External to Internal Lateral Movement:
- Phishing attack compromises employee credentials
- VPN access using stolen credentials
- Network scanning reveals internal services
- Exploit unpatched internal server
- Access domain controller
- Dump credentials for lateral movement
- Access sensitive file shares and databases
Cloud Attack Paths
IAM Misconfiguration to Data Access:
- Discover overly permissive IAM role
- Assume role with excessive privileges
- Access S3 buckets containing sensitive data
- Use assumed role to access secrets manager
- Retrieve database credentials
- Query production database directly
Prioritizing Remediation Based on Attack Paths
When you understand attack paths, you can prioritize remediation more effectively:
Disrupt the Path, Not Just the Finding
Sometimes the most effective remediation isn't fixing every vulnerability in the chain, but breaking the chain at its weakest point:
- Fixing the initial access point might be easier than hardening all downstream systems
- Adding MFA might disrupt credential-based attack paths regardless of other vulnerabilities
- Network segmentation might prevent lateral movement even if internal systems are vulnerable
Risk-Based Prioritization
Not all attack paths are equal. Prioritize based on:
- Impact: What's the business impact if this path is successfully exploited?
- Likelihood: How easily can an attacker discover and execute this path?
- Detectability: Will you know if someone is attempting this attack path?
- Remediation cost: What's the effort required to disrupt this path?
Attack Path Analysis Checklist
When evaluating your security testing, ensure it addresses attack paths:
- Testing maintains state across the assessment
- Findings are connected, not just listed individually
- Multi-step exploitation scenarios are explored
- Business context informs what paths are valuable
- Attack paths are documented visually
- Remediation guidance considers path disruption
- Results explain business impact, not just technical details
Conclusion
Understanding attack paths transforms how you think about security testing. Instead of treating vulnerabilities as isolated findings to be prioritized and fixed independently, you see them as potential steps in an attacker's journey.
This perspective changes everything:
- A low-severity finding that's part of a critical attack path becomes urgent
- Remediation focuses on disrupting paths, not just patching CVEs
- Testing validates not just that vulnerabilities exist, but what an attacker could actually do
In a world where attackers think in terms of attack paths, your security testing should too.
RedVeil's AI-powered penetration testing identifies multi-step attack paths that traditional scanning misses, with stateful agents that maintain context across complex exploitation scenarios and documentation showing how findings connect.