← 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

Place Events on the Computer That Knows the Fact

Map endpoint, resource-server, and domain-controller records so absence on one system is not mistaken for absence everywhere.

In this lesson, you will learn to:

  • Predict the likely recording location for logon and account-logon evidence.
  • Distinguish an absent event from an uncollected, unaudited, overwritten, or mis-scoped event.

Place Events on the Computer That Knows the Fact

Shows how audit subcategories and event placement shape the available evidence, with special attention to success, failure, and collection gaps.

Follow the fact to the system that records it

Windows separates Logon/Logoff auditing from Account Logon auditing. The target workstation or server records creation of a local logon session. A domain controller records domain credential validation or ticket requests because it is authoritative for those facts. For an interactive sign-in to a workstation, the workstation can record 4624 while a domain controller records related Kerberos events. For access to a file share, the file server records a network logon even though the user acted from another device.

Draw a topology before querying: source device, target resource, domain controller, and collection platform. Then list the expected event family at each point. Event 4648 can show a process attempted a logon with explicit credentials; it does not by itself show that the target accepted them. Event 4672 can show special privileges assigned to a new logon; it should be linked through the local Logon ID. Event 4634 or 4647 may describe session ending, but missing logoff data is common and session duration should not be invented from a lone start event.

Authentication evidence is distributed across systemsSource device, target server, domain controller, and collector each know different facts about the same attempted access.FIELD GUIDEAuthentication evidence is distributed across systemsInvestigationSource deviceTarget serverDomain controllerCentral collectorTELEMETRY NETWORK
Authentication evidence is distributed across systems — Source device, target server, domain controller, and collector each know different facts about the same attempted access.

Audit the collection path before judging the activity

Before interpreting absence, verify the audit policy, event channel, host clock, time-zone normalization, forwarder health, filtering rule, ingestion delay, retention window, and whether the system was online. A central platform can normalize fields or drop XML details; preserve the raw event when a field changes the conclusion. Duplicate collection can also make one activity look like several. Use provider, channel, computer, EventRecordID, and timestamp to recognize repeated copies.

Failed logons require the same discipline. Status and substatus values can distinguish unknown accounts, bad passwords, disabled accounts, restrictions, and other conditions, but local policy and event version matter. A burst of 4625 events on a server may be a stale service password, a user mistake, discovery, or password spraying. Identify the account distribution, source distribution, targets, timing, logon types, and subsequent successes. A failure count without denominators or baseline is not a severity assessment.

A Windows event is a structured claim with collection contextProvider, computer, event ID, time, subject, target, logon type, status, and source fields must be read together.FIELD GUIDEA Windows event is a structured claim with collectioncontextProvider andhostFIELD 1Time and recordIDFIELD 2Subject andtargetFIELD 3Type andpackageFIELD 4Source andstatusFIELD 5CHECKPOINTS1Provider andhost2Time and recordID3Subject andtargetEVENT ANATOMY
A Windows event is a structured claim with collection context — Provider, computer, event ID, time, subject, target, logon type, status, and source fields must be read together.

Resources

← Previous: From Credentials to a Windows Logon Session Next: Reconstruct Kerberos Ticket Activity →