Recently I came upon an attack path in BloodHound that looked like this:

I had control of a computer object (an Exchange server) that effectively had WriteDacl over the domain.

I had a few constraints as well:

  • All systems were configured with EDR
  • I only had the AES key of the computer account, not the NT hash or plaintext password

One of the ways you can typically exploit this is with PowerView.  For various reasons I wanted to avoid needing PowerShell or any Windows-based offensive tooling.  I needed the tool have the ability to use Kerberos authentication, as I didn’t have the password or hash for the computer account.

I created a tool to exploit this exclusively using Python, and it is heavily based upon https://github.com/tothi/rbcd-attack which uses Impacket’s ldapattack.py under the hood.

Here’s a walk-through overview of my attack chain:

First, getting the AES key for the computer account.

Next, getting a Kerberos ticket using getTGT.py and the AES key.

After getting the ticket run the new fancy all Python-based DCSync tool: https://github.com/n00py/DCSync

Lastly, validate the privs using secretsdump.py

To clean up after you are done, use ACLpwn. This tool is pretty old and not maintained, but you can get it to work. One thing you will need to do is replace “neo4j.v1” with just “neo4j” in database.py. This tool is meant to work hand in hand with BloodHound, but for our purposes we don’t need any of that. To restore the ACLs to the original configuration, use the restore state file created by the DCSync tool.

I do not believe this supports Kerberos authentication, but after performing a successful DCSync you should have the NT hash of the account you used to escalate.

Update 1/27/2022

After publishing this blog and tool, I managed to find a couple other tools that did the same thing. First, I found acltoolkit. This tool appears to mostly work, but I was unable to successfully use Kerberos authentication nor was I able to successfully set the DCSync permissions. Even so, it does not appear to have the ability to set the DCSync target to a different user than the one authenticating, so it doesn’t quite fit my use case.

I also found a tool that was a bit older than mine, BloodyAD.  This tool also seems to have some bugs related to Kerberos authentication, and I wasn’t able to get it working using a TGT at all. Otherwise, this one seems to work like a charm with a small difference: while my script only sets the Replication-Get-Changes and Replication-Get-Changes-All attributes, this tool gives the user all permissions. I’m not to say which one is better. This will not only give you DCSync but the ability to do anything on the domain.

The one fantastic thing about BloodyAD is that it does have the ability to cleanup. by adding the “enable=False” flag it will remove the permissions.