KRBTGT is an account used for Microsoft’s implementation of Kerberos, the default Microsoft Windows authentication protocol. Understanding the ins and outs of KRBTGT accounts can mean the difference between having a secure, compliant network and opening up your organization to vulnerabilities that could allow perpetrators to impersonate authentication and wreak havoc in your network. I discussed some of these issues at Microsoft Ignite this year with Microsoft Certified Master Sean Metcalf (you may have seen the related blog post on 6 AD Security Public Service Announcements). In this blog post, we take a deeper dive into KRBTGT and answer some of your toughest Microsoft security questions.
What is KRBTGT?
KRBTGT is an automatically created default account used when a Microsoft Active Directory domain is created. Its main purpose is to authenticate Kerberos tickets as the Key Distribution Center (KDC) account.
How does KRBTGT work?
In Greek mythology, Cerberus is a three-headed dog that guards the entrance to Hades.
Guarding the gates to your network is a three-way trust called Kerberos. This is and has been the default Microsoft Windows authentication and authorization protocol used to grant access to network applications and services since Windows Server 2000.
Specifically, KRB means Kerberos, and TGT stands for Ticket Granting Ticket.
To describe how KRBTGT works, I’ll put it in terms of going to the movie theatre. I really want to see the movie Shrek which my local theatre has started showing again. But I can’t just walk into the theatre with my popcorn and enjoy the show. I must be verified by a trusted third party – the ticket counter – which verifies my ID, charges my credit card and gives me a ticket to see Shrek in a specific theatre at a specific time.
This is the same for users who want access to an application server. They can’t just log in directly to that server. They must first be verified by a trusted third party, the Key Distribution Center (KDC). A KDC is a domain service located on a domain controller. So the user sends a request to the KDC authentication server (AS) with their NTLM hashed password. Once they are authenticated, the KDC sends them a Ticket Granting Ticket (TGT).
The user (I should say client because the user just logs in and all this goes on unbeknownst to the user) sends the TGT to the KDC Ticket Granting Server (TGS) along with the request for what the user wants to access. The TGS decrypts the TGT with the secret key shared with the AS. An encrypted token is sent back to the user, and then it is sent on to the application server. The application server then verifies the token with the shared KRBTGT hashed password and grants access to its resources to the user for a specific period of time, also known as TTL or Time to Live (default timeframe is 10 hours).
So, to recap, the TGT gives me access to the theatre complex and the TGS gives me access to a specific movie in a specific theatre at a specific time. Once I have my ticket and I decide I want to see The Croods instead, my specific ticket will not allow me into that movie because I’ve been authorized to see Shrek.
Is KRBTGT more secure than NTLM authentication?
Yes. With NTLM authentication, the hashed user password is stored on the client, the DC, and the application server, and an application server would have to coordinate directly with the DC to validate access. It’s everywhere and someone with a tool like mimikatz could certainly grab that password from any of those locations and make hay.
With KRBTGT, the hash isn’t stored in memory across as many systems, making the theft of a KRBTGT password much more difficult. To have full unfettered access, a user would have to gain access to the KDC on the DC and steal the password to create a Golden Ticket (more on this below).
How do I enable my KRBTGT account?
You don’t enable it. When you build out your Active Directory, its already there. Every AD domain has an associated KRBTGT account to encrypt and sign all Kerberos tickets for the domain.
The KRBTGT account should stay disabled. Enabling it does nothing.
Why should I change the KRBTGT password?
With Kerberos, attackers stealing a user password won’t go very far – they’ll only be able to access what the user can access. Attackers want more! To get more, they’ll need to steal the NTLM hash of the KRBTGT account. This will allow them to forge tickets.
And if they want even more, they will need to execute a Golden Ticket attack. This was coined by French research and mimikatz creator, Benjamin Delpy, as a nod to Willy Wonka’s Golden Ticket.
A Golden Ticket attack is when perpetrators take control of the KRBTGT account – specifically they need to steal the NTLM hash of the KRBTGT account. This will give attackers the ability to impersonate authentication, forge tickets and elevate access rights across the environment. You can find more detail on these attacks in this article: Golden Ticket Attacks: How They Work And How to Defend Against Them.
Who can create Golden Tickets?
Anyone can create a forged ticket. Creating a Golden Ticket that grants access to the entire domain is a bit different. The key elements someone will have to obtain are the FQDN (Fully Qualified Domain Name) of the domain, SID (Security Identifier) of the domain, username of the account you want access to and the KRBTGT NTLM hash.
Example. A forged ticket cannot do anything. It would be like having a forged credit card, but without a correct account number. Just as a credit card needs key elements to be perceived as legit, the same is true for a Golden Ticket.
Any users can get the first 3 pieces of information if they have access to an account in the domain. The KRBTGT NTLM hash requires elevated permissions to obtain this information. By default, you will see these permissions for “Replicating Directory Changes ALL” (more detailed information can be found here).
Example. This is the output from a .csv file from Enterprise Reporter and visualized with PowerBI. Through group nesting in the built-in Administrators group, you can see there are 270 objects with this permission and I can drill through to see which members have that right.
Looking at screenshot above, I can see that Azure AD Connect is being used, since that also sends a copy of the password hash to Azure. Legacy versions of on-premises SharePoint also have had this right and can be removed if they are no longer using on-premises SharePoint. If any individuals have this permission directly, at any point in time they can get the information needed to create a Golden Ticket.
How often should I change the KRBTGT password?
Microsoft recommends regular password updates to the KRBTGT account; and STIG recommendations get more specific (every 180 days). However, seeing the number of objects that are able to get the KRBTGT hash, you might consider changing that password EVERY time a human that had the ability to create a Golden Ticket leaves an organization. If a privileged account is terminated, but users had the ability to use a ticket that was generated while they were still “trusted,” they could potentially cause havoc in your environment.
What can break if I change the KRBTGT password?
It is important to remember that the KRBTGT remembers the last two passwords when using Kerberos, since this is the shared secret that is getting passed along for access. So changing it one time is good, but if you are concerned about an attacker in your network, you’ll need to change it twice. However, before you do this, you need to understand what could break.
Resetting the KRBTGT password twice in rapid success before the password can replicate across your DCs and application servers, will break access to your servers.
We had this question asked in my Microsoft Ignite session on Hybrid AD Security best practices. My co-presenter Sean Metcalf, Microsoft Certified Master, gave this great answer:
Reduce your AD attack surface.
“I’ve definitely heard of bad things happening when you change the KRBTGT password rapidly. Definitely the solid approach to changes at once, is to make sure that the replication converges so all your domain controllers in the active directory domain get that change and then update that across all of them so you have the convergence. Our typical recommendation is to change it one week and then change it a week later because, the KRBTGT computer account is going to have the current password and the previous password. Until all the DCS get what the current one is, which then the current one, the old current one becomes the previous one.
Then the new current one is the new current one. It needs to be able to know what those are to open up Kerberos tickets and actually authenticate them. Bad things can happen if you change them even within the same 10 or 12 hours, because there are tickets that are already out there, especially on some Unix devices that tend to cache some of that information and have trouble with the KRBTGT getting changed too quickly. We have some customers that even change it one month and then change it again a month later. That’s fine. It just should be changed every year, twice.”
How can I detect if Golden Tickets are being used?
Golden Tickets can wreak havoc on your environment, so you need to have a solid plan in place to detect and defend against these attacks. Here are my recommendations for detecting Golden Ticket attacks.
- Run Microsoft’s KRBTGT Account Password Reset Script every 180 days. This script is helpful in resetting the password without creating authentication errors caused by delayed replication of the new KRBTGT hashed key across your environment.
- Track privileged users and service accounts with Domain Administrative permissions or Replicating Directory Changes permissions. Both grant rights to discover objects in AD. This access is used in a DCSync attack to get the KRBTGT hash and create Golden Tickets.
- Perform an IT Audit for tickets by examining the TTL (Time to Live) value. Kerberos tickets are by default set to 10 hours. Golden Tickets are set to 10 years. Basically, you want to look for anyone who has exceeded their lifetime. If a 10-hour window is too long for you, Microsoft has some guidance here where it could be changed to a 4-hour window without much additional burden.
- Establish and test an Active Directory recovery plan in case attackers trash your DC after a compromise to obfuscate their tracks or to spot and remediate differences in unauthorized privilege escalation.
Follow these best practices to maximize network security
Looking at it all together, it’s abundantly clear how essential it is that you get a solid grasp of KRBTGT domain account best practices if you want to minimize the chances of someone creating a Golden Ticket in your environment, and subsequently forging tickets and elevating access rights. But by following some of the best practices listed here – like performing IT audits, running Microsoft’s KRBTGT Account Password Reset Script every 180 days, and resetting the KRBTGT password twice – you’ll stay ahead of the game when it comes to fortifying your network from unauthorized activity.
