Attack Path Analysis: Finding Routes Before Attackers Do

Attack path analysis fails when it becomes another list of possible problems. Its job is to identify the relationship that removes the most credible routes to business impact.

Attack path analysis connects entry conditions, identities, network reach, vulnerabilities, permissions, sessions, management systems, and critical targets. It asks how separate weaknesses combine. Then it gives an operator a specific edge to close and a test that proves the route no longer works.

That is a different outcome from finding more vulnerabilities. A server may have no Critical CVE and still expose a short route through a broad service account. Another may carry ten severe findings yet sit behind a control that blocks the required access. Path analysis forces the program to judge sequence, evidence, and consequence together.

What is attack path analysis?

Attack path analysis is the process of finding and evaluating routes an attacker could use from a plausible starting condition to a target or harmful outcome. The analysis usually runs on an attack graph, but the graph is only the model. Analysis includes scope, evidence checks, route calculation, prioritization, ownership, repair, and verification.

A path can cross technical layers. An exposed application leads to a host session. A cached support credential reaches a management server. A deployment identity changes a hypervisor. The hypervisor exposes the backup system. Four individually familiar conditions become one route to recovery loss.

Possible is not the same as observed. A possible path satisfies modeled prerequisites. An observed path includes activity showing that some or all edges were used. A verified closed path fails the original access test under recorded conditions. Keep those states separate in reports.

How is path analysis different from vulnerability prioritization?

Vulnerability prioritization ranks findings. Path analysis ranks connected routes and the repairs that break them. A CVE can create one edge, but identities, configuration, sessions, routes, and control planes often create the others. Patching one node may leave an alternate route intact.

Use both. Threat and vulnerability data identify active entry methods. Environmental evidence shows whether the required service, route, identity, and privilege exist. Business context explains why the target matters. The context aware vulnerability prioritization guide covers the finding decision. Path analysis extends that logic across several connected conditions.

Avoid turning path length into a risk score by itself. A one hop path that requires physical access may be less practical than a three hop path that uses standing credentials and an open management channel. Count hops, but rank feasibility and evidence first.

Why do current incidents demand route level analysis?

Verizon published the 2026 Data Breach Investigations Report in May 2026. The 2026 DBIR report page says software vulnerability exploitation became the leading initial access method at 31 percent of breaches, while ransomware appeared in 48 percent. Entry and impact often belong to one connected problem. A patch list shows the front door. Path analysis asks whether that door reaches identity, production, and recovery systems.

Mandiant published M-Trends 2026 in March after more than 500,000 hours of 2025 investigations. Its M-Trends Executive Edition reports a 14 day global median dwell time. It also measured a median handoff of 22 seconds between opportunistic access and a secondary threat group, down from more than eight hours in 2022. Some actors stay quiet for months. Others move almost immediately. A monthly graph refresh serves neither case well.

The asset scope is widening too. Microsoft updated its attack path documentation on June 17, 2026 to include storage, containers, serverless systems, unmanaged APIs, and AI agents among covered cloud resources. That recent change is useful beyond one product. Any current path model must include machine identities, tokens, APIs, and agent authority alongside users and servers.

Where should attack path analysis start?

Start with impact. Pick systems that can change identity, deploy software, run production, hold regulated data, or restore the business. Name a business owner and technical owner for each. Record the consequence in plain terms: payroll stops, customer data leaves, code signing becomes untrusted, or backups cannot restore operations.

Then choose plausible entry conditions. Include internet exposed services, ordinary user endpoints, contractor access, remote support, build systems, cloud identities, edge devices, and supplier connections where evidence supports them. Do not label every asset an entry point. That produces every route and no priority.

Scope data coverage before calculation. For each target, can the team read effective network access, accepted identities, delegated rights, active sessions, installed software, exposure, and management dependencies? Mark the missing sources. A path model with a blank identity layer should not issue a confident safety claim.

How do you perform attack path analysis?

1. Define critical targets and plausible entry conditions with named owners.
2. Collect current effective state for identity, network, endpoint, cloud, vulnerability, and management layers.
3. Build testable edges and attach source, time, confidence, and expiry to each one.
4. Calculate routes, then remove those with a failed prerequisite or stale evidence.
5. Rank remaining routes by feasibility, target impact, observed activity, and shared choke points.
6. Assign the edge repair, preserve rollback, make the change, and repeat the path test.

The evidence review is where most of the value sits. A directory group may grant authority through nested membership. A network policy may allow a route while the service is not listening. A session may expose a token that expires before the change window. Keep the facts granular enough to update one edge without rebuilding the whole model.

What does an attack path query look like?

This Cypher query counts routes of one to five relationships from modeled entry assets to critical targets. The variable length relationship pattern and length() function follow the official Neo4j Cypher query guide.

The result contains modeled routes. It does not validate them. Inspect the relationship evidence, limit the source and target sets, and cap path length so the result remains reviewable. Count is useful for finding concentration. It should not replace judgment about edge quality or target impact.

How should paths and choke points be ranked?

Score what changes the decision: entry feasibility, required privilege, availability of authentication material, network access, control strength, target impact, observed activity, evidence age, and uncertainty. Use ranges or clear states when the data cannot support a precise number.

Compare repairs by serious paths removed per unit of constrained effort. Suppose a team has 240 High and Critical findings and capacity for 20 production changes. Path analysis finds six findings on routes to identity control, four shared permission edges that expose backup systems, and 12 independent routes to ordinary servers. Closing the four shared edges removes 38 serious paths. That work may outrank a patch that removes one edge from one route.

Do not reward a repair for removing noisy theoretical paths. Require current evidence and a defined target. If 30 of those 38 paths depend on a group export from six weeks ago, refresh the source before making a disruptive change. Confidence belongs in the queue.

What does a worked path analysis look like?

An internet exposed reporting server has a vulnerable library. Endpoint evidence shows the affected service is running. The server accepts a support identity that also administers a virtualization manager. That manager can snapshot an identity server and change backup jobs. The route ends at both credential material and recovery control.

The team has several choices. Patch the reporting service. Remove the support identity from the server. Deny the reporting network access to the virtualization manager. Split virtualization administration from backup control. Each closes a different edge. The broadest safe repair is usually the one that removes a trust relationship no workflow needs.

Test before and after. Record that the server can reach the manager, the support identity authenticates, and the identity can request a snapshot in the test scope. After the change, repeat those exact checks. If an alternate account or API route still works, the path remains open and the model should show it.

Who owns an attack path?

No single team owns the whole route. Someone still needs to own the decision. Security usually owns the model and priority. Identity owns logon and delegated rights. Network teams own reach. Platform teams own management systems. Application owners confirm dependencies. Business owners confirm impact and acceptable interruption.

Assign work to the edge owner, not the target owner by habit. A database team cannot remove a broad directory group it does not control. A vulnerability analyst cannot restrict a cloud role. Bad routing turns a strong analysis into another aging ticket.

Store the source fact, proposed change, approver, owner, due date, rollback, verification test, result, and expiry. That record lets a CISO explain why one repair moved ahead of 200 severe findings. It also lets an auditor see where uncertainty remained.

How do you verify that a path is closed?

Repeat the path prerequisites from the same source and identity where safety allows. Test route, authentication, authorization, execution, and target effect separately. A blocked port proves only the route tested. A rejected credential proves only that identity and channel. State the boundary.

Recalculate alternate routes after the change. Removing one group may expose a nested membership. Blocking WinRM may leave RDP or a deployment agent. Rotating a password may leave a valid token. The lateral movement techniques guide maps those alternate channels and their evidence.

Watch for drift. Keep the detection that would reveal the edge returning. A graph can say closed on Monday and be wrong after Friday's emergency firewall change. Verification is a dated result, not a permanent label.

Which attack path analysis metrics matter?

Track verified paths to critical targets, serious paths removed, shared edges removed, percentage of edges with current evidence, time from new path discovery to owner assignment, time to verified closure, and the rate at which closed edges reappear. Pair every reduction metric with coverage.

Avoid celebrating raw graph size. More nodes can mean better collection, not more risk. Fewer paths can mean a safer estate or a failed source. Report coverage, confidence, and change beside the count. Executives need the decision, the business exposure, and the proof that the repair changed reachability.

Artemes uses deep endpoint context with AI driven analysis to help assemble reviewable evidence and proposed next steps. Human review still matters. The model should show missing information, and operators should verify the chosen edge in the running environment before promoting a conclusion into work.

Frequently asked questions

Is attack path analysis the same as attack surface management?

Attack surface management inventories and monitors exposed assets and conditions. Path analysis connects entry conditions through internal relationships to a target or impact. The practices overlap, but they are not the same.

Does the shortest attack path always matter most?

A short route may require rare access or a strong control failure. Rank feasibility, evidence, and impact with path length instead of assuming the fewest hops wins.

Can attack path analysis replace penetration testing?

Analysis cannot replace an approved penetration test. A test can validate some paths through controlled action and may find missing edges. Neither method proves complete coverage.

How often should teams run attack path analysis?

Recalculate after material identity, network, cloud, endpoint, asset, or management changes. Review critical paths continuously or at a cadence matched to source freshness and business risk.

The executive takeaway

Select ten critical targets and fund one month of path closure work. Require current evidence on every edge, rank repairs by credible routes removed, assign the actual edge owner, and repeat the access test after each change. If leadership sees only a graph screenshot and a ticket count, the analysis has not reached an operational result.