Golden Ticket
Golden Tickets are forged TGTs created using the NTLM hash or AES keys of the krbtgt account, an account responsible for signing all TGTs in an AD domain. With this secret, attackers can generate valid TGTs for any user, including DAs, effectively enabling full domain impersonation. Unlike Silver Tickets, which target service tickets, Golden Tickets provide domain-wide access and persistence.
The krbtgt account is disabled by default and it doesn’t have any interesting rights for better protection.
The TGT returned in the AS‑REP contains user and authorization information embedded in the Privilege Attribute Certificate (PAC). This PAC is subsequently copied into each TGS, allowing service accounts to determine the identity and privileges of the requesting user without directly querying the DC. If the krbtgt account is compromised, an attacker can modify the PAC within a forged TGT and re‑encrypt it using the krbtgt key.
This technique does not require domain membership, elevated privileges on the local host, or ongoing access to the DC after the krbtgt secret has been obtained. Since the krbtgt account password rarely changes, Golden Tickets remain a reliable and stealthy post-exploitation method even after DA credentials rotate.
To successfully create a Golden Ticket, the attacker requires four key elements: the domain name, the domain SID, the username to impersonate, and the krbtgt account hash.
To remediate a Golden Ticket attack, the password of the krbtgt account must be changed twice. The KDC maintains two password hashes for krbtgt: the current hash and the previous one. This design ensures that authentication does not fail for tickets issued shortly before a password change.
A Golden Ticket remains valid as long as it is signed with either of these hashes. Therefore:
First password change: previously forged tickets may still be accepted because the earlier hash is still stored as the “previous” password.
Second password change: both hashes are replaced, which invalidates all existing forged tickets.
After the first reset, sufficient time must be allowed for full replication across the entire domain or forest before performing the second reset. In many environments this convergence occurs within several hours, but organisations often wait up to 24 hours to ensure consistency. During this window, an attacker who still has privileged access may be able to compromise the environment again and obtain the updated hash.
The Golden Ticket attack is often used by red teamers and penetration testers to demonstrate the potential impact of a domain compromise. This is commonly achieved by forging a ticket for a non‑existent user, which highlights the level of persistence and control an attacker could maintain within the domain.
OPSEC and Persistence
Golden Tickets are essentially a Kerberos-based Overpass-the-Hash. Forged TGTs are accepted by the KDC as valid because they're signed with the krbtgt secret. The only requirement is network access to the Kerberos port (88) on the DC. The attack can be performed from non-domain-joined machines.
Although DA credentials grant full access, they must follow the domain password policy and are likely to change. In contrast, the krbtgt account password is static by default, making Golden Tickets an ideal long-term persistence method. For long-term access and minimal detection, prefer AES keys over NTLM and use DCSync to reduce footprint on DCs.
In addition, standard Windows event logs cannot reliably distinguish between a legitimate TGT and a forged one, making detection challenging. Furthermore, resetting the password of the impersonated account does not invalidate a Golden Ticket, as it is signed with the krbtgt account key rather than the user’s credentials.
Tools such as mimikatz generate Golden Tickets with a default lifetime of ten years, which may serve as a potential IoC. In comparison, legitimate Kerberos TGTs typically have a lifetime of approximately ten hours and can be renewed without re-authentication for up to seven days.
Detection may also be possible by examining inconsistencies in the ticket’s domain field. Normally, the DOMAIN field stored in the PAC contains the NetBIOS domain name (for example, MARVEL). If the field is left blank or contains the FQDN, such as MARVEL.LOCAL, instead of the NetBIOS name, this may indicate improper ticket crafting. Careful inspection of how the ticket was generated and how the tool populates these fields is therefore essential.
Windows
Create a session in the context of the compromised DA.
Next, there are two common ways to extract krbtgt credentials.
OPSEC: The DCSync method is preferred as it extracts both the AES256 key and NT hash without touching the DC. The local dump method extracts just the NTLM hash and executes code on the DC.
Previous tickets can be purged before executing the Golden Ticket attack.
Rubeus can be used to generate the Golden Ticket-forging command from a non-elevated shell. The below command makes three queries to the DC to retrieve the following information:
Flags for the specified user
/groups,/pgid,/minpassageand/maxpassage/netbiosof the current domain
OPSEC:
Target an active DA account, not just the default account; the latter may be dormant or act as a honeypot.
Key parameters (SID, groups, UAC flags, etc.) can be pulled dynamically or specified manually for better stealth.
Linux
Last updated