Attack path
In internal and cloud testing, an attack path is the concrete sequence of steps that connects a position an attacker can reach to a position that matters, such as an ordinary domain account to domain administrator. It is a route through relationships that already exist, not a list of vulnerabilities.
How it works
Model the estate as a graph. Nodes are users, computers, groups, service accounts, roles, certificate templates and objects. Edges are the relationships between them: membership, permission to reset a password, permission to modify a group, an active session on a host, the right to assume a role. An attack path is a directed walk from a node you control to a node you want, and finding one is a graph query rather than an exploit.
The technique is deliberately unglamorous. Almost every edge is a legitimate configuration created for a reason, and no single edge is a finding. The path is the finding, which is why tooling that enumerates and graphs directory relationships changed internal testing so completely.
What goes wrong
Estates are audited object by object and attacked path by path. A permission review that examines each group in isolation will approve every step of a five-step route to domain administrator, because each step, on its own, is defensible. Nobody owns the composition.
The edges that appear most often in the paths we draw are ordinary: a help desk group with the right to reset passwords on accounts that are also members of a privileged group, a service account with local administrator rights on a large set of machines, a group nested inside another group four levels deep, a certificate template that permits an ordinary user to request a certificate on somebody else’s behalf, or an administrator’s session sitting on a workstation, which turns into credential dumping and lateral movement. In cloud the same shape appears as one role permitted to assume another, which is a cloud attack path.
The fix is also structural: cut the edge, not the node. Removing one relationship frequently breaks dozens of paths at once, and that is the analysis worth paying for.
Where this shows up in an audit
Our internal reports lead with the path, drawn as a sequence with the evidence at each step, and the individual weaknesses appear underneath as the components. Then we identify the smallest set of edges whose removal breaks the largest number of paths, which is a prioritisation a list of findings cannot express. This is what a product cannot tell you, because it can enumerate the edges and cannot walk them. This is part of how an internal engagement is reported as a route rather than a list.