Let’s talk about Mimikatz and golden ticket attacks! And we don’t mean the Wonka bars, but something far more malicious. This type of attack could cause an unsuspecting network administrator a world of trouble.
What is Mimikatz?
Golden ticket attacks started with the development of a tool called Mimikatz. Researcher Benjamin Delpy developed Mimikatz, an executable, in 2011.
In his words, it is a tool that plays with Windows security. It exploits vulnerabilities found within Active Directory and how Active Directory functions with Kerberos Authentication.
What is a Golden Ticket Attack?
A golden ticket attack allows an attacker to create a Kerberos authentication ticket from a compromised service account, called krbtgt, with the help of Mimikatz.
With the hash of this compromised account and some information about the domain, an attacker can create fraudulent tickets. These tickets appear pre-authorized to perform whatever action the attackers want without any real authentication.
This attack is stealthy and hard to detect, making it appealing to attackers who plan to live inside a domain for some time.
What Is Kerberos Authentication?
From a high level, when a client attempts to authenticate to a workstation on a domain, the client sends a message to the authentication server. If the user exists in the authentication server’s database, then the server sends back an encrypted message with the hashed value of the correct password.
If the hashed value of the password provided by the user matches what was sent back by the authentication server, the client is able to decrypt the value of the encrypted message and gain a session ticket, which is signed by the krbtgt account.
The Attack Itself
Similarly, when user successfully authenticates into their workstation on a domain and then needs to access services on the domain, they will need to acquire tickets accordingly. The process is much like what I just described: the authentication server checks if the user has the privilege to a service requested. If so, a ticket will be granted so the client/user can perform the requested action.
So, by compromising the krbtgt account, the attacker gains the ability to create session tickets which already contain the verifiable hash of the krbtgt account, which makes Active Directory believe the session has already been authenticated and approved, even if the account or username used doesn’t even exist within the domain.
Golden Ticket Detection
Ultimately, detecting a golden ticket attack depends on the method used. If the Mimikatz tool was dropped in your environment, antivirus might identify and block it. That said, Mimikatz itself is very simple to modify, changing its hash and invalidating any hash-based detection. Improved behavioral monitoring may detect Mimikatz despite modifications; however, due to the nature of the attack, most hackers wouldn’t let it touch the disk.
They would likely do one of two things. First, they might perform the attack entirely via memory, utilizing a C2 like Cobalt Strike. Otherwise, they would perform the attack locally on their own device after downloading cached hash data from an endpoint.
In these cases, detection will ultimately rely on watching for unusual behavior. This could look like accounts accessing systems they would not normally access or accounts authenticating with different accounts. It could also be SIDs that do not match the username or generic usernames in use that do not exist in the environment.
Therefore, it is important to audit your user and service accounts on a regular basis. If you don’t know what is usual, detecting unusual activity is virtually impossible.
Remediation
In order to remediate a golden ticket attack, the krbtgt account must be reset. You can do this manually in Active Directory. You can also use a reset script available from Microsoft’s TechNet, which I would highly recommended.
The process is not complex, but you must be careful. If you make a mistake, you risk authentication and DCSync issues.
The key thing to understand is that Active Directory stores the current and previous password hash for the krbtgt account. Old session tickets can still be validated after a reset of the krbtgt account; however, that also means any golden tickets are still valid after a single reset.
So, the account must be reset twice. This is where you can cause real damage.
You must not–I repeat, DO NOT—reset the account twice, back to back, in quick succession. This will orphan any current sessions or tickets in the environment and break DCSync.
Using the PS Script, you can easily verify the maximum user ticket lifetime in your environment using option 1. This is how long you must wait between resets to invalidate any existing golden tickets without borking your domain.
Again: Do. Not. Double-tap. It’s a golden ticket, not a zombie.
Protection
You can take one or more of these steps to protect against golden ticket attacks.
- Enforce a least privilege access model.
- Limit user access to only what they need.
- Limit the amount of admin accounts to only those who absolutely need it and ensure admin access is not simply added to their day-to-day user account.
- Implement multi-factor authentication (MFA) on all external authentication points, including VPN and OWA/O365.
- Don’t have RDP open to the internet. Seriously. Port numbers don’t matter. Get RDP behind a VPN, and implement MFA on it.
- Fake credentials can be injected into the LSAS cache, which would be tempting to hackers. Seeing these “honeycreds” used would clearly indicate an issue.
- Perform the reset of the krbtgt account (twice) in accordance with your password reset policies, or quarterly.
- If possible, consider running LSAS in its available protected mode.
- Enable Windows Defender Credential Guard on applicable systems (Windows 10 and Server 2016 and above). Do not use on domain controllers.
Conclusion
While the above measures can help prevent an attack, they aren’t “magic bullets” to stop a golden ticket attack. Ultimately, diligence, commitment, and attention to detail are the keys to help you protect your domain. Don’t forget the security fundamentals, and make sure you’re not relying on one measure or system to completely protect you.
This article was written by Tim and Mike of Team Ambush
If this is overwhelming, we can help. Talk to one of our pen testers today to get your defenses up to snuff against vulnerabilities like this one.
