Detecting and Stopping Kerberoasting in Active Directory

Kerberoasting is one of the quietest ways an attacker turns a single low-privileged account into full domain compromise, and because it abuses Kerberos exactly as designed, it often generates no obvious alert. The good news: it is very detectable and very preventable once you know where to look. This is a blue-team guide to finding your exposure, spotting the attack, and closing it, with the commands to do each.

How Kerberoasting works, in one paragraph

Any authenticated domain user can request a Kerberos service ticket (TGS) for any account that has a Service Principal Name (SPN). Part of that ticket is encrypted with the service account's password hash. The attacker requests tickets for service accounts, exports them, and cracks them offline, no further contact with your domain controllers needed. If a service account has a weak password, it falls in minutes, and service accounts are often over-privileged. The technique is standard knowledge and built into tools like Rubeus and Impacket's GetUserSPNs; your job is to make it fail.

Step 1: find your own exposure

Start by listing the accounts that are roastable, user accounts with an SPN set, and flag the risky ones. Run this on your own domain:

PowerShell (ActiveDirectory module)

# List user accounts that have an SPN (these are Kerberoastable)
Get-ADUser -Filter {ServicePrincipalName -like '*'} -Properties ServicePrincipalName,PasswordLastSet,msDS-SupportedEncryptionTypes |
  Select-Object SamAccountName,PasswordLastSet,msDS-SupportedEncryptionTypes,ServicePrincipalName |
  Sort-Object PasswordLastSet | Format-Table -Auto

# Flag accounts still allowing weak RC4 tickets (value is null, 0, or 4)
Get-ADUser -Filter {ServicePrincipalName -like '*'} -Properties msDS-SupportedEncryptionTypes |
  Where-Object { -not ($_.'msDS-SupportedEncryptionTypes' -band 0x18) }

The accounts with the oldest PasswordLastSet and RC4 still enabled are your highest risk. A service account with a ten-year-old, human-chosen password is a gift to an attacker.

Step 2: detect the attack

Kerberoasting shows up as a burst of TGS requests (Event ID 4769), especially ones requesting weak RC4 encryption (ticket encryption type 0x17). Enable Kerberos service-ticket auditing on your domain controllers, then hunt. In Microsoft Sentinel or Defender (KQL):

KQL (Sentinel / Defender)

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == '0x17'          // RC4 - legacy and suspicious
| where ServiceName !endswith '$'                // ignore machine accounts
| summarize Requests=count(), Services=make_set(ServiceName) by Account, bin(TimeGenerated, 1h)
| where Requests > 10                             // one user, many service tickets, fast
| order by Requests desc

The same idea in Splunk:

Splunk SPL

index=wineventlog EventCode=4769 Ticket_Encryption_Type=0x17
| search Service_Name!="*$"
| stats count dc(Service_Name) as unique_services by Account_Name, _time
| where count > 10

A single user account requesting service tickets for many different services in a short window, particularly with RC4, is the signature. Legitimate applications request the same few SPNs steadily; roasting is bursty and broad.

Step 3: shut it down

Detection buys you time; hardening removes the vulnerability. Three moves do most of the work.

Kill weak passwords. Service-account passwords should be long and random, 25+ characters. At that length, offline cracking becomes impractical even if a ticket is stolen. The cleanest way to guarantee that is to stop managing the passwords by hand.

Use group Managed Service Accounts (gMSA). A gMSA has a 120-character password that Active Directory rotates automatically. It is the single best defense against Kerberoasting.

PowerShell

# Create a gMSA with an automatically managed, uncrackable password
New-ADServiceAccount -Name svc-app01 -DNSHostName svc-app01.corp.example.com -PrincipalsAllowedToRetrieveManagedPassword 'AppServers'
# Then install it on the host that runs the service:
Install-ADServiceAccount -Identity svc-app01

Disable RC4. Force AES-only Kerberos for service accounts so tickets cannot be requested in the weak, fast-to-crack format:

PowerShell

# Require AES128/AES256 and drop RC4 for a service account
Set-ADUser svc-legacyapp -KerberosEncryptionType AES128,AES256

Finally, apply least privilege: most service accounts do not need to be in Domain Admins or any privileged group. Even if one is cracked, tiering limits what the attacker gains.

Bringing it together

Enumerate your SPN accounts, retire weak passwords to gMSAs, disable RC4, and stand up detection on Event 4769 with a honeytoken for high-fidelity alerts. Do that, and Kerberoasting goes from a silent path to Domain Admin to a dead end that trips your alarms. Want us to validate it against a real assumed-breach scenario? That is core to our internal network penetration testing and ransomware risk assessments, get in touch.