Lesson 41 — Building an Incident Timeline
The incident contains the alerts.
The entities give you the pivots.
But neither automatically tells you what happened first.
That is the job of the timeline.
What you will learn
Reconstruct incident activity in the order it actually happened.
Learning objectives
- Explain why chronology matters during incident investigation.
- Use the Sentinel incident timeline as an investigation starting point.
- Distinguish detection time from the time suspicious activity actually occurred.
- Add alerts, bookmarks, entity activity and raw telemetry to a working timeline.
- Use KQL to reconstruct activity before, during and after a detection.
- Separate confirmed events from analyst interpretation.
The question changes
Lessons 39 and 40 asked:
What do the alerts say?
Which entities are involved?
Now ask:
What happened, and in what order?
Why build a timeline?
Security evidence rarely arrives in perfect chronological order. One detection might identify activity that happened several minutes earlier. Another alert might be created later but describe the beginning of the attack.
The order alerts arrive is not necessarily the order the attack happened.
Sentinel already gives you a starting timeline
Microsoft Sentinel's incident timeline brings alerts and hunting bookmarks together chronologically. Analysts can select individual items to inspect their details and use that ordered view to begin reconstructing attacker activity.
But the incident timeline is not the whole story
An incident only contains the evidence that has been associated with it.
Important activity may exist before the first alert, between alerts or after the final detection. The analyst must investigate those gaps.
The Agent Foskett timeline workflow
Creation time is not always activity time
An alert has timestamps associated with its creation and the activity it represents. Do not assume the moment the alert appeared is the moment the attacker acted.
Always determine which timestamp answers your investigation question.
Start earlier than the first alert
If the first alert occurred at 02:14, query the preceding period.
The attacker may have authenticated, enumerated resources, created persistence or staged execution before any detection fired.
Build a working timeline table
| Time | Event | Entity | Source | Confidence |
|---|---|---|---|---|
| 01:57 | Successful sign-in from unusual IP | alex@contoso.com | SigninLogs | Confirmed event |
| 02:03 | Session activity begins | alex@contoso.com | Identity telemetry | Confirmed event |
| 02:08 | Suspicious mailbox rule created | alex@contoso.com | Alert + audit data | Confirmed |
| 02:14 | PowerShell process launched | DEVICE-27 | Endpoint telemetry | Confirmed event |
| 02:17 | Connection to suspicious infrastructure | DEVICE-27 | Network telemetry | Confirmed event |
Evidence first
Write what the evidence demonstrates.
Good: “PowerShell executed on DEVICE-27 at 02:14.”
Too early: “The attacker used PowerShell at 02:14.”
Interpretation second
Once events are ordered, you can begin testing explanations for how they relate.
Keep interpretation clearly separate from observed facts so another analyst can reproduce your reasoning.
Use bookmarks as preserved evidence
Sentinel's incident timeline can include hunting bookmarks as well as alerts. A bookmark can preserve an important query result that did not generate an alert but belongs in the attack story.
Your alert begins at 02:08, but hunting finds a suspicious successful sign-in at 01:57. Preserve the event as investigation evidence and place it into the chronology.
Entity timelines fill gaps
A user or device timeline can reveal activity beyond the alerts already attached to the incident.
Look for authentication, process, network and other relevant activity surrounding the known events.
Different entities tell different parts
The user's timeline may explain initial access.
The device timeline may reveal execution.
An IP or cloud-resource timeline may expose additional scope.
Use KQL to reconstruct the evidence window
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
SigninLogs
| where UserPrincipalName =~ "alex@contoso.com"
| where TimeGenerated between (
datetime(2026-10-07 01:30:00) ..
datetime(2026-10-07 02:30:00)
)
| project TimeGenerated, UserPrincipalName, IPAddress,
AppDisplayName, ResultType, ConditionalAccessStatus
| order by TimeGenerated asc
The query deliberately starts before the first known suspicious event and ends after it. The goal is to find the surrounding sequence, not merely reproduce the alert.
Expand the time window deliberately
Do not automatically query seven days of data when the question concerns a ten-minute sequence.
Start with a focused window. Expand it when the evidence gives you a reason.
Use the same clock
When combining evidence from multiple sources, confirm how timestamps are represented and displayed.
A timeline is only useful when events are being compared consistently.
Look between the alerts
The spaces between detections are often where the investigation becomes interesting.
Ask “what happened immediately before?”
Before a suspicious process: which user logged on? Which parent process launched it? Was a file downloaded?
Before a mailbox rule: was there a new sign-in or token event?
Ask “what happened immediately after?”
After execution: did the device make a network connection? Was another process created? Did the same user appear elsewhere?
The next event can explain the purpose of the previous one.
Alert chronology versus attack chronology
| Alert chronology | Attack chronology |
|---|---|
| Orders detections by alert time | Orders underlying activity by event time |
| Useful for understanding what the SOC saw | Useful for understanding what actually happened |
| May contain gaps | Uses additional telemetry to fill gaps |
| Platform-generated | Analyst-reconstructed |
Do not force the story
If the evidence does not explain the gap between two events, leave the gap visible.
“Unknown” is better than inventing a connection because it makes the timeline look complete.
Mark confidence
A useful working timeline can distinguish confirmed events, strong correlations and analyst hypotheses.
This makes handover and escalation far easier to defend.
A timeline should change as evidence changes
Your first chronology is provisional. New entity pivots, bookmarks, alerts and raw events can move the apparent beginning of the incident earlier or extend the known activity later.
Sentinel and Defender portal
Microsoft is moving Sentinel operations into the Defender portal, and incident experiences continue to evolve.
The durable skill is not memorising one timeline widget. It is learning to reconstruct chronology from alerts, entities and underlying events.
Activities are a different timeline
Do not confuse attacker activity with the incident activity log.
The activity log records analyst and automated actions taken on the incident. That is valuable for case management, but it answers a different question: what did the SOC do?
Two timelines, two questions
| Investigation / attack timeline | Incident activity log |
|---|---|
| What happened in the environment? | What happened to the case? |
| Alerts, bookmarks and telemetry | Manual and automated incident actions |
| Used to reconstruct attacker activity | Used for accountability and case history |
| Supports technical conclusions | Supports operational auditing and handover |
Common mistake — start at the first alert
The first alert is merely the first detection currently visible.
Always test whether relevant activity occurred earlier.
Common mistake — sort by alert creation
Detection order can distort the attack story.
Use the timestamps of the underlying events whenever you are reconstructing activity.
Common mistake — mix facts and conclusions
Do not write assumptions into the timeline as though they are observed events.
Label hypotheses clearly.
Common mistake — ignore quiet periods
A gap can be meaningful.
It may represent missing telemetry, delayed execution, persistence or simply no activity. Investigate before deciding.
Agent Foskett investigation exercise
Your incident contains three alerts: suspicious mailbox activity at 02:08, PowerShell at 02:14 and a malicious network connection at 02:17. The affected identity is alex@contoso.com and the endpoint is DEVICE-27.
- Put the known events into chronological order.
- Choose a sensible time window to investigate before 02:08.
- Identify which user and device telemetry you would query.
- Add a newly discovered 01:57 suspicious sign-in to the working timeline.
- Explain whether the sign-in proves the later endpoint activity was performed by the same attacker.
- Identify one gap that still needs investigation.
- Write one confirmed fact and one hypothesis from the timeline.
Best practices
- Start with the incident timeline, but do not stop there.
- Use event time when reconstructing attacker activity.
- Investigate before and after important detections.
- Add relevant bookmark and entity evidence.
- Use focused KQL windows to fill gaps.
- Keep confirmed facts separate from interpretation.
- Leave unexplained gaps visible.
- Update the chronology when new evidence appears.
Agent Foskett takeaway
An incident is a collection of evidence.
A timeline turns that evidence into sequence.
Do not ask only what alerted. Ask what happened before it, what happened after it, and whether the evidence proves the connection.
Related Agent Foskett learning
Continue learning
Building a Microsoft Sentinel Incident Timeline
Building an incident timeline in Microsoft Sentinel helps security analysts reconstruct attacker activity from alerts, hunting bookmarks, entities and raw telemetry. A strong timeline distinguishes alert creation from underlying event time and investigates activity before, between and after known detections.
Microsoft Sentinel Lesson 41
This Agent Foskett Microsoft Sentinel Academy lesson teaches analysts how to build an evidence-based incident chronology, use KQL to investigate gaps, combine identity and endpoint activity, distinguish attack chronology from incident management activity and separate confirmed evidence from analyst hypotheses.
