Kerberoasting Attack Investigation

When You See This

1. 1

   SIEM alert for a single user requesting TGS tickets (Event ID 4769) for multiple SPNs in a short window

2. 2

   Kerberos ticket requests with RC4 encryption type (0x17) rather than AES (0x12); attackers prefer RC4 because it is faster to crack

3. 3

   Security tooling detects Rubeus, Impacket GetUserSPNs, or PowerShell Kerberoasting scripts

4. 4

   Unusual account requesting TGS tickets for services it has never accessed before

Investigation Steps

1. 1

   Analyze the Kerberos ticket request pattern

   Pull all Event ID 4769 (TGS ticket request) events from the suspect account. Count the number of unique SPNs requested, the time window, and the encryption type. Normal users rarely request more than 2-3 service tickets in a short period. Kerberoasting tools request tickets for all SPNs with a single command, often 50-200+ requests in seconds.

   SIEM

   Splunk SPLMicrosoft KQLElastic Lucene

   index=windows EventCode=4769 Account_Name="suspect_user" | stats dc(Service_Name) as unique_services, count, earliest(_time) as started, latest(_time) as ended by Account_Name, Ticket_Encryption_Type | eval duration_sec=ended-started

   index=windows EventCode=4769 Ticket_Encryption_Type=0x17 | stats dc(Service_Name) as services_requested, count by Account_Name | where services_requested > 5 | sort -services_requested

   Decision Point

   If: A single account requested TGS tickets for 10+ unique SPNs within minutes, especially with RC4 encryption

   Yes → Confirmed Kerberoasting. The attacker has the ticket hashes and may be cracking them RIGHT NOW. Proceed to assess which service accounts are at risk.

   No → May be legitimate admin activity or service discovery. Verify with the account owner.

2. 2

   Identify which service accounts were targeted

   List all SPNs for which tickets were requested. Map each SPN to its service account. Assess the privilege level of each account; domain admin service accounts are the highest priority. Check password age for each service account; accounts with passwords unchanged for years are most likely to be cracked.

   SIEM

   Splunk SPLMicrosoft KQLElastic Lucene

   index=windows EventCode=4769 Account_Name="suspect_user" | stats count by Service_Name, Service_ID | sort -count

3. 3

   Determine how the attacker gained initial access

   Kerberoasting requires only a valid domain account; investigate how the attacker obtained one. Check for prior phishing, brute force, or credential theft events for the account performing the Kerberoasting. This reveals the full attack chain.

   SIEMXDR

   Splunk SPLMicrosoft KQLElastic Lucene

   index=auth user="suspect_user" | stats count by action, src_ip, app | sort -_time | head 50

4. 4

   Assess if any service account passwords were compromised

   Check for suspicious activity from the targeted service accounts AFTER the Kerberoasting event. If a service account suddenly authenticates from a new source or performs unusual actions, its password was likely cracked. Service accounts with weak passwords can be cracked in seconds to minutes.

   SIEM

   Splunk SPLMicrosoft KQLElastic Lucene

   index=auth user IN ("svc_sql","svc_backup","svc_admin") action=success | where src_ip!="expected_service_host" | table _time, user, src_ip, app, action

5. 5

   Contain and remediate

   Immediately rotate passwords for all targeted service accounts; start with the most privileged ones. Use long, complex passwords (25+ characters) for service accounts. Disable the compromised user account. Consider implementing Group Managed Service Accounts (gMSA) which automatically rotate passwords. Add detection rules for future Kerberoasting attempts.

   SIEM

Common Mistakes

1. 1

   Not checking the encryption type; legitimate Kerberos requests typically use AES (0x12), while Kerberoasting tools often request RC4 (0x17) because it is faster to crack

2. 2

   Resetting only the attacking user account without rotating the targeted service account passwords; the attacker already has the ticket hashes

3. 3

   Not assessing service account privilege levels; a cracked domain admin service account is a complete domain compromise

4. 4

   Assuming service accounts are safe because they have "strong" passwords; many organizations set service account passwords once and never rotate them

Escalation Criteria

• Kerberoasting targeted service accounts with domain admin or equivalent privileges

• Evidence of a targeted service account being used from an unexpected source after the attack

• The Kerberoasting was performed by an account that was itself recently compromised

Frequently Asked Questions

What is Kerberoasting and why is it dangerous?

Kerberoasting lets any domain user request encrypted service tickets for any account with a Service Principal Name. The attacker cracks these tickets offline to get plaintext passwords. It is dangerous because: (1) it requires no special privileges, (2) it generates minimal noise, (3) the cracking happens offline where you cannot detect it, and (4) service accounts often have domain admin access.

How quickly can Kerberos tickets be cracked?

With modern GPUs, RC4-encrypted Kerberos tickets with weak passwords (8-12 characters) can be cracked in minutes to hours. Service accounts with complex 25+ character passwords may take years. This is why password length and complexity for service accounts is critical; and why Managed Service Accounts with automatic rotation are the best defense.

How do I practice Kerberoasting investigations?

SOCSimulator includes Active Directory attack scenarios featuring Kerberoasting, credential harvesting, and privilege escalation. Practice detecting these attacks in SIEM logs. Start free forever.