Golden Ticket

What is

A Golden Ticket is a forged Kerberos Ticket Granting Ticket (TGT) created using the long-term secret associated with the krbtgt account of an Active Directory domain.

The krbtgt account is a special account used by the Key Distribution Center (KDC) to protect Kerberos authentication data. Its secret is used to sign or encrypt information associated with Ticket Granting Tickets.

If an attacker obtains the krbtgt account’s secret, they can forge their own TGTs without obtaining a legitimate TGT from the Domain Controller.

This allows the attacker to create a Kerberos identity containing a chosen username and group memberships. The forged ticket can then be used to request service tickets for resources in the domain.

For this reason, compromise of the krbtgt account is considered a serious Active Directory compromise.

A Golden Ticket does not directly grant unrestricted access to every resource. The effective access depends on the information represented in the forged ticket and the permissions assigned to the corresponding security principals.

Requirements

The following conditions are required for a Golden Ticket attack:

• Sufficient privileges to obtain the krbtgt account’s secret.
• The NTLM hash or another suitable cryptographic key associated with krbtgt.
• The Active Directory domain name.
• The Security Identifier (SID) of the target domain.
• Access to a Windows environment where the forged ticket can be created and injected.
• A Kerberos-enabled Active Directory environment.

A common lab scenario is obtaining Domain Admin or equivalent privileges and using them to extract the krbtgt account information from a Domain Controller.

How to

Summary

The basic workflow is:

Detailed

1. Start Mimikatz

The first step is to start Mimikatz in an elevated context.

The process must have sufficient privileges to access the information required from the Domain Controller or the local security subsystem.

Once Mimikatz is running, enable the debug privilege using privilege::debug.

A successful result indicates that Mimikatz has obtained SeDebugPrivilege.

2. Obtain the krbtgt account secret

The next step is to retrieve the cryptographic material associated with the krbtgt account.

Use:

lsadump::lsa /inject /name:krbtgt

This instructs Mimikatz to target the krbtgt account and retrieve information associated with its secret.

The output contains several pieces of information. For the Golden Ticket technique described here, the important values are:

• The domain name.

• The domain SID.

• The krbtgt NTLM hash.

The exact output can vary depending on the Windows version and Mimikatz version.

The krbtgt secret is the critical component because it allows the attacker to generate a TGT that can be cryptographically validated by the domain’s Kerberos infrastructure.

3. Forge the Golden Ticket

Once the required information has been collected, Mimikatz can create a forged TGT using kerberos::golden.

The command has the following structure:

kerberos::golden /user:<USERNAME> /domain:<DOMAIN> /sid:<DOMAIN_SID> /krbtgt:<NTLM_HASH> /id:500 /ptt

The important parameters are:

• /user:<USERNAME> specifies the username represented by the forged ticket.
• /domain:<DOMAIN> specifies the Active Directory domain.
• /sid:<DOMAIN_SID> specifies the SID of the domain.
• /krbtgt:<NTLM_HASH> specifies the cryptographic secret associated with the krbtgt account.
• /id:500 specifies the RID represented by the ticket.
• /ptt instructs Mimikatz to pass the ticket into the current logon session.

The username does not have to correspond to an existing Active Directory user for the ticket to be created.

However, the identity represented by the ticket and the group memberships included in it determine what authorization decisions may be made when the ticket is used.

4. Inject the ticket

The /ptt option causes Mimikatz to inject the forged ticket into the current Windows logon session.

This means that the ticket becomes available to Kerberos-aware applications running in that security context.

The important distinction is between creating the Golden Ticket and injecting it.

A forged ticket can exist as a file or in memory, but it must be available to the relevant logon session before Kerberos-aware applications can use it.

5. Open a new command shell

After injecting the ticket, Mimikatz can be used to create a new command shell with misc::cmd.

This provides a convenient environment for testing whether the injected Kerberos ticket is being used.

The resulting shell operates within the security context associated with the current logon session.

The effective access should then be validated against specific domain resources rather than assuming that the ticket automatically provides unrestricted access everywhere.

Understanding the attack

The Golden Ticket attack abuses the trust relationship between Active Directory services and the krbtgt account.

A simplified Kerberos flow is:

                Legitimate Kerberos authentication

User
 |
 | Authentication
 v
KDC / Domain Controller
 |
 | TGT signed using krbtgt secret
 v
TGT
 |
 | Request service ticket
 v
KDC
 |
 | TGS
 v
Service

Normally, a user authenticates to the KDC and receives a TGT.

The KDC uses the krbtgt account’s secret when creating and protecting the TGT.

The user can then present that TGT to the KDC when requesting Service Tickets (TGS) for specific services.

The Golden Ticket attack changes this process.

Instead of obtaining a TGT from the KDC, the attacker creates one locally using the compromised krbtgt secret.

The resulting flow becomes:

             Compromised krbtgt secret
                       |
                       v
                    Mimikatz
                       |
                       | Forge TGT
                       v
               Golden Ticket
                       |
                       | Inject
                       v
                Windows session
                       |
                       | Request TGS
                       v
              Domain Controller
                       |
                       | Service Ticket
                       v
                 Target service

The KDC can accept the forged TGT because it is generated using the secret associated with krbtgt.

This is the fundamental reason why the krbtgt account is so important to Active Directory security.

Why the krbtgt account is important

The krbtgt account is not a normal administrative account.

It is used by the KDC as part of the Kerberos trust infrastructure of the domain.

Compromising an ordinary domain administrator and compromising krbtgt therefore have different technical implications.

A compromised Domain Admin account provides the privileges associated with that account.

A compromised krbtgt secret allows an attacker to forge Kerberos TGTs and potentially maintain domain-level persistence independently of a particular user’s password.

Golden Ticket persistence

One of the important characteristics of Golden Tickets is their persistence.

Changing the password of the user represented by a forged ticket does not invalidate the ticket because the ticket was not created using that user’s password.

The relevant secret is the krbtgt account secret.

As a result, remediation requires rotating the krbtgt password rather than simply changing the password of the impersonated user.

Because existing Kerberos tickets can remain valid for a period of time, organizations normally need to plan krbtgt password rotation carefully.

Common problems

The krbtgt information cannot be retrieved

Verify that the current account has sufficient privileges to access the required Domain Controller secrets.

Domain Admin is a common lab context, but the exact privileges required depend on the extraction method.

The forged ticket is created but does not provide the expected access

Creating a Golden Ticket does not guarantee unrestricted access to every service.

Verify:

• The domain name.
• The domain SID.
• The krbtgt secret.
• The username represented by the ticket.
• The group memberships included in the ticket.
• The permissions assigned to the represented identity.
• The target service and authentication protocol.

The ticket is not being used

If the ticket was created without /ptt, it may not have been injected into the current logon session.

Verify the Kerberos tickets available to the current session and ensure that the forged TGT is present.

Creating a new command shell can also provide a cleaner environment for testing the injected ticket.

The attack stops working after remediation

A krbtgt password rotation invalidates tickets created using the previous krbtgt secret once the relevant ticket lifetimes and replication considerations have been accounted for.

If an attacker still possesses the old secret, they may attempt to create new tickets using it until the old key is no longer accepted.

This is why krbtgt remediation generally involves controlled password rotation rather than simply changing the account password once and immediately assuming that all previously issued tickets have become invalid.

Defensive considerations

Protecting the krbtgt account and detecting abnormal Kerberos activity are important parts of Active Directory security.

Important defensive measures include:

• Protect Domain Controllers using strong administrative controls.
• Minimize the number of accounts with Domain Admin or equivalent privileges.
• Prevent privileged accounts from authenticating unnecessarily to ordinary workstations.
• Monitor access to Domain Controller credential material.
• Monitor for unusual Kerberos authentication patterns.
• Monitor for abnormal TGT lifetimes or ticket characteristics.
• Protect and monitor the krbtgt account.
• Maintain appropriate backups and recovery procedures for Active Directory.
• Rotate the krbtgt password according to an established incident-response or security procedure when compromise is suspected.

If the krbtgt secret is known to have been compromised, changing unrelated user passwords is not sufficient by itself.

The krbtgt account must be remediated, and the organization should account for existing Kerberos tickets and Active Directory replication when planning the recovery process.

Notes

A Golden Ticket should not be confused with a normal Kerberos ticket obtained through legitimate authentication.

A legitimate TGT is issued by the KDC after the user authenticates.

A Golden Ticket is created by the attacker using the compromised krbtgt secret.

The technique is therefore fundamentally dependent on the compromise of the domain’s Kerberos trust secret.