TTechniqueActiveDirectory
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.
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.
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.
MITRE · MITRE ATT&CK reference for Kerberoasting — the technique this discovery step directly feeds into
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.
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.
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.
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.
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.
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.