Identifying Kerberoastable Service Accounts

ActiveDirectoryDiscoveryintermediateT1087.00212 min

Identifying Kerberoastable service accounts is a targeted discovery technique that finds user-based accounts with Service Principal Names registered in Active Directory. This lesson explains what makes an account a viable Kerberoasting target, how to distinguish high-value targets from noise, what the attacker gains before the actual roasting step, and how to communicate this discovery work clearly in interviews and reports.

This lesson builds on

Theory

Why It Matters

Kerberoasting is only as effective as the targets you select. Blindly requesting tickets for every SPN in the domain wastes time on computer accounts that cannot be cracked and low-privilege service accounts that lead nowhere.

The real skill is identifying which SPN-bearing accounts are worth targeting — accounts with weak passwords, excessive privileges, or both. Interviewers expect candidates to explain the discovery step, not just the cracking step, because target selection is what separates a thoughtful operator from someone running a tool with default options.

Preconditions

Identifying Kerberoastable accounts requires an authenticated domain user account at any privilege level. Service Principal Names are stored as attributes on user and computer objects in Active Directory and are readable by any authenticated user via LDAP. The attacker needs domain credentials and either a domain-joined host or network access to query a domain controller. No elevated privileges are required to enumerate every SPN in the directory.

Key Concepts

  • User accounts versus computer accounts — both can have SPNs, but computer account passwords are long, random, and machine-managed, making them effectively uncrackable; only user-based service accounts are viable Kerberoasting targets
  • SPN as a targeting signal — the presence of an SPN on a user account means the KDC will issue a TGS ticket encrypted with that account's password hash; the SPN itself is the indicator that Kerberoasting is possible against that account
  • Password age as a prioritization factor — the pwdLastSet attribute reveals when the password was last changed; accounts with passwords unchanged for years are more likely to have weak, crackable passwords
  • Privilege level as a value indicator — a Kerberoastable account in Domain Admins is a critical finding; a Kerberoastable account with access to a single non-sensitive application is a low-priority target; the discovery step must assess both crackability and impact
  • Group Managed Service Accounts (gMSAs) — these have long, random, auto-rotated passwords and are not viable Kerberoasting targets; identifying whether an environment uses gMSAs tells the attacker how mature the service account management is
  • Targeted Kerberoasting preparation — if the attacker has write access to an account (GenericAll, GenericWrite), they can set an SPN on any user account, making it Kerberoastable; this discovery step also includes identifying accounts vulnerable to targeted SPN assignment

Why It Works

Active Directory stores Service Principal Names as the servicePrincipalName attribute on account objects, and this attribute is readable by any authenticated user via LDAP. SPNs exist to support Kerberos service ticket routing: when a client requests access to a service, the KDC uses the SPN to locate the account whose key should encrypt the ticket.

This means the directory must advertise which accounts run which services, and that advertisement is inherently visible to all domain users. An attacker queries for user accounts (not computer accounts) that have at least one SPN registered, because user-based service accounts are the only ones whose passwords are set manually and therefore potentially crackable.

What the Attacker Gains

The attacker gains a prioritized target list for Kerberoasting. For each SPN-bearing user account, they can determine the account's group memberships, password last-set date, whether the account is enabled and active, and what service the SPN represents.

This intelligence transforms Kerberoasting from a blind spray into a targeted operation: the attacker can prioritize accounts that are in privileged groups with old passwords over low-privilege accounts with recently changed passwords. A single well-chosen target is worth more than fifty random ones.

Where It Fits in the Attack Chain

This discovery technique sits immediately before Kerberoasting in the attack chain. After initial access and basic enumeration (domain structure, privileged groups, password policy), the attacker identifies which service accounts are Kerberoastable and which ones are worth prioritizing.

The results flow directly into the credential access phase: the attacker requests TGS tickets only for the highest-value targets identified during this step. This technique also complements BloodHound analysis, which can reveal whether Kerberoastable accounts sit on privilege escalation paths.

Tools & Examples

  • PowerView Get-DomainUser -SPN — enumerates all user accounts with registered SPNs, excluding computer accounts
  • Impacket GetUserSPNs.py — remotely identifies Kerberoastable accounts and can optionally request tickets in the same step
  • ldapsearch for SPN accounts — raw LDAP query using filter (&(objectClass=user)(servicePrincipalName=*)(!(objectClass=computer))) targeting user-based SPN accounts
  • BloodHound — marks Kerberoastable accounts in the graph and shows whether they sit on privilege escalation paths
  • Active Directory PowerShell module Get-ADUser -Filter {ServicePrincipalName -ne '$null'} — native Windows approach for SPN enumeration

Defender's Perspective

  • Audit all user accounts with SPNs regularly. Every SPN on a user account should have a documented business justification and an associated password strength requirement.
  • Convert service accounts to Group Managed Service Accounts (gMSAs) wherever possible. gMSA passwords are 120 characters, randomly generated, and automatically rotated.
  • Remove SPNs from user accounts that no longer require them. Legacy SPNs on decommissioned services are unnecessary attack surface.
  • Monitor for LDAP queries that enumerate accounts with SPNs, particularly queries filtering on servicePrincipalName from unusual sources or at unusual times.
  • Enforce long passwords (25+ characters) on all service accounts that cannot be converted to gMSAs, and rotate them on a defined schedule.

Communication

How to Explain It in an Interview

Before Kerberoasting, I identify which accounts are actually worth targeting. I query for user accounts with Service Principal Names, because those are the only accounts whose TGS tickets are crackable — computer account SPNs are not viable targets due to their long, random passwords. For each SPN-bearing user account, I check the group memberships to assess what access the account has, the password last-set date to estimate crackability, and whether the account is active. This lets me prioritize: a service account in Domain Admins with a password unchanged for three years is a critical target, while a low-privilege account with a recently rotated password is probably not worth the cracking time.

The discovery step is where you make the decision about whether Kerberoasting will be productive and where to focus the effort.

How to Explain It to a Stakeholder

Before an attacker attempts to crack service account passwords, they first identify which accounts are vulnerable and which ones would give them the most access if compromised.

Any employee-level account can query your directory to find service accounts with properties that make their passwords extractable and potentially crackable. The attacker then prioritizes accounts that have both weak password indicators (old, never-rotated passwords) and high access levels (membership in administrative groups). The risk is that this reconnaissance step is invisible to most monitoring and gives the attacker a precise target list. The fix is converting service accounts to automatically managed passwords where possible and enforcing strong, regularly rotated passwords on the rest.

How It Might Appear in a Report

Finding: Kerberoastable Service Accounts Identified in Privileged Groups. During the assessment, the operator enumerated user accounts with registered Service Principal Names and identified 12 Kerberoastable service accounts. Three of these accounts (svc_sqlprod, svc_backup, svc_exchange) are members of the Domain Admins group with passwords last changed over two years ago. The remaining nine accounts have varying privilege levels, with five having local administrator access on multiple servers. No Group Managed Service Accounts (gMSAs) were in use.

Severity: High.

Recommendation: Convert service accounts to gMSAs where supported. For remaining accounts, enforce passwords of at least 25 characters and implement regular rotation. Remove service accounts from Domain Admins and delegate only the specific permissions required.

Common Weak Answers

  • Jumping straight to Kerberoasting without explaining the discovery step. Running GetUserSPNs.py and immediately requesting tickets shows tool knowledge but not target prioritization or understanding of what makes a target valuable.
  • Not distinguishing between user-based and computer-based SPNs. Computer accounts have SPNs but are not viable Kerberoasting targets. Failing to explain this distinction suggests surface-level understanding.
  • Treating all Kerberoastable accounts as equally important. A service account in Domain Admins with a three-year-old password is a fundamentally different finding than a low-privilege account with a recently rotated password.
  • Not mentioning password age as a prioritization factor. The pwdLastSet attribute is one of the strongest indicators of crackability and is available during the discovery step.
  • Ignoring the existence of Group Managed Service Accounts. Knowing whether the environment uses gMSAs tells you about the maturity of service account management and narrows the target set.

Likely Follow-Up Questions

  • Why are computer account SPNs not useful Kerberoasting targets?
  • How would you prioritize which Kerberoastable accounts to target first?
  • What does the pwdLastSet attribute tell you about a service account's crackability?
  • What is targeted Kerberoasting, and how does the discovery step differ from standard SPN enumeration?
  • If an environment has converted all service accounts to gMSAs, what does that mean for your Kerberoasting plan?

Further Reading