A common configuration error in Active Directory is assigning Service Principal Names (SPNs) to ordinary user accounts.
This mistake can create an overlooked path for Kerberoasting attacks, allowing adversaries to obtain credentials without needing privileged access or causing account lockouts.
Kerberoasting typically targets Active Directory service accounts that hold SPNs, which Kerberos uses to identify services such as SQL Server, web applications, and LDAP.
A domain user can request a Kerberos Ticket Granting Service (TGS) ticket for an SPN. This ticket contains data encrypted using the password-derived key associated with the service account.
Active Directory SPN Misconfigurations
An attacker can take this ticket offline and attempt to crack it. Unlike repeated password attempts on an online login page, offline cracking does not trigger failed authentication events or increase the account lockout counter.
If the targeted account uses a weak or predictable password, the attacker may recover the credentials without leaving the usual trail of login failures.
Trellix researchers Maulik Maheta and Henry Bernabe have warned that SPNs assigned to standard user accounts can complicate detection efforts.
Security teams usually inventory and review service accounts for unnecessary SPNs, excessive permissions, aging credentials, and weak encryption. However, ordinary user accounts may receive less scrutiny.
This oversight is significant because a user account with an SPN can become roastable just like a conventional service account. An attacker who has already obtained valid domain credentials can enumerate SPNs throughout the environment, identify unusual account-to-SPN relationships, and request tickets for valuable targets.
Misconfigurations can also arise from delegated Active Directory permissions. For example, an account with GenericWrite rights over another directory object could potentially alter that object’s SPN attribute outside the organization’s normal service onboarding process.
The modified SPN may appear as a legitimate service identifier, enabling the attacker to convert the account into a Kerberoasting target.
This situation turns an identity-management oversight into an attack pathway that facilitates credential theft, lateral movement, and privilege escalation.
The risk intensifies when Active Directory continues to allow RC4-HMAC encryption for Kerberos service tickets. RC4-HMAC, represented by the encryption type 0x17, is widely regarded as weaker than modern Kerberos encryption options and is often associated with Kerberoasting.
After obtaining a TGS ticket, attackers can export the cached ticket data and use password-cracking tools to crack it offline. A successful crack reveals the underlying account password, which may then be reused to gain access to additional systems or services.
Additionally, stolen Kerberos tickets can be abused in pass-the-ticket attacks, enabling an attacker to authenticate as the ticket’s owner without submitting the plaintext password again.
The entire process is particularly troubling because it combines stealth with persistence. The problematic SPN assignment remains in place until an administrator identifies and removes it. Meanwhile, offline cracking does not generate the failed-login activity that defenders often rely on to detect password attacks.
Defenders should start by auditing every SPN in the domain, not just those tied to designated service accounts. Security teams need to investigate SPNs assigned to typical employee or administrator accounts, validate whether each mapping supports a legitimate service, and review delegated permissions that allow users to modify directory attributes.
Other defensive priorities include:
- Resetting passwords for affected accounts and enforcing long, unique, and preferably managed credentials for service accounts.
- Removing unnecessary SPNs and documenting approved account-to-service mappings.
- Disabling RC4-HMAC where compatibility permits and prioritizing stronger Kerberos encryption.
- Monitoring Kerberos TGS requests, especially for unusual volumes, uncommon requesting hosts, and tickets for user-associated SPNs.
- Alerting on PowerShell-based SPN enumeration, directory attribute changes, ticket export behavior, and suspicious credential-access tools.
Trellix reported that its Network Detection and Response platform detected SPN enumeration before credential extraction and lateral movement occurred.
Its investigation workflow linked the activity to the MITRE ATT&CK technique T1558.003, Kerberoasting. It correlated the requesting users, targeted SPNs, endpoints, processes, and remediation actions.
The key takeaway is simple: an SPN is not just a service configuration detail. When improperly attached to the wrong account, or modifiable by the wrong principal, it can become a covert credential-harvesting mechanism that evades traditional lockout-based defenses.
Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC
 to ordinary user accounts.){kind=link}