Press "Enter" to skip to content

Targeted Kerberoasting

This is a short followup demonstrating a technique that dawned on me after posting about decrypting AS-REPs earlier this week. As mentioned previously, @_wald0, @cptjesus, and I are currently working Active Directory ACL integration for BloodHound. One of the control relationships we’re interested in is GenericAll/GenericWrite over a target user object, say victimuser in this instance. If we want to utilize the user’s access, we could force a password reset, but this is fairly ‘destructive’ in that the target user would notice. We’ve been brainstorming another method to abuse these types of relationships with the target remaining unaware, and we believe we now have another option.

Given GenericWrite/GenericAll DACL rights over a target, we can modify most of the user’s attributes, save for attributes related to delegation and other protected components like sidHistory. However, we can change a victim’s userAccountControl to not require Kerberos preauthentication, grab the user’s crackable AS-REP, and then change the setting back:

Then it dawned on me: why not execute this with ‘normal’ Kerberoasting instead, taking advantage of existing John the Ripper and Hashcat cracking modules. Given modification rights on a target, we can change the user’s serviceprincipalname to any SPN we want (even something fake), Kerberoast the service ticket, and then repair the serviceprincipalname value. And the best part is that everything needed is already implemented in PowerView with Set-DomainObject and Get-DomainSPNTicket!

This approach is still dependent on the target user having a weak/crackable password, but it’s a nice alternative to force-resetting the user’s password. And while the modified SPN doesn’t remain in the domain to be detected by defensive sweeping, there are event logs that can be enabled to detect these types of specific malicious modification. If you have elevated (i.e. Domain Admin) rights, you can always ‘downgrade’ a user to reversible encryption and then DCSync their plaintext password, so this approach is only really useful in cases where you encounter these type of rights before you’re able to elevate on the domain itself.


  1. […] In this instance, we have a relatively low-privileged user on the far left with an ACL-only attack path ending up in control of the Domain Admins group. Unfortunately, from an OPSEC perspective, we are forced to perform a password reset against one of the many users in the 7th step of the attack path. Along the way, we may choose to perform password resets on the two other users we identified; however, we have other options up our sleeve as well, including altering the user’s scriptPath attribute or registering an SPN with the target user, as Will (@harmj0y) outlines in his blog post, “Targeted Kerberoasting”: […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.