Agent Foskett Academy • SOC Analyst Academy • Module 4 • Lesson 40 • Endpoint Incidents: Following the Attack Chain

Lesson 40 — Building the Complete Endpoint Compromise Timeline

Ten lessons ago, the investigation began with one uncomfortable process relationship:

a browser spawned PowerShell.

Since then, the SOC followed encoded execution, unusual process ancestry, file creation, outbound communication, persistence, possible credential access, movement to another endpoint and finally containment.

Now Agent Foskett had one final job for Module 4:

put every defensible event into one timeline and explain exactly what the evidence says happened.

A strong incident timeline does not merely list alerts. It connects evidence, entities, timestamps and analyst decisions into a sequence another investigator can reproduce.
Agent Foskett reconstructing a complete endpoint compromise timeline
From one process to the whole attack chain

Combine endpoint, file, network, persistence and logon evidence into one chronological investigation record.

✓ Normalise the evidence
✓ Order events chronologically
✓ Separate facts from conclusions
✓ Produce a defensible incident story

Case briefing — the complete chain

10:14:27 Browser spawns PowerShell ↓ 10:14:31 Encoded PowerShell observed ↓ 10:14:38 update-check.exe created ↓ 10:14:45 update-check.exe executes ↓ 10:14:53 External connection begins ↓ 10:15:19 Persistence created ↓ 10:16:02 Unexpected LSASS access ↓ 10:19:11 Account logs on to WS-HR-021 ↓ 10:23:40 Containment decision ↓ 10:25:02 WS-FIN-044 isolated ONE INCIDENT. MULTIPLE TABLES. MULTIPLE ENTITIES. ONE TIMELINE.

Investigation objective

Reconstruct the endpoint compromise in chronological order, preserve the evidence source for each event, identify which conclusions are proven and which remain hypotheses, and produce a handover-quality incident record.

Investigator's rule

The timeline must be reproducible. Another analyst should be able to follow your timestamps and pivots back to the underlying telemetry.

Stage 1 — define the incident window

Start slightly before the first known suspicious event and continue beyond containment. This helps preserve precursor activity and confirms what happened after the response action.

01-incident-window.kql
12345 678910
let IncidentStart = datetime(2026-08-25 10:10:00);
let IncidentEnd   = datetime(2026-08-25 10:35:00);
DeviceProcessEvents
| where Timestamp between (IncidentStart .. IncidentEnd)
| where DeviceName in~ ("WS-FIN-044", "WS-HR-021")
| project Timestamp, DeviceName, AccountName,
          FileName, ProcessCommandLine,
          InitiatingProcessFileName, SHA1
| order by Timestamp asc

Do not start exactly at the alert

The alert may occur after the attack began. Give yourself enough time before the first detection to identify the initiating activity.

Continue after containment

Post-containment telemetry can help validate whether expected activity stopped and whether related entities remained active elsewhere.

Stage 2 — build a process timeline

02-process-timeline.kql
12345 6789101112
DeviceProcessEvents
| where Timestamp between (
    datetime(2026-08-25 10:10:00) ..
    datetime(2026-08-25 10:35:00)
)
| where DeviceName in~ ("WS-FIN-044", "WS-HR-021")
| project Timestamp, DeviceName, AccountName,
          FileName, ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine, SHA1
| order by Timestamp asc

Process ancestry explains causality

The timeline should preserve parent-child relationships where available. Knowing that PowerShell executed is useful; knowing what launched it is much more useful.

Keep hashes with important processes

Hashes allow the same executable to be correlated across file, process and environment-wide hunting results.

Stage 3 — add file and network evidence

03-file-network-evidence.kql
12345 6789101112 1314151617
let TargetHash = "9D0B...E41C";
union
(
    DeviceFileEvents
    | where SHA1 == TargetHash
    | project Timestamp, DeviceName,
              EvidenceType="File",
              Detail=strcat(ActionType, " - ", FolderPath, "\", FileName)
),
(
    DeviceNetworkEvents
    | where InitiatingProcessSHA1 == TargetHash
    | project Timestamp, DeviceName,
              EvidenceType="Network",
              Detail=strcat(RemoteIP, ":", tostring(RemotePort))
)
| order by Timestamp asc

Normalise before combining

Different Advanced Hunting tables have different schemas. Project common fields such as timestamp, device, evidence type and detail before using union.

Do not hide the source table

Your investigation notes should still record where important evidence came from so another analyst can reproduce the query.

Stage 4 — add persistence and credential-access context

PROCESS EXECUTION update-check.exe ↓ NETWORK ACTIVITY external connection ↓ DEVICE EVENT scheduled task created ↓ DEVICE EVENT unexpected LSASS-related activity ↓ IDENTITY RISK INCREASES THE TIMELINE NOW SHOWS BEHAVIOUR, NOT JUST ALERTS.

Use the event actually recorded

Describe persistence and LSASS-related activity using the evidence available in Defender. Do not claim a credential dump or successful theft unless the telemetry supports that conclusion.

Confidence should change with evidence

Early in the incident, compromise may be only a hypothesis. As independent events correlate, the analyst can increase confidence while still documenting uncertainty precisely.

Stage 5 — add account movement

04-account-movement.kql
12345 67891011
DeviceLogonEvents
| where Timestamp between (
    datetime(2026-08-25 10:10:00) ..
    datetime(2026-08-25 10:35:00)
)
| where AccountName =~ "alex.wilson"
| project Timestamp, DeviceName,
          AccountName, LogonType,
          RemoteIP, RemoteDeviceName,
          ActionType
| order by Timestamp asc

The account bridges endpoints

Once the same identity appears on a second device, the timeline must preserve both endpoint and identity context.

Call it possible movement until proven

The sequence may strongly support lateral movement, but the wording of the finding should match the evidence rather than overstate it.

Stage 6 — create the analyst timeline

TimeEntityObserved evidenceAnalyst interpretation
10:14:27WS-FIN-044Browser launched PowerShell.Unusual process ancestry requiring investigation.
10:14:31powershell.exeEncoded command-line content observed.Obfuscation increases suspicion; decode and validate.
10:14:38update-check.exeExecutable created in user-writable path.Potential payload.
10:14:45update-check.exeFile executed seconds after creation.File creation and execution correlate.
10:14:53update-check.exeOutbound connection recorded.Execution now correlates with network activity.
10:15:19WS-FIN-044Persistence mechanism created.Possible attempt to maintain execution.
10:16:02WS-FIN-044Unexpected LSASS-related activity.Possible credential-access behaviour.
10:19:11alex.wilson / WS-HR-021Account logged on to second endpoint.Possible lateral movement; destination requires investigation.
10:23:40WS-FIN-044Containment approved.Evidence sufficient for response action.
10:25:02WS-FIN-044Endpoint isolated.Containment action recorded; investigation continues.

Separate observation from interpretation

This is one of the most important habits in SOC documentation. The event is the fact; your explanation of what it may mean is the interpretation.

Include response actions in the timeline

Containment, identity remediation and recovery decisions are part of the incident history and should be timestamped alongside technical events.

Stage 7 — test the complete story

ASK OF EVERY CONCLUSION: What evidence supports it? ↓ Which table recorded it? ↓ Which entity does it belong to? ↓ What happened immediately before it? ↓ What happened immediately after it? ↓ Is there a legitimate explanation? ↓ Can another analyst reproduce it? IF NOT: THE TIMELINE IS NOT FINISHED.

Challenge your own theory

A good final timeline includes evidence that could weaken the compromise hypothesis, not only evidence that confirms it.

Remove unsupported certainty

Replace statements such as “credentials were stolen” with “possible credential-access behaviour” unless successful extraction or subsequent use is actually demonstrated.

Stage 8 — write the final incident narrative

FINAL INCIDENT SUMMARY At 10:14:27, a browser process on WS-FIN-044 launched PowerShell. Subsequent telemetry showed encoded command activity followed by creation and execution of update-check.exe. The executable then initiated outbound network activity and was associated with creation of a persistence mechanism. Unexpected LSASS-related activity was observed shortly afterwards, increasing concern for possible credential access. At 10:19:11, the affected account alex.wilson authenticated to WS-HR-021. This extended the investigation to a second endpoint and raised the hypothesis of possible lateral movement. Based on the correlated process, file, network, persistence and identity evidence, containment of WS-FIN-044 was approved and the endpoint was isolated. Investigation of WS-HR-021 and the affected identity continued as part of incident scoping.

Stage 9 — produce the handover

Handover itemWhat to include
Incident scopeKnown affected devices, accounts and applications.
Confirmed evidenceProcesses, files, hashes, connections, persistence and logons.
Working hypothesesCredential access, lateral movement or other conclusions not yet fully proven.
Response actionsIsolation, identity actions and other containment steps with timestamps.
Outstanding workRemaining devices, accounts, indicators and validation tasks.

Lesson 40 key takeaways

  • Define an incident window that begins before the first alert and continues beyond containment.
  • Build the process chain before attempting to explain the entire incident.
  • Correlate process, file, network, persistence and logon evidence.
  • Normalise fields when combining evidence from different Advanced Hunting tables.
  • Preserve the source of important evidence so queries remain reproducible.
  • Keep observations separate from analyst interpretations.
  • Use language that matches the confidence supported by the evidence.
  • Include containment and other response actions in the chronology.
  • Challenge the final theory with legitimate alternative explanations.
  • Finish with a handover that states confirmed facts, hypotheses, scope and outstanding work.

Module 4 complete — Endpoint Incidents: Following the Attack Chain

You began Module 4 with a browser spawning PowerShell. You finish it with a complete, evidence-led endpoint compromise timeline spanning execution, file activity, network communication, persistence, credential-access risk, cross-device movement and containment.

Module 4 complete • Lessons 31–40 • Endpoint Incidents: Following the Attack Chain

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

🔎 SOC Analyst Academy — Module 4: Endpoint Incidents: Following the Attack Chain

Module 4 complete — reconstruct the full endpoint attack chain from initial execution through persistence, credential-access risk, movement and containment.

How to build an endpoint compromise timeline in Microsoft Defender XDR

Lesson 40 of the Agent Foskett SOC Analyst Academy teaches analysts how to reconstruct a complete endpoint compromise using DeviceProcessEvents, DeviceFileEvents, DeviceNetworkEvents, DeviceEvents and DeviceLogonEvents.

KQL endpoint incident timeline for SOC analysts

Learn how to correlate execution, file creation, network activity, persistence, possible credential access, lateral movement and containment into a chronological and defensible Microsoft Defender XDR investigation.