Attack Path Mapping and Choke-Point Analysis

Every enterprise network already contains the attack paths that will eventually be used against it — they are latent in the misconfigured trust relationships, over-privileged service accounts, and stale group memberships that accumulate silently across identity, network, and cloud layers. Attack path mapping makes those paths visible before an adversary finds them, and choke-point analysis tells you which handful of fixes will collapse the most paths at once. This article is a hands-on guide to building both capabilities into a Continuous Threat Exposure Management program, with the graph math, workflows, and agentic AI acceleration that make it operationally real rather than a one-time consulting exercise.

Why vulnerability lists lie about your real exposure

Most exposure programs still start and end with a CVE list sorted by CVSS score. That approach answers the wrong question. CVSS tells you how severe a flaw is in isolation; it says nothing about whether that flaw sits on a path from an internet-facing asset to your domain controllers, your cloud administrator role, or your crown-jewel database. A critical vulnerability on an isolated print server that no compromised identity can ever reach is, for practical purposes, less dangerous than a medium-severity misconfiguration that sits at the single junction connecting every marketing workstation to the finance environment.

Attackers do not think in CVE lists. They think in graphs: an initial foothold, a set of credentials or tokens harvested from that foothold, a lateral hop enabled by those credentials, another hop, and eventually a target. Security teams that only patch by severity score are optimizing a metric that has almost no correlation with actual breach likelihood. The industry has increasingly recognized this — it is the core justification for Continuous Threat Exposure Management as a discipline, and specifically for the validation and mobilization stages of the CTEM cycle, where exposures are tested against real attack paths rather than treated as independent findings. For a full treatment of how attack path mapping fits into the five CTEM stages, see our companion piece on exposure management and CTEM.

Attack path mapping and choke-point analysis exist to correct this. They shift the unit of analysis from "the vulnerability" to "the path," and from "the path" to "the graph structure that generates thousands of paths." Once you can see the graph, prioritization becomes a computable property of the graph itself, not a subjective severity debate.

Building the graph model: nodes, edges, and traversal semantics

What counts as a node

An attack path graph is a directed graph where nodes represent entities an attacker can occupy or control, and edges represent an action that moves the attacker from one entity to another, typically with an associated privilege gain. Getting the node taxonomy right is the foundation of everything downstream. In a converged identity-network-cloud model, you need at minimum these node classes:

• Identities — human users, service accounts, managed identities, API keys, workload identities (Kubernetes service accounts, cloud IAM roles), and federated identities bridging on-prem AD to Entra ID or Okta.
• Groups and roles — AD security groups, Entra ID roles, AWS IAM roles/policies, GCP IAM bindings, Kubernetes RBAC bindings. These are aggregation nodes: many identities inherit privilege through them, and they are frequently the highest-leverage choke points.
• Devices and hosts — workstations, servers, virtual machines, containers, and the sessions/credentials cached on them.
• Network segments and control points — VLANs, subnets, firewall rule sets, VPN concentrators, jump hosts, and the reachability relationships between segments.
• Cloud resources — storage buckets, compute instances, secrets managers, container registries, serverless functions, and the resource-based policies attached to them.
• Trust and federation objects — AD trusts, Entra ID conditional access exceptions, OIDC/SAML federation configs, cross-account IAM role assumption relationships in AWS Organizations.

What counts as an edge

Edges are where the actual attacker tradecraft lives. Each edge type corresponds to a known technique, ideally mapped to a MITRE ATT&CK technique ID so the graph can be cross-referenced with detection coverage. Common edge types include:

• HasSession — a user has an active or cached logon session on a host (enables credential theft, T1003).
• AdminTo — a user or group has local administrator rights on a host, enabling lateral movement via PsExec, WMI, or WinRM (T1021).
• MemberOf — group membership, which is transitive and often nested many levels deep in real AD environments.
• GenericAll / GenericWrite / WriteDacl / WriteOwner / ForceChangePassword — AD ACL abuse primitives that BloodHound made famous, each corresponding to a specific privilege escalation technique.
• CanRDP / CanPSRemote — remote access rights that constitute lateral movement edges even without full admin rights.
• AssumeRole / sts:AssumeRole trust — the cloud analog of AD trusts; an identity in Account A can assume a role in Account B, often the root of cross-account privilege escalation chains.
• CanAssignRole / CanCreatePolicyVersion — IAM self-escalation primitives in AWS, where a compromised identity with permission to modify its own or another entity's policy can grant itself administrator access without ever touching a "sensitive" resource directly.
• NetworkReachable — derived from firewall rules and routing tables, indicating that a source segment can reach a destination segment on a given port.
• OwnsKey / CanReadSecret — access to a secrets manager entry, KMS key, or certificate that unlocks a downstream identity.

Each edge should carry a weight reflecting the operational cost or detectability of executing it — a WriteDacl abuse against a domain admin’s object is trivial and near-silent if unmonitored; a Kerberoasting attempt against a highly monitored SPN with an alerting deception decoy is costly and risky. This weighting is what lets you compute realistic shortest paths rather than naive hop counts, a subject we return to in the choke-point math section below.

Data sources for edge construction

Building this graph requires ingesting from multiple collectors, normalized into a common schema:

• AD/LDAP dumps of users, groups, OUs, GPOs, and ACLs (SharpHound-style collection or equivalent).
• Entra ID Graph API exports of role assignments, conditional access policies, app registrations, and service principal permissions.
• Cloud provider IAM policy exports (AWS IAM policy simulator data, GCP Policy Analyzer, Azure RBAC + PIM assignments) plus resource-based policies (S3 bucket policies, KMS key policies).
• CMDB and EDR telemetry for host-to-identity session mapping (who has logged in where, and when).
• Firewall rule bases, SDN/NSX policies, cloud security group and NACL configurations, and actual NetFlow/VPC Flow Logs to validate that rules match observed reachability (rules on paper frequently diverge from what is actually permitted).
• Kubernetes RBAC bindings, service account token mounts, and pod-to-node scheduling constraints for containerized workloads.

Normalization is nontrivial: an AWS "AdministratorAccess" policy, an Azure "Owner" role, and a Domain Admins membership are semantically equivalent (full control) but syntactically nothing alike. Your graph schema needs a canonical privilege-level abstraction — something like a five-tier model (read, write, operate, admin, tier-0/root) — so that cross-cloud and cross-domain paths can be compared and scored consistently.

Choke-point math: betweenness, cut sets, and why counting paths is not enough

The naive approach and why it fails

The intuitive first move is to enumerate every path from every "attacker-reachable" starting node (internet-facing hosts, phishable users, exposed cloud entry points) to every "high-value target" node (domain controllers, Tier-0 assets, production databases, crown-jewel S3 buckets), then count how many paths cross each intermediate node. Nodes crossed by the most paths look like choke points. This is directionally correct but mathematically incomplete, for two reasons.

First, raw path counts explode combinatorially in dense graphs — a real AD environment with nested groups can have millions of technically valid paths between a workstation and Domain Admins, most of them redundant restatements of the same three actual chokepoints. Second, naive counting treats all paths as equally likely, ignoring that some edges are far easier for an attacker to execute than others.

Betweenness centrality as the proper measure

The correct formalization borrows from graph theory: betweenness centrality. For a node v, betweenness centrality is the sum, over all pairs of nodes (s, t) in the graph, of the fraction of shortest paths between s and t that pass through v:

C_B(v) = ∑_s≠v≠t σ_st(v) / σ_st

where σ_st is the total number of shortest paths from s to t, and σ_st(v) is the number of those shortest paths that pass through v. Restricting the (s, t) pairs to (attacker-reachable entry points, crown-jewel targets) rather than all node pairs gives you a security-relevant variant sometimes called exposure betweenness or choke-point score. Nodes with high exposure betweenness are the ones where remediation has outsized effect, because they lie on the shortest — meaning cheapest, fastest, least-detectable — route for the largest number of attack scenarios.

Shortest path here should be computed on edge-weighted cost, not hop count. If you weight edges by estimated attacker effort or detectability (a GenericAll ACL abuse on an under-monitored OU costs less than a Kerberoasting attempt against a Tier-0 SPN with a honeytoken), Dijkstra’s algorithm over that weighted graph gives you paths that reflect what a competent adversary would actually choose, not just the graph-theoretically shortest route.

Minimum vertex cut sets: what to actually remediate

Betweenness tells you which nodes matter, but the remediation question is really a minimum vertex cut problem: given a set of source nodes S and target nodes T, what is the smallest set of nodes (or edges) whose removal disconnects every path from every s ∈ S to every t ∈ T? By the max-flow min-cut theorem, this minimum cut size equals the maximum flow between S and T when every node/edge has unit capacity, and can be computed efficiently with standard max-flow algorithms (Ford-Fulkerson, or Dinic’s algorithm for larger graphs) after applying node-splitting (each node v is split into v_in and v_out connected by a capacity-1 edge, so that "cutting" a node rather than an edge is representable in the flow formulation).

This is the mathematically rigorous version of "what should we fix first": it identifies the smallest set of remediations that provably eliminates all paths, not just the highest-degree or highest-betweenness nodes individually. In practice you compute both: betweenness centrality gives you an intuitive, explainable ranking for reporting and prioritization dashboards, while min-cut analysis gives you the actual remediation set with a mathematical disconnection guarantee. The two usually agree on the top few nodes but min-cut is what you want when you need to say, with confidence, "these four changes eliminate every currently known path from internet-facing assets to Domain Admins."

Marginal path reduction as a scoring function

For remediation backlogs with limited engineering capacity, a more actionable metric than either of the above is marginal path reduction: for each candidate fix, simulate removing that node/edge from the graph and recompute the number of surviving attack paths (or the recomputed min-cut size) to high-value targets. Rank candidate fixes by paths-eliminated-per-unit-of-remediation-effort. This produces a prioritized list where each item has a concrete, defensible "if we do this, N attack paths disappear" justification — a dramatically stronger argument to engineering and IT operations teams than a CVSS score.

Worked example: an Active Directory to Entra ID hybrid escalation chain

Consider a mid-size enterprise with an on-prem AD forest synchronized to Entra ID via Entra Connect, common in nearly every hybrid Microsoft shop. The graph reveals the following chain, which is one of the most frequently observed real-world patterns in red team engagements and actual incident post-mortems:

1. A phishing email compromises a helpdesk technician’s workstation. The technician account is a member of a "Helpdesk_Admins" AD group.
2. Helpdesk_Admins has GenericWrite over an OU containing a service account, "svc-backup," used for scheduled backup jobs. GenericWrite over an object in AD is sufficient to reset that account’s attributes, including forcing a Kerberos pre-auth downgrade or performing a targeted Kerberoast, and in many misconfigured environments allows a full password reset via ACL abuse.
3. svc-backup, in turn, is a member of "Backup Operators" locally on three file servers, which grants SeBackupPrivilege — sufficient to read the NTDS.dit file (or an equivalent registry hive dump) and extract the KRBTGT hash, enabling a Golden Ticket attack across the entire forest.
4. Separately, svc-backup’s AD account is synchronized via Entra Connect and holds an Entra ID role assignment ("Directory Synchronization Accounts" plus, due to a legacy misconfiguration, an unintended "Global Reader" role) that was granted during a since-forgotten migration project and never revoked.
5. Global Reader in Entra ID permits enumeration of every conditional access policy, every app registration, and every service principal’s configured permissions — reconnaissance that lets the attacker identify a service principal with Owner-level Azure RBAC on the production subscription, and a client secret stored insecurely in an app registration’s manifest that a Global Reader can still view metadata for, informing a follow-on attack.

In isolation, none of these five findings would top a CVSS-sorted list. GenericWrite over a stale OU is an AD hygiene item. Backup Operators membership is "expected" per the backup team’s runbook. An unused Entra ID role assignment from a two-year-old migration is easy to lose in a role assignment export with thousands of rows. But mapped as a graph, this is a five-hop path from a phishable helpdesk technician to full forest compromise and a foothold in the production Azure subscription — and the svc-backup node has extremely high exposure betweenness, because it is very likely the single node through which multiple similar chains from other OUs also pass, since backup service accounts are almost always over-privileged by necessity of their function.

The choke point here is not the phishing vector (you cannot eliminate phishing risk to zero) and it is not the KRBTGT extraction technique (you cannot un-invent Backup Operators). The choke point is the GenericWrite ACL on the OU and the stale Global Reader role assignment — two specific, surgical, low-risk-to-fix misconfigurations that, once remediated, break this entire chain and very likely several adjacent ones that also route through svc-backup. This is exactly the kind of prioritization insight that raw vulnerability scanning cannot produce, and it is the core deliverable of attack path mapping done well. It is also a strong example of why identity-centric exposure management deserves its own dedicated discipline — see our deeper coverage of identity security, IAM, and PAM for the broader control set that prevents these chains from forming in the first place.

Worked example: cloud IAM self-escalation and cross-account trust abuse

Cloud environments introduce a distinct but structurally similar class of choke point: IAM policy graphs where the edges are permission grants rather than ACLs, and privilege escalation frequently does not require exploiting any software vulnerability at all — only chaining together individually "reasonable" permissions.

A common AWS pattern: a CI/CD pipeline role has iam:PassRole and lambda:CreateFunction permissions so it can deploy serverless workloads. Individually these are mundane deployment permissions. Combined, they allow the pipeline’s identity (or anyone who compromises it) to create a new Lambda function, pass it an execution role with broader privileges than the pipeline role itself possesses, and then invoke that function to perform actions the original role could never do directly — a textbook confused-deputy privilege escalation. Add a second edge: that broader execution role has sts:AssumeRole trust from a security-tooling AWS account into the production account "for monitoring purposes," and the pipeline compromise now grants a path into production with full administrative reach, several accounts removed from where the CI/CD pipeline nominally lives.

These chains are graph-native problems. AWS IAM Access Analyzer, Azure Permissions Management, and open frameworks like PMapper or Cloudsplaining can each surface individual escalation primitives, but the choke-point value comes from linking those primitives into the same connected graph as your on-prem identity data and your network reachability data, so that a single query can answer: "across every entry point we consider attacker-reachable, what is the smallest set of IAM policy changes that eliminates every path into the production account’s administrator role?" That is a min-cut query, not a list of individual findings, and it routinely surfaces two or three specific overly broad trust policies or role-passing permissions as the answer, out of what might be hundreds of individually flagged IAM findings across the environment.

Lateral movement across the network layer

Network segmentation completes the third leg of the graph. Firewall rules and security groups define NetworkReachable edges, and the critical exercise is validating that the rules-as-written match reachability-as-observed. It is common to find "temporary" firewall exceptions from a migration project, VPN split-tunnel misconfigurations that expose management subnets to general corporate networks, or overly permissive security group rules (0.0.0.0/0 on management ports, or "allow all within VPC" rules that ignore the fact that a compromised low-trust workload sits in the same VPC as a high-trust database tier) that create reachability an architecture diagram would never suggest exists. Feeding actual flow log data into the graph, rather than trusting the rule base alone, frequently reveals reachability paths that were never intended and that the network team is unaware of — these are some of the highest-value, lowest-effort choke points to close, because closing a firewall rule rarely breaks a legitimate business process the way removing an AD group membership might.

Operational workflow: from data collection to remediation ticket

Step 1: continuous collection, not point-in-time snapshots

Attack path graphs decay the moment a new group membership, IAM policy, or firewall rule is created. A quarterly BloodHound run or an annual pen test snapshot is a photograph of a graph that has already changed. Collection agents/connectors for AD, Entra ID, AWS/Azure/GCP IAM, Kubernetes RBAC, and network configuration should run on a continuous or near-continuous cadence (hourly to daily depending on data source volatility), feeding an incremental graph update rather than a full rebuild each time where possible, to keep compute costs manageable at enterprise scale.

Step 2: define your crown jewels and entry points explicitly

Choke-point analysis is meaningless without well-defined S (attacker-reachable entry points) and T (high-value targets) sets. Entry points typically include: internet-facing hosts and applications, all identities subject to phishing (effectively all human users, weighted by phishability signals such as MFA status and past click-through rates), exposed cloud storage and APIs, and third-party/vendor access points. Targets typically include: domain controllers and Tier-0 AD infrastructure, production database credentials and encryption keys, cloud administrator and organization-management roles, source code repositories with deployment credentials, and any system in scope for regulatory crown-jewel designation (PCI cardholder data environments, PHI systems, etc.). This designation exercise itself is valuable and should be revisited quarterly with business stakeholders, not left to security team assumption alone.

Step 3: compute, rank, and validate

Run betweenness centrality and minimum-cut computation against the current graph, restricted to your defined S/T sets. Rank candidate remediations by marginal path reduction. Before mobilizing any fix, validate the highest-ranked findings with controlled, authorized adversary emulation — actually attempting the ACL abuse or role assumption in a safe manner (or using a breach-and-attack-simulation platform) to confirm the edge is exploitable as modeled and not blocked by a control the graph model didn’t capture (an EDR rule, a conditional access policy, a just-in-time access gate). This validation step is precisely the "Validation" stage of the CTEM cycle, and it is where many programs fail by skipping straight from graph theory to remediation tickets without confirming exploitability in the live environment.

Step 4: mobilize remediation with path-elimination framing

Remediation tickets should state the number and nature of attack paths eliminated, not just "fix ACL on OU=Finance." Include the specific chain(s) broken, the choke-point score before and after, and adjacent findings that become lower priority once this fix lands (because their paths were redundant with this one). This framing dramatically improves engineering team buy-in because it replaces an abstract compliance requirement with a concrete, falsifiable security outcome.

Step 5: re-run and track trend, not snapshot

After remediation, recompute the graph and confirm the targeted paths are gone (and watch for new paths introduced by the fix itself — removing a GenericWrite ACL by adding a new delegated permission is a classic way to accidentally create a different escalation route). Track exposure metrics over time: total paths to crown jewels, average path length, number of Tier-0-adjacent choke points, and mean time to remediate a discovered choke point. These become the KPIs that demonstrate program maturity to leadership and the board, far more legible than a raw vulnerability count.

Where agentic AI changes the economics of this work

Everything described above is computationally well-defined but operationally heavy: continuous multi-source data collection and normalization, graph computation at scale, exploitability validation, and remediation-ticket generation with cross-team coordination. This is precisely the profile of work that benefits from agentic AI — not as a replacement for the graph algorithms, which are deterministic and should remain deterministic, but as the orchestration layer that keeps the whole pipeline running continuously and translates graph output into action without a human manually stitching together five different tools every week.

Where agents add real leverage

• Continuous connector maintenance and schema normalization. An agent can monitor for API/schema drift in AD, Entra ID, and cloud IAM export formats, detect when a collector is silently failing or returning stale data (a very common and dangerous failure mode — a graph built on nine-month-old AD data will confidently show remediated choke points as still-open), and re-run enrichment jobs automatically.
• Natural-language investigation of graph findings. Rather than requiring an analyst to hand-write Cypher or Gremlin queries against the graph database, an agent can translate "show me every path from a phishable identity to the production Kubernetes cluster’s secrets" into the correct graph query, execute it, and summarize the resulting chains in plain language with the specific ACLs, role assignments, and firewall rules implicated.
• Automated exploitability validation. Agents integrated with authorized attack-emulation tooling can safely attempt to validate whether a modeled edge (a GenericWrite ACL, a role-assumption trust) is truly exploitable in the current environment, flagging false positives where a compensating control already blocks the theoretical path, before a human ever spends time on the finding.
• Remediation drafting and cross-team routing. Once a choke point is confirmed, an agent can draft the remediation ticket with the specific chain diagram, the before/after choke-point score, the owning team (derived from CMDB/asset ownership data), and route it through the appropriate change-management workflow, closing the loop between graph analytics and the ITSM systems where actual work gets tracked.
• Continuous re-scoring as the environment changes. Because agentic workflows can run on a schedule or be triggered by change events (a new IAM policy deployed, a new AD group created), the choke-point ranking can update near-real-time rather than waiting for the next scheduled assessment cycle, catching newly introduced risk (like the accidental new ACL from the remediation-introduced-a-new-path scenario above) within hours instead of months.

This is the operating model behind an agentic SOC approach to exposure management: human analysts set the strategy (which crown jewels matter, what risk tolerance is acceptable), deterministic graph algorithms compute the mathematically correct answer, and agents handle the continuous grind of data freshness, investigation, validation, and ticket routing that would otherwise consume the majority of an analyst’s week and cause most programs to degrade back into quarterly-snapshot mode within two quarters of launch. Platforms like CyberMox apply this pattern directly to exposure management, while the broader operational orchestration layer draws on the same agentic workforce concepts found in Norra, and correlates with the AIOps telemetry that ITMox already collects about asset ownership, change events, and infrastructure topology — data that materially improves the accuracy of the underlying graph model since asset ownership and change timing are exactly what you need to route remediation correctly and detect stale collector data.

Metrics that actually belong on an exposure management dashboard

Choosing the right metrics is what separates a CTEM program that sustains executive support from one that gets defunded after the initial assessment novelty wears off. The following metrics, derived directly from the graph, should anchor your reporting cadence:

• Paths-to-crown-jewel count, tracked per defined target, over time — the primary trend line.
• Choke-point remediation velocity — median time from choke-point identification to confirmed closure.
• Top-N choke-point concentration — what percentage of all paths route through your top 10 ranked nodes; a high concentration means a small remediation set yields outsized risk reduction, which is both a useful planning number and a strong argument for resourcing the fix.
• Blast radius per Tier-0-adjacent identity — how many high-value targets are reachable from each service account or admin identity, used to prioritize privileged access management and just-in-time access rollout.
• Graph freshness / collector health — percentage of data sources updated within their expected SLA window; a leading indicator that your other metrics can be trusted.
• Validated versus theoretical path ratio — what fraction of modeled paths have been confirmed exploitable through authorized testing, versus remaining theoretical; rising validated coverage is a maturity signal.

Avoid vanity metrics like total nodes or edges in the graph, or raw vulnerability counts discovered — these grow naturally as collection improves and do not communicate risk reduction. Every metric on the dashboard should map back to "fewer ways for an attacker to reach something that matters," which is the entire point of the exercise.

Common pitfalls and how to avoid them

Modeling the graph but never validating exploitability

A purely theoretical graph, built entirely from configuration exports without any live validation, will contain false positives from compensating controls the model does not know about (EDR blocking a technique, conditional access blocking a token replay, a honeytoken triggering an alert before the path completes). Treat the graph as a hypothesis-generation engine and pair it with periodic authorized validation, not as ground truth on its own.

Ignoring edge weight and defaulting to hop count

Teams that rank choke points purely by node degree or unweighted shortest path frequently over-prioritize convenient-to-fix but low-impact nodes and under-prioritize the genuinely cheap, silent techniques (ACL abuse, token theft) that real intrusions actually use, because those techniques often appear as longer hop-count paths that are nonetheless the cheapest in practice.

Recomputing only after full quarterly assessments

Environments change daily. A choke point closed in January can reopen in March when a new project stands up a new service account with familiar over-broad permissions "just to get it working." Continuous recomputation, not scheduled snapshots, is the only way to catch this reliably, which is exactly why agentic execution matters as described above.

Treating on-prem, cloud, and network as separate remediation tracks

When identity, network, and cloud teams each run their own point tooling and remediation backlog independently, cross-domain choke points — almost always the highest-value ones — never get identified because no single team owns the full chain. Attack path mapping only delivers its core value when it is a converged, cross-team program with a single graph and a single prioritized backlog, even if remediation execution is still split across the owning teams.

Over-rotating on the graph and under-investing in crown-jewel definition

The most sophisticated graph engine produces meaningless output if your target set is wrong — either too broad (every server is "critical," which collapses back into "fix everything") or too narrow (missing a business-critical system that isn’t obviously a "server" in the traditional sense, like a SaaS admin console holding customer data). Revisit crown-jewel and entry-point definitions with business stakeholders on a recurring cadence, not just once at program kickoff.

Getting started: a pragmatic 90-day rollout

Organizations new to attack path mapping should not attempt to model the entire estate on day one. A pragmatic sequence: in the first 30 days, stand up AD/Entra ID collection and build the identity graph alone, since identity misconfigurations are almost always the fastest-decaying and highest-density source of paths; in days 30–60, add cloud IAM for your single most business-critical cloud account or subscription, and validate the top five choke points with authorized testing; in days 60–90, integrate network reachability data (starting with flow-log-validated segmentation between your highest-risk network zones) and produce your first cross-domain chain analysis. Expand scope account-by-account and segment-by-segment from there, rather than attempting a big-bang full-estate model that risks stalling on data quality issues before it ever produces an actionable choke point. For organizations evaluating platform options to accelerate this build-out, our CTEM solutions overview and technical whitepapers cover reference architectures in more depth.

Frequently asked questions