Windows Authentication Evidence

Separate proof from session creation

A domain controller may validate identity while a member host creates the local session. Collect from the system that records each fact. A successful local logon event does not by itself identify the complete remote authentication path.

Draw the topology first: source device, target workstation or server, domain controllers, application, and collection platform. Then list which component can observe credential validation, ticket issuance, network access, and local session creation. A Windows 4624 event describes a logon on the recording host; it does not automatically prove where the user sat or which domain controller participated. Preserve the logon type, authentication package, source fields, target account, and host.

Respect identifier scope

Logon IDs, process IDs, ticket identifiers, account names, and source addresses have different scopes and reuse rules. Record host, boot or session context, time, and protocol before joining events.

A local Logon ID can connect events on one host but is not a global session identifier. Process IDs can be reused after termination; names can collide across local and domain accounts; NAT, proxies, and remote-desktop hosts can obscure the original client. Prefer provider-created stable identifiers when available and record every join key. Treat a relationship based only on matching names and close timestamps as inferred, not equivalent to an explicit session link.

Follow Kerberos sequences

Kerberos investigations connect ticket requests, service tickets, validation, destination access, encryption types, and account context. Missing expected events may reflect collection, caching, forwarding, or a different protocol rather than maliciousness.

Start with the account, service principal, client, domain controller, destination, and bounded time. Distinguish a ticket-granting ticket request from a service-ticket request and from the destination’s local access event. Caching means a user may access another service without a fresh initial authentication. Investigate unusual services, encryption choices, delegation, ticket lifetime, and failures in context; administrative tools, legacy systems, and service accounts can produce uncommon but legitimate sequences.

Interpret NTLM in context

NTLM records can show validation and account context while omitting the full application path. Investigate why the protocol was selected, whether fallback is expected, and how the source and destination roles affect interpretation.

NTLM use may arise from local accounts, applications that do not support Kerberos, name or trust problems, IP-based access, or deliberate downgrade and relay conditions. Identify the target resource, account authority, workstation fields, validation system, and application. A protocol choice is an investigation lead, not a verdict. Compare with the host’s role and known legacy dependencies, then look for related access, privilege, process, and network evidence.

Build a bounded authentication timeline

Start with one identity and event, then expand through stable relationships and a bounded time window. Compare alternatives, baseline the relevant role, and apply source evaluation and corroboration before raising confidence.

Separate credential validation, session creation, privilege assignment, explicit credential use, network share access, remote desktop activity, and session ending. Add device inventory, VPN, identity-provider, endpoint, application, and network evidence only through documented joins. State whether the sequence shows an attempt, successful proof, local session, resource access, or consequential action. Missing logoff events are common, so do not invent session duration from a lone start. When clocks or collection delays differ, preserve both source and ingestion times and describe the uncertainty instead of forcing an exact sequence.