Understanding the Golden Ticket Attack

Resources
News
Persistence Attack in Active Directory: The Golden Ticket Attack

Persistence attacks are one of the main objectives of an Advanced Persistent Threat or APT, this refers to a certain kind of attacker that, after gaining access to a system, can keep long-term, “persistent” access. An APT may keep their position after gaining administrative access to the network without being noticed and unaffected by any type of defense mechanism.

Based on this, today we will talk about what the Golden Ticket Attack is, what attackers need to perform it, how it looks from the attacker side, mitigations, hardening and some recommendations on how defenders (blue team) can detect these attacks.

What is a Golden ticket attack?

Similar to its namesake for Willy Wonka’s chocolate factory, a golden ticket in Active Directory gives the holder unrestricted access to any object in the domain. The Kerberos protocol, which depends on the usage of shared secrets to encrypt and sign messages, is abused by a Golden Ticket attack. The password hash for the KRBTGT user, which is used to generate the Kerberos tickets necessary to get access to IT systems and data, is one of these secrets that is only known to the Key Distribution Center (KDC) that could be thought of as the central department of creation of tickets for granting access which is located inside domain controllers.

How do attackers perform Golden Ticket attacks?

A common technique that attackers perform once they obtain domain administrator privileges is the DCSync attack.. With the use of domain replication, an attacker using the DCSync attack can mimic the actions of a domain controller (DC) and obtain password information. As it may be used to obtain the KRBTGT hash, DCSync is typically employed prior to a Golden Ticket attack.

The ability to create Kerberos tickets as if they were Active Directory itself would be available to an opponent who successfully cracks (or obtains by another method like DCSync attack) the KRBTGT password hash. This would allow them to access whatever resource they want.

To deliver this persistent mechanism you need these minimum requirements:

/Domain — The fully qualified domain name (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 (needs to be an existing account)
/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 (in other words, injected in memory).

Some optional flags may be:

/Startoffset: Optional when the ticket is available (MimiKatz and Rubeus tools default is 0 – right now) in minutes. Use a negative number for a ticket available from the past and a positive number greater than 0 for the future.
/Endin: Optional ticket lifetime (MimiKatz and Rubeus tools default is 10 years) in minutes. The default AD setting is 10 hours = 600 minutes
/Renewmax: Optional ticket lifetime with renewal (MimiKatz and Rubeus tools default is 10 years) in minutes. The default AD setting is 7 days = 100800 minutes.

Implementing the Golden Ticket Attack Strategy

Here is an example of execution of the Golden Ticket attack using MimiKatz:

We view our current tickets and see that we do not have access to other systems in the active directory environment. Command:

klist

Implementing-the-Golden-Ticket-Attack-Strategy

2. Use invoke-mimikatz (powershell version of mimikatz) to forge a golden ticket for the ‘Administrator’ user (which is the domain administrator in our lab environment) with the parameters we had mentioned. Command:

Invoke–Mimi –Command ‘”kerberos::golden

/User:Administrator

/domain:[FQDN OF THE DOMAIN]

/sid:[SID OF THE DOMAIN]

/aes256:[AES256 HASH]

/id:500

/groups:512

/startoffset:0

/endin:600

/renewmax:10080

/ptt”‘

3. Viewing our current ticket, we see that we have a TGS for the Administrator user, then we successfully access the C drive of the domain controller from the lab environment, having administrator access to it!

Attacker OPSEC recommendations

Ensure that /id and /user flags match.
Ensure that /endin and /renewmax match with the output from the Kerberos policy, MimiKatz default values are exaggerated from a normal Kerberos policy in an enterprise environment.
Do not store the ticket (do not use the /ticket), in OPSEC terms it’s better to use the ticket in the moment to do something specific, then purge the ticket. This is because if a ticket is generated early, then used but has already expired, would generate an alert.
Always purge the tickets generated after using it. If you do not do this, you may unintentionally use it again after it has expired and generate an alert.
Do not use RC4 NT hash, use aes256, because MDI (Microsoft Defender for Identity) would throw an “encryption downgrade” alert.
Use the smallest number of groups possible in /group flags.
Reference: default SIDS and RIDS >> https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers

Mitigation recommendations

In case of compromise the general recommendation is to update the KRBTGT password twice. When resetting the Key Distribution Center Service Account password twice, a 10 hour waiting period is required between resets. 10 hours are the default Maximum lifetime for user ticket and Maximum lifetime for service ticket policy settings, hence in a case where the Maximum lifetime period has been altered, the minimum waiting period between resets should be greater than the configured value. Changing the password twice ensures that any ticket signed with a stolen KDC key will be invalidated. The DC stores two versions of the KRBTGT password (a current and previous version), which enables the KDC to check whether an invalid TGT has a KDC key that matches a previous KRBTGT password.

But to really ensure the presence of the attacker is gone from the internal network, the best option is to rebuild the entire Forest domain, this means all domains belonging to the same forest, the reason for this is that once an attacker compromises a domain, it can easily compromise other domains in the same forest.

Hardening recommendations

Make sure that DCs are well protected by limiting the number of accounts with domain administrator privileges.
Limit domain admin account permissions to domain controllers and limited servers.
Delegate administrative privileges to custom administrator groups.
Rotate KRBTGT passwords twice every 6 or less months.

How to Detect Golden Ticket Attacks?

It is difficult to detect the forge of a golden ticket, so from the blue team perspective the best way to detect the attack is when the attacker used that forged ticket, in other words, when the attacker performs the pass the ticket attack.

To detect the pass the ticket attack, the blue team would need to understand in depth the Kerberos protocol, the structure of a Kerberos ticket for evidence of tampering, and implement customized rules based on the logs found. These rules should be looking strange behaviors in the Kerberos authentication process like:

Any Modification of group memberships (added or removed).
Watch for Username and RID mismatches.
Search for weaker than normal encryption types on Kerberos tickets (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 or Rubeus is 10 years).

The windows events codes that can help to search for these strange behaviors are:

Event ID 4769 originated on domain controllers, this event can provide information like ticket encryption type and username that requested a Kerberos ticket.
Event ID 4627 originated on domain controllers and member computers. This event is generated when a successful login is performed by a user. This event provides group membership information. Thanks to this, we can extract the user’s security identifier (SID) and the user’s group membership (the opportunity for blue teamers to see any strange group that the user belongs to).
Event ID 4624 originates on the same host as Event ID 4627. From this event, we can extract the user’s security identifier (SID) and username source IP (which can potentially expose the compromised host).

About CovertSwarm

The team at CovertSwarm is driven by a single objective: to constantly compromise the security of our clients through the deep detection of blind spots within their cyber defenses and technology stacks before real threat actors are able to exploit them.

Our continuous client-focused cyber intelligence gathering, simulated attacks, clear vulnerability reporting, live ethical hacker interaction capability, and follow-up education services challenge the status quo of a cyber market in desperate need of modernization.

Organizations seeking higher degrees of cyber assurance and security confidence than those offered by ‘snapshot’ penetration testing and red team engagements are increasingly partnering with us.

They agree that ‘point-in-time’ testing is no longer enough to secure their organizations, and it is through this shared ethos that CovertSwarm challenges everything that has so far been considered to be ‘standard’ in today’s cyber vendor market.

If you would like to find out more, contact us today.

Further read for more technical explanation on the blog topic: