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 whichMimikatz
will issue the ticket (Windows 2019 blocks tickets if they are for inexistent users.)/id
: Relative ID (last part ofSID
) for the user for whomMimikatz
will 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
krbtgt
account; 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 ofkrbtgt
KrbtgtKeys.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
SIDHistory
filtering between the domains in forests to prevent the escalation from a child domain to a parent domain (because the escalation path involves abusing theSIDHistory
property 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