Kerberoasting Prevention: How to Harden Service Accounts to Stop Offline Password Cracking
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Kerberoasting is one of the most reliable paths from standard domain user to privileged access. In most organizations, there are service accounts with SPNs, elevated privileges, and passwords that have not been rotated in years -- accounts set up when the application was first deployed and never touched since. An attacker enumerates all SPNs with a single LDAP query, requests tickets for all of them, and cracks them offline at leisure. The defense is not blocking the ticket request (any domain user can legitimately request service tickets), it is making the cracked material either useless (gMSA with 240-char auto-rotating passwords) or computationally infeasible to crack (AES-256 only, long random passwords).
Enumerate All Kerberoastable Accounts
Find all user accounts with SPNs set (gMSA and machine accounts are excluded -- they already have strong auto-rotating passwords): Get-ADUser -Filter { ServicePrincipalName -ne '$null' } -Properties ServicePrincipalName, PasswordLastSet, PasswordNeverExpires, MemberOf, msDS-SupportedEncryptionTypes | Select-Object SamAccountName, ServicePrincipalName, PasswordLastSet, PasswordNeverExpires, @{N='EncryptionTypes';E={$.'msDS-SupportedEncryptionTypes'}}, @{N='Groups';E={($.MemberOf | Get-ADGroup | Select-Object -ExpandProperty Name) -join ', '}} | Sort-Object PasswordLastSet. Key columns to analyze: PasswordLastSet (older than 1 year is high risk for cracking -- the password may be in breach databases or match common patterns), PasswordNeverExpires (service accounts often have this set -- if also have an SPN, flag for immediate attention), Groups (any service account with SPN that is in Domain Admins, Backup Operators, or high-privilege groups is critical priority), EncryptionTypes (value of 0 or 23 means RC4 is allowed -- value of 24 or higher includes AES).
Prioritize by Privilege and Password Age
Not all Kerberoastable accounts are equal risk. Triage matrix: Critical (fix within 24 hours): service account with SPN, password over 1 year old, RC4 encryption, member of any privileged group. These accounts are almost certainly Kerberoastable to meaningful privilege. High (fix within 1 week): service account with SPN, password over 1 year old, not in privileged groups but with access to sensitive systems (file servers, databases, applications). These can be cracked for lateral movement. Medium (fix within 30 days): service account with SPN, password recently rotated, RC4 encryption. Lower crack risk due to newer password but still worth migrating to AES or gMSA. Low (track and monitor): service account with SPN, AES-256 only, strong random password, recently rotated. These are well-configured but should be migrated to gMSA at next application maintenance window.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Migrate to Group Managed Service Accounts (gMSA)
The best mitigation for Kerberoastable service accounts is eliminating the human-managed password entirely by migrating to gMSA. gMSA passwords are 240 random characters, generated and rotated automatically by Active Directory every 30 days, and cannot be extracted by any domain user (only the authorized computer accounts can retrieve the current gMSA password). A gMSA ticket is theoretically Kerberoastable but cracking a 240-character random password is computationally infeasible. Migration steps: create the gMSA with New-ADServiceAccount -Name 'svc-app-gmsa' -DNSHostName 'app.domain.com' -PrincipalsAllowedToRetrieveManagedPassword 'ServerName$' (the computer account of the server running the service). Install the gMSA on the target server: Install-ADServiceAccount -Identity 'svc-app-gmsa'. Configure the Windows service or application to use the gMSA (format: domain\svc-app-gmsa$, with no password field -- the system retrieves the password from AD). Test service start. Remove the old service account's SPN once migration is confirmed. gMSA works for Windows services, IIS application pools, Scheduled Tasks, and COM+ applications.
Enforce AES-256 Encryption for Accounts That Cannot Use gMSA
Some applications cannot use gMSA (applications that require explicit password input, third-party services, or applications running on non-domain-joined systems). For these accounts: enforce AES-only encryption to prevent RC4-based Kerberoasting. Set msDS-SupportedEncryptionTypes to 24 (AES-128 and AES-256 only, RC4 disabled) via PowerShell: Set-ADUser -Identity 'svc-app' -KerberosEncryptionType AES128,AES256. This prevents the KDC from issuing RC4-encrypted service tickets, forcing AES-256 which is significantly harder to crack. Additionally: rotate the password to a 63-character random string immediately (New-Guid generates a GUID that can be used as part of a random password; better is a dedicated random string generator). Set a password rotation policy -- service accounts should rotate at least annually, quarterly for high-privilege accounts. Use a PAM solution to manage service account password rotation automatically.
Detect Kerberoasting Activity
Event ID 4769 on domain controllers logs each TGS request. Most 4769 events are legitimate, but Kerberoasting has a signature: high-volume TGS requests for multiple SPNs from a single source in a short time window, requesting RC4 tickets (Ticket Encryption Type 0x17 = RC4) for accounts that should be using AES. KQL in Sentinel: SecurityEvent | where EventID == 4769 and TicketEncryptionType == '0x17' and ServiceName !endswith '$' | summarize Count=count(), Accounts=make_set(ServiceName) by IpAddress, bin(TimeGenerated, 5m) | where Count > 5. Alert on: RC4 TGS requests for non-machine accounts (machine accounts end in $), especially if multiple different service accounts are requested within minutes from the same source IP. After migrating to AES-only encryption for all service accounts, any 4769 with RC4 encryption type is anomalous.
The bottom line
Kerberoasting prevention is achievable: enumerate all SPNs, prioritize by privilege and password age, migrate the highest-risk accounts to gMSA first, enforce AES-only encryption for those that cannot migrate, and rotate passwords to 63+ character random strings. Alert on RC4 TGS requests via Event ID 4769 -- after completing the AES migration, any RC4 service ticket request is anomalous. The migration is an operational project, not a configuration change; plan 2 to 6 weeks depending on the number of affected service accounts.
Frequently asked questions
Can gMSA replace all service account types?
gMSA works for Windows services, IIS application pools, Scheduled Tasks, and COM+ applications where the application uses the Windows token for authentication rather than explicitly handling credentials. gMSA does not work for: applications that require a plaintext password or a password hash as input (some JDBC/ODBC connection string configurations, some SMTP configurations), applications running on Linux (gMSA requires domain-joined Windows hosts for password retrieval), and applications running on non-domain-joined systems. For these cases, use AES-only encryption and a PAM-managed password with automatic rotation.
Does enforcing AES-only encryption break existing Kerberos connections?
It breaks connections from clients or services that only support RC4 Kerberos encryption. Modern Windows clients (Windows 7 and later) support AES-256 by default. The most common compatibility issue is older applications using Kerberos libraries that do not support AES (pre-2010 Java applications using old krb5.conf, some older SAP and Oracle versions). Test AES enforcement on a non-production instance of the application first. Check Event ID 4769 for the account after switching: if the encryption type in the event changes from 0x17 (RC4) to 0x12 (AES-256), the transition is working. If the application fails to authenticate, the application's Kerberos library needs to be updated.
Is Kerberoasting detectable if the attacker is slow?
A sophisticated attacker can perform Kerberoasting at a very low rate -- one TGS request per service account over several hours -- to avoid the volume-based detection query. At this rate, the only reliable detection is anomaly-based: an account that never normally requests service tickets suddenly requesting one is suspicious regardless of rate. Defender for Identity (MDI) applies baseline modeling to TGS requests and alerts on anomalous behavior even at low rates. Raw event log queries work best for high-volume attacks; MDI provides better coverage for low-and-slow attacks.
What is the difference between Kerberoasting and AS-REP Roasting?
Kerberoasting targets accounts with SPNs (service accounts) and requires an authenticated domain user to request a TGS. AS-REP Roasting targets accounts with Kerberos pre-authentication disabled and requires no credentials -- anyone on the network can request the AS-REP. Both produce offline-crackable material. Both are addressed by strong passwords or gMSA. They are separate attack types with separate detection queries (4769 for Kerberoasting, 4768 with pre-auth type 0 for ASREPRoasting).
What SPN naming patterns make a service account a higher-priority Kerberoasting target?
SPNs registered on accounts with high privileges are the highest priority. Specifically: SPNs on accounts with AdminCount=1 (previously in a privileged group, placed in AdminSDHolder protection), SPNs on accounts that are members of Domain Admins or other Tier 0 groups, and SPNs on accounts with delegation configured (because their compromise grants delegation capability in addition to the cracked password). SPNs registered to user accounts rather than computer accounts are also higher risk because computer accounts have auto-rotated random 120-character passwords. Query BloodHound: any path from a Kerberoastable account to Domain Admins in 3 hops or fewer is critical.
What is the difference between Kerberoasting and ASREPRoasting and how do defenses differ?
Kerberoasting targets accounts with Service Principal Names (SPNs): any authenticated domain user can request a TGS ticket for any SPN-bearing account, and the ticket is encrypted with the service account's password hash, which can be cracked offline. ASREPRoasting targets accounts with Kerberos pre-authentication disabled: an unauthenticated attacker requests an AS-REP for any username and receives a response partially encrypted with the account's password hash, crackable without any domain credentials. Defenses differ at the account configuration layer. Kerberoasting defense: eliminate user-account SPNs, migrate to Group Managed Service Accounts (gMSA) whose 120-character auto-rotating passwords are computationally impossible to crack, and use AES-only encryption for Kerberos. ASREPRoasting defense: enable pre-authentication for all accounts (the default; look for accounts where it was explicitly disabled), enforce long complex passwords on the rare accounts that require pre-auth disabled for legacy compatibility, and monitor Event ID 4768 for AS-REP requests without pre-auth. Both attacks result in an offline cracking challenge; both require auditing which accounts are vulnerable before a compromise occurs.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.