Event ID 4769: A Kerberos service ticket was requested

Event 4769 lives in the Audit Kerberos Service Ticket Operations subcategory and generates only on domain controllers, once per Ticket Granting Service request that reaches the KDC. A user already holds a TGT from the AS exchange; the moment that user (or their machine, or a service running as them) wants to talk to a file share, a SQL instance, an HTTP endpoint or a print server, the Kerberos client presents the TGT and asks the KDC for a service ticket scoped to that target's service principal name. That request is what 4769 records, success or failure. On failure the Status field carries a non-zero Failure Code.

The volume consequence is the thing to internalize first. Every mapped drive reconnect, every Group Policy refresh, every Exchange or SharePoint call, every SCCM check-in and every SMB session a workstation opens generates one of these. A mid-sized domain with a few thousand endpoints can write hundreds of thousands of 4769 records per day across its DCs, and the overwhelming majority are computer accounts talking to other computer accounts. Nobody triages 4769 by reading it. You triage it by knowing what normal looks like for your service accounts and alerting on the deviation, which means the baseline is the detection.

Since the January 2025 security update, Windows Server 2016 and later emit an extended version of the event (Version 2) with additional encryption-policy fields: the msDS-SupportedEncryptionTypes value and available keys for the requesting account, the service, and the DC, plus the client's advertised etypes and the session key encryption type. Older DCs still write the original field set. Your parsers need to tolerate both shapes.

Service Name (ServiceName in the XML) is the account or computer for which the ticket was requested, and Service ID (ServiceSid) is its SID. This pair is where the Kerberoasting logic lives. A ticket for a computer account shows a Service Name ending in a dollar sign, for example FS01$. The service key behind it is the machine account password, 120 characters of random data rotated every 30 days by default, which is not crackable in any useful timeframe.

A ticket for a user account with a registered SPN (svc_sql, svc_backup, a gMSA, an application identity someone created in 2016) is a different animal. That ticket is encrypted with a key derived from a human-chosen password, and anyone with a valid domain logon can request it. The offline crack is the attack; the request is the only part you can see. So a 4769 whose Service Name is a user-style account name, not a $-suffixed computer, is the population you care about, and it is a small fraction of total volume once you carve it out.

The krbtgt service name is its own special case. Requests with ServiceName equal to krbtgt are TGT renewals and cross-realm referrals, not service access, and they are extremely common. Filter them with the machine accounts. Service ID shows NULL SID on failure events, so joins on ServiceSid only work on successes.

Account Name (TargetUserName) is the requester in normalized UPN form (user@FULL.DOMAIN), built from the SamAccountName plus the domain, not the actual userPrincipalName attribute. Computer accounts also carry the $ suffix here. Logon GUID lets you tie a DC-side 4769 back to the 4624 or 4648 the target server writes when the ticket is used, which is how you confirm the ticket was actually presented somewhere rather than just requested and cracked.