Service Principal Names (SPNs) have been around since the early days of Windows 2000 as a way to uniquely identify client services running on a machine for authentication purposes.
However, poor configuration and management of SPNs can still lead to security issues almost 25 years later.
In this post, I’ll break down what SPNs are, why they can be dangerous, and the key tips to avoid SPN-related attacks.
Read until the end!
What is a Service Principal Name (SPN)?
An SPN is a unique name that gets assigned to a service account that is allowed to run on a machine under a certain domain account. For example, the Domain Administrator account may run services that get assigned SPNs like:
- HTTP/fileserver1.company.com
- HOST/fileserver1.company.com
- RestrictedKRBHost/fileserver1.company.com
These names clearly identify services running as the Domain Admin on that particular server.
The SPN set on a service account gets mapped to an account’s security identifier (SID) and is used during authentication processes like Kerberos ticket exchanges.
SPNs provide the following key benefits:
- Uniquely identifies services: Having an SPN helps accurately distinguish service instances.
- Enables mutual authentication: Both clients and services can verify each other’s identities.
- Required for Kerberos: SPNs are necessary for Kerberos authentication.
However, if SPNs are not properly configured or managed, they can unfortunately be exploited by attackers.
A good explanation on SPNs can be found here: https://technet.microsoft.com/en-us/library/cc961723.aspx.
Examples of SPNs:
Dangers of Improperly Handled SPNs
If SPNs are set incorrectly or managed poorly, this can open doors for certain attacks, particularly privilege escalation and lateral movement tactics. Some key dangers include:
Account Takeover
If a user account has control of an SPN belonging to a service account, that user can impersonate the service. For example, if a user could assign themselves the HOST/fileserver1.company.com SPN, they could impersonate any service on that host.
Credential Theft
Attackers may harvest SPN values found in environments through reconnaissance. They can then use password cracking against the SPNs to try acquiring that service’s credentials.
Kerberoasting
A tactic called Kerberoasting abuses Kerberos protocol weaknesses related to SPNs to obtain crackable service tickets. Offline cracking can then reveal the service account password.
Silver Ticket Attacks
Silver ticket attacks can forge Kerberos tickets using known SPN values and password hashes to authenticate as any service on the network.
Privilege Escalation
If a user manages to modify their own account object to add the SPN of a privileged service account, this can be used to escalate privileges.
These types of attacks expose why proper SPN management is critical.
5 Key SPN Security Tips
I want to recommend some essential practices to keep SPNs secured in your environment:
1. Ensure Unique SPNs
Make sure the setspn command is used to assign each SPN and that no duplicate SPNs exist. You can scan for duplicates with:
setspn -xDuplicate SPNs weaken security and enable misuse.
2. Restrict Authority for SetSPN Rights
Carefully control which accounts have the right to manage or modify SPNs. Avoid allowing end-user accounts to have any control.
Check for unauthorized SetSPN rights with PowerShell:
Get-ADPermission -Filter * -Properties ObjectType,ActiveDirectoryRights | Where {$_.ObjectType -like '*serviceprincipalname*'} | select IdentityReference,ActiveDirectoryRightsFollow the principle of least privilege.
3. Use Dedicated Service Accounts
You can avoid sharing local admin accounts or user accounts for services. Dedicated service accounts with strong random passwords enhance SPN security.
4. Regularly Audit SPNs
Audit domain controllers regularly for any unauthorized SPN changes made to accounts. Look for suspicious additions.
Enable security event logging for this event ID:
Event ID 5136 - The directory service attempted to modify the SPN registration of an account.You have to monitor these events closely for signs of misuse.
5. Remove unused SPNs
I would recommend removing unused SPNs. To remove an unused SPN, you can run the following command:
«setspn –D MSSQLSvc/dc01:1433 Dailyadmin»
In my example, the SPN is not in use. In real life, the SPN has to be changed to reflect the correct configuration. Either to a machine account, a managed service account, or a self-made service account with an insane password.
Take note that Active Directory uses SPN by design. You simply cannot delete every SPN to feel safe.
Moving SPNs to Managed Service Accounts
Managed Service Accounts (MSAs) added in newer Windows Server versions offer an improved model over standard SPNs on domain accounts.
Key features of MSAs:
- Do not require password management; passwords are managed automatically.
- Provide enhanced SPN security with tighter access controls.
- Built-in support for service isolation and grouped managed service accounts.
Migrating from traditional domain accounts to managed service accounts is recommended for stronger SPN and service management.
The Ongoing Need for Diligence with SPNs
While SPNs remain fundamental for service authentication on Windows networks, organizations must be vigilant about proper configuration and lifecycle management given the potential for abuse.
Following strong privilege separation, applying the principle of least privilege, auditing changes, and considering new account primitives like MSAs can help modernize SPN protections. But continued vigilance is key for spotting and responding to new attack techniques targeting these pivotal identifiers.
Here are some links I find interesting about it:
- https://adsecurity.org/?p=556
- https://passing-the-hash.blogspot.no/
- https://www.beneaththewaves.net/Projects/Mimikatz_20_-_Brute-Forcing_Service_Account_Passwords.html
- Video of the Kerberoast author Tim Medin: https://www.irongeek.com/i.php?page=videos/derbycon4/t120-attacking-microsoft-kerberos-kicking-the-guard-dog-of-hades-tim-medin
- https://blog.gentilkiwi.com/downloads/Abusing-Microsoft-Kerberos-Sorry-You-Guys-Don-t-Get-It.pdf
I hope this blogpost gave some information on how attackers can misuse Service Principal Names and that you, as an IT professional, can implement mitigations to prevent them from succeeding.
Other Topics:
