Kerberoasting detection with Event ID 4769

Kerberoasting is quiet. The attacker needs nothing more than a normal domain account. They ask the domain controller for service tickets, and the DC hands them over, because handing out service tickets is its job. Part of each ticket is encrypted with the service account's password hash, so the attacker takes the tickets offline and guesses passwords until one decrypts. No failed logons, no lockouts, nothing on the target server.

The one place it leaves a trace is Event ID 4769 on your domain controllers. The trouble is that 4769 is one of the noisiest events in Active Directory. Every time anyone opens a file share or a SQL connection, a 4769 is written. So Kerberoasting detection with Event ID 4769 is really about filtering: knowing which few fields separate an attacker's request from the thousands of normal ones.

What does Event ID 4769 record?

4769 is "A Kerberos service ticket was requested." It is logged on the domain controller that issued the ticket, under the Kerberos Service Ticket Operations audit subcategory. The fields that matter for Kerberoasting are:

The confusing part is the naming. In 4769, Account Name is the requester, not the target. The account being attacked is the one in Service Name.

Why do attackers ask for RC4 tickets?

A service ticket is encrypted with a key derived from the service account's password. If the ticket uses RC4, that key is the NT hash, and cracking it is fast: a decent GPU tries billions of guesses a second. AES keys are salted and run through thousands of hashing rounds, which makes each guess far slower. So tools like Rubeus and Impacket's GetUserSPNs ask for RC4 where the account allows it.

That gives you the best single signal: a 4769 with encryption type 0x17 for a user-based service account. In a domain that has moved to AES, legitimate RC4 tickets are rare, and each one is worth a look. In an older domain, you will have background RC4 traffic and need the volume patterns below.

How do I filter 4769 down to real Kerberoasting?

I filter in this order. Each step removes most of what's left.

1. Drop computer services. Exclude any ServiceName ending in $, and krbtgt. Computer account passwords are 120 random characters and rotate every 30 days; nobody cracks those.
2. Drop failures. Keep Status 0x0. A failed request gives the attacker nothing to crack.
3. Keep RC4. TicketEncryptionType 0x17. On an older domain, keep this filter but expect to tune it with step 4.
4. Look at volume per requester. A normal user asks for tickets to a handful of services they actually use. A roasting tool asks for every SPN it found, often 10 to 100 different service accounts in under a minute.

Then look at who the requester is. A user from finance requesting tickets for svc_sql, svc_backup, svc_sccm and svc_exchange within thirty seconds is not using those services. Neither is a workstation that has never talked to a database server.

Which 4769 events are usually noise?

• Old applications and appliances that only support RC4: legacy NAS boxes, old Java clients, some printers and scanners. They request RC4 tickets every day for the same one or two services.
• Vulnerability scanners and AD auditing tools that enumerate SPNs on purpose. They look exactly like an attack, so allow-list them by requester account and source IP, and make sure you know when they run.
• Service accounts without AES keys. An account whose password hasn't changed since before the domain reached 2008 functional level has no AES keys at all, so the DC falls back to RC4 for everyone. That is a fix, not a false positive to suppress forever.

Hunting queries for Kerberoasting

First check that the events are being logged on every DC:

auditpol /get /subcategory:"Kerberos Service Ticket Operations"

It needs Success. Then, in PowerShell on a domain controller, count RC4 tickets per requester for the last day:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddDays(-1)} |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}; $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    if ($d.TicketEncryptionType -eq '0x17' -and $d.Status -eq '0x0' -and
        $d.ServiceName -notlike '*$' -and $d.ServiceName -ne 'krbtgt') {
      [pscustomobject]@{ Time = $_.TimeCreated; User = $d.TargetUserName; Service = $d.ServiceName; Ip = $d.IpAddress }
    }
  } | Group-Object User |
  Select-Object Name, Count, @{n='Services'; e={ ($_.Group.Service | Sort-Object -Unique).Count }} |
  Sort-Object Services -Descending

In Microsoft Sentinel, this flags any account that requested RC4 tickets for five or more different services in ten minutes:

SecurityEvent
| where TimeGenerated > ago(1d) and EventID == 4769
| extend Enc = extract(@'<Data Name="TicketEncryptionType">([^<]+)', 1, EventData),
         Result = extract(@'<Data Name="Status">([^<]+)', 1, EventData),
         Svc = extract(@'<Data Name="ServiceName">([^<]+)', 1, EventData)
| where Enc == "0x17" and Result == "0x0"
| where Svc !endswith "$" and Svc !~ "krbtgt"
| summarize Services = dcount(Svc), ServiceList = make_set(Svc, 20)
    by TargetUserName, IpAddress, bin(TimeGenerated, 10m)
| where Services >= 5
| order by Services desc

Five is a starting point. Run it for a week without the threshold, see what normal looks like in your domain, and set the line just above your noisiest legitimate requester.

What should I do when I find it?

1. Find the requester's session. The IpAddress gives you the workstation. Look for the 4624 logon on that host and what ran there (4688 or Sysmon Event ID 1 for Rubeus.exe, powershell with Invoke-Kerberoast, or Python on a host that shouldn't have it). The Windows logon types guide helps here.
2. Treat the requesting account as compromised. Someone ran a tool under it. Reset its password and check where else it logged on.
3. Reset every service account that was requested. Assume the tickets have left the network. Use long random passwords, 25 characters or more; a cracked ticket is only as good as the password behind it.
4. Watch those service accounts. If a password was weak enough to crack before you reset it, the attacker may already have logged on with it. Check failed and successful logons for each one.

How do I stop Kerberoasting?

• Move service accounts to gMSAs where the application supports it. Their passwords are long, random and rotated automatically, which makes roasting pointless.
• For the rest, use 25+ character random passwords and rotate them. Cracking is an offline guessing game; length wins it.
• Set service accounts to AES only (msDS-SupportedEncryptionTypes = 0x18) after you've checked that the application works with AES. Change the password afterwards so the AES keys exist.
• Remove SPNs nobody uses. An SPN left on a user account from an old project is a free target. setspn -Q */* lists them all.
• Plant a honey account. A user account with a believable SPN, a strong password and no real service behind it. Any 4769 for it is an alert with almost no false positives.

FAQ

Is every 4769 with encryption type 0x17 Kerberoasting?

No. Older clients and accounts without AES keys produce legitimate RC4 tickets. The combination that matters is RC4, a user-based service account, and one requester asking for many different services in a short time.

Can Kerberoasting happen without Event ID 4769?

Not against Active Directory. The ticket has to come from a domain controller, and the DC logs 4769 when the audit subcategory is on. If you see nothing, check the audit policy on every DC, not just one.

What is the difference between Kerberoasting and AS-REP roasting?

AS-REP roasting targets user accounts with "Do not require Kerberos preauthentication" set, and shows up as Event ID 4768 with pre-authentication type 0. Kerberoasting targets accounts with an SPN and shows up as 4769.

Do gMSA accounts show up in Kerberoasting results?

They can be requested like any account with an SPN, but their names end in $ and their 240-byte random passwords can't realistically be cracked. That is why the filters above exclude $ accounts.