Create a temporary SPN through an effective object right

Needs: Effective SPN-property right, compatible account, unique temporary SPN, authenticated TGS request and exact cleanup

Built-in SPN operations

If Block 10 proved effective write access to a user object's servicePrincipalName, an SPN can be temporarily added, requested and removed. This is a state-changing directory attack and must preserve original state.

REM Built-in SPN operations
setspn -L TARGET_USER
setspn -S temporary/TARGET_USER TARGET_USER

Request only that account

# Request only that account
impacket-GetUserSPNs -request-user TARGET_USER -dc-ip DC_IP \
  -outputfile targeted-TARGET_USER.hashes 'DOMAIN/USER'

Cleanup

REM Cleanup
setspn -D temporary/TARGET_USER TARGET_USER
setspn -L TARGET_USER

PowerShell commands

The controlled right must apply to the SPN attribute, -S must not collide with an existing SPN, and cleanup is part of the procedure. A recovered password is still validated and mapped as a new identity.

If the effective right permits writing servicePrincipalName on a user, add a unique temporary SPN, request that account's ticket and remove the SPN immediately. The cracking workflow is in Kerberos and identity transitions.

# Baseline
setspn -S TEMP/TARGET_USER TARGET_USER
setspn -Q TEMP/TARGET_USER
Rubeus.exe kerberoast /user:TARGET_USER /outfile:TARGET_USER.tgs /format:hashcat
setspn -D TEMP/TARGET_USER TARGET_USER

Verify → Verify effective right, requested account and cleanup; confirm any recovered credential independently.

If it fails → GenericWrite must actually apply to the property/object. Duplicate SPNs, protected objects or policy can prevent the chain. More detail ↓

If → then

A supported stored verifier or converted protected artifact → Recover passwords with feasible dictionary, rule and mask attacks
Needs: Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend
A password tied to a plausible user and service → Validate known passwords and context-specific reuse
Needs: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state
An ACL/graph edge names GenericAll, GenericWrite, WriteDacl, WriteOwner or an extended/property right → Validate effective directory-object control
Needs: Effective trustee membership, target object/type, inheritance/deny behavior and the exact permitted operation

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Create a temporary SPN through an effective object right

USE WHEN: A controlled principal can write a user's servicePrincipalName
STARTING ACCESS: A domain identity, appropriate host privilege, or a validated effective directory-object right
RESULT: A recovery artifact for the controlled target account

Recognize the clue

Inspect a useful user's SPN set and resolved effective ACL rather than assuming GenericWrite always permits a desired property change.

Get-DomainUser -Identity TARGET_USER -Properties serviceprincipalname
Get-DomainObjectAcl -Identity TARGET_USER -ResolveGUIDs

SYNTHETIC EXAMPLE OUTPUT

Existing SPNs: none
Effective trustee: CONTROLLED_GROUP
Potential right: write servicePrincipalName

Means: A specific writable SPN property on a useful user can create a ticket-request opportunity.

Confirm: Verify trustee/effective property scope, enabled account, unique temporary SPN, KDC context and exact restoration.

After validation: The permitted temporary SPN produces the selected artifact and is removed: use the targeted recovery method.
Ruled out in this context: The ACE does not apply to this property/object: reject the proposed SPN modification.
Still inconclusive: A stale GenericWrite graph edge without current ACE verification is insufficient.

Troubleshooting: GenericWrite must actually apply to the property/object. Duplicate SPNs, protected objects or policy can prevent the chain.

Additional prerequisite checks

Get-DomainObjectAcl -Identity TARGET_USER -ResolveGUIDs
setspn -L TARGET_USER

If Block 10 proved effective write access to a user object's servicePrincipalName, an SPN can be temporarily added, requested and removed. This is a state-changing directory attack and must preserve original state.

Built-in SPN operations:

Request only that account:

Cleanup:

The controlled right must apply to the SPN attribute, -S must not collide with an existing SPN, and cleanup is part of the procedure. A recovered password is still validated and mapped as a new identity.

If the effective right permits writing servicePrincipalName on a user, add a unique temporary SPN, request that account's ticket and remove the SPN immediately. The cracking workflow is in Kerberos and identity transitions.

Why it works

Writing an SPN exposes a ticket-request route for the target account key. It does not reset the password; recovery still depends on password strength and encryption.

Worked example · hypothetical

Observation: a user has no SPN but the controlled identity has the required property write. Test: add a unique temporary value, request that user's TGS and remove the value. Illustrative output: the artifact is obtained and the original SPN set is restored. Interpretation: recover offline if feasible.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗