Lesson 18 — Building Investigation Timelines
Investigation timelines turn scattered alerts, logs, entities and analyst notes into a defensible chronological attack story.
Security Copilot can help organise identity, endpoint, email, cloud and Sentinel evidence, but the analyst must still normalise timestamps, remove duplicates, identify gaps and challenge unsupported transitions.
This lesson explains how to build technical, handover and executive timelines that clearly show what happened, when it happened and what remains uncertain.
What you will learn
This lesson develops a complete cross-product timeline reconstruction workflow.
Investigation-timeline workflow
↓
Collect identity, email, endpoint, cloud and Sentinel evidence
↓
Normalise timestamps into one stated time zone
↓
Confirm immutable identifiers and source attribution
↓
Remove duplicates and unrelated events
↓
Separate confirmed facts, inference and unknowns
↓
Order the remaining events chronologically
↓
Identify first observed, first detected and latest confirmed activity
↓
Highlight gaps, contradictions and missing visibility
↓
Map supported attack stages
↓
Review with another analyst
↓
Approve the final human-validated timeline
Timeline evidence domains
| Domain | Evidence | Investigation question |
|---|---|---|
| Identity | Sign-ins, MFA, user risk, password and privilege changes. | When did identity compromise begin? |
| Delivery, click, attachment, user report and remediation. | Did the message create the initial access path? | |
| Endpoint | Processes, files, network activity, persistence and containment. | What happened on the device? |
| Cloud | Resource access, deployments, permissions and alerts. | Did the activity reach cloud workloads or data? |
| Sentinel | Workspace logs, analytics, incidents and external sources. | What broader events complete the story? |
| Response | Isolation, token revocation, blocking, remediation and closure. | When was the activity contained? |
Learning objectives
- Build chronological investigation timelines.
- Distinguish first observed and first detected activity.
- Normalise time zones and ingestion delays.
- Record evidence, inference and uncertainty.
- Identify gaps and contradictions.
- Create technical and executive views.
- Validate the final attack story.
What is an investigation timeline?
An investigation timeline is a chronological record of verified events used to explain how an incident unfolded.
Timeline is not an alert list
A useful timeline removes duplication, records context and shows relationships rather than copying every alert.
Start with a defined window
Choose a start and end time broad enough to include activity before and after the first alert.
First detected versus first observed
The first alert can occur long after the earliest malicious or suspicious event.
Use one time zone
Convert evidence into one stated time zone so the sequence can be understood consistently.
Preserve original timestamps
Keep original source timestamps where needed for audit, legal or technical review.
Event time versus ingestion time
A log can be ingested after the activity occurred, making the portal sequence appear incorrect.
Clock drift
Devices and systems with incorrect clocks can distort event order.
Daylight saving time
Time-zone changes can create apparent gaps or duplicate times if they are not handled explicitly.
Identity timeline
Include sign-ins, MFA, risk detections, authentication changes, role changes and session activity.
Email timeline
Include message delivery, clicks, attachment opens, user reports and remediation.
Endpoint timeline
Include processes, files, scripts, network activity, persistence and response actions.
Cloud timeline
Include deployments, role changes, resource access, alerts and remediation.
Sentinel timeline
Use workspace logs and incident entities to connect broader telemetry.
Defender XDR timeline
Use incidents, alerts and entity evidence across endpoint, identity, email and cloud apps.
Start with confirmed events
Add events supported by original records before adding inferred stages.
Use source attribution
Every event should identify the product or log source that supplied it.
Use immutable identifiers
Record DeviceId, AccountObjectId, NetworkMessageId, AlertId, IncidentId and resource IDs where possible.
Use readable labels too
Include usernames, hostnames and resource names for readability while preserving stronger identifiers.
Group related events
Combine repeated detections or duplicate alerts into one meaningful timeline entry.
Keep distinct events separate
Do not merge activities that only share a username, IP address or similar time.
Record event type
Label events as authentication, delivery, process, network, privilege, persistence, data access or response.
Record event status
Show whether the event is confirmed, probable, possible, benign or unresolved.
Record confidence
Assign confidence to individual events and relationships.
Add analyst notes
Explain why the event matters and how it connects to the investigation.
Add supporting evidence
Reference alert IDs, query results, file hashes, message IDs and source links.
Separate evidence from interpretation
Keep the source event distinct from the analyst’s explanation.
Use causal relationships carefully
One event should only be shown as causing another when evidence supports the link.
Time proximity is not causation
Events occurring close together may still be unrelated.
Build the attack story in stages
Organise events into initial access, execution, persistence, privilege escalation, lateral movement, collection and impact only when supported.
Initial access
Identify the earliest verified point where the attacker may have gained access.
Execution
Record commands, processes, scripts or cloud actions that show activity.
Persistence
Include rules, tasks, services, authentication methods, app consent or cloud changes.
Privilege escalation
Record role, group, token or permission changes supported by evidence.
Credential access
Include password theft, token theft, LSASS access or suspicious authentication changes.
Discovery
Record account, device, network, application or resource enumeration.
Lateral movement
Show remote connections, shared credentials, device-to-device movement or cloud pivots.
Collection
Record file access, mailbox search, SharePoint access or staging activity.
Exfiltration
Only include data transfer or theft when evidence supports it.
Impact
Record disruption, encryption, deletion or business effect separately from suspected intent.
Response actions
Include account disablement, token revocation, isolation, quarantine and blocking.
Missing evidence
Identify gaps where logs, sensors, connectors or permissions are unavailable.
Conflicting evidence
Record evidence that weakens or contradicts the leading theory.
Unknown periods
Highlight time windows where important activity may have occurred but evidence is missing.
Use Copilot for draft timelines
Security Copilot can organise events and propose a chronological attack story.
Validate Copilot order
Check every timestamp, entity and relationship against the original source.
Review the process log
Identify which plugins, products and sources contributed to the draft.
Ask for first and latest events
Prompt Copilot to identify the first confirmed and latest confirmed activity.
Ask for gaps
Request missing periods, unsupported transitions and contradictory evidence.
Ask for source attribution
Require the source product and identifier for every major timeline event.
Ask for confidence
Require a confidence level for each stage and relationship.
Use tables for detail
A table can show time, source, entity, event, evidence, confidence and analyst note.
Use diagrams for overview
A simple flow can communicate the attack story without replacing detailed evidence.
Use colour carefully
Colour can distinguish confirmed, inferred, benign and unresolved events but should not be the only indicator.
Build technical timelines
Technical timelines retain detailed entities, IDs, commands, files and timestamps.
Build handover timelines
Shift handover timelines emphasise current state, completed actions and next tasks.
Build executive timelines
Executive timelines focus on key milestones, impact, response and remaining risk.
Update continuously
Revise the timeline when new evidence changes the sequence or scope.
Version important changes
Record when events were added, removed or reclassified.
Do not erase old hypotheses
Keep a record of how the investigation changed where governance requires it.
Use peer review
Another analyst should review complex timelines before major decisions or final reporting.
Close with the final story
The completed timeline should explain what happened, when, to whom, how far it progressed and what remains unknown.
Final analyst validation
Security Copilot can assemble the draft, but the analyst approves the final chronology.
Example investigation-timeline prompt
Use Microsoft Defender XDR, Microsoft Entra, Microsoft Sentinel and email evidence.
Include:
1. Timestamp in one stated time zone
2. Source product and original event identifier
3. User, device, mailbox, IP, domain or resource involved
4. Event description
5. Supporting evidence
6. Confirmed, probable, possible or unsupported status
7. First observed and first detected activity
8. Missing periods and conflicting evidence
9. Supported MITRE ATT&CK stage where appropriate
10. Response actions and latest confirmed activity
Do not create causal links from time proximity alone.
Agent Foskett investigation: “The attacker was already gone…”
↓
The initial summary treated 09:47 as the attack start
↓
Agent Foskett rebuilt the timeline
↓
08:03 — phishing email delivered
↓
08:11 — user visited the credential page
↓
08:16 — suspicious sign-in from attacker infrastructure
↓
08:23 — privilege assignment changed
↓
08:28 — mailbox forwarding rule created
↓
08:37 — sensitive files accessed
↓
09:02 — attacker session ended
↓
09:47 — Defender generated the first alert
↓
The attack had begun 104 minutes before detection
↓
By the time the alert appeared, the active session was already gone
↓
The response focused on token revocation, persistence removal and impact review
↓
The alert explained detection
↓
The timeline explained the incident
Timeline validation checklist
| Area | Question | Validation action |
|---|---|---|
| Window | Does the timeline include activity before and after detection? | Expand the investigation window. |
| Time zone | Are all events shown in one stated time zone? | Convert and preserve originals. |
| Timestamp | Is this event time or ingestion time? | Confirm the source field. |
| Entity | Is the same user, device or resource involved? | Check immutable identifiers. |
| Source | Can the event be opened in the original product? | Record source attribution. |
| Sequence | Is the proposed order technically possible? | Review dependencies and clock drift. |
| Duplicate | Are repeated alerts inflating the timeline? | Consolidate duplicate events. |
| Gap | Are important periods missing evidence? | Document visibility limitations. |
| Confidence | Is each event or link appropriately classified? | Separate confirmed and inferred stages. |
| Closure | Does the timeline show containment and residual risk? | Record response actions and latest activity. |
Key takeaways
- Investigation timelines turn scattered records into a chronological attack story.
- The first detected alert may occur long after the first observed attacker activity.
- All evidence should be normalised into one stated time zone.
- Event time, ingestion time, clock drift and daylight saving can affect sequence.
- Every event should retain source attribution and strong identifiers.
- Duplicate alerts should be consolidated before timeline analysis.
- Confirmed evidence, inference and unknowns should remain separate.
- Missing periods and contradictory evidence must be visible.
- Technical, handover and executive timelines serve different audiences.
- The final chronology remains a human-validated investigation record.
What Agent Foskett checked
- Email delivery
- Credential-page visit
- Entra sign-in
- Privilege change
- Mailbox rule
- File access
- Session end
- Defender alert
- Response actions
- Final incident window
Best practices
- Start before the alert.
- Use one time zone.
- Confirm source timestamps.
- Preserve strong identifiers.
- Remove duplicates.
- Show gaps and conflicts.
- Separate facts and inference.
- Assign confidence.
- Review with another analyst.
- Record the final story.
Related Agent Foskett resources
Continue the Microsoft Security Copilot Academy
How do you build investigation timelines with Microsoft Security Copilot?
Security Copilot can help organise Microsoft Defender XDR, Entra, Sentinel, email and cloud evidence into a chronological draft timeline for analyst validation.
Security incident timeline best practices
Reliable timelines use one stated time zone, strong identifiers, source attribution, duplicate removal, confidence labels and clear separation between confirmed evidence and inference.
First observed versus first detected activity
The first security alert often occurs after earlier malicious activity, so analysts should search before and after the detection window to identify the true incident start and containment point.
