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!

Get-DomainUser victimuser | Select serviceprincipalname
Set-DomainObject -Identity victimuser -SET @{serviceprincipalname='nonexistent/BLAHBLAH'}
$User = Get-DomainUser victimuser 
$User | Get-DomainSPNTicket | fl
$User | Select serviceprincipalname
Set-DomainObject -Identity victimuser -Clear serviceprincipalname

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.