Golden Ticket
Description
The Kerberos Golden Ticket is an attack in which threat agents can create/generate tickets for any user in the Domain, therefore effectively acting as a Domain Controller.
When a Domain is created, a unique user account named krbtgt is automatically generated. This account is disabled by default and cannot be deleted, renamed, or enabled. The Key Distribution Center (KDC) service on the Domain Controller utilizes the password of the krbtgt account to derive a key for signing all Kerberos tickets. The hash of this password is highly trusted within the Domain, as it is essential for validating the authenticity of Kerberos tickets issued by the Domain.
Therefore, any user possessing the password's hash of krbtgt can create valid Kerberos TGTs. Because krbtgt signs them, forged TGTs are considered valid tickets within an environment. Previously, it was even possible to create TGTs for inexistent users and assign any privileges to their accounts. Because the password's hash of krbtgt signs these tickets, the entire domain blindly trusts them, behaving as if the user(s) existed and possessed the privileges inscribed in the ticket.
The Golden Ticket attack allows us to escalate rights from any child domain to the parent in the same forest. Therefore, we can escalate to the production domain from any test domain we may have, as the domain is not a security boundary.
This attack provides means for elevated persistence in the domain. It occurs after an adversary has gained Domain Admin (or similar) privileges.
Attack
To perform the Golden Ticket attack, we can use Mimikatz with the following arguments:
/domain: The domain's name./sid: The domain's SID value./rc4: The password's hash ofkrbtgt./user: The username for whichMimikatzwill issue the ticket (Windows 2019 blocks tickets if they are for inexistent users.)/id: Relative ID (last part ofSID) for the user for whomMimikatzwill issue the ticket.
Additionally, advanced threat agents mostly will specify values for the /renewmax and /endin arguments, as otherwise, Mimikatz will generate the ticket(s) with a lifetime of 10 years, making it very easy to detect by EDRs:
/renewmax: The maximum number of days the ticket can be renewed./endin: End-of-life for the ticket.
First, we need to obtain the password's hash of krbtgt and the SID value of the Domain. We can utilize DCSync with Rocky's account from the previous attack to obtain the hash:
We will use the Get-DomainSID function from PowerView to obtain the SID value of the Domain:
Now, armed with all the required information, we can use Mimikatz to create a ticket for the account Administrator. The /ptt argument makes Mimikatz pass the ticket into the current session:
The output shows that Mimikatz injected the ticket in the current session, and we can verify that by running the command klist (after exiting from Mimikatz):
To verify that the ticket is working, we can list the content of the C$ share of DC1 using it:
Prevention
Preventing the creation of forged tickets is difficult as the KDC generates valid tickets using the same procedure. Therefore, once an attacker has all the required information, they can forge a ticket. Nonetheless, there are a few things we can and should do:
Block privileged users from authenticating to any device.
Periodically reset the password of the
krbtgtaccount; the secrecy of this hash value is crucial to Active Directory. When resetting the password ofkrbtgt(regardless of the password's strength), it will always be overwritten with a new randomly generated and cryptographically secure one. Utilizing Microsoft's script for changing the password ofkrbtgtKrbtgtKeys.ps1 is highly recommended as it has an audit mode that checks the domain for preventing impacts upon password change. It also forces DC replication across the globe so all Domain Controllers sync the new value instantly, reducing potential business disruptions.Enforce
SIDHistoryfiltering between the domains in forests to prevent the escalation from a child domain to a parent domain (because the escalation path involves abusing theSIDHistoryproperty by setting it to that of a privileged group, for example,Enterprise Admins). However, doing this may result in potential issues in migrating domains.
Detection
Correlating users' behavior is the best technique to detect abuse of forged tickets. Suppose we know the location and time a user regularly uses to log in. In that case, it will be easy to alert on other (suspicious) behaviors—for example, consider the account 'Administrator' in the attack described above. If a mature organization uses Privileged Access Workstations (PAWs), they should be alert to any privileged users not authenticating from those machines, proactively monitoring events with the ID 4624 and 4625 (successful and failed logon).
Domain Controllers will not log events when a threat agent forges a Golden Ticket from a compromised machine. However, when attempting to access another system(s), we will see events for successful logon originating from the compromised machine:
Another detection point could be a TGS service requested for a user without a previous TGT. However, this can be a tedious task due to the sheer volume of tickets (and many other factors). If we go back to the attack scenario, by running dir \\dc1\c$ at the end, we generated two TGS tickets on the Domain Controller:
Ticket 1:
Ticket 2:
The only difference between the tickets is the service. However, they are ordinary compared to the same events not associated with the Golden Ticket.
If SID filtering is enabled, we will get alerts with the event ID 4675 during cross-domain escalation.
Note
If an Active Directory forest has been compromised, we need to reset all users' passwords and revoke all certificates, and for krbtgt, we must reset its password twice (in every domain). The password history value for the krbtgt account is 2. Therefore it stores the two most recent passwords. By resetting the password twice, we effectively clear any old passwords from the history, so there is no way another DC will replicate this DC by using an old password. However, it is recommended that this password reset occur at least 10 hours apart from each other (maximum user ticket lifetime); otherwise, expect some services to break if done in a shorter period.
Q & A
1) Practice the techniques shown in this section. What is the NTLM hash of the krbtgt user?
First, we need to acquire the krbtgt password hash and the Domain’s SID value. We can use DCSync with Rocky’s account from the previous attack to retrieve the hash.
Answer: db0d0630064747072a7da3f7c3b4069e
Last updated