← 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
1. Build the Sign-In Evidence Model

From Credentials to a Windows Logon Session

Trace the path from an authentication attempt to a local session and avoid equating every credential event with an interactive desktop sign-in.

In this lesson, you will learn to:

  • Distinguish authentication from creation of a local logon session.
  • Use account, host, logon type, and Logon ID together when interpreting a sign-in.

From Credentials to a Windows Logon Session

Introduces security principals, authentication packages, logon types, tokens, and the local identifiers used to correlate activity within a host.

Separate identity proof from local session creation

An account name is a claim about a security principal. Authentication is the process that validates material or tickets for that claim. A Windows computer may then create a local logon session and an access token that represents the principal and its group memberships for authorization. These are related steps, but they are not interchangeable. A network access can create a type 3 session on a server without placing the user at that server’s keyboard, while a service can create a type 5 session as part of normal startup.

Start an investigation with five questions: which account, which source, which destination, which logon type, and which authentication package? Add time and result. Event 4624 records a successful logon on the computer that accepted the access and created the session; event 4625 records a failed attempt on the computer where the attempt occurred. The Subject fields can identify the local process or account that reported the event, while New Logon or Account For Which Logon Failed fields describe the target identity. Reading only the first username invites a wrong conclusion.

Authentication and a local logon session are distinct stagesCredentials or tickets are validated before a target host creates a session, token, and authorized resource access.FIELD GUIDEAuthentication and a local logon session are distinctstagesDECISION CUEIdentityclaimAccess tokenIdentityclaimCredentialor ticketValidationLogonsessionAccess tokenRESPONSE CHAIN
Authentication and a local logon session are distinct stages — Credentials or tickets are validated before a target host creates a session, token, and authorized resource access.

Treat identifiers as scoped correlation keys

A hexadecimal Logon ID links events that refer to the same local logon session on one computer. It is not a globally unique user-session identifier, and the same-looking value on another host does not imply the same session. Correlate it with computer name, time, account SID, logon type, source fields, and authentication package. Process IDs are also host- and time-scoped and can be reused. When available, durable identifiers such as a Sysmon Process GUID or platform session identifier reduce ambiguity but still require their documented scope.

Account names can be renamed, formatted differently, or represented as user principal names, domain-qualified names, machine accounts ending in a dollar sign, and well-known service identities. Prefer SIDs and device identifiers where the source reliably supplies them, but do not assume resolution is complete. A 4624 proves the recorded logon succeeded; it does not prove the person named in a ticket was physically present, that all later activity was authorized, or that the session caused an alert seen elsewhere.

A Logon ID belongs inside a host and time boundaryAccount SID, computer, logon type, time, and local Logon ID combine into a usable correlation key.FIELD GUIDEA Logon ID belongs inside a host and time boundaryLocal Logon IDAccount and SIDHost and logon typeTime and protocolCHECKPOINTS1Local Logon ID2Account and SID3Host and logontypeSESSION RINGS
A Logon ID belongs inside a host and time boundary — Account SID, computer, logon type, time, and local Logon ID combine into a usable correlation key.

Resources

  • Microsoft event 4624 reference — Use the field and logon-type reference for successful logons, including source, target, authentication, and linked-session data.
Next: Place Events on the Computer That Knows the Fact →