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]:
Add a real SPN to a Domain Admin for persistence.
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
Step 2 - Find Out if the User Already Has a SPN
Step 3 - Set a SPN for the User
Make sure it is unqiue for the domain.
Step 4 - Check If the User Has a New SPN By Repeating Step 2
Step 5 - Kerberoast the Account
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