3. Investigate and Make the Decision

Build a Cross-Host Authentication Timeline

Join failures, tickets, successes, privileges, processes, and resource access while preserving source-specific time and identifier limits.

In this lesson, you will learn to:

  • Normalize and correlate authentication records from several systems.
  • Use sequence and corroboration to distinguish access attempts from successful and impactful activity.

Build a Cross-Host Authentication Timeline

Provides a repeatable timeline method and worked reasoning pattern for suspicious remote access and service-account activity.

Start narrow and expand through stable entities

Choose an anchor event and a narrow time window. Preserve the raw timestamp and record source, then normalize a working timeline to UTC. Add account SID and name, source and target computers, domain controller, event ID, result, logon type, authentication package, local Logon ID, source address, workstation name, and relevant process. Keep “not present” separate from “not collected.” Expand the window only when a defined question requires earlier credential activity or later resource impact.

Pivot by stable entity combinations rather than one string: account plus source device, account plus target, source plus failure pattern, service principal plus client, or local Logon ID plus host. Link 4768 and 4769 on a domain controller to 4624 on a target only when time, account, client, service, and network evidence are compatible. Add 4672 for assigned special privileges, 4648 for explicit credential attempts, process creation for the initiating program, and file, share, remote-management, or application logs for actual use. The timeline should show claims and gaps, not force every row into a single session.

Test the sequence against competing explanations

Test at least two explanations. For example, “an administrator used an approved remote-management tool” and “stolen credentials were used for lateral movement” predict different source devices, processes, targets, times, and change records. Seek evidence that would disconfirm the leading explanation. A successful type 3 logon followed by no resource activity can still matter, but it is different from a privileged session that creates a service or accesses sensitive data.

Sequence changes meaning. Distributed failures across many accounts followed by one success can support password-spraying concern. Repeated failures for one service account after a password rotation usually predict a specific scheduled system. A new Kerberos service ticket from the normal workstation during the user’s workday is less unusual than the same request from a server the user never uses. Document clock uncertainty and ingestion delay when ordering close events. End with the earliest supported access, latest observed impact, affected entities, and explicit boundaries of the data searched.

Resources

  • Microsoft Audit Logon overview — Use the audit-subcategory overview to locate success, failure, explicit-credential, and related logon records on the accessed computer.