Golden Ticket Attack Explaining (
From The Blue Team Perspective)
If you want to be a king, you must wear a crown. If you want to be the king of a network, then you need a Golden Ticket.
With the Golden Ticket attack, the attacker can exploit a vulnerability in Kerberos to give the Domain Controller machine the impression of a real domain user and then gain access to services and accounts in the Active Directory domain.
Therefore we have the know “how Kerberos work ?”
How Kerberos work ?
Kerberos acts like a trusted third party working with a domain controller (DC) to authenticate clients trying to access services. The Kerberos authentication workflow revolves around tickets (tickets) that act as cryptographic proof of identity that can be exchanged between clients, services, and DC.
To understand how the Golden Ticket attack occurred, we need to see how Kerberos is structured and some agriculture.
- Key Distribution Center KDC: A Kerberos service that uploads to the DC and creates tickets. The components of KDC are authentication server (AS) and ticket granting server (TGS).
- Tickets: tokens that serve as proof of identity.
- The ticket-granting ticket (TGT) is generated by the KDC.
- TGT is proof that the customer has submitted valid user information to KDC.
- TGS ticket is generated by KDC. A TGS ticket is created for each service that the client (having a valid TGT) wants to access.
- Privilege attribute certificate (PAC) contains information about client privileges and allows the service to verify whether the client is authorized to access the service. PAC, both TGT and
are also placed on TGS tickets. - KDC key: An encryption key that proves the TGT is valid. The KDC key is generated from the hashed password of the KRBTGT account, which is the first account created in an Active Directory domain (for example, krbtgt/orhan.com@orhan[.]com ).
- Kerberos is built on symmetric key encryption (shared secrets). Hashed passwords act as encryption keys. Encryption protects passwords, prevents ticket tampering, and acts as an additional authentication mechanism.
The golden ticket is a fake TGT created with a stolen KDC key. The golden ticket allows an attacker to create a fake domain administrator ID to access any service in a domain.
KDC automatically trusts a TGT encrypted with a KDC key. But stealing the KDC key is no easy task. To do this, an attacker would need to infiltrate the network, elevate their privileges, and compromise the DC. All these steps require expertise and time. However, this attack can be facilitated with the help of tools like Mimikatz or Empire designed to take advantage of Kerberos.
With Mimikatz, an 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 and specifies domain administrator privileges for that username (2). The attacker skips the first step of requesting TGT from the KDC and directly requests a TGS ticket for a service such as an administrative share or an important database (3). KDC trusts the golden ticket and creates a TGS ticket with a fake PAC.
How to Detect Golden Ticket Attacks?
Monitor for any unusual activity associated with Active Directory and Keberos. You can audit Kerberos AS and TGS events for inconsistencies. Windows logon and logout events with blank fields (Event ID 4624, 4672, and 4634) can be indicators of a ticket or ticket pass activity associated with golden tickets. Other indications of a gold ticket attack may include TGS ticket requests with no previous TGT requests or TGT tickets with arbitrary lifetime values.
- Important Indicator
When an attacker issues a Golden Ticket with tools like Mimikatz, they use a fake/blank account name or fake/blank domain name — these parameters don’t have to be real when issuing a valid ticket. We can use this to search event logs in DC 4769 — request service ticket for users or domains not present in the environment:
How To Prevent Golden Ticket Attack ?
- Routinely update the KRBTGT password twice. Changing the password twice will invalidate any ticket signed with a stolen KDC key.
- DC stores two versions (current and previous version) of the KRBTGT password; this allows the KDC to check if an invalid TGT has a KDC key that matches a previous KRBTGT passphrase. (Windows Event ID 4769 will notify you if a golden ticket is sent to a DC after the KRBTGT password has been reset twice.)
- Ensure DCs are well protected by limiting the number of accounts with domain administrator privileges.
- Limit the number of servers a domain administrator logs on to and assign administrative privileges to special administrator groups. Follow these recommendations to reduce the attack surface for compromising a domain administrator account and accessing a DC.
You’ve come this far and if you like it, don’t forget to follow.
\
