SPN Jacking
SPN Jacking is an attack technique that abuses the WriteSPN permission in Active Directory (AD). It combines DACL abuse with constrained delegation to obtain Kerberos service tickets for unintended services and impersonate privileged users.
In AD, SPNs are stored in the servicePrincipalName attribute. If a principal has WriteProperty on this attribute, tools often label it as WriteSPN, meaning the SPNs of the object can be modified. A separate permission called Validated-SPN allows SPN modification as well, but with Domain Controller validation rules applied.
The attack relies on modifying the servicePrincipalName attribute of a computer or service account. By manipulating SPNs, an attacker can influence how Kerberos service tickets are issued and subsequently modify them to access services on a target system.
There are two main variants of this attack:
Ghost SPN Jacking – abuses SPNs that are no longer in use.
Live SPN Jacking – abuses SPNs that are currently assigned to active services.
Ghost SPN Jacking
Ghost SPN Jacking abuses orphaned SPNs that are still referenced in constrained delegation configurations but are no longer actively used by any service. By temporarily assigning such an SPN to another host, an attacker can obtain a Kerberos service ticket (TGS) that is encrypted for the target system and later modify the service name to access a different service.
The attack requires control of a computer or service account configured for constrained delegation, which allows the attacker to request Kerberos service tickets on behalf of other users.
For this attack to succeed, the following conditions must be met:
Elevated privileges on a compromised host in order to obtain the machine account credentials
WriteSPN(or similar) permissions on the target computer objectAn orphaned SPN referenced in delegation settings but no longer actively used
Once these conditions are satisfied, the attacker can temporarily assign the orphaned SPN to another system and abuse Kerberos delegation to obtain a usable service ticket.
In the following example, the ghost SPN is dhcp/DB01, the target host is WEB01, and the compromised host is SRV01. The machine account SRV01$ is configured for constrained delegation to the DHCP service on DB01. Because the SPN is no longer actively used, it can be reassigned to another system and abused.
The attack proceeds as follows:
Assign the ghost SPN (
dhcp/DB01) to the target computer object (WEB01).Using the compromised machine account (
SRV01$), request a TGS fordhcp/DB01while impersonating theAdministrator.Modify the SPN inside the ticket so that it corresponds to a usable service on the target system, for example
cifs/WEB01.
Tools such as BloodHound can be used to identify principals with the ability to modify SPNs.
The same permissions can also be enumerated using PowerView.
Orphaned SPNs can be discovered by reviewing constrained delegation configurations and verifying whether the referenced service or host still exists. This can be done with PowerView and the Get-ConstrainedDelegation wrapper.
This indicates that SRV01 can delegate to the DHCP service on DB01, but the service is no longer present. This creates an opportunity for Ghost SPN Jacking. First, review the SPNs currently assigned to the target host and then assign the orphaned SPN to the target host.
Using the compromised machine account, request a TGS as Administrator. This can be done with Rubeus.
At this point, the obtained ticket cannot yet be used to access WEB01 because:
The ticket was issued for
dhcp/DB01The DHCP service does not provide a usable access path to
WEB01
However, an important detail enables the attack.
Kerberos service tickets are encrypted using the key of the account that owns the SPN. When the orphaned SPN dhcp/DB01 was temporarily assigned to WEB01, the Key Distribution Center (KDC) issued a TGS that is encrypted with WEB01’s machine account key, even though the ticket still references the original SPN.
However, the service name inside the ticket is not encrypted. This means the SPN can be modified after the ticket is issued. By changing the service name to something valid on the target host (e.g., cifs/WEB01), the attacker can use the ticket to authenticate to that service.
Because the ticket is already encrypted with WEB01’s key, the host accepts it as a valid service ticket.
Live SPN Jacking
Unlike Ghost SPN Jacking, which abuses unused SPNs, Live SPN Jacking targets SPNs that are currently assigned to active services. Because AD enforces SPN uniqueness, the attacker cannot directly assign a duplicate SPN to another account while it is already in use.
If an attacker attempts to assign an SPN that already exists on another object, the DC blocks the operation.
This happens because duplicate SPNs are not allowed in modern environments unless modified by highly privileged accounts. However, if the attacker has WriteSPN permissions on the object that owns the SPN, they can temporarily remove the SPN and assign it elsewhere.
In the following example:
Active SPN:
dmserver/DB02Original host:
DB02Target host:
WEB01Compromised host:
SRV01
The compromised machine account (SRV01$) has constrained delegation rights to dmserver/DB02.
Windows
Identify the SPNs of the original host, temporarily remove them, and reassign them to the target.
At this point, the SPN is owned by WEB01, meaning any TGS requested for that SPN will be encrypted using WEB01’s machine account key.
Using Rubeus, request a TGS for the delegated SPN and alter its name. Next, inject the ticket in the current session, restore the SPNs on the original host, and access the target host. Restoring the SPNs helps reduce the chance of detection and prevents service disruption. Because the ticket has already been issued and injected, restoring the SPN does not affect the current session.
Linux
The same attack can also be performed from Linux using Impacket and addspn.py from Krbrelayx tools for manipulating the SPNs.
Last updated