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.

Ticket Encryption Type (TicketEncryptionType) is the cryptographic suite used for the issued service ticket, and its values are the single most useful triage field on this event:

The reason 0x17 matters: RC4-HMAC keys are the NT hash of the account password, so a cracked RC4 service ticket yields a password guess that hashcat can test at billions of candidates per second. AES tickets use a PBKDF2-derived key with 4,096 iterations and the account name as salt, which slows cracking by orders of magnitude. Kerberoasting tools (Rubeus, Impacket's GetUserSPNs.py, PowerView) therefore ask the KDC for RC4 by advertising only RC4 in their supported etypes, and the KDC obliges if the target account's msDS-SupportedEncryptionTypes still permits it. On the new Version 2 event you see that negotiation directly: the ClientAdvertizedEncryptionTypes field lists only RC4-HMAC-NT while the DC and service both advertise AES. That mismatch is close to a smoking gun.

Microsoft's own guidance is to alert on any Ticket Encryption Type other than 0x11 or 0x12 from Server 2008 onward, and to treat 0x1 and 0x3 as never acceptable. In practice a legacy-heavy domain still has RC4 traffic, which is why the detection below scopes 0x17 to user-account SPNs rather than to everything. Session Encryption Type (SessionKeyEncryptionType) is the separate suite for the session key and uses the same value table.

Ticket Options (TicketOptions) is a 32-bit flag set. The three values you will see almost everywhere are 0x40810010 (Forwardable, Renewable, Canonicalize, Renewable-ok), 0x40810000 (Forwardable, Renewable, Canonicalize) and 0x60810010 (the same plus Forwarded, meaning the ticket came from a forwarded TGT, which is delegation). Anything else is unusual enough to look at. Rubeus and Impacket historically default to 0x40810000, and several published hunts key on 0x40810000 combined with 0x17 as the roasting tuple, though the value alone is legitimate and shows up in Microsoft's own sample event. Treat it as a corroborating field, not a primary one. Transited Services (TransmittedServices) lists the SPNs involved when constrained delegation was used and is otherwise a dash.

Failure events carry a hexadecimal code in Status. The bulk of them are 0x20 (KRB_AP_ERR_TKT_EXPIRED), which Microsoft explicitly labels as informational: the service ticket aged out and renewal is automatic. Suppress it before you count anything. The codes that carry signal:

• 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN: the DC could not find the requested server name. Bursts of this from one client are SPN guessing or a broken script; steady low volume is stale DNS or a decommissioned host.
• 0x6 KDC_ERR_C_PRINCIPAL_UNKNOWN: the requesting user does not exist. Rare on TGS requests because you need a TGT first; investigate if it appears.
• 0xC KDC_ERR_POLICY: logon restrictions on the account (workstation restriction, logon hours, smart card requirement) blocked the ticket. A privileged account tripping this from an unexpected host is worth a look.
• 0xD KDC_ERR_BADOPTION: usually a constrained delegation request for an SPN not in the allowed-to-delegate-to list. Attackers probing delegation paths generate this.
• 0xE KDC_ERR_ETYPE_NOTSUPP: no common encryption type. This is what you see when a client insists on RC4 against an account that only allows AES; it is a Kerberoasting attempt that your hardening blocked. Alert on it anyway.
• 0x1B KDC_ERR_MUST_USE_USER2USER: the service has no SPN registered.
• 0x25 KRB_AP_ERR_SKEW: clock drift beyond the Kerberos tolerance. Operational, but a single host suddenly skewing can be a VM snapshot revert.

Some codes only surface when KdcExtraLogLevel is set on the DC (0x01 for SPN-unknown audits, 0x10 for etype and bad-option audits). If your 0x7 and 0xE counts are zero across the estate, check that registry value before concluding nobody is probing you.

Client Address (IpAddress) is where the TGS request came from, usually in ::ffff:10.0.0.12 form for IPv4. ::1 means the request originated on the DC itself, which means someone was logged on to a domain controller; compare Account Name against your list of accounts permitted to do that. Client Port (IpPort) is the source port; 0 for local requests, and Microsoft recommends examining any value between 1 and 1023 because a well-known port as an outbound source is abnormal for a Kerberos client.

The pivot pattern: take the IpAddress from a suspicious 4769, pull every 4769 from that address in the surrounding hour, and count distinct ServiceName values. A normal workstation talks to a handful of services. A roasting host talks to all of them.

Every query on this page applies the same two exclusions before it does any counting: drop rows where ServiceName ends in $ and drop rows where ServiceName is krbtgt. On a typical domain this removes well over 90 percent of volume and leaves the set of tickets issued for accounts with human-managed passwords, which is the only set Kerberoasting can target. Without those exclusions a "distinct services per client" count is meaningless: a single workstation booting at 08:00 legitimately requests tickets for a dozen computer accounts and krbtgt inside a minute.

A second, softer filter is the requester. Rows where TargetUserName ends in $ are machines requesting tickets on their own behalf (computer-to-computer traffic). Kerberoasting needs a user TGT, so excluding machine requesters trims the population further without losing the attack.

The honest RC4 sources are legacy applications and appliances: Java clients pinned to older Kerberos libraries, NAS devices, printers that joined the domain in 2014, third-party SSO gateways, and accounts whose msDS-SupportedEncryptionTypes attribute was never set after the domain functional level moved past 2008. Those produce 0x17 tickets on a schedule, for the same one or two SPNs, from the same source hosts, every day. Build an allow list of (requester, ServiceName, IpAddress) tuples for them and let the rule see through it.

The malicious shape is different on three axes at once. Breadth: many distinct user-account SPNs requested by one requester inside minutes, often the full list an LDAP query for servicePrincipalName=* returns. Encryption: 0x17 for accounts whose service and DC both advertise AES. Provenance: the requesting IpAddress is a workstation or VPN pool address, not the application server that normally talks to that service, and the Logon GUID never shows up in a 4624 on the target server because the ticket was never presented anywhere. Any one of these is a maybe. Two together is a ticket. All three is an incident.

Two edge cases. First, vulnerability scanners and AD assessment tools (BloodHound collectors, PingCastle, some EDR posture modules) legitimately enumerate SPNs and can look like a roast; know their source hosts. Second, a real attacker who has read the same guidance will request AES tickets and crack them slowly, so an AES-only environment still needs the breadth rule, not just the etype rule.

At 14:12 your Sentinel rule fires: 41 distinct non-$ ServiceName values requested by j.moreno@CORP.LOCAL from ::ffff:10.40.7.118 inside a 90-second window, every ticket 0x17. You pull the raw 4769s. The list reads like an inventory: svc_sql_prod, svc_sccm, svc_backup, svc_sharepoint, svc_vcenter, svc_adfs, and thirty-five more. TicketOptions is 0x40810000 on every row. On the Version 2 records, ClientAdvertizedEncryptionTypes shows only RC4-HMAC-NT while ServiceAvailableKeys says AES-SHA1, RC4 for most targets.

You check 10.40.7.118: a finance analyst's laptop, not a server. EDR shows a PowerShell process spawned from an Outlook child, and a network connection to the DC on 88/tcp at 14:11. No 4624 on any of the 41 target servers references the Logon GUIDs from those tickets, so nothing was accessed yet; the tickets left the building to be cracked. You isolate the host, reset j.moreno's password and TGT, and open a case to rotate the passwords on the seven service accounts whose ServiceAvailableKeys listed RC4, starting with svc_adfs and svc_sql_prod. The rest of the afternoon goes to finding out how the attacker got a shell on a finance laptop, which is a different event ID entirely.