Attack Path Analysis

Infracast automatically discovers and visualizes potential attack paths in your infrastructure. Unlike scanners that report isolated findings, attack path analysis shows how vulnerabilities chain together to enable real-world attacks — with full route awareness, EPSS-based prioritization, and cross-environment traversal.

Overview

Attack paths represent the steps an attacker could take to move through your environment:

• Entry Point — Initial access vector (public-facing asset, compromised credential)
• Hops — Intermediate steps using misconfigurations or permissions
• Target — High-value asset (database, secrets manager, admin access)

Infracast attack paths are route-confirmed, EPSS-enriched, and cross-environment-aware. A path that looks dangerous on a graph but is blocked by actual routing is no longer surfaced — only real, traversable paths appear.

---

Attack Path Categories

Lateral Movement

Movement between resources using network access or trust relationships.

Example: Internet → Public EC2 → Private Subnet → RDS Database

Risk Factors:

• Overly permissive security groups
• Missing network segmentation
• EC2 instances with SSM access to other resources

Data Exfiltration

Paths that could lead to sensitive data leaving the environment.

Example: Compromised EC2 → S3 Bucket (no VPC endpoint) → Internet egress

Risk Factors:

• Public S3 buckets
• Missing VPC endpoints
• Unrestricted outbound traffic

Privilege Escalation

Paths where lower-privileged access can gain higher privileges.

Example: IAM User → AssumeRole → Admin Role → Full Account Access

Risk Factors:

• Overprivileged IAM roles
• Missing permission boundaries
• Cross-account trust without external ID

Initial Access

Entry points attackers could use to gain initial foothold.

Example: Public ALB → EC2 with unpatched CVE → Shell Access

Risk Factors:

• Public-facing services
• Missing WAF/Shield
• Outdated software

Persistence

Mechanisms attackers could use to maintain access.

Example: Compromised Lambda → Creates IAM User → Backdoor Access

Risk Factors:

• Excessive IAM permissions
• Missing CloudTrail alerts
• No break-glass procedures

---

Route-Aware Path Analysis

Previously, attack path traversal used raw graph adjacency — two nodes connected in the topology graph were treated as reachable, even if actual routing would block the hop. This produced false positives: paths that looked dangerous but were never traversable in practice.

Infracast integrates reachability.ComputeSubnetReachability directly into the attack path engine:

• Every candidate hop is checked against actual route tables, BGP routing, and tunnel configurations
• Hops with no valid egress route are pruned before a path is surfaced
• Each PathNode carries a RouteConfirmed flag indicating whether the hop was validated against the routing fabric
• The path tracer can distinguish route_blocked from sg_blocked — two very different remediation stories

What this means operationally:

• Fewer false positives — paths that were theoretical but routing-blocked no longer appear
• Actionable results — every surfaced path is one an attacker could actually take
• Routing context — each hop shows why it's reachable (which route table, which tunnel, which BGP path)

The route-aware engine consumes routing data from AWS/Azure/GCP route table parsing, routes_to edges to IGW/NAT/TGW/VGW/peering, network device RIB, BGP best-path selection, ECMP 5-tuple flow hashing, and IPsec/WireGuard/GRE/VXLAN tunnel introspection.

---

Cross-Environment Traversal

Attack paths can cross environment boundaries — cloud to on-prem, cloud to cloud via private connectivity, and internet to private via relay bridges.

Bridge detection: The engine identifies nodes that serve as environment boundary bridges:

• AWS Direct Connect (DX) gateways and virtual interfaces
• VPN gateways and site-to-site tunnels
• Azure ExpressRoute circuits and gateways
• GCP Interconnect attachments
• On-prem relay nodes

PathNode fields:

• IsBridgeNode — true if this hop crosses an environment boundary
• BridgeType — the type of bridge (dx, vpn, expressroute, interconnect, relay)

AttackPath field:

• CrossesEnvironmentBoundary — true if any hop in the path is a bridge node

Risk bonus: Paths that cross environment boundaries receive a +15 risk bonus on top of their base score. A cross-environment path is a more severe finding because:

1. It often bypasses cloud-native security controls (SGs, NACLs)
2. The on-prem segment may have weaker detection/monitoring
3. Network segmentation assumptions break down at the boundary

Example cross-environment path:

Internet → Public ALB (AWS) → EC2 (us-east-1) → DX Gateway [bridge] → On-prem Cisco router → Internal RDS-equivalent (on-prem)

Previously, this path would have been invisible because the attack path engine didn't model DX/VPN bridges.

---

EPSS-Based Risk Scoring

Infracast integrates the FIRST.org EPSS (Exploit Prediction Scoring System) feed to add exploit probability into attack path risk scoring.

What is EPSS?

EPSS is a daily-updated probabilistic score (0–1) for each CVE, representing the probability that vulnerability will be exploited in the wild within 30 days. It is published by FIRST.org and is free/open.

A CVSS 9.8 vulnerability with EPSS 0.01 is less urgent than a CVSS 7.0 with EPSS 0.94 — EPSS corrects for the fact that most CVEs are never exploited.

EPSS Implementation

The EPSS module:

• Downloads epss_scores-current.csv.gz from FIRST.org daily
• 24-hour TTL in-memory cache with lazy background refresh
• Thread-safe via sync.RWMutex; graceful degradation if feed is unavailable
• DefaultFetcher singleton for use across the codebase
• Provides CVE → EPSS score lookup with fallback to 0.0

EPSS Risk Bonuses (applied per hop)

Condition	Risk Bonus
EPSS > 0.9 and in CISA KEV	+25
EPSS > 0.7	+15
EPSS 0.3–0.7	no bonus (base CVSS scoring applies)
EPSS < 0.3	no bonus

CVEs are sourced from the SBOM store — each node's package inventory is cross-referenced against EPSS scores. Nodes with high-EPSS CVEs in their software stack receive increased risk contributions to any path they participate in.

PathNode EPSS Fields

• RouteConfirmed — whether this hop was validated against the route fabric (distinct from EPSS, but related: both improve path fidelity)

ThreatContext EPSS Fields

Each AttackPath.ThreatContext is now populated with:

• EPSSMax — highest EPSS score across all CVEs in the path
• EPSSCVEs — array of CVE IDs contributing EPSS scores to the path

---

Finding-Chain Correlation

Infracast detects finding-chain correlation — "toxic combinations" where multiple lower-severity findings chain together into a composite critical risk.

Logic

When an attack path contains:

• 3 or more AffectedFindings across 2 or more hops

The path is flagged as:

• IsChainedRisk = true
• ChainedRiskReason = human-readable explanation (e.g., "toxic combination: 3 findings across 4 hops create a composite CRITICAL path from internet to prod RDS")
• The path's effective severity is escalated to CRITICAL regardless of individual finding severities

This is the core "toxic combination" insight: a MEDIUM misconfiguration + a LOW IAM finding + a MEDIUM unpatched CVE in sequence is far more dangerous than any one finding in isolation.

Example chain:

Finding 1 (MEDIUM): Security group allows 0.0.0.0/0 on port 8080 → EC2 running outdated Nginx
Finding 2 (MEDIUM): EC2 instance role has s3:GetObject on * (overly broad)
Finding 3 (LOW): S3 bucket contains SSM parameter store credentials (detected via SBOM)
→ ChainedRisk: CRITICAL — internet to EC2 to S3 to credential exfiltration in 3 steps

AttackPath Fields

• IsChainedRisk — true if 3+ findings across 2+ hops
• ChainedRiskReason — descriptive explanation of the chain

---

ThreatContext Enrichment

Every attack path now carries a fully populated ThreatContext struct (previously defined but never populated):

Field	Source	Description
EPSSMax	EPSS feed	Highest EPSS score across all CVEs in path
EPSSCVEs	SBOM store	CVE IDs contributing EPSS scores
KEVHits	CISA KEV feed	CVEs in path that are in CISA's Known Exploited Vulnerabilities catalog
MITRETechniques	Threat Intel	MITRE ATT&CK technique IDs annotated per hop
ThreatActors	Threat Intel	Named threat actors associated with techniques in this path
ThreatLevel	Computed	critical/high/medium/low — escalated by EPSS tier

Threat level escalation logic:

• EPSS > 0.9 + KEV → escalates to critical
• EPSS > 0.7 → escalates to high (if not already critical)
• No EPSS data → uses existing KEV/MITRE-based scoring

---

Risk Scoring

Each attack path has a risk score (0–100) based on weighted factors:

Factor	Weight	Notes
Severity of target asset	35%	Crown jewels (prod RDS, secrets, admin) score highest
Exposure level of entry point	25%	Internet-facing > adjacent > internal
Number of hops (shorter = worse)	15%	Fewer hops = easier to execute
EPSS scores on path CVEs	15%	Up to +25 bonus from high-EPSS+KEV CVEs
Compensating controls present	10%	WAF, MFA, segmentation reduce score

Additive risk bonuses (applied on top of base score):

• Cross-environment boundary traversal: +15
• EPSS > 0.9 + KEV: +25 (per affected hop)
• EPSS > 0.7: +15 (per affected hop)
• Chained risk (3+ findings, 2+ hops): severity escalated to CRITICAL

---

Using Attack Path Analysis

Viewing Attack Paths

1. Navigate to Attack Paths in the sidebar
2. Paths are sorted by severity (CRITICAL, HIGH, MEDIUM, LOW)
3. Paths marked with 🌐 cross environment boundaries
4. Paths marked with ⛓️ are chained-risk findings
5. Click a path to see the full hop-by-hop breakdown with route confirmation, EPSS scores, and ThreatContext

Topology Integration

Click View on Topology Map to see the attack path overlaid on your infrastructure graph:

• Path hops are highlighted
• Bridge nodes (DX/VPN/ExpressRoute) are distinctly marked
• Risk indicators show at each node including EPSS contribution
• Pan and zoom to explore context

Path Detail View

Each hop shows:

• Asset involved (node type and name)
• RouteConfirmed: whether the hop was validated against route fabric
• IsBridgeNode / BridgeType: if this hop crosses an environment boundary
• CVEs at this node with EPSS scores
• Risk factor (why it's exploitable)
• Remediation recommendation

---

API Endpoints

List Attack Paths

GET /api/v1/tenants/{tenantID}/attack-paths

Returns all discovered attack paths, sorted by severity. Response now includes CrossesEnvironmentBoundary, IsChainedRisk, ChainedRiskReason, and ThreatContext.EPSSMax for each path.

Get Attack Path Detail

GET /api/v1/tenants/{tenantID}/attack-paths/{pathID}

Returns detailed information about a specific attack path, including full hop-by-hop RouteConfirmed, IsBridgeNode, BridgeType, and per-CVE EPSS scores.

PathNode Fields

Field	Type	Description
RouteConfirmed	bool	Hop validated against route tables/BGP/tunnels
IsBridgeNode	bool	Node crosses an environment boundary
BridgeType	string	"dx", "vpn", "expressroute", "interconnect", "relay"

AttackPath Fields

Field	Type	Description
CrossesEnvironmentBoundary	bool	Path contains one or more bridge hops
IsChainedRisk	bool	3+ findings across 2+ hops
ChainedRiskReason	string	Human-readable chain description

ThreatContext Fields

Field	Type	Description
EPSSMax	float64	Highest EPSS score across all CVEs in path
EPSSCVEs	[]string	CVE IDs contributing EPSS scores

---

Remediation Priority

Fix attack paths in this order:

1. CRITICAL chained-risk paths — Multiple findings creating composite risk (IsChainedRisk=true)
2. CRITICAL paths to crown jewels — Databases, secrets, admin access
3. Cross-environment paths — Higher blast radius, harder to detect
4. High-EPSS CVE paths — EPSS > 0.7 means real-world exploitation is likely within 30 days
5. Short paths (few hops) — Easier to exploit
6. Paths from internet — Higher likelihood of exploitation
7. MEDIUM/LOW paths — Defense in depth

---

Best Practices

1. Segment Networks — Isolate sensitive workloads in private subnets; route-aware paths will confirm whether segmentation is actually effective
2. Prioritize EPSS-High CVEs — Use EPSS scores (not just CVSS) to prioritize patching; a CVSS 7 with EPSS 0.9 is more urgent than a CVSS 9.8 with EPSS 0.01
3. Least Privilege IAM — Remove unnecessary permissions that create chained-risk paths
4. Monitor Bridge Nodes — DX/VPN/ExpressRoute gateways are high-value targets; ensure logging and anomaly detection are enabled on all bridge nodes
5. Enable MFA — Require MFA for privileged access, especially on paths crossing environment boundaries
6. Patch KEV+EPSS CVEs First — CVEs that are both in CISA KEV and have EPSS > 0.9 represent the highest-confidence exploitation risk
7. Regular Reviews — Re-run attack path analysis after infrastructure changes, route table modifications, or new CVE disclosures
8. Eliminate Chained Findings — Break chained-risk paths by remediating any single finding in the chain — you don't need to fix all of them to eliminate the composite CRITICAL

---

Scan Lineage & Resource Lifecycle

Infracast tracks the full lifecycle of discovered resources using scan lineage metadata.

How It Works

Every node and edge in the topology graph now carries:

Field	Description
first_seen_scan_id	The scan ID that first discovered this resource
last_seen_scan_id	The most recent scan ID that observed this resource
deleted_at	Timestamp when the resource was soft-deleted (disappeared from scan)

After each AWS/Azure/GCP scan completes, PurgeStaleNodes runs and marks any resource not seen in the latest scan with deleted_at = now(). These resources are soft-deleted — they remain in the database for 90 days before hard purge.

Impact on Attack Paths

Attack paths only traverse live resources. All topology queries filter deleted_at IS NULL, which means:

• A resource that was deleted (e.g., an EC2 instance terminated, an IAM role removed) is immediately removed from attack path traversal
• Paths that relied on that resource are invalidated and will no longer appear
• Historical path data remains available for 90 days for forensic review

This prevents stale topology from producing phantom attack paths — every surfaced path reflects the current state of your infrastructure.

Foundation for Time-Travel / Rewind

The first_seen_scan_id / last_seen_scan_id / deleted_at triplet is the foundation for future topology rewind — the ability to replay your infrastructure topology as it appeared at any point in time. This will power change-diff views and pre/post-incident analysis.

---

IAM Relationship Edges & Attack Chain Traversal

Infracast added security-relevant IAM relationship edges to the topology graph, enabling more accurate and complete attack path chaining.

New Edge Coverage

From	To	Edge Type	Attack Path Relevance
aws.iam.policy	aws.iam.role	attached_to	Identifies which roles a policy grants
aws.iam.policy	aws.iam.user	attached_to	Identifies which users a policy applies to
aws.lambda.function	aws.iam.role	executes_as	Lambda's execution identity
aws.ec2.instance	aws.iam.role	depends_on	EC2 instance profile role
aws.cloudtrail.trail	aws.s3.bucket	logs_to	Audit log destination (detect tampering paths)
aws.config.recorder	aws.s3.bucket	logs_to	Config delivery destination
aws.cloudfront.distribution	aws.s3.bucket	depends_on	CDN origin (data exfiltration paths)
aws.rds.instance / aws.lambda.function / aws.ebs.volume / aws.secretsmanager.secret / aws.efs.filesystem / aws.sqs.queue	aws.kms.key	encrypted_by	Encryption key dependency

End-to-End Attack Chain Example

With these edges, the attack path engine can now trace chains like:

Compromised IAM user
  → (attached_to) IAM policy with S3:GetObject + AssumeRole
  → (attached_to) IAM role with admin permissions
  → (executes_as) Lambda function
  → (depends_on) S3 bucket containing credentials
  → ... further hops to crown jewels

Previously, this chain would have appeared as three separate, disconnected findings. Infracast now connects them into a single traversable path, so the attack path engine can surface the full blast radius of a compromised IAM identity.

Encryption Key as Attack Target

encrypted_by edges also reveal a new attack pattern: KMS key compromise. A single KMS key that encrypts RDS, EBS, Secrets Manager, and EFS volumes is a high-value target. If the KMS key is accessible (due to an overly permissive key policy), all resources encrypted by it are potentially exposed in a single step.

Nightly Attack-Path Recomputation

Attack surfaces don't stand still — a CVE published overnight can turn a benign internal server into a stepping stone to your crown jewels. Infracast's continuous attack-path monitoring means you wake up to a clear answer to one question: "What can an attacker reach today that they couldn't yesterday?"

How it works

When enabled for a workspace, Infracast runs a nightly job that:

1. Recomputes all attack paths for the workspace, incorporating the latest CVE data from NVD, CISA KEV, and EPSS feeds.
2. Diffs the new result against the previous run by a stable path fingerprint (entry point → ordered hops → target), so the same logical path compares equal even when its risk score drifts.
3. Classifies every change as:
   • New — a path that exists now but didn't before.
   • Resolved — a path that existed before but is now gone (remediated or infrastructure removed).
   • Changed — the same path, but its severity bucket moved (e.g. HIGH → CRITICAL).
4. Alerts your security team — but only on actionable deltas (new paths, or paths that escalated to a higher severity). Routine score jitter does not page anyone.

Alerts are delivered through your existing notification channels (email, Slack, Teams, PagerDuty, OpsGenie, webhook), in the familiar format:

3 new CRITICAL attack paths emerged overnight due to CVE-2026-12345. Internet → [public-ALB] → [web-server (CVE-2026-12345)] → [prod-database]

Enabling it

Go to Settings → Workspaces → Nightly Attack-Path Recomputation and toggle it on. It is opt-in per workspace (off by default). You can also choose the UTC hour the job runs (default 02:00), so reports land before your team's morning standup.

On-demand recomputation

Don't want to wait for the nightly run? On the Attack Paths page, click Recompute & diff to run the same job immediately and see exactly what changed since the last run. This is also exposed as an API endpoint for automation:

POST /api/v1/tenants/{tenantID}/attack-paths/recompute

The response includes the full diff (new, resolved, changed) plus the new snapshot's run ID, so you can wire it into infrastructure-change webhooks or your own CI/CD gates.