Identity Attack Paths Guide

Most identity compromises do not need a vulnerability: they follow chains of group memberships, permissions, sessions and trusts that nobody designed but that lead from an ordinary account to control of the directory or the cloud tenant. Each link usually looks harmless on its own, which is why reviews of individual settings miss them and why attackers who map them as a graph find them quickly. This guide goes deeper than the ISPM Guide on that one class of finding: how identity attack paths form in Active Directory, Entra ID and Azure, the dangerous permissions such as GenericAll and WriteDACL behind them, how graph-based analysis works, and how to prioritise, close and validate paths. It is written for identity security engineers, directory owners and detection teams.

Key takeaways

• Think in graphs, not lists. An attack path is a sequence of edges between identities, groups, computers and resources; a permission that looks minor matters if it sits on a route to Tier 0.
• Dangerous ACLs are the hidden majority. GenericAll, GenericWrite, WriteDacl, WriteOwner and password reset rights on privileged objects create paths that group membership reviews never show.
• Cloud paths are identity paths too. Application ownership, service principal credentials, high-privilege Microsoft Graph permissions and Azure role assignment rights chain in the same way as AD permissions.
• Fix chokepoints first. Closing the one edge or node that many paths share removes more risk than fixing the longest list of individual findings.
• A path is closed only when it is validated. Re-run the analysis, confirm the edge is gone at source, and alert if it reappears.

What an identity attack path is

An identity attack path is a chain of relationships that lets a principal gain control of something it was never directly granted. The joint Five Eyes guidance on detecting and mitigating Active Directory compromises puts it this way: "It is often these hidden relationships, which are overlooked by organisations, that malicious actors exploit". Microsoft's exposure management documentation describes attack paths as combining "assets and techniques to show end-to-end paths that attackers can create to get from an entry point of an organization to critical assets".

The model has three parts:

• Nodes: users, groups, computers, service accounts, organisational units (OUs), Group Policy Objects (GPOs), certificate templates, Entra roles, applications, service principals, managed identities, subscriptions and key vaults.
• Edges: relationships that let one node act on another: membership, local admin rights, an active privileged session on a host, a permission in an access control list, delegation, an app role assignment, a role assignment at a scope, ownership.
• Targets: the assets that end the game, usually your Tier 0 set: domain admin equivalence, Global Administrator, the identity synchronisation and federation servers, and the cloud roles that can grant any other role.

Attack path chaining is the attacker's view: a phished help desk user is a member of a group that holds password reset rights over an OU; that OU contains a service account; the service account is local admin on a server where a Domain Admin has a session. Four ordinary facts, one path to domain admin. A toxic attack path is one where individually accepted settings combine into a route from a broad starting population, such as Domain Users or every member of a tenant, to Tier 0. A privilege escalation path is the same idea inside one system, for example from a Contributor role to Owner.

Attackers map paths with ordinary discovery: group enumeration (MITRE ATT&CK T1069.002 Domain Groups, T1069.003 Cloud Groups) and trust enumeration (T1482 Domain Trust Discovery). Any authenticated domain user can read most of the directory, including most permissions, so the map an attacker builds in an hour is one defenders should already hold.

Edge types that create identity attack paths

Dangerous AD permissions: GenericAll, WriteDACL and friends

AD ACL abuse is the part of identity attack paths that ordinary access reviews miss, because nothing shows up in group membership. Every AD object carries a security descriptor (the nTSecurityDescriptor attribute) whose discretionary access control list (DACL) says who can do what. Microsoft's definitions of the rights that matter most:

• GenericAll: "The right to create or delete children, delete a subtree, read and write properties, examine children and the object itself, add and remove the object from the directory, and read or write with an extended right." Full control.
• GenericWrite: "The right to read permissions on this object, write all the properties on this object, and perform all validated writes to this object." Enough to change attributes that control authentication or delegation.
• WriteDacl: "The right to modify the DACL in the object security descriptor." The holder can grant itself GenericAll, so WriteDACL is full control one step removed.
• WriteOwner: "The right to assume ownership of the object." Owners can rewrite the DACL, so this too ends in full control.
• ExtendedRight: "A customized control access right", which includes password reset and directory replication rights; an ACE granting all extended rights is a dangerous ACL on a user or on the domain object.

Where dangerous ACLs hide:

• The domain root: the Five Eyes guidance notes DCSync needs Replicating Directory Changes and Replicating Directory Changes All, or GenericAll or AllExtendedRights, on the domain root object, and recommends reviewing which objects hold them every 12 months.
• AdminSDHolder: Microsoft describes it as "template" permissions for protected accounts and groups (Domain Admins, Enterprise Admins, Administrators, Account Operators, Backup Operators and others). SDProp runs every 60 minutes by default on the PDC emulator and resets protected objects to match it, so an extra ACE added to AdminSDHolder reappears on every protected account within the hour.
• OUs with inheritance: a delegation granted years ago on a parent OU flows to every object created below it, including new admin accounts.
• Broad principals: any ACE that grants write rights to Everyone, Authenticated Users, Domain Users or Domain Computers on a privileged object starts a path from the whole domain. The Five Eyes guidance specifically asks that Domain Computers has no write privileges on any AD object.
• GPOs and certificate templates: edit rights on a GPO linked above Tier 0 objects, and enrolment rights on templates that let the requester choose the identity in the certificate, are paths to Tier 0 that do not involve any account permission at all.

To remove them, compare each Tier 0 object's DACL with the schema default, attribute every non-default ACE to an owner and reason, and remove what nobody can justify. Start with AdminSDHolder, or SDProp will put the rights back.

Entra ID and Azure attack paths

Cloud identity paths run through roles, applications and resource permissions rather than ACLs, but the graph logic is the same.

• Applications as stepping stones: an application's owners, and holders of roles that manage applications, can add secrets or certificates and then authenticate as the application. If the application holds high-privilege permissions, its owner effectively holds them too. In the Midnight Blizzard breach, a password-sprayed account in a legacy test tenant led to a legacy test OAuth application with "elevated access to the Microsoft corporate environment", which the actor used to grant itself the Exchange Online full_access_as_app role.
• Graph permissions: Microsoft's security operations guidance flags apps granted broad permissions such as Directory.ReadWrite.All and delegated grants made on behalf of all users (consent type AllPrincipals) as high severity events.
• Entra to Azure: a Global Administrator can turn on "Access management for Azure resources" and receive User Access Administrator at root scope, which Microsoft says "grants you permission to assign roles in all Azure subscriptions and management groups". Microsoft notes that deactivating a PIM role does not switch this off.
• Roles that rewrite access: the Azure Key Vault Contributor exposure showed a role documented as having no data access that included Microsoft.KeyVault/vaults/write, enough to change vault access policies and grant itself secrets on vaults using the access policy model; Microsoft classified it as by design.
• Hybrid edges: synchronisation accounts and federation servers join the on-premises and cloud graphs, so a path that ends at Domain Admin can continue to Global Administrator. Treat any edge into them as a Tier 0 attack path.

Graph-based attack path analysis

Attack path analysis turns the directory and tenant into a graph and asks which principals can reach which targets. Tools fall into a few categories: open-source and commercial graph-based attack path tools, identity security posture management platforms, and exposure management platforms such as Microsoft Security Exposure Management, which highlights "choke points" as "critical assets where multiple attack paths intersect" and offers a blast radius view from them. What they share:

1. Collection: objects, group memberships, ACLs, GPO links and delegation settings from AD by LDAP; local group membership and sign-in sessions from hosts; roles, applications, permissions and role assignments from Entra ID and Azure.
2. Modelling: each relationship becomes a typed edge. Attack path modelling quality depends on which edge types the tool understands; a tool that ignores certificate templates or app ownership will report no path where one exists.
3. Querying: shortest paths from a starting set (all users, a phished user, an internet-facing service account) to the targets you define, and the inverse, every principal that can reach a target.
4. Attack path visualisation: drawing the path so an owner can see why a fix matters. A screenshot of a six-hop path to domain admin persuades faster than a findings table.

Three cautions. Results depend on the targets you define: Microsoft warns that attack paths "might not be fully representative" without "fully defined critical assets". Session data is a snapshot, so collect repeatedly. And the collected graph is a map of your weakest points: store it as sensitive data and run collection from a known managed host.

Prioritising attack paths

Attack path discovery in a large directory returns thousands of paths. Attack path prioritisation should rank them by what an attacker gains and how easily, not by count.

Fix toxic paths and chokepoints first. A common example is a help desk group with password reset rights over a user OU that also holds admin accounts; moving the admin accounts out closes every path through the help desk in one change. For how attack paths feed wider exposure programmes, see the Exposure Management and CTEM Guide.

Closing and validating attack paths

Attack path reduction has four levers, in order of preference:

• Remove the edge: delete the ACE, membership, owner or role assignment.
• Move or harden the node: relocate privileged objects out of broadly delegated OUs, replace a service account with a group managed service account, or enforce tier logon restrictions so risky sessions cannot occur.
• Shrink the start: remove broad principals (Everyone, Authenticated Users, Domain Computers) from ACEs so the path no longer starts from the whole domain.
• Accept and monitor: where an edge is needed, document an owner, an expiry date and a specific detection for its use.

Attack path closure is not complete when the ticket is closed. Attack path validation means: re-collect and re-query to confirm the path no longer exists; check that the change was made in the source of truth (for example the delegation script or infrastructure as code) so it is not reverted; for high-impact paths, ask a red team or controlled exercise to attempt the old route; and add a detection so reintroduction is caught. See the Breach and Attack Simulation (BAS) Guide for continuous validation approaches.

Detecting path abuse and path changes

Paths change daily as people join groups and sign in to machines, and Microsoft notes that logons and group changes alter which paths exist. Monitor both creation and use:

• ACL changes: event 5136 (directory service object modified, under Audit Directory Service Changes) needs a SACL on the object. Microsoft recommends monitoring all modifications to the AdminSDHolder object and to the domainDNS class; add nTSecurityDescriptor changes on Tier 0 objects, OUs and GPOs.
• DCSync: event 4662 on domain controllers showing the replication rights GUIDs (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 and 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2) from an account that is not a domain controller or the documented sync account.
• Group changes: 4728, 4732 and 4756 for additions to privileged global, local and universal groups (T1098.007 Additional Local or Domain Groups).
• Entra ID: "Add owner to application", "Update Application-Certificates and secrets management", "Add app role assignment to service principal", "Add delegated permission grant" and "Add member to role" audit events, plus the Azure RBAC (Elevated Access) event "User has elevated their access to User Access Administrator for their Azure Resources".
• Discovery: unusual LDAP query volumes from workstations (diagnostic event 1644 when enabled) and session enumeration across many hosts.

Route these to identity threat detection; see the ITDR Guide.

Running attack path management as a programme

1. Define targets: the Tier 0 and crown-jewel list paths are measured against.
2. Baseline: a read-only collection across AD, Entra ID and Azure, recording how many principals reach each target.
3. Fix the top chokepoints: the ten edges or nodes carrying most paths to Tier 0, each tested in a pilot OU or subscription first.
4. Clean Tier 0 ACLs: keep an export of every removed ACE so it can be restored (the rollback) if an application breaks.
5. Automate: weekly collection where new paths to Tier 0 open a ticket.
6. Detect and validate: detections for edges you keep, re-tests for paths you close, trend metrics for leadership.

Small organisations can collect quarterly and fix by hand; large estates need weekly collection, an owner for every OU and application, and change processes that check new delegations against the graph first.

Metrics

• Exposure to Tier 0: number and percentage of enabled users with any path to Tier 0, target near zero.
• Shortest path length: the minimum hops from Domain Users or all tenant members to Tier 0; rising is good.
• Non-default ACEs on Tier 0 objects: count, with owner and justification for each remaining.
• Chokepoint closure: top chokepoints closed per quarter.
• Time to close: median days from a new Tier 0 path appearing to validated closure.
• Reintroduction rate: closed paths that reappear within 90 days.

Common failure patterns

• Reviewing groups only: privileged group membership is clean while ACLs, GPO rights and app ownership provide the real paths.
• No defined targets: analysis runs, produces thousands of paths, and nobody can say which matter.
• Fixing leaves, not chokepoints: teams close individual findings while one over-delegated group keeps hundreds of paths open.
• AdminSDHolder forgotten: rights removed from protected accounts return within the hour.
• On-premises only: the graph stops at the synchronisation server, so paths into Entra ID and Azure stay invisible.
• Treating the graph as harmless: collection output left on file shares gives an intruder a ready-made map.

Framework mapping

Practitioner checklist

• Define the Tier 0 and crown-jewel targets that every attack path is measured against.
• Collect AD, Entra ID and Azure relationships into one graph at least monthly, and weekly for large estates.
• Remove non-default GenericAll, GenericWrite, WriteDacl, WriteOwner and extended rights on Tier 0 objects, starting with AdminSDHolder and the domain root.
• Remove Everyone, Authenticated Users, Domain Users and Domain Computers from write ACEs on privileged objects.
• Restrict replication rights to domain controllers and the documented sync account, and alert on 4662 replication requests from anything else.
• Remove owners from privileged applications and alert on new credentials and high-privilege Graph permissions.
• Close the top ten chokepoints and track the share of users with a path to Tier 0.
• Validate every closed path by re-running analysis, and alert on reintroduction.
• Protect collection output and collection accounts as sensitive.

Standards and references

• ASD, CISA, NSA et al.: Detecting and mitigating Active Directory compromises
• Microsoft Learn: ActiveDirectoryRights enumeration
• Microsoft Learn: Protected accounts and groups in Active Directory (AdminSDHolder)
• Microsoft Learn: Work with attack paths in Microsoft Security Exposure Management
• Microsoft Learn: Elevate access to manage all Azure subscriptions and management groups
• Microsoft Learn: Microsoft Entra security operations for applications
• MITRE ATT&CK: T1484.001 Domain or Tenant Policy Modification: Group Policy Modification
• MITRE ATT&CK: T1069.002 Permission Groups Discovery: Domain Groups

Related NHI Mgmt Group resources: ISPM Guide · Active Directory and Entra ID Hardening Guide · Service Account Security Guide · Red Teaming Guide