← Windows Sign-In Evidence: Investigating Authentication Across Hosts
1. Build the Sign-In Evidence Model
From Credentials to a Windows Logon Session Place Events on the Computer That Knows the Fact
2. Interpret Kerberos and NTLM Evidence
Reconstruct Kerberos Ticket Activity Interpret NTLM Validation and Fallback
3. Investigate and Make the Decision
Build a Cross-Host Authentication Timeline Baseline, Escalate, and Document the Finding
2. Interpret Kerberos and NTLM Evidence

Reconstruct Kerberos Ticket Activity

Connect ticket-granting ticket requests, service tickets, and target-host logons without claiming a ticket request equals successful resource use.

In this lesson, you will learn to:

  • Place TGT and service-ticket events in the Kerberos exchange.
  • Correlate ticket evidence with target-host access and account context.

Reconstruct Kerberos Ticket Activity

Explains the Kerberos client, KDC, service-ticket sequence and the evidence generated by 4768, 4769, 4771, and target-host events.

Follow the ticket sequence

In an Active Directory domain, the Key Distribution Center runs on a domain controller. A client first obtains a ticket-granting ticket, then requests a service ticket for a service principal name, and presents that ticket to the target service. Event 4768 records a TGT request on the domain controller. Event 4769 records a service-ticket request. Event 4771 records Kerberos pre-authentication failure in relevant configurations. The target computer may then record 4624 when it accepts access and creates a local logon session.

These records describe adjacent steps, not one indivisible transaction. A 4769 shows that the KDC issued or processed a service-ticket request; it does not prove the client successfully reached the service or used the ticket. Correlate account, client address, service name, ticket options, encryption type, result code, domain controller, and time with target-host and network evidence. Network address fields can be absent, translated, or represented in IPv6 form, so normalize carefully and retain raw values.

Kerberos crosses client, KDC, and service lanesThe TGT request, service-ticket request, ticket presentation, and target logon create evidence at different systems.FIELD GUIDEKerberos crosses client, KDC, and service lanesClientDomain controller /KDCTarget serviceCentral telemetryCHECKPOINTS1Client2Domaincontroller / KDC3Target serviceKERBEROS SWIMLANE
Kerberos crosses client, KDC, and service lanes — The TGT request, service-ticket request, ticket presentation, and target logon create evidence at different systems.

Investigate anomalies in context

Begin with expected behavior. User workstations request many service tickets during ordinary file, web, print, and management activity. Service accounts can request tickets at machine-like schedules. Investigative value comes from deviations: a sensitive service requested by an unusual device, many service principals enumerated rapidly, encryption inconsistent with policy, repeated pre-authentication failures, a disabled account, or a success that follows a suspicious failure pattern.

Do not label every high ticket volume as Kerberoasting or every pre-authentication failure as password guessing. Establish the account type, device role, prior frequency, target sensitivity, and whether related process and network activity exists. Clock skew can break Kerberos and create failures that look unusual. Name-resolution, SPN duplication, or application configuration can cause fallback. Record the most likely administrative explanation and test it against change records, service owners, and baseline. Escalate when ticket behavior aligns with unauthorized access, credential theft evidence, or high-impact targets.

Ticket evidence forms a time-ordered chainTGT issuance, service-ticket request, network contact, target logon, and later activity must be correlated rather than collapsed.FIELD GUIDETicket evidence forms a time-ordered chain4768 TGT4769 serviceticketNetwork contact4624 target logonResource activityCHECKPOINTS14768 TGT24769 serviceticket3Network contactTICKET TIMELINE
Ticket evidence forms a time-ordered chain — TGT issuance, service-ticket request, network contact, target logon, and later activity must be correlated rather than collapsed.

Resources

  • Microsoft event 4768 reference — Use the official TGT request fields, result codes, ticket options, and monitoring guidance when analyzing Kerberos authentication.
← Previous: Place Events on the Computer That Knows the Fact Next: Interpret NTLM Validation and Fallback →