Active Directory: the 5 most common paths to Domain Admin
Active Directory is present in nearly every enterprise network. And in nearly every infrastructure pentest I run, at least one of these five paths leads to a Domain Admin account within a few hours. Not because teams are negligent, but because these vulnerabilities are structural, often inherited from configurations a decade old, and standard detection tools don't surface them.
1. Kerberoasting
Kerberos allows any authenticated user to request a service ticket (TGS) for any account with a registered Service Principal Name (SPN). This ticket is encrypted with the hash of the service account's password. An attacker can request this ticket, export it, and crack it offline with hashcat.
The problem: service accounts often have weak passwords, unchanged for years, and extensive rights in the domain. A kerberoastable SQL service account with a 2015 password and GenericAll rights on an OU is the norm, not the exception.
Hard to detect: TGS requests are legitimate Kerberos behaviour. Fix: manage service accounts with 30+ character complex passwords, or migrate to gMSAs (Group Managed Service Accounts) whose password is automatically managed by the domain.
2. AS-REP Roasting
Some accounts have the "Do not require Kerberos pre-authentication" option enabled. For these accounts, anyone can request an AS-REP (Authentication Service Response) without prior authentication. This AS-REP contains data encrypted with the account's password hash, directly crackable offline.
The attack doesn't even require a valid domain account to enumerate vulnerable accounts. And the option is sometimes accidentally enabled during migrations or compatibility configurations, then forgotten.
3. ACL abuse (Access Control Lists)
Active Directory is a graph of permissions. Every object (user, group, OU, GPO…) has an ACL defining who can do what with it. Apparently harmless rights can create direct escalation paths to Domain Admin.
- GenericAll on a user: the attacker can change their password without knowing the old one.
- WriteDACL on a group: the attacker can add themselves to the group, including Domain Admins.
- ForceChangePassword: reset a target account's password without user interaction.
- WriteOwner on an object: take ownership and modify its permissions arbitrarily.
These attack paths can be mapped with BloodHound. In practice, we regularly find rights delegations accumulated over several years, never audited, creating escalation paths in 3 or 4 hops from a standard user account.
4. Misconfigured ADCS (Active Directory Certificate Services)
AD CS is the PKI service built into Active Directory. It is present in the vast majority of Windows domains, often installed by default, rarely audited. Misconfigurations allow an unprivileged user to request a certificate on behalf of another account, including a Domain Admin.
Vulnerable certificate templates are numerous: ESC1 (a user can specify the certificate SAN), ESC2 (template with Any Purpose EKU), ESC4 (write rights on a template), ESC8 (NTLM relay to the web enrollment). With a valid certificate in the name of a Domain Admin, one can obtain their NTLM hash and authenticate as them.
ADCS is one of the most underestimated AD attack surfaces. The vast majority of organisations that have deployed it don't know it's there, let alone in what configuration state it sits.
5. Kerberos Unconstrained Delegation
Kerberos delegation allows a service to authenticate to other services on behalf of a user. Unconstrained delegation is the oldest and most dangerous form: a server configured with this right receives and stores the TGT (Ticket Granting Ticket) of any user who connects to it.
If an attacker compromises a server with unconstrained delegation, they can force a Domain Controller to authenticate to it (via a printer or SpoolSample, for example), capture the TGT of the DC's machine account, and use it to perform a DCSync, full domain dump.
Fix: migrate to constrained delegation or resource-based constrained delegation (RBCD). Identify all accounts and servers with unconstrained delegation via Get-ADComputer -Filter {TrustedForDelegation -eq $true}.
What an Active Directory pentest covers
An AD pentest isn't limited to running BloodHound and reading the graph. It involves manual analysis of your domain's specific configurations, building realistic attack chains from a defined starting point (standard user account, network access only), and demonstrating concrete impact, not just a report of theoretical vulnerabilities.
The five paths described here are not an exhaustive list, they are the most common ones. DCSync, Pass-the-Hash, Pass-the-Ticket, Shadow Credentials, Golden/Silver Ticket… every AD environment has its own combination of weaknesses, shaped by ten or fifteen years of accumulated technical decisions. That is what an audit is supposed to reveal.
Further reading
A question after reading?
You have an Active Directory and want to know what an attacker could do with it? Send a message. No pitch, no automatic quote.
Or book a 30-minute scoping call directly
Book a call →