Detecting and Mitigating Kerberoasting (T1558.003)

Kerberoasting works because Kerberos is generous. Any user with a valid ticket-granting ticket can ask a domain controller for service tickets, and part of each ticket is encrypted with a key derived from the service account's password. Take that data offline and guess passwords at your leisure. Kerberoasting (T1558.003) is a Windows Credential Access technique and a subtechnique of Steal or Forge Kerberos Tickets.

How attackers use it

MITRE explains that service principal names (SPNs) uniquely identify each instance of a Windows service, and Kerberos requires each SPN to be associated with at least one service logon account.

An adversary with a valid ticket-granting ticket may request service tickets for any SPN from a domain controller. Portions of these tickets may be encrypted with RC4, meaning the Kerberos 5 TGS-REP etype 23 hash of the service account is the private key. That makes the ticket vulnerable to offline brute force. The same can be done with service tickets captured from network traffic.

Cracked hashes can enable Persistence, Privilege Escalation and Lateral Movement through access to Valid Accounts. The attacker never needs to touch the service itself, and the requests look like ordinary Kerberos traffic.

How to detect it

MITRE's analytic focuses on Windows event ID 4769, the Kerberos service ticket request:

• Requests with RC4 encryption, shown as etype 0x17.
• Accounts requesting an unusually large number of service tickets in a short period.
• Service accounts targeted outside their normal usage baselines.
• Suspicious process activity that correlates with Kerberos ticket anomalies, such as a process accessing LSASS.

A single user asking for tickets to dozens of unrelated services in a minute is a good starting rule. Pair it with an inventory of accounts that have SPNs, so you know which ones are worth protecting first.

Your domain controllers need to log Kerberos service ticket operations for event 4769 to exist. Check that before you write the rule.

Building the detection step by step

A rule that fires on every service ticket request will drown you. Build it up in layers.

1. Start with volume per account. Count service ticket requests (event 4769) per requesting account per five minutes. Real users ask for a handful of services. A script that works through every service principal name asks for many.
2. Add the encryption type. Filter to RC4, shown as etype 0x17. If your domain mostly uses AES, RC4 requests are rare and the filter is sharp. If many applications still need RC4, the filter is noisy until you migrate them.
3. Add the target. Flag requests for accounts that have never been requested by that user before, or for service accounts that hold privileged group membership.
4. Add host context. Correlate with the process on the requesting machine, because MITRE also points to suspicious activity such as LSASS access around the same time.

Keep a list of known scanners and vulnerability tools that legitimately request many tickets, so the rule starts with a short allowlist.

Why RC4 is the center of this

MITRE explains the weakness in terms of the encryption type. When a ticket is encrypted with RC4, the key is the service account's password hash, and a guess can be tested offline with no further contact with the domain. AES changes what has to be cracked and how long a guess takes. That is why two of MITRE's three mitigations are about passwords and encryption: you cannot stop a domain user from requesting a ticket, so you make the ticket worthless.

If you get a hit

1. Identify the requesting account and the host it came from.
2. List which service accounts the tickets were for.
3. Treat each of those service accounts as potentially exposed. Rotate their passwords, starting with the ones in privileged groups.
4. Review sign-in activity for those service accounts since the time of the requests, looking for logons from hosts they do not normally use.
5. Fix the root cause: shorten the list of accounts with service principal names, move what you can to Group Managed Service Accounts, and enable AES.

How to reduce the risk

MITRE lists three mitigations.

1. Password policies. Service account passwords should be 25 characters or longer, complex, and periodically expire. Consider Group Managed Service Accounts or a password vault, which remove the human-chosen password from the equation.
2. Encrypt sensitive information. Enable AES Kerberos encryption rather than RC4 where possible. This changes the hash an adversary would have to crack.
3. Privileged account management. Limit service accounts to minimal privileges and keep them out of privileged groups such as Domain Administrators. If a service account is cracked, the damage stays small.

Check your own environment

The PowerShell below is read-only and needs the Active Directory module.

# Windows: list user accounts that have service principal names
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName,PasswordLastSet,MemberOf |
  Select-Object SamAccountName,PasswordLastSet,ServicePrincipalName

Review the output against this checklist:

• Which of these accounts are members of privileged groups?
• When were their passwords last changed? Anything older than your policy needs a plan.
• Which could become Group Managed Service Accounts?
• Are you logging event 4769, and can you filter it by encryption type?

Common mistakes

• Alerting on every 4769 event. The volume is enormous and the rule will be switched off within a week.
• Treating the number of tickets as the only signal. A careful adversary can request a few at a time, so also watch which accounts are targeted.
• Rotating the password of one cracked service account and stopping. If one was requested, all of that user's requests are in scope.

Quick check

Sources

• MITRE ATT&CK T1558.003: Kerberoasting