BlogWhen a user wants to access a network service—to print a file or access a database, for example—they must first prove their identity and privileges to the service. The Kerberos authentication protocol (common in Windows Active Directory environments) acts like a checkpoint and issues tickets that vouch for the identity of the user. The ticket is then evaluated by the service.
Without Kerberos, users would need to constantly submit plaintext passwords to interact with network services. Kerberos provides many benefits that help make authentication secure and convenient.
But skilled attackers can exploit weaknesses in Kerberos to forge a golden ticket. Despite the entertaining reference to Charlie and the Chocolate Factory, a golden ticket attack is extremely dangerous. The attacker has not only subverted normal authentication workflows, but also gained unlimited access to any account or resource on an Active Directory domain.
Learn how a Kerberos golden ticket attack works, how ExtraHop Reveal(x) detects golden ticket attacks, and how to protect your environment against these attacks.
What is Kerberos?
Kerberos acts as a trusted third party, working with a domain controller (DC) to authenticate clients trying to access services. The Kerberos authentication workflow revolves around tickets, which act as a cryptographic proof of identity that can be exchanged between clients, services, and the DC.
Let's review the basic components in a Microsoft Kerberos Active Directory authentication workflow that are relevant to a golden ticket attack.
- Key Distribution Center (KDC): a Kerberos service that is installed on a DC and creates tickets. Components of the KDC are the authentication server (AS) and the ticket granting server (TGS).
- Tickets: tokens that serve as a proof of identity.
- The ticket-granting ticket (TGT) is created by the KDC.
- The TGT is proof that the client submitted valid user information to the KDC.
- The TGS ticket is created by the KDC. A TGS ticket is created for each service that the client (with a valid TGT) wants to access.
- A Privilege Attribute Certificate (PAC) contains information about client privileges and enables the service to confirm whether the client is authorized to access the service. The PAC is built into both TGT and TGS tickets.
- KDC key: an encryption key that proves the TGT is valid. The KDC key is created from the hashed password of the KRBTGT account, which is the first account created in an Active Directory domain (for example, krbtgt/domain.com@domain[.]com).
- Kerberos is built on symmetric-key encryption (shared secrets). Hashed passwords act as the encryption keys. Encryption protects passwords, prevents ticket tampering, and acts as an additional authentication mechanism.
Acquiring Kerberos tickets requires several complex interactions. Here's a general Kerberos workflow that highlights the basic components relevant to a golden ticket attack. The name of the Kerberos requests and responses that are seen on the network are also highlighted (such as AS_REQ, AS_RSP, etc.)
First, the client sends user information—including the client principal name (CPN)—to the KDC. After validating the user's identity, the KDC sends the TGT (encrypted with the KDC key and containing the client's PAC) to the client (1). Next, the client requests access to a service—represented as the service principal name (SPN)—by sending the encrypted TGT and the SPN to the KDC. After confirming the validity of the TGT, the KDC copies the PAC information into a TGS ticket (2). Finally, the client sends the TGS ticket to the service. After evaluating the user privileges specified in the PAC, the service grants access to the client (3).
For more detailed information about the entire Kerberos workflow, visit this Kerberos tutorial site or the RFC for the Kerberos protocol.
What Is a Golden Ticket?
A golden ticket is a forged TGT created with a stolen KDC key. A golden ticket enables the attacker to create a fake domain administrator identity to gain access to any service on a domain.
The KDC automatically trusts a TGT that is encrypted with a KDC key. But stealing the KDC key is not an easy feat. To do this, an attacker must establish themselves on the network, escalate their privileges, and compromise the DC. All of these steps require expertise and time. But this attack can be facilitated with the help of tools, such as Mimikatz or Empire, designed to exploit Kerberos.
Here's the general workflow for a golden ticket attack.
With Mimikatz, the attacker can bypass the step of compromising the DC to steal the KRBTGT account hash (KDC key) with a technique called DCSync (1). With the stolen KDC key, Mimikatz helps the attacker create a golden ticket with a fake username and PAC, specifying domain administrator privileges for that username (2). The attacker bypasses the initial step of requesting the TGT from the KDC and directly requests a TGS ticket for a service, such as an administrative share or an important database (3). The KDC trusts the golden ticket and creates a TGS ticket with the fake PAC.
How to Detect Golden Ticket Attacks
Monitor for unusual activity associated with Active Directory and Keberos. You can audit Kerberos AS and TGS events for discrepancies. Windows logon and logoff events that contain empty fields (Event ID 4624, 4672, and 4634) can be indicators of a golden ticket or pass-the-ticket activity associated with golden tickets. Other indicators of a golden ticket attack can include TGS ticket requests without previous TGT requests or TGT tickets with arbitrary lifetime values.
Reveal(x) automatically detects Kerberos requests for TGS tickets (TGS_REQ) sent over the network that include indicators of a forged TGT. (You can enhance Kerberos detection capabilities by enabling DC-assisted decryption in Reveal(x).)
How to Prevent Golden Ticket Attacks
Routinely update the KRBTGT password twice. 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. (The Windows Event ID 4769 will notify you if a golden ticket is submitted to a DC after the KRBTGT password was reset twice.)
Make sure that DCs are well protected by limiting the number of accounts with domain administrator privileges. Also limit the number of servers a domain administrator logs into, and delegate administrative privileges to custom administrator groups. Follow these recommendations to reduce the attack surface for compromising a domain administrator account and accessing a DC.
