Kerberoasting and Golden Ticket Attacks

To understand Kerberoasting and Golden Ticket attacks, you need a clear picture of Kerberos service ticket issuance. When a client wants to access a service (e.g., an SQL server), it presents its Ticket Granting Ticket (TGT) to the Domain Controller's Ticket Granting Service (TGS). The TGS issues a Service Ticket encrypted with the service account's password hash. The client presents this ticket to the service, which decrypts it with its own hash to verify authenticity. This design means service tickets are encrypted with the target service's credential — a critical detail that Kerberoasting exploits.

Kerberoasting is an attack that exploits the fact that any authenticated domain user can request a Kerberos service ticket for any service registered with an SPN (Service Principal Name). The attacker requests service tickets for accounts with SPNs, captures the encrypted ticket blobs, and then attempts to crack the service account password offline — without any further interaction with Active Directory or any account lockout risk. Service accounts often have weak passwords, old passwords that predate modern complexity requirements, or passwords that never expire, making them highly vulnerable to offline cracking.

The captured service ticket hashes from Kerberoasting are encrypted with RC4-HMAC (NTLM hash) by default (for compatibility), which is faster to crack than AES-256 Kerberos tickets. An attacker feeds the captured $krb5tgs$23$ hashes into Hashcat or John the Ripper for offline dictionary and brute-force attacks. Common wordlists like RockYou plus rule sets can crack most weak service account passwords in minutes to hours on consumer GPU hardware. Once cracked, the attacker has the service account's plaintext password, which they can use to authenticate directly.

Kerberoasting mitigations target three areas: password strength — service accounts should have long, random passwords (25+ characters) that resist offline cracking even with GPU clusters; Group Managed Service Accounts (gMSA) — Windows automatically manages gMSA passwords (240-character random values rotated every 30 days), making Kerberoasting computationally infeasible; AES-only encryption — configure service accounts to require AES-256 tickets (msDS-SupportedEncryptionTypes), which crack exponentially slower than RC4; and detection — alert on unusual volume of TGS requests (Event ID 4769) for service accounts from non-standard workstations.

The KRBTGT account is a special built-in Active Directory account whose password hash is used to sign and encrypt all Kerberos TGTs in the domain. The domain controller uses the KRBTGT hash to create TGTs and to validate incoming TGTs. This makes the KRBTGT hash the single most valuable credential in an Active Directory environment — anyone who possesses it can create arbitrary, fully valid Kerberos tickets for any user, including non-existent users, with any group membership, for any duration. The KRBTGT password has typically never been changed in many organizations, because the change process requires careful coordination.

A Golden Ticket attack creates a forged, fully valid Kerberos TGT using the compromised KRBTGT account's password hash. The attacker uses Mimikatz's kerberos::golden command to generate a TGT for any user (often a fake Administrator-like account) with any group memberships (typically including Domain Admins), with any validity period (commonly set to 10 years). This forged ticket is indistinguishable from a legitimate ticket to the domain controller, because it is cryptographically valid — it was signed with the real KRBTGT hash. A Golden Ticket provides complete, persistent, unlimited control over the domain.

Golden Tickets are particularly dangerous because they persist even after the original attack is discovered and cleaned up. Changing the targeted user's password does nothing — the ticket was forged, not based on the user's real credentials. The only remediation is changing the KRBTGT password twice (once to invalidate existing tickets, once more because there are two KRBTGT keys at any time for rolling purposes). However, KRBTGT password changes require careful coordination: if changed improperly, it breaks Kerberos authentication domain-wide. Many organizations are reluctant to perform this remediation, leaving Golden Tickets valid indefinitely.

A Silver Ticket is similar to a Golden Ticket but more limited in scope. It uses the target service account's hash (instead of KRBTGT) to forge a service ticket for that specific service only. For example, with an SQL server service account hash, an attacker can forge a service ticket granting them any access to that SQL server. Silver Tickets are harder to detect than Golden Tickets because they bypass the domain controller entirely — the forged ticket goes directly from attacker to service, with no KDC contact. Mitigation requires protecting service account hashes and monitoring for anomalous access patterns on sensitive services.

Attackers obtain the KRBTGT hash using the DCSync attack, which abuses Active Directory's legitimate domain replication protocol. The Directory Replication Service (DRS) allows domain controllers to sync AD data, including password hashes, between each other. An attacker with DCSync privileges (typically Domain Admin, Enterprise Admin, or any account with Replicating Directory Changes All permissions) can impersonate a domain controller and request hash replication for any account. Mimikatz's lsadump::dcsync command performs this attack entirely over the network — no code needs to run on the DC itself.

Detecting Golden Ticket usage is challenging but possible by looking for anomalies in Kerberos ticket metadata: tickets with unusually long lifetimes (real tickets have 10-hour TGT lifetime; Golden Tickets are often set to 10 years); Event ID 4769 where the ticket encryption type is RC4 (0x17) when AES-256 (0x12) is the domain default; account names in tickets that do not exist in AD; and missing Event ID 4768 (TGT request) before Event ID 4769 (service ticket request) — Golden Tickets skip the TGT request phase since the TGT itself is forged. A Microsoft Sentinel or Defender for Identity rule can flag these patterns automatically.

A layered defense against Kerberos attacks: use gMSA for all service accounts to make Kerberoasting infeasible; enable AES-only encryption for all accounts, especially high-value service accounts, to maximize cracking difficulty; restrict DCSync privileges — audit accounts with replication permissions and remove any that should not have them; enable Microsoft Defender for Identity (formerly ATA) which provides Kerberos-aware threat detection including Golden Ticket, Kerberoasting, and DCSync alerts in real time; and implement a tiered administration model so that even if a Tier 2 account is compromised, it cannot be used to reach DC-level credentials.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: Kerberoasting requests service tickets for SPN-registered accounts and cracks them offline — defeated by gMSA, strong passwords, and AES-only encryption, Golden Ticket attacks use the KRBTGT hash to forge unlimited TGTs providing persistent domain control that persists until the KRBTGT password is reset twice, and DCSync attacks replicate the KRBTGT hash over the network without running code on the DC — requiring strict DCSync privilege auditing. Next up we explore the MITRE ATT&CK framework for mapping attacker techniques to defenses.