Kerberoasting, Golden Tickets, and Domain Dominance: AD Attack Chains We Execute in Every Engagement

Active Directory remains the backbone of enterprise identity management. Microsoft's own figures put AD or Entra ID (formerly Azure AD) in over 90% of Fortune 1000 companies.^[1] That dominance makes it the single highest-value target in almost every internal penetration test we run. Compromise one domain controller and you own the keys to every server, workstation, and SaaS integration that trusts it.

This article is not a theoretical overview. It is a technical catalog of the attack chains our team executes during real engagements, including the exact tools, the specific Kerberos mechanics being abused, and the defensive controls that would have stopped us. If you operate an AD environment, this is the adversary playbook your blue team needs to understand.

The Reconnaissance Phase: BloodHound and LDAP Enumeration

Every AD engagement starts the same way: we collect the graph. BloodHound, originally released by SpecterOps in 2016 and now maintained as BloodHound Community Edition (CE), ingests LDAP data and maps every relationship between users, groups, computers, GPOs, and ACLs into a Neo4j or PostgreSQL graph database.^[2] The power is not in seeing individual objects. It is in seeing paths.

We run the SharpHound collector (or its Python equivalent, BloodHound.py) from any domain-joined context. A standard domain user account is sufficient. SharpHound queries LDAP for group memberships, ACL entries, session data, and trust relationships. The collection typically finishes in under five minutes for environments with fewer than 10,000 objects.

Once the data is imported, we query for "shortest path to Domain Admins" and work outward from there. BloodHound's pre-built queries reveal attack paths that would take hours to find manually: nested group memberships granting unintended privileges, computers where high-value users have active sessions, and ACL misconfigurations that allow password resets or object takeover.

Beyond BloodHound, we enumerate with targeted LDAP queries using tools like ldapsearch, PowerView (now largely succeeded by its .NET rewrite in SharpView), and NetExec (the actively maintained fork of CrackMapExec). We look for service accounts with SPNs set, accounts with Kerberos pre-authentication disabled, unconstrained delegation configurations, and certificate templates in Active Directory Certificate Services (ADCS).

AS-REP Roasting: Harvesting Hashes Without Authentication

AS-REP Roasting targets accounts that have the "Do not require Kerberos preauthentication" flag set (DONT_REQ_PREAUTH in UserAccountControl). When preauthentication is disabled, anyone on the network can request an Authentication Service Reply (AS-REP) for that user. The reply contains a portion encrypted with the user's password hash, which we can crack offline.

The attack is straightforward with Impacket's GetNPUsers.py:

GetNPUsers.py DOMAIN/ -usersfile users.txt -no-pass -dc-ip 10.10.10.1 -format hashcat -outputfile asrep_hashes.txt

Alternatively, Rubeus handles it from a domain-joined Windows host:

Rubeus.exe asreproast /format:hashcat /outfile:asrep_hashes.txt

The resulting hashes use Hashcat mode 18200. With a decent wordlist (we typically start with rockyou combined with company-specific mutations) and a GPU rig running an RTX 4090, most weak passwords fall within minutes. Passwords based on seasons, years, or company names crack almost instantly.

AS-REP Roasting is often overlooked because it requires a specific misconfiguration. But we find it in roughly 30-40% of engagements, usually on legacy service accounts or accounts created by third-party applications that set the flag during provisioning.

Defenses Against AS-REP Roasting

• Audit and remove the DONT_REQ_PREAUTH flag on all accounts. There is almost never a legitimate reason for it in modern environments.
• Enforce a minimum password length of 16+ characters on any account where the flag cannot be removed.
• Monitor Event ID 4768 (Kerberos Authentication Service requests) for accounts with pre-authentication disabled.

Kerberoasting: The Workhorse Attack

Kerberoasting is the single most reliable privilege escalation technique in Active Directory. It works against any domain user account that has a Service Principal Name (SPN) registered. When a user requests a Kerberos service ticket (TGS) for an SPN, the Key Distribution Center (KDC) encrypts part of the ticket with the service account's NTLM hash. Any authenticated domain user can request these tickets, and the encrypted portion can be cracked offline.^[3]

The attack has been well-known since Tim Medin presented it at DerbyCon in 2014, yet it remains devastatingly effective because organizations continue to run service accounts with weak passwords and SPNs registered to privileged accounts.

Using Rubeus from a Windows host:

Rubeus.exe kerberoast /stats (to enumerate roastable accounts first)

Rubeus.exe kerberoast /format:hashcat /outfile:tgs_hashes.txt

Or with Impacket from Linux:

GetUserSPNs.py DOMAIN/user:password -dc-ip 10.10.10.1 -request -outputfile tgs_hashes.txt

The resulting hashes use Hashcat mode 13100 (RC4) or 19700 (AES). RC4-encrypted tickets crack significantly faster than AES, and many environments still default to RC4 for backward compatibility. A single RTX 4090 can test approximately 7 billion RC4 candidates per second against Kerberos 5 TGS-REP hashes.

What makes Kerberoasting particularly dangerous is the target profile. Service accounts with SPNs are frequently highly privileged. They run SQL Server instances (MSSQLSvc/), web applications (HTTP/), or backup solutions (backupexec/) with Domain Admin or equivalent privileges. Crack one of these passwords and you skip multiple steps in the kill chain.

Defenses Against Kerberoasting

• Use Group Managed Service Accounts (gMSAs) wherever possible. Their passwords are 240+ characters, randomly generated, and rotated automatically by AD.
• For accounts that must use traditional passwords, enforce a minimum of 25 characters.
• Remove SPNs from accounts that no longer need them.
• Monitor for anomalous TGS requests (Event ID 4769), particularly bulk requests or requests using RC4 encryption (0x17).
• Configure AES256 encryption for service accounts to make cracking significantly slower.

Pass-the-Hash and Pass-the-Ticket

Once we have a cracked password or can dump credentials from memory, lateral movement accelerates rapidly. Pass-the-Hash (PtH) uses the NTLM hash directly, without needing to know the plaintext password, to authenticate to other systems via NTLM authentication. This works because Windows NTLM authentication uses the hash as the shared secret, not the password itself.^[4]

NetExec (the successor to CrackMapExec) is our primary tool for PtH-based lateral movement:

nxc smb 10.10.10.0/24 -u administrator -H aad3b435b51404eeaad3b435b51404ee:5f4dcc3b5aa765d61d8327deb882cf99 --shares

Pass-the-Ticket (PtT) operates at the Kerberos level. Instead of hashes, we inject a stolen Kerberos ticket (TGT or TGS) into our session. Rubeus makes this trivial:

Rubeus.exe ptt /ticket:base64_encoded_ticket

The critical insight for defenders is that PtH only works against NTLM authentication, while PtT works against Kerberos. Disabling NTLM entirely (a significant but worthwhile project) eliminates PtH but does nothing against PtT. You need to address both protocols.

Credential Dumping with Mimikatz and Alternatives

To obtain hashes and tickets for these attacks, we dump credentials from memory using Mimikatz, its .NET equivalent SafetyKatz, or the built-in comsvcs.dll MiniDump technique to extract LSASS process memory. On modern, well-defended endpoints with Credential Guard enabled, these techniques are blocked. But Credential Guard adoption remains low. Microsoft's own telemetry suggests fewer than 25% of enterprise Windows 11 deployments have it fully configured.

We also extract credentials from the NTDS.dit file (the AD database) when we reach a domain controller, from SAM/SYSTEM registry hives on individual hosts, and from cached credentials (mscash2 hashes) on laptops that authenticate while off the corporate network.

Delegation Abuse: Unconstrained, Constrained, and Resource-Based

Kerberos delegation is one of the most misunderstood and misconfigured features in AD. It allows a service to impersonate a user when accessing another service. There are three types, and all three are abusable.

Unconstrained Delegation

When a server is configured for unconstrained delegation, it stores the full TGT of any user who authenticates to it. If we compromise that server, we can extract those TGTs and impersonate any user who connected to it, including Domain Admins. The "printer bug" (MS-RPRN) or PetitPotam (MS-EFSRPC) can be used to coerce a domain controller to authenticate to our compromised server, delivering the DC's machine account TGT directly to us.^[5]

Rubeus can monitor for incoming TGTs in real time:

Rubeus.exe monitor /interval:5 /filteruser:DC01$

Combined with the SpoolSample or PetitPotam coercion tools, this gives us a domain controller's TGT, which we can use for DCSync.

Constrained Delegation

Constrained delegation limits which services an account can delegate to, using the msDS-AllowedToDelegateTo attribute. However, the S4U2Self and S4U2Proxy Kerberos extensions that power constrained delegation can be abused. If we compromise an account with constrained delegation configured, we can request tickets to the allowed services as any user, including Domain Admins. Rubeus handles the S4U chain:

Rubeus.exe s4u /user:sqlservice /rc4:HASH /impersonateuser:administrator /msdsspn:cifs/fileserver.domain.com /ptt

Resource-Based Constrained Delegation (RBCD)

RBCD flips the delegation model. Instead of the front-end service specifying which back-end services it can delegate to, the back-end service specifies which front-end services can delegate to it, via the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. The attack requires write access to a computer object's properties. If we can modify this attribute on a target computer, we can configure a machine account we control to delegate to it, then use S4U2Self and S4U2Proxy to access the target as any user.

This is particularly powerful because any domain user can, by default, create up to 10 machine accounts (ms-DS-MachineAccountQuota), giving us the front-end service account we need for the attack chain.

DCSync: Replicating the Keys to the Kingdom

DCSync is the attack that turns domain compromise from "we have admin access" to "we own the entire directory permanently." It abuses the Directory Replication Service (DRS) protocol, specifically the GetNCChanges function, to request password data from a domain controller as if we were another DC performing replication.^[6]

Any account with the "Replicating Directory Changes" and "Replicating Directory Changes All" privileges can perform DCSync. By default, this includes Domain Admins, Enterprise Admins, and the domain controller machine accounts. But we frequently find these privileges delegated to service accounts, backup solutions, or identity management platforms.

Using Impacket's secretsdump.py:

secretsdump.py DOMAIN/compromised_user:[email protected] -just-dc-ntlm

Or with Mimikatz:

lsadump::dcsync /domain:domain.com /user:krbtgt

The krbtgt hash is the ultimate prize. With it, we can forge Golden Tickets.

Golden Tickets: Persistence That Survives Password Resets

A Golden Ticket is a forged Ticket Granting Ticket (TGT) created using the krbtgt account's NTLM hash. Since every TGT in the domain is encrypted with the krbtgt hash, possessing that hash allows us to create valid TGTs for any user, with any group memberships, with any expiration date. The forged ticket is indistinguishable from a legitimate one because it is encrypted with the same key the KDC uses.^[7]

Creating a Golden Ticket with Mimikatz:

kerberos::golden /user:administrator /domain:domain.com /sid:S-1-5-21-XXXXXXXXXX /krbtgt:HASH /ptt

Or with Impacket's ticketer.py:

ticketer.py -nthash KRBTGT_HASH -domain-sid S-1-5-21-XXXXXXXXXX -domain domain.com administrator

Golden Tickets are a persistence mechanism, not an initial access technique. They allow an attacker who has been evicted to return without needing to re-compromise any account. The ticket remains valid until the krbtgt password is changed, and because the krbtgt password must be changed twice (the previous password is retained for continuity), remediation requires two resets with a replication cycle between them.

Silver Tickets

Silver Tickets are the targeted cousin of Golden Tickets. Instead of forging a TGT, we forge a TGS for a specific service using that service account's NTLM hash. Silver Tickets never touch the KDC, making them harder to detect. They are useful for targeted persistence against specific services like CIFS (file shares), MSSQL, or HTTP (web services).

NTLM Relay: Capturing and Forwarding Authentication

NTLM relay attacks intercept NTLM authentication attempts and forward them to a different target service. The attacker positions themselves between the client and server, capturing the authentication handshake and relaying it to achieve unauthorized access. Impacket's ntlmrelayx.py is the standard tool.^[8]

The attack requires two components: a way to coerce or intercept authentication, and a target that accepts NTLM authentication without signing. Common coercion methods include:

• LLMNR/NBT-NS poisoning: Responding to multicast name resolution queries on the local network with Responder.
• PetitPotam (CVE-2021-36942): Coercing a machine to authenticate via the EFS RPC interface.
• Print Spooler (MS-RPRN): Abusing the Print Spooler service to coerce authentication.
• DFSCoerce: Abusing the Distributed File System protocol for authentication coercion.

Relay targets include LDAP (for modifying AD objects, including writing RBCD attributes), SMB (for code execution on hosts without SMB signing), HTTP (for ADCS web enrollment), and MSSQL. The most devastating relay chain we execute regularly is PetitPotam to ADCS web enrollment, which yields a domain controller certificate that can be used for authentication as the DC's machine account.

Defenses Against NTLM Relay

• Enable SMB signing on all hosts (required on DCs by default, but not on member servers or workstations).
• Enable LDAP signing and channel binding.
• Enable Extended Protection for Authentication (EPA) on all web services, including ADCS web enrollment.
• Disable LLMNR and NBT-NS via Group Policy.
• Disable the Print Spooler service on domain controllers and servers that do not need it.
• Apply patches for PetitPotam and related coercion vulnerabilities.

ADCS Abuse: The New Frontier (ESC1 through ESC8)

Active Directory Certificate Services has emerged as one of the most impactful attack surfaces in AD since the "Certified Pre-Owned" whitepaper by Will Schroeder and Lee Christensen of SpecterOps in 2021.^[9] ADCS misconfigurations can provide domain escalation, persistence, and credential theft. The escalation scenarios are categorized as ESC1 through ESC8 (with additional scenarios identified since the original research).

ESC1: Misconfigured Certificate Templates

ESC1 is the most common and most directly exploitable. It occurs when a certificate template allows a low-privileged user to enroll, permits the enrollee to specify a Subject Alternative Name (SAN), and the template is configured for client authentication. This allows us to request a certificate as any user, including Domain Admins. Certipy (the Python tool) or Certify (the .NET tool) enumerate and exploit this:

certipy find -u [email protected] -p password -dc-ip 10.10.10.1 -vulnerable

certipy req -u [email protected] -p password -ca CORP-CA -template VulnerableTemplate -upn [email protected]

The resulting certificate can be used with PKINIT to obtain a TGT as the targeted user.

ESC4: Vulnerable Certificate Template ACLs

If we have write access to a certificate template object in AD, we can modify it to become vulnerable to ESC1, request our malicious certificate, then revert the template to its original state. This is a write-once, exploit, clean-up chain that is difficult to detect without monitoring certificate template modifications.

ESC8: NTLM Relay to ADCS Web Enrollment

ESC8 combines NTLM relay with ADCS. If the Certificate Authority's web enrollment endpoint (certsrv) does not enforce EPA, we can relay NTLM authentication to it and request a certificate on behalf of the relayed account. Relaying a domain controller's machine account (coerced via PetitPotam) gives us a certificate that authenticates as the DC, leading directly to DCSync.

ntlmrelayx.py -t http://ca.domain.com/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

ESC11: NTLM Relay to ICPR (RPC)

Even after organizations secure the HTTP enrollment endpoint, the RPC-based certificate enrollment interface (MS-ICPR) may remain vulnerable to relay if the CA does not enforce "IF_ENFORCEENCRYPTICERTREQUEST." Certipy supports this attack path as well.

Chaining It All Together: Real Attack Paths

Individual techniques are useful to understand, but real AD compromise happens through chains. Here are three chains we execute regularly.

Chain 1: Kerberoast to DCSync

1. Enumerate SPNs with BloodHound or GetUserSPNs.py.
2. Request TGS tickets for service accounts.
3. Crack a service account password that has Replicating Directory Changes privileges (common with backup or identity sync accounts).
4. DCSync to extract the krbtgt hash and all domain hashes.

Chain 2: NTLM Relay to ADCS to Domain Admin

1. Run PetitPotam to coerce the DC to authenticate to our relay server.
2. Relay the DC's NTLM authentication to the ADCS web enrollment endpoint (ESC8).
3. Obtain a certificate for the DC's machine account.
4. Use the certificate with PKINIT to get a TGT as the DC.
5. Perform DCSync with the DC's machine account privileges.

Chain 3: Delegation Abuse to Lateral Movement

1. Identify a computer with unconstrained delegation via BloodHound.
2. Compromise that computer (often through a separate chain, such as local admin reuse found via NetExec).
3. Use the printer bug or PetitPotam to coerce DC authentication.
4. Capture the DC's TGT from the unconstrained delegation server's memory.
5. Use the TGT for DCSync or direct domain controller access.

Detection and Hardening: A Practical Checklist

Stopping these attacks requires layered defenses. No single control prevents all of them. Here is the priority list we give to every client after an AD engagement.

1. Enable Credential Guard on all Windows 10/11 and Server 2016+ systems to protect LSASS from memory dumping.
2. Deploy a tiered administration model (Tier 0/1/2) to prevent domain admin credentials from touching workstations and member servers.
3. Migrate service accounts to gMSAs to eliminate Kerberoasting entirely for those accounts.
4. Set ms-DS-MachineAccountQuota to 0 to prevent RBCD attacks using attacker-created machine accounts.
5. Enable SMB signing, LDAP signing, and LDAP channel binding across the environment.
6. Disable NTLM where possible. Start by auditing NTLM usage with the "Restrict NTLM" Group Policy settings, then progressively block it.
7. Audit ADCS templates and remove unnecessary enrollment permissions and the "Supply in Request" SAN flag.
8. Monitor for indicators: Event IDs 4769 (Kerberoasting), 4768 (AS-REP roasting), 4662 (DCSync), and certificate enrollment events.
9. Reset the krbtgt password twice during incident response, with a minimum 12-hour gap between resets to allow replication.
10. Run BloodHound regularly against your own environment to discover attack paths before adversaries do.

Conclusion

Active Directory attack chains are not novel. The techniques described in this article have been publicly documented for years, and the tools are open-source. Yet we continue to achieve domain dominance on the majority of our internal penetration tests because the defensive fundamentals remain unimplemented in most environments.

The gap is not knowledge. It is execution. Tiered administration is well-understood but rarely deployed. gMSAs are available in every modern AD environment but ignored in favor of shared-password service accounts. ADCS has been a known attack surface since 2021, yet many organizations have never audited their certificate templates.

If your organization has not had an AD-focused penetration test in the last 12 months, the attack paths described here almost certainly exist in your environment. The question is whether your team will find them first, or whether an adversary will.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.