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!

DO NOT compromise the AES256 hash of the domain’s krbtgt account unless you have been given permission from the client to do so. The consequences of compromising this hash is incredibly dangerous and will make everyone who provides support for the environment you have compromised HATE you with a passion. The fix is NOT as simple as changing a password. It needs to be cycled, often times twice to take effect, and requires what is essentially a rebuild of the domain. Again, DO NOT compromise this unless you know what you are doing and DO NOT be careless with the hash once you have it. DO NOT store it anywhere. It is rarely changed, and once it is compromised, you have effectively left the front door of the environment unlocked permanently..or until the aforementioned, arduous, process has been completed. So, you need to make sure that you, not only, have permission to compromise this hash; but you also need to make sure that your client understands the implications of compromising this hash.

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:

DCSync Fails
DCSync Fails

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:

Replication Rights Check
Replication Rights Check

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:

Add AD Account to Privileged Group
Add AD Account to Privileged Group

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!

DCSync Success
DCSync Success

Now, remove your non-privileged account from the “AD-Replication” group with the following command:

Remove AD Account from Privileged Group
Remove AD Account from Privileged Group

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!