Event ID 4768: Kerberos TGT Requested — Who Authenticated, From Where

What it records

Event 4768 is the Kerberos authentication service writing down a ticket-granting ticket request. Microsoft’s description is blunt about scope: “This event generates every time Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT)” and “This event generates only on domain controllers.” It belongs to the Audit Kerberos Authentication Service subcategory, and the required server role is Active Directory domain controller.

Success and failure share the event ID. The deciding field is Result Code: “If TGT issue fails then you will see Failure event with Result Code field not equal to ‘0x0’.” Microsoft’s table starts at 0x0 (KDC_ERR_NONE, no error) and runs through 0x6 KDC_ERR_C_PRINCIPAL_UNKNOWN, “Client not found in Kerberos database”, whose documented cause is “The username doesn’t exist”, 0x7 for an unknown server principal and 0x8 for duplicate principal entries.

There is one gap you have to know about: “This event doesn’t generate for Result Codes: 0x10 and 0x18. Event ‘4771: Kerberos pre-authentication failed.’ generates instead.” So the classic wrong-password Kerberos failure, 0x18, never appears here — look for it in 4771. Account-state refusals such as 0x12 and 0x17 are not excluded, so they can surface as 4768 failures.

Around the result code sit the identity and network fields: Account Name, Supplied Realm Name, User ID, Service Name (normally krbtgt, and typically krbtgt/REALM_NAME on failures), Client Address and Client Port. Ticket Options is a hexadecimal flag set — Microsoft decodes 0x40810010 as Forwardable, Renewable, Canonicalize, Renewable-ok. Certificate-based requests populate Certificate Issuer Name, Certificate Serial Number and Certificate Thumbprint; Microsoft’s older sample shows them filled in with issuer contoso-DC01-CA-1, while the current sample leaves them empty.

Microsoft also notes an update: “Windows Server 2016 and later OSs will display an updated version of Event 4768 after getting the January 14th, 2025 or later Security Cumulative Update.” The updated version adds encryption-type detail — MSDS-SupportedEncryptionTypes and Available Keys for the account, the service and the domain controller, plus Advertized Etypes and a Response ticket hash.

When it matters

Pattern	Reading
Many failures with Result Code 0x6 from one Client Address	Names that do not exist — account enumeration, the Kerberos cousin of 0xC0000064
Failures with 0x12 for one account	The account itself is barred from logging on
Failures with 0x17 on a service account	Password expired on an identity that should have been rotated under control
No 4768 failures but a run of 4771	Pre-authentication failures (0x18 / 0x10) by design go to 4771
A successful 4768 for a sensitive account from a Client Address it has never used	A TGT was issued to someone at a new location — check the 4624 on the destination
Successful 4768 immediately after a burst of 4771 for the same account	A guessed password that finally worked

How to investigate

Start on the domain controllers with failed TGT requests grouped by source, because one client address touching many account names is the enumeration and spraying shape:

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4768
| where Status !~ "0x0"
| extend ClientIp = replace_string(IpAddress, "::ffff:", "")
| summarize Failures = count(), Accounts = dcount(TargetUserName),
            AccountList = make_set(TargetUserName, 20), Codes = make_set(Status, 10),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by ClientIp, Computer
| order by Accounts desc, Failures desc

Then ask the question that changes severity — did any of those sources get a ticket afterwards?

let badReq = SecurityEvent
    | where TimeGenerated > ago(24h) and EventID == 4768 and Status !~ "0x0"
    | extend ClientIp = replace_string(IpAddress, "::ffff:", "")
    | summarize Failures = count(), LastFail = max(TimeGenerated) by ClientIp, TargetUserName;
SecurityEvent
| where TimeGenerated > ago(24h) and EventID == 4768 and Status =~ "0x0"
| extend ClientIp = replace_string(IpAddress, "::ffff:", "")
| join kind=inner badReq on ClientIp, TargetUserName
| where TimeGenerated > LastFail
| project TimeGenerated, Computer, TargetUserName, TargetDomainName, ClientIp, IpPort,
          ServiceName, TargetSid, Failures
| order by TimeGenerated asc

Novelty is the cheapest anomaly on this event — an account that has never requested a TGT from this address before:

let seen = SecurityEvent
    | where TimeGenerated between (ago(30d) .. ago(1d))
    | where EventID == 4768
    | extend ClientIp = replace_string(IpAddress, "::ffff:", "")
    | distinct TargetUserName, ClientIp;
SecurityEvent
| where TimeGenerated > ago(1d) and EventID == 4768 and Status =~ "0x0"
| extend ClientIp = replace_string(IpAddress, "::ffff:", "")
| join kind=leftanti seen on TargetUserName, ClientIp
| project TimeGenerated, Computer, TargetUserName, TargetDomainName, ClientIp, ServiceName
| order by TimeGenerated asc

Note the limits of the table: PreAuthType, TicketOptions and TicketEncryptionType live only in the event XML, not as SecurityEvent columns, so read those from the raw event on the DC.

From a hit, pivot outward. 4771 on the same DC covers the pre-authentication failures this event omits, 4776 covers NTLM credential validation, 4740 tells you if the account locked out, and 4769 shows which services the resulting TGT was then used to request tickets for. On the destination host, 4624 shows the session the ticket produced and 4672 whether it carried administrator privileges. If the failures look like spraying, the Windows 4625 password-spray rule covers the same grouping on the logon-failure side. Without a SIEM, export the DC Security log as XML from Event Viewer and load it into the free browser log analyzer.