Golden Ticket Without Domain Admin
Acheiving the krbtgt AES256 hash when domain admins do not have replication rights
Acquiring a golden ticket, by dumping the krbtgt AES256 hash, without compromising a domain admin account? Surely you jest. This cannot be possible, can it? Well, in most situations, no. Not unless there are some serious AD configuration issues. However, we’re not here to talk about horrendous AD security misconfigurations. We’re here to discuss an AD configuration that is configured properly. In fact, in this type of environment, we encounter domain admin accounts that are configured without the replication rights. So, in this environment, we cannot dump the AES256 hash of the domain’s krbtgt account even once we have compromised a domain admin account. Hmm, and here I was..all happy-dance ready with my shiny new, pilfered, domain admin credentials; but when I went to make use of them to permanently own the domain in question…nothing. No joy. How can this be? I thought initially. Is it AV? Is it EDR? Why was my attack failing? Where is my AES256 hash?! Well, buckle up and find out what was going on in detail. Well, in more detail than the above blurb already revealed; and find out, most importantly, how to overcome and get those sweet-sweet domain creds!
We are starting from the position of having a domain admin account and having admin and SYSTEM privileges on a domain controller. We run dcsync and get the following error:
After looking into the possibility of AV and/or EDR being the reason for the attack failing, it became clear that both AV and EDR were effectively bypassed. So, what could be the issue? Could domain admins not possess the requisite replication rights to pull off the attack? Well, let’s check..
We used the following script to verify which AD groups and accounts possess replication rights:
The results from the script reveal that domain admins do not, in fact, possess replication rights. Good job to the client for thinking securely! However, we do see accounts and AD groups that have replication rights. For the discussion, we will call one of the AD groups with replication rights “AD-Replication”. We are moving forward with a kerberos TGT from a DA account imported into an active session. From there we perform the following command on a domain controller:
The first blue blob in that screenshot would contain “AD-Replication” and the second blue blob would be a non-privileged user account that you have control of, essentially your test account for the engagement. Once your non-privileged account has been added to the AD group that possesses replication rights, you can then run mimikatz on your local machine with that AD account. This will result in attack success!
Now, remove your non-privileged account from the “AD-Replication” group with the following command:
Again, the first blue blob in that screenshot above would contain “AD-Replication” and the second blue blob would be the non-privileged user account that you have control of, essentially your test account for the engagement.
Now, with the domain’s SID and the krbtgt AES256 hash, you can generate golden tickets galore!