Active Directory Attack Paths: From Domain User to Domain Admin

When teams prepare for an Active Directory security review, patch levels and domain controller hardening usually receive most of the attention. The reasoning is understandable: domain controllers hold the most sensitive assets in the environment.

An attacker with valid domain credentials can often avoid attacking a domain controller directly. After gaining access through phishing, password reuse, or an exposed service, they can query directory metadata available to authenticated users. From there, existing permissions, active sessions, delegation settings, and trust relationships may provide a route to higher privileges.

Active Directory works as a graph of accounts, groups, permissions, delegation settings, certificate templates, and systems connected through trust. Domain compromise often develops through several ordinary-looking relationships that become dangerous once combined.

This article explains how Active Directory penetration testing maps attack paths from a standard domain user to Domain Admin, why these paths appear, and how assessors validate them in practice. It also covers BloodHound analysis, endpoint and session data, hybrid identity, forest trusts, and attack-path reporting.

Why Attack Paths Matter More Than Individual Active Directory Attacks

Configuration reviews, vulnerability assessments, and penetration tests often cover the same parts of an Active Directory environment. The difference lies in the questions they answer and the evidence they produce.

A mature Active Directory penetration test brings these perspectives together. Configuration review establishes the control baseline. Relationship graphing shows possible routes between identities and systems. Endpoint testing reveals what an account can reach in practice. Controlled exploitation confirms whether a suspected route still works under the environment’s actual security controls.

BloodHound may show that one principal can control another, while endpoint protection, network segmentation, authentication policy, or signing requirements prevent the transition. The reverse also happens: a permission that looks relatively minor can become critical when it connects a standard user to a highly privileged service account.

For this reason, assessors separate discovery from validation. Discovery identifies a possible edge in the graph. Validation shows whether the edge can be used and what level of control it provides.

What Are Active Directory Attack Paths?

An Active Directory attack path is a chain of abusable privileges and user behaviors connecting principals directly or indirectly. BloodHound uses this model to show how control can move through an environment. In an assessment, the model usually includes three elements.

1. Principals. Users, groups, computers, service accounts, group Managed Service Accounts (gMSAs), and certificate-backed identities can all hold or inherit control.
2. Relationships. Group membership, object permissions, local administrator rights, sessions, delegation, certificate enrollment, GPO control, forest trusts, and directory replication rights connect those principals.
3. Control transitions. A validated relationship may allow the assessor to obtain credentials, impersonate another identity, execute commands on another host, change group membership, or modify a security-sensitive object.

A representative route might look like this:

BloodHound and SharpHound make these relationships visible as nodes and edges. Collection may include directory objects, access control lists (ACLs), sessions, local group memberships, GPO links, service principal names (SPNs), delegation settings, trusts, and certificate-service relationships. Analysts can then query the graph for routes from a controlled principal to a high-value object.

Collection depth should match the rules of engagement. Session, local-administrator, RDP, DCOM, and remote-management collection can generate broad network activity, so running every available collection method by default may be unnecessary or inappropriate.

The resulting graph still requires interpretation. Session data may be stale. An inherited ACL may behave differently from what the graph suggests. A local administrator edge may lead to a system the tester cannot reach. A certificate path may depend on enrollment or CA settings that need separate confirmation.

The shortest route in BloodHound may also be noisy, impractical, or less important than a longer path. Assessors need to verify each material edge and understand the operational context before testing it.

Anatomy of an Active Directory Attack Path

Phase One: Establish the Starting Position and Scope

In an assumed-breach assessment, the client typically provides a standard domain identity and network access comparable to an ordinary employee workstation. The engagement starts after the initial access event, so the team can focus on how far a low-privileged foothold can move through the environment.

The scope directly affects the quality of the result. LDAP-only testing may reveal dangerous permissions while missing the endpoint, certificate, trust, and synchronization relationships that make those permissions exploitable.

The rules of engagement should explicitly cover password spraying, ticket requests, authentication coercion and relay, remote execution, certificate enrollment, production endpoints, and the accepted proof of tier-zero impact. These activities carry different levels of operational risk. Agreeing on them before testing begins gives the team a clear path from discovery to controlled evidence.

Phase Two: Build and Verify the Relationship Graph

SharpHound gives the assessment team a broad map of users, groups, computers, sessions, local administrators, ACLs, trusts, GPO links, delegation, and other identity relationships. In BloodHound, analysts can mark the starting account as controlled, review reachable principals, and inspect routes toward tier-zero assets.

Local group and session collection is especially important because many active directory attack paths never appear in centrally managed AD data. A domain group may have local administrator rights on one server, and a privileged user’s session on that server may create the next step. Leaving endpoint relationships out of scope can make the environment look safer than it is.

Promising edges are then checked with native PowerShell or LDAP queries and, where approved, tools such as NetExec, Impacket, Rubeus, or Certipy. Tool choice depends on the question being tested: whether the identity has effective permission, whether the service is reachable, and whether a security control blocks the expected action.

Blocked transitions are valuable findings as well. If LDAP signing rejects an unsigned bind, SMB signing removes the relevant relay condition, or endpoint controls prevent credential access, the report should record that result. It shows that a defensive control has broken a potential path.

Common Active Directory Attack Vectors and Techniques

Credential Theft and Reuse

Many successful Active Directory attack paths begin with credentials stored in locations that an authenticated user can access.

• Passwords in accessible locations. Scripts on open file shares, the SYSVOL share, Group Policy Preferences (the legacy cpassword issue), and configuration files frequently contain service or administrative credentials readable by any domain user.
• Password spraying. When performed below known lockout thresholds, password spraying can test a small number of common passwords across many accounts. Its success and detectability depend on the password policy, identity controls, monitoring, and the quality of the chosen passwords.
• Local admin and credential caching. If the same local administrator password is reused across workstations, one compromised host exposes it everywhere. Cached domain credentials and tokens on a compromised machine can expose accounts that have logged in there. A privileged user’s interactive session on a workstation can therefore become part of an attack path.

The resulting pivot may be simple and still have serious consequences: a standard user reads an accessible share, recovers a service account password, and finds that the account has local administrator rights across several servers.

Kerberos Abuse

Kerberos, the authentication protocol at the core of Active Directory, includes two well-understood abuse paths that can be tested with limited initial access.

• Kerberoasting. Any authenticated user can request a service ticket for an account with a Service Principal Name (SPN). The response contains data encrypted with the service account’s long-term Kerberos key, allowing password guesses to be tested offline. Human-managed service account passwords and excessive privileges can turn this exposure into a viable path.
• AS-REP Roasting. Accounts configured with “Do not require Kerberos preauthentication” allow an attacker with network access to a domain controller and knowledge of a valid username to request authentication data that can be cracked offline without first possessing domain credentials.

A Kerberoastable account alone says little about impact. The assessment needs to determine whether the password can be cracked within the agreed testing window and what the account can access afterward. That is where a technical exposure becomes a validated attack path.

Dangerous ACLs

Access control entries on directory objects are a common source of hidden privilege. Rights granted years earlier for a helpdesk process or administrative shortcut may remain in place long after the original need has disappeared.

Dangerous rights an assessment specifically hunts for include:

• GenericAll / GenericWrite over a user, group, or computer — full or broad control of that object.
• WriteDacl / WriteOwner — the ability to rewrite an object’s permissions or take ownership, then grant oneself full control.
• ForceChangePassword over a user — reset their password without knowing the old one.
• AddMember (or write on the member attribute) over a group — quietly add oneself to a privileged group.

These permissions become most dangerous when they connect. A compromised user may have GenericWrite over a second user, who belongs to a group with WriteDacl over another group, which administers a server where a Domain Admin has an active session. Each permission can look limited on its own. Together, they may provide a complete route to domain compromise.

Replication Rights and Tier-Zero Control

DCSync abuses legitimate directory replication rights. A principal with sufficient permissions can behave like a domain controller and request credential material for domain accounts without executing code on the controller.

The path often starts before the replication request itself. A service account, delegated administrator, or compromised group may already hold replication rights. An attacker may also obtain WriteDacl over the domain object and grant those rights to a controlled principal. In that situation, an ACL weakness provides access to the domain’s credential database.

Once replication access has been validated, the domain should be treated as compromised. Extracting every domain hash is usually unnecessary. A limited request for an approved test account can prove the impact while reducing sensitive-data handling. The report should show both the principal capable of replication and the permission chain that brought those rights within reach.

Group Policy Abuse

Group Policy Objects (GPOs) can translate directory permissions into configuration changes and code execution across every computer or user within their scope. A low-privileged principal may gain this influence by modifying a GPO, controlling its files in SYSVOL, or linking an attacker-controlled GPO to an organizational unit (OU).

• Computer configuration. A writable GPO can alter local group membership, create scheduled tasks or startup scripts, change services, or weaken security settings on every computer within its scope.
• User configuration. Logon scripts and user-side policy settings can execute in the context of affected users, creating a credential-access or lateral-movement path when privileged administrators receive the policy.
• GPO linking and scope. Rights to create, link, or relink GPOs can apply an attacker-controlled policy to a sensitive OU even when existing production GPOs are not directly writable. Security filtering, inheritance, enforced links, and OU placement determine which principals and systems are affected.

The assessment needs to establish where the writable GPO is linked, which principals process it, and what execution context follows. Write access to a workstation policy may have limited impact. The same access over a GPO applied to management servers or domain controllers can lead directly to tier-zero control.

Kerberos Delegation Abuse

Delegation allows a service to act on behalf of a user when accessing another service. The security impact depends on the delegation model and the surrounding configuration.

A delegation configuration becomes exploitable only when the assessor can control the relevant principal, meet the protocol preconditions, and reach a service where impersonation produces meaningful access. With RBCD, write access to a single computer object’s attributes can allow impersonation of a Domain Admin on that host. The practical impact is far greater than the original permission may suggest.

Active Directory Certificate Services (AD CS)

Where AD CS is deployed, certificate templates and certification authority settings can create high-impact attack paths. The public ESC (Escalation) catalog documents configurations that may allow a low-privileged user to obtain a certificate authenticating as a privileged account.

• ESC1-style template abuse. A path can exist when ordinary users can enroll in an authentication-capable template, supply the subject or Subject Alternative Name, and obtain issuance without manager approval or required authorized signatures.
• ESC8 / relay to web enrollment. A CA web-enrollment endpoint can accept relayed NTLM authentication and issue a certificate representing the relayed user or machine account. If that identity is privileged, such as a domain controller account, the result can lead to domain compromise.

Certificates can remain valid after a password reset, which makes these paths particularly serious from both escalation and persistence perspectives. The assessment should identify vulnerable templates and CA settings and, where authorized, confirm that a certificate providing privileged authentication can actually be issued.

Relay and Authentication Coercion

NTLM relay takes authentication generated by one system and forwards it to another service that accepts NTLM. The relayed session carries the permissions of the authenticating account on the destination.

• Authentication coercion. Protocols and services exposed by Windows systems can be abused to force a server, including a domain controller under certain conditions, to authenticate to an attacker-controlled endpoint.
• Relay to a compatible service. If the destination does not enforce the relevant signing, channel-binding, or Extended Protection controls, the attacker can forward the authentication to SMB, LDAP, HTTP enrollment, SQL Server, or another supported service.
• Privilege inherited from the relayed identity. A coerced machine account may have little value on one target and administrative rights on another. The destination and its permissions determine whether the relay produces lateral movement or privilege escalation.

A useful finding documents the whole route: which identity can be induced to authenticate, where its authentication can be relayed, and what control the relayed session provides.

Attack Paths Beyond a Single Active Directory Domain

Attack paths can cross the boundary of one Active Directory domain. Hybrid identity components connect on-premises AD DS with Microsoft Entra ID, while domain and forest trusts extend authentication and resource access across separate directory environments. Both need to be included when they can carry privilege beyond the initial domain.

Hybrid Identity: When the Path Crosses into Microsoft Entra ID

Microsoft Entra ID and on-premises Active Directory Domain Services use separate identity control planes. Synchronization and authentication components connect them in a hybrid environment, creating dependencies that belong in the attack-path model.

Microsoft Entra Connect or Cloud Sync may introduce service identities, synchronization permissions, servers, and operational accounts with influence across both environments. The direction of a possible attack path depends on the organization’s synchronization, authentication, role, and administrative architecture.

The assessment should map which attributes and credential material are synchronized, where synchronization components run, which accounts administer them, and how privileged cloud and on-premises identities are separated. Federation, pass-through authentication, password hash synchronization, service principals, and administrative role assignments should also be reviewed when they fall within scope.

Because the synchronization plane connects two identity environments, it may qualify as tier zero. Leaving it outside the assessment can exclude one of the most consequential trust boundaries in the organization.

Forest and Trust Boundaries

AD DS trusts allow identities from one domain or forest to be evaluated against permissions in another environment. Practical access depends on trust direction, transitivity, selective authentication, SID filtering, resource ACLs, and administrative ownership.

A forest is commonly treated as an administrative security boundary, yet that separation can weaken over time. Overbroad resource permissions, disabled or ineffective filtering, shared management infrastructure, credential reuse, and administrators operating across forests can all create cross-boundary paths.

A practical review should cover foreign users and group memberships, duplicate or reused identities across forests, accounts that administer systems on both sides of the trust, TGT delegation settings, and resources using forest-wide rather than selective authentication.

Testing should identify the trust path, confirm which identities can authenticate to which resources, and examine the operational relationships around the trust. A cross-trust edge in the graph is evidence for further analysis; compromise of the remote forest still requires validation.

Real Attack Scenario: From Domain User to Domain Admin via SCCM

During a recent assessment, our team followed a path that began with a weak password policy and ended in complete domain compromise. The initial foothold required neither a zero-day vulnerability nor access to an existing privileged account.

The foothold: a lax password policy. The domain enforced an eight-character minimum and had no regular password audit. A controlled spray below the known lockout threshold recovered credentials for a low-privileged account while still generating detectable authentication activity.

The pivot: an NTLM relay into the SCCM database. The team then targeted Microsoft Configuration Manager, formerly known as System Center Configuration Manager (SCCM). Using Coercer/PetitPotam, it induced authentication to a controlled endpoint and relayed it to the SCCM SQL Server. The relayed identity had database administration rights. An SQL query confirmed access, and controlled use of xp_cmdshell confirmed command execution on the host.

The escalation: abusing SCCM’s approval workflow. Database control allowed the team to elevate a low-privileged account to SCCM administrator. SCCM separates script creation from approval, so a second low-privileged account compromised through the same password weakness was also elevated. The two controlled identities could then satisfy the nominal separation-of-duties requirement and approve execution.

The impact: cleartext Domain Administrator credentials. SCCM stores credentials for the accounts it uses to manage the estate, and an SCCM administrator can decrypt them. After gaining administrative control of the SCCM environment, the team decrypted stored credentials and recovered clear-text passwords for privileged accounts, including Domain Administrators. Possession of those credentials gave the team full control of the Active Directory domain.

The validated path was as follows:

Why this chain matters. The environment contained several issues that could easily have been assigned to different teams: a lax password policy, a coercible host, a relay destination, excessive database permissions, and an approval model that assumed independently controlled administrators. Once connected, they created a continuous path from a weak password to complete domain compromise.

Common Mistakes Organizations Make

Privileged group membership rarely shows the full privilege model in Active Directory. Effective control may also come from delegated ACLs, local group membership, GPO control, certificate enrollment, service accounts, sessions, trusts, and synchronization infrastructure.

Service accounts tend to accumulate rights over time. An account created for one application becomes an administrator on several servers, gains access to a deployment share, and keeps the same password because nobody owns the dependency. Windows LAPS may protect local administrator passwords while privileged users continue to sign in to lower-tier systems and expose their credentials there.

AD CS is often reviewed separately from the rest of identity security. BloodHound data may be collected once, then left without validation, remediation, or regular refresh. Teams sometimes remove the final edge from a demonstrated path while equivalent routes remain available elsewhere in the environment.

These weaknesses usually sit across different administrative areas. An attacker only needs the relationships between them to remain usable.

How Iterasec Helps Secure Active Directory Environments

Iterasec assesses Active Directory through the relationships between identities, systems, permissions, and trust boundaries. The engagement begins from an agreed low-privileged position and follows the routes that could lead to high-value assets.

Assumed-breach path mapping. We begin with a standard domain user or another low-privileged foothold, collect the directory graph, and identify candidate paths to Domain Admin and other high-value targets. Paths are prioritized by reachability, preconditions, likely impact, and operational relevance before each step is validated.

Controlled exploitation and validation. Under explicit authorization, we conduct an agreed, time-bounded offline password audit against selected Kerberoastable and AS-REP-roastable credentials. We also validate delegation, ACL, GPO, relay, and certificate-service paths to establish which relationships produce real privilege in the tested environment.

Hybrid and forest-wide scope. Where the environment synchronizes with Entra ID or spans multiple domains and forests, the assessment includes the trust relationships and administrative dependencies between them.

Defensible, prioritized reporting. Findings are documented as reproducible active directory attack paths with clear reproduction steps, affected objects, and CVSS-aligned severity. Remediation guidance identifies the configuration changes that break each path and helps teams check for equivalent routes.

The final report gives security and infrastructure teams a practical view of how compromise can spread through the environment, where each path can be interrupted, and which fixes should be handled first.

Final Thoughts

A fully patched Active Directory environment can still be compromised through exposed credentials, delegated permissions, certificate services, privileged sessions, and trust relationships. Vulnerability scanning may identify some of these weaknesses individually, yet the connected route from a standard user to Domain Admin can remain hidden.

Active Directory penetration testing maps and validates those routes under controlled conditions, giving teams evidence they can use to prioritize remediation. Contact Iterasec to discuss an assessment covering your domain, endpoints, AD CS, hybrid identity, and multi-domain or multi-forest environment.