Kerberos Delegation and SPN Abuse

Overview

Kerberos delegation lets a service account access another service on a user’s behalf. Used correctly, it supports SSO (Single Sign-On), but loose management of SPNs (Service Principal Names) or delegation attributes can create paths to privilege escalation and lateral movement.

The key premise is that the KDC reads directory attributes through LDAP when issuing a TGS (service ticket). The SPN owner, delegation targets, and RBCD allowlist are all controlled by attributes of AD objects.

Types of delegation

Type	Main attribute	Meaning
Unconstrained Delegation	`TRUSTED_FOR_DELEGATION`	A service can use a received TGT to delegate to any backend.
Constrained Delegation (KCD)	`msDS-AllowedToDelegateTo`	A service can delegate only to SPNs that were allowed in advance.
RBCD	`msDS-AllowedToActOnBehalfOfOtherIdentity`	The resource specifies who may delegate to it.

The distinction is where the allowlist resides: KCD stores destination SPNs on the delegating account, while RBCD stores allowed accounts on the resource receiving the delegation.

S4U2self and S4U2Proxy

S4U (Service for User) is a Kerberos extension that lets a service account obtain tickets on behalf of a user.

S4U2self: A service account obtains a service ticket to itself for any user.
S4U2Proxy: The service uses a user context obtained through S4U2self or a similar process to obtain a service ticket for another service.

service account -> KDC: S4U2self(User -> service)
service account <- KDC: User-to-service ticket
service account -> KDC: S4U2Proxy(User -> backend SPN)
service account <- KDC: User-to-backend ticket

A message such as can now impersonate users via S4U2Proxy does not mean the account obtained the user’s password. It means the account can obtain a ticket from the KDC to present to a specific service as that user.

Delegation-based impersonation is restricted for protected users, including those with Account is sensitive and cannot be delegated enabled and members of Protected Users.

Reading RBCD

RBCD is controlled by the resource’s msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

The attribute is a security descriptor, but conceptually it can be read as follows:

WEB01$:
  msDS-AllowedToActOnBehalfOfOtherIdentity = APP01$

Meaning:
  APP01$ can request a service ticket for WEB01 on behalf of a user.

With the credentials for APP01$ in this state, an attacker can, for example, request a ticket for cifs/WEB01.example.local as Administrator and access SMB. Which services can actually be used depends on the requested SPN and the services configured on the target host.

The power of WriteSPN

WriteSPN is permission to change the servicePrincipalName attribute of the target object. A common abuse is targeted Kerberoasting.

attacker has WriteSPN on user
attacker adds fake SPN to user
attacker requests TGS for that SPN
attacker cracks service ticket offline
attacker removes fake SPN

However, WriteSPN is not limited to Kerberoasting. Combined with existing KCD or service routing, it can lead to SPN-jacking.

SPN-jacking

SPN-jacking moves ownership of an SPN to change which account’s key the KDC uses to encrypt a ticket.

Example:

Prerequisites:
  svc-front can perform KCD to HTTP/web01.example.local
  attacker can modify servicePrincipalName on WEB01$ and DC01$

Actions:
  Remove HTTP/web01.example.local from WEB01$
  Add HTTP/web01.example.local to DC01$

Result:
  KDC resolves HTTP/web01.example.local as an SPN of DC01$
  The issued service ticket can be decrypted with the key of DC01$

The important point is that the service name string and the AD account that owns the SPN are separate. In Kerberos, the KDC resolves the SPN in the directory and encrypts the ticket with its owner’s key. Changing the SPN owner changes which account can decrypt a ticket issued for the same SPN string.

When moving an SPN, the delete from the original object and the add to the new object must be performed accurately. Failing to restore the original state can cause Kerberos failures or change the authentication destination unintentionally.

Defense and auditing

Do not broadly delegate WriteSPN on privileged user or computer objects.
Regularly review KCD’s msDS-AllowedToDelegateTo and RBCD’s msDS-AllowedToActOnBehalfOfOtherIdentity.
Detect duplicate SPNs with tools such as setspn -X.
Enable Directory Service Changes auditing and track changes to servicePrincipalName and delegation attributes.
Strictly limit attribute modification rights on Tier 0 computer objects and DCs.
Apply Protected Users or Account is sensitive and cannot be delegated to privileged users.