Log Dejargonizer

Windows Security Log · Event 4769

Event 4769: A Kerberos service ticket was requested

An account asked for a ticket to reach a specific service. It is the single best detection for Kerberoasting — because the ticket is encrypted with the service account's password, and anyone who can request one can attack that password offline, undetected.

Also written as Event ID 47694769 kerberoastingservice ticket request

What it means for you

On a personal computer

This only appears on Windows Server domain controllers in a business network.

For an analyst

The key insight is that requesting a service ticket is a normal, unprivileged action — any authenticated account can ask for a ticket to any service. The ticket is encrypted with the service account's password hash, so the attacker takes it away and cracks it offline with nothing further touching your network. Detection therefore has to happen here, at the request, because nothing later will show it.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
A Kerberos service ticket was requested.

Account Information:
  Account Name:   jbrooks@CORP
  Account Domain: CORP
  Logon GUID:     {a1b2c3d4-0000-0000-0000-00000000abcd}

Service Information:
  Service Name:   svc-sqlprod
  Service ID:     CORP\svc-sqlprod

Network Information:
  Client Address: ::ffff:192.0.2.44
  Client Port:    50914

Additional Information:
  Ticket Options: 0x40810000
  Ticket Encryption Type: 0x17
  Failure Code:   0x0

The fields that decide it

Everything else in the log line is context.

ServiceName
The service the ticket was for. Accounts with a Service Principal Name are the roastable ones.
  • An account name rather than a computer nameA user account with an SPN — exactly what Kerberoasting targets, because user account passwords are usually weaker than machine account passwords.
  • A name ending in $A computer account. Machine passwords are long and random, so these are not practically crackable.
  • krbtgtThe ticket-granting service itself. A service ticket request for krbtgt is unusual and worth reading.
TicketEncryptionType
The encryption used. The field that decides whether this is interesting.
  • 0x12AES256. The modern default.
  • 0x11AES128. Also fine.
  • 0x17RC4-HMAC. Weak and far cheaper to crack offline — deliberately requested during Kerberoasting.
  • 0xffffffffAn unknown or unsupported type, which some tooling produces.
TargetUserName
The account requesting the ticket.
IpAddress
Where the request came from. Real network data, often IPv6-mapped.
Status
0x0 for success. Failures here usually mean the service does not exist or access was refused.

Ordinary reasons this happens

Most of the time it is one of these.

  • Every access to a networked service in the domain — file shares, databases, web applications, mail.
  • Computer accounts requesting tickets constantly as part of normal operation.
  • Ticket renewal throughout a working day.
  • Legacy applications that genuinely require RC4 encryption.
  • Monitoring and backup tooling connecting to services on a schedule.

When it is not ordinary

Kerberoasting.

What gives it awayOne account requesting RC4 tickets for many different service accounts in a short window. The breadth is the signal — a normal user needs a handful of services, not dozens.

ATT&CK T1558.003

Targeted roasting of one high-value service account.

What gives it awayA single RC4 request for a privileged service account from a source that has never used that service.

ATT&CK T1558.003

Silver ticket use.

What gives it awayService ticket use with no corresponding 4768 ticket-granting ticket request, because the ticket was forged rather than issued.

ATT&CK T1558.002

Service enumeration before an attack.

What gives it awayRequests across many services from one account, whether or not they succeed.

ATT&CK T1046

What to do next

  1. Filter to TicketEncryptionType 0x17 and exclude service names ending in $. Machine accounts are not the target.
  2. Count distinct ServiceName values per requesting account in a short window. Breadth is the strongest single indicator.
  3. Check whether the requesting account normally uses those services at all.
  4. Correlate with 4768 from the same source — Kerberoasting usually follows a normal sign-in.
  5. Audit which accounts have Service Principal Names, and whether their passwords are long enough to survive offline attack.
  6. For any account you find is roastable and privileged, treat the password as the finding regardless of whether an attack has happened.

Queries to run

kql The core Kerberoasting detection: one account requesting RC4 tickets for many distinct service accounts. Tune the threshold to your environment. 
SecurityEvent | where EventID == 4769 and TicketEncryptionType == '0x17' | where ServiceName !endswith '$' and ServiceName != 'krbtgt' | summarize services = dcount(ServiceName), requests = count() by TargetUserName, IpAddress, bin(TimeGenerated, 30m) | where services > 5 | order by services desc
kql Which service accounts are receiving RC4 tickets at all. Fix those before worrying about detection. 
SecurityEvent | where EventID == 4769 and TicketEncryptionType == '0x17' and ServiceName !endswith '$' | summarize count() by ServiceName | order by count_ desc
powershell Every roastable account in the domain. A privileged account on this list with an old, short password is the actual vulnerability. 
Get-ADUser -Filter { ServicePrincipalName -like '*' } -Properties ServicePrincipalName, PasswordLastSet, MemberOf | Select-Object SamAccountName, PasswordLastSet, ServicePrincipalName
sigma Starting point. Aggregation by distinct service count matters more than any single event. 
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'
  filter:
    ServiceName|endswith: '$'
  condition: selection and not filter

Common questions

What is Kerberoasting?

Any authenticated account can request a service ticket for any service in the domain, and that ticket is encrypted with the service account's password. An attacker requests tickets for accounts that have a Service Principal Name, takes them away, and cracks the passwords offline. Nothing further touches your network, so the request itself is the only thing you can detect.

Why does encryption type 0x17 matter in Event 4769?

0x17 is RC4, which is dramatically cheaper to crack offline than AES. Attackers request it deliberately for that reason. A service account that normally receives 0x12 suddenly receiving 0x17 is the downgrade step of the attack, and it is usually the clearest single indicator you will get.

How do I stop Kerberoasting?

Detection helps, but the real fix is making the passwords uncrackable. Use Group Managed Service Accounts where you can — their passwords are long, random, and rotate automatically. Where you cannot, give service accounts passwords of 25 characters or more, and disable RC4 in the domain once you have confirmed nothing legitimately needs it.

What is the difference between Event 4768 and Event 4769?

4768 is the initial ticket-granting ticket request — authentication itself. 4769 is a request for a ticket to a specific service, which happens afterwards and repeatedly. Kerberoasting shows up in 4769, because that is where the service account's password is used as the encryption key.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026