Kerberoasting
Also known as: Kerberoast, Service ticket cracking, SPN ticket abuse, T1558.003
An Active Directory attack in which a service ticket, encrypted with a key derived from a service account's password, is taken and attacked offline, so weak service-account passwords fall without any failed-logon noise.
Watch it in 60 seconds
How it works
Kerberoasting abuses how Kerberos protects access to services in Active Directory. Any authenticated domain user may ask the domain controller for a service ticket for any account that has a service principal name (SPN) registered. Part of that ticket is encrypted with a key derived from the service account's password.
Because the domain controller hands the ticket out without checking that the requester is entitled to use the service, the holder can carry it away and test password guesses against it offline. No further contact with the domain is needed, so there are no failed sign-ins, no lockouts and nothing for a lockout policy to catch. A short or guessable service-account password falls quickly, and these accounts are often old, over-privileged and never rotated.
The legacy RC4 encryption type makes this far cheaper for the attacker than AES, which is why the RC4 value in a ticket request is the classic tell. The request itself is ordinary traffic; what gives it away is the pattern: many service tickets requested by one account in a short window, for services that account has no reason to use, often in the RC4 type when the rest of the estate negotiates AES.
Defence therefore has two halves. Detect the unusual burst of ticket requests and scope which service accounts were exposed. Then remove the reward: give service accounts long random or managed passwords (gMSA), enforce AES, strip unneeded SPNs and privileges, and keep monitoring so a repeat is seen at once.
Walk through it
- 1A burst of service tickets
- 2Read the encryption type
- 3Who is asking?
- Scope the exposed service accounts
- Contain and harden
Your SIEM raised a medium alert on the domain controllers: an unusual volume of Kerberos service-ticket requests from a single account in a few minutes. Nobody has complained, and nothing failed, which is exactly why this attack hides in plain sight. Read the alert before you pivot.
Kerberos service-ticket volume anomaly
Source: domain controllers DC01 and DC02, Security log, event 4769 (service ticket requested).
Baseline for this account: 4 requests per day. Last 6 minutes: 63 requests.
Requests span 41 different service principal names. No failed logons, no lockouts.
Spot it
- A burst of event 4769 from one account or host, far above its baseline, covering many different service names.
- Ticket Encryption Type 0x17 (RC4) in an estate where AES (0x12 or 0x11) is the norm.
- Requests for service accounts the requester has no business relationship with, especially older accounts with SPNs and high privileges.
- Directory queries enumerating accounts that have a service principal name set, shortly before the ticket burst.
- A service account later signing in from a new host or at an unusual time, which suggests an offline guess succeeded.
Domain controller Security log (4769)
ts=2026-10-11T09:14:02Z EventID=4769 Account=j.reyes@FABRIKAM.EXAMPLE Service=svc-sqlbackup TicketEncryptionType=0x17 Status=0x0 Client=10.20.4.77
ts=2026-10-11T09:14:02Z EventID=4769 Account=j.reyes@FABRIKAM.EXAMPLE Service=svc-fileshare TicketEncryptionType=0x17 Status=0x0 Client=10.20.4.77
ts=2026-10-11T09:14:03Z EventID=4769 Account=j.reyes@FABRIKAM.EXAMPLE Service=svc-printq TicketEncryptionType=0x17 Status=0x0 Client=10.20.4.77Directory service access (LDAP query logging)
ts=2026-10-11T09:13:41Z src=10.20.4.77 account=j.reyes ldap_filter=(servicePrincipalName=*) scope=subtree results=41kqlSentinel - one account requesting many RC4 service tickets
SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17" and Status == "0x0"
| where ServiceName !endswith "$" and ServiceName != "krbtgt"
| summarize Services = dcount(ServiceName), Requests = count() by TargetUserName, IpAddress, bin(TimeGenerated, 10m)
| where Services > 10
| order by Services descTune the threshold to your baseline. Legacy applications that still need RC4 will show a few; dozens of distinct services from one account in minutes is the signal.
splSplunk - service-ticket volume per requester
index=wineventlog EventCode=4769 Ticket_Encryption_Type=0x17 Failure_Code=0x0
| stats dc(Service_Name) AS services count BY Account_Name Client_Address
| where services > 10Exclude computer accounts (names ending in $) and known legacy hosts once you have validated them.
Stop it
Make service-account passwords uncrackable: use gMSA
Group managed service accounts have long, random, automatically rotated passwords. An offline attack on a ticket for such an account is not realistic, so the stolen ticket is worthless. Where gMSA is not possible, use passwords of 25 or more random characters held in a vault.
Enforce AES and retire RC4
Set service accounts to support AES only and disable RC4 across the domain once legacy dependencies are removed. AES makes each guess far more expensive and turns any remaining RC4 request into an obvious alert.
Shrink the target list
Remove SPNs that are not needed, never give a service account domain-admin rights, and scope each account to the minimum it needs. A cracked low-privilege service account is an incident; a cracked privileged one is a breach.
Monitor and alert on the pattern
Alert on bursts of 4769 and on RC4 tickets, and optionally plant a honeypot service account with an SPN that nobody legitimately uses so that any request for it is a high-confidence alert.
Service-account policy intent
Hardened
FOR each account with a servicePrincipalName:
IF a gMSA can run the service THEN migrate to gMSA
ELSE password = random, 25+ characters, stored in a vault, rotated on schedule
SET supported encryption = AES256, AES128 only
REMOVE membership of privileged groups
REMOVE SPNs that are no longer in useExpressed as policy intent; implement with your directory's management tooling and test legacy applications first.
- Inventory every account with an SPN and record its owner, privileges and password age.
- Migrate services to group managed service accounts wherever the application supports it.
- Set long random passwords on the rest, rotate them, and store them in a privileged-access vault.
- Enforce AES-only Kerberos encryption and track down the last RC4 dependencies.
- Log event 4769 on all domain controllers and alert on volume, RC4 use and honeypot-account requests.
- Keep service accounts out of Domain Admins and other tier-0 groups.
If it already happened
Disable or isolate the requesting account and host, revoke its sessions, and force a password change on every service account whose ticket was requested during the burst.
Investigate how the requesting account was compromised, hunt for the same account signing in as any exposed service account, and remove any persistence found.
Rotate the exposed service-account passwords to long random values or move them to gMSA, restart dependent services in a controlled order, and confirm normal sign-in.
Add the volume and RC4 detections if missing, remove unneeded SPNs and privileges, and complete the AES-only migration.
Check yourself
1. Which log pattern most strongly suggests Kerberoasting on a domain controller?
2. Why does a weak service-account password make a captured service ticket dangerous?
3. Which change most directly removes the payoff of Kerberoasting for a given service?