AD Hardening Against Kerberos Golden Ticket Attack

Kerberos is the default authentication protocol in Windows Active Directory(AD) environments. It is the most secure authentication method Windows AD can offer, but it is not without its vulnerabilities. One of the most potent vulnerabilities is the Golden Ticket Attack.

Since Kerberos is a complex set of protocols, I will not cover how it works here. “How Kerberos works” would take up most of this post, leaving little room to discuss how we can defend it. Additionally, others have explained it far better than I. So I will focus on the details you need to know to defend against a Golden Ticket Attack.

Short on time? TLDR

Kerberos Refresher

Do you need a quick refresher on how Kerberos works? I recommend the following post.

https://phoenixnap.com/blog/kerberos-authentication

Ticket Granting Ticket(TGT) Forging

With a few critical pieces of data, an Attacker can completely subvert the Kerberos Key Distribution Center (KDC) and forge Ticket Granting Tickets(TGT) with a multi-year life span. In the proper Kerberos process, the KDC issues a TGT that a user can use after authenticating. Tickets generated within the KDC are encrypted with the“KRBTGT” account NTLM password hash from Active Directory, not its password. This last encryption step acts as ticket verification since using the wrong NTLM password hash will cause a ticket not to work.

What Does an Attacker Need to Forge TGTs?

The critical pieces of data an attacker needs to forge Golden Tickets are as follow.

The “KRBTGT” account NTLM password hash.
The Domain SID.
The name of a User account, preferably one with elevated permissions.
The FQDN of the local Domain.

If an attacker is on your local network and can talk to your Active Directory Server, then three of the four pieces of data are easy to obtain. The “KRBTGT” account NTLM password hash is the difficult one.

When Would An Attacker Use a Golden Ticket Attack?

Obtaining the “KRBTGT” account NTLM password hash requires either Domain Admin or Administrator rights on the Domain Controler. So the Domain Controler has to be compromised to carry out the Golden Ticket Attack. Post-breach, a Golden Ticket Attack, will ensure an Attacker has continuing access to the network. The key here is, with the “KRBTGT” NTLM hash, an Attacker can say they are anyone regardless of that Users password.

Defending Against a Golden Ticket Attack

There is no absolute defense against Attackers forging a Golden Ticket. However, we can take steps to minimize the potential of abuse. If we change the “KRBTGT” account password, all Kerberos tickets will become invalidated. Additionally, the password history for the “KRBTGT” account is two; both can decrypt TGTs. Therefore, we need to update the “KRBTGT” account password twice to invalidate all TGTs. So, how often and why should we change the “KRBTGT” account password?

Change the KRBTGT account password.

Every 180 days, per industry best guidance.
Immediately after or suspicion of a breach.
Whenever a User with high privileges leaves the company.

Update the KRBTGT Account Password

While updating the KRBTGT account password is as simple as resetting any AD user’s password, there is a more thorough method. Microsoft provides a script that will reset the KRBTGT password while verifying all the other aspects related to the process. For example, checking AD-Syncing of the changes, and more.

Use the below command to download the Microsoft script.

# Temporarily allow TLS1.2 
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
# Download the script.
Invoke-WebRequest https://raw.githubusercontent.com/microsoft/New-KrbtgtKeys.ps1/master/New-KrbtgtKeys.ps1 -O ./New-KrbtgtKeys.ps1

Run the script as administrator with the following commands.

# Temporarily allow srcipts to be run.
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
# Run the Microsoft script.
./New-KrbtgtKeys.ps1

The script will ask if you want to read the script documentation. I recommend you read the documentation once, but if you have, type “NO” and move on.

We will use “Mode 4” to make the KRBTGT account password updates. Selecting “Mode 4” will prompt you for the target AD Domain and target AD Forest; in most cases, those are the same(“MyAdDomain.com”). The script will confirm access to the target AD Domain and Forest. Once verified, we need to define the scope; option 1 is the most common.

Lastly, typing “CONTINUE” applies the KRBTGT password update.

We Are Not Done Yet!

Recall that Active Directory keeps the last two KRBTGT account passwords, which need to be updated. So we need to update the password twice. However, if we were to update the password a second time right away, it would break active sessions. We need to wait until all Kerberos tickets expire in a production environment. The default lifespan of a Kerberos ticket is 10 hours. So after we update the KRBTGT password once, we need to wait 10 hours and then update the password again. You need to rerun the script and do the same as before.

Wrap-Up: TLDR

Here are the key takeaways you need to know about the attack.

A Golden Ticket Attack successfully done gives an Attacker full unrestrained access to our domain.
An Attacker needs Domain Admin rights for the attack. Meaning an Attacker has already pwned our domain.
There is no absolute way to prevent Golden Ticket Attacks.

Defensive actions we can take.

Update the KRBTGT account password twice, 10 hours apart, every 180 days.
If breached, immediately update the KRBTGT account password twice to void all TGTs, including Golden Tickets. This breaks Kerberos sessions but is necessary to stop an Attacker. Restarting applications and services should resolve broken Kerberos sessions.
Limit a malicious-insider from forging Golden TGTs using the “principle of least privilege.” Limit access to the KRBTGT password hash.