Service Principal Name (SPN)
Service Principal Name (SPN)
A Service Principal Name is the Kerberos service identifier — the
name a client uses in a TGS-REQ to request a ticket for a service (not a
user). Format: service/host[:port], e.g. MSSQLSvc/sql01.corp.local:1433,
cifs/file01, HTTP/web01. SPNs are stored on AD computer objects
(servicePrincipalName) and are the target of kerberoasting — the
single most important reason they matter to an attacker. See
kerberos-authentication for where SPNs sit in the AS/TGS flow.
How SPNs work in the TGS stage
- The client already has a TGT (from the AS-REQ/AS-REP, see kerberos-authentication).
- To reach a service, it sends a TGS-REQ naming the service by its
SPN (
service/host). - The KDC finds the account that registered that SPN and issues a TGS encrypted with that account’s key (the service account’s NT hash or AES key — see kerberos-encryption-types).
- The client presents the TGS to the service.
Key point: the TGS is encrypted with the service account’s secret, so whoever cracks the TGS recovers the service account’s password. That’s the entire kerberoasting primitive — and it’s why SPNs are high-value.
Where SPNs live (the attack surface)
servicePrincipalNameon computer objects — the standard, visible SPNs (SQL, MSSQLSvc, HOST/, etc.).Get-SPNs/GetUserSPNs.pyenumerate them.servicePrincipalNameon user objects — service accounts (non-built-in accounts likesvc_sql) that registered an SPN. These are the classic Kerberoast targets — a normal user object with an SPN is a TGS you can request and crack.msDS-AllowedToDelegateTo— constrained-delegation service names (kerberos-delegation-abuse).- GMSA / gMSA — Group Managed Service Accounts auto-manage SPNs + rotating keys (gmsa) — a mitigation against Kerberoasting because the key rotates.
Enumeration (the first step of Kerberoasting)
# PowerView — list accounts with SPNs (the Kerberoast candidate list)
Get-SPN -Types MSSQLSvc,MySQL,Oracle,PostgreSQL,SMTP,HTTP | Select-Object ObjectName,ServicePrincipalName
# Impacket — the canonical Kerberoast enumeration (requests TGSs)
GetUserSPNs.py -dc-ip <dc> corp.local/<user> -request
Every account in that output is a Kerberoast target — request its TGS and crack it. See kerberoasting for the full request + crack flow.
Why it matters to an attacker
- kerberoasting — request a TGS for any SPN-owning account and crack the service password (RC4 downgrade for speed — see kerberos-encryption-types).
- Service identification — SPNs tell you what runs on a host (SQL, IIS, MySQL) → what to attack next.
- Constrained delegation —
msDS-AllowedToDelegateTois an SPN list; abuse = impersonation (kerberos-delegation-abuse). - SPN registration abuse — registering an SPN on your controlled account lets you be targeted for Kerberoast / delegation.
Detection
- 4769 TGS-REQ bursts for many different service SPNs from one client — Kerberoast enumeration (see kerberoasting).
- 4768/4769 RC4 (
0x17) downgrade — RC4 TGS requests are a Kerberoast tell. - SPN registration — a new
servicePrincipalNameon a user object is unusual (Event 5136 on the account).
Mitigations
- GMsA — auto-rotating service keys so a captured TGS is short-lived (gmsa).
- Force AES for service tickets (drop RC4) — slows cracking (kerberos-encryption-types).
- Minimize SPN-owning service accounts — use dedicated, low-priv service accounts; avoid domain-privileged accounts owning SPNs.
- Alert on bulk 4769 TGS requests and RC4 downgrades.
Links
- kerberoasting — the primary SPN attack (TGS request + crack)
- kerberos-authentication — the TGS-REQ/TGS-REP stage SPNs drive
- kerberos-encryption-types — the RC4/AES the TGS is encrypted with
- kerberos-delegation-abuse —
msDS-AllowedToDelegateToSPN lists - gmsa — the rotating-key SPN mitigation
- resource-based-constrained-delegation — the machine-side SPN/delegation abuse
- pass-the-hash-and-ticket — once the SPN’s account is cracked, reuse it
- tgt-tgs — a TGS is a ticket for an SPN (and its key is the abuse surface)