Lab 12 Incident Timeline Reconstruction

Mission Overview

Welcome to Lab 12 — Incident Timeline Reconstruction.

You have already learned how to investigate authentication activity, Windows and Linux events, phishing, endpoint alerts, network traffic, DNS/web activity, SIEM telemetry, and threat intelligence.

Now you will combine those individual pieces into one of the most important SOC investigation artifacts:

The Master Incident Timeline

Security incidents rarely appear as one perfectly ordered sequence. Evidence is distributed across systems, timestamps may use different time zones, SIEM ingestion can be delayed, multiple tools may record the same activity, and some events may be missing entirely.

Your job is to reconstruct what the available evidence can actually prove.

Mission Goal: Collect security events from multiple telemetry sources, normalize their timestamps, correlate related activity, remove duplicate representations, establish first-seen and last-seen boundaries, identify evidence gaps, reconstruct the incident chronologically, and produce a defensible Master Incident Timeline.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	Incident Timeline Reconstruction
Secondary Skill	Multi-Source Evidence Correlation
Environment	GoHackersCloud SOC Analyst Lab
Input	Email, identity, endpoint, host, DNS, proxy, firewall and SIEM evidence
Primary Outcome	Master Incident Timeline
Safety Level	Authorized Training Evidence Only

Learning Objectives

By completing this lab, you will be able to:

• collect timeline-relevant evidence

• preserve original timestamps

• distinguish event time from ingestion time

• identify source time zones

• normalize timestamps into UTC

• correlate events from multiple telemetry sources

• identify duplicate representations

• distinguish correlation from causation

• sequence related activity

• identify first-seen and last-seen activity

• identify missing telemetry

• distinguish observed from inferred events

• assign confidence to timeline entries

• reconstruct attack or incident phases

• determine affected users and systems

• identify positive security-control actions

• build a defensible incident narrative

• produce a professional Master Incident Timeline

Core Methodology

Use:

Collect → Normalize Time → Correlate → Sequence → Validate → Identify Gaps → Establish First/Last Seen → Reconstruct

Expanded:

Collect Evidence
      │
      ▼
Preserve Original Time
      │
      ▼
Identify Time Zone
      │
      ▼
Normalize to UTC
      │
      ▼
Correlate Events
      │
      ▼
Consolidate Duplicates
      │
      ▼
Sequence Activity
      │
      ▼
Validate Relationships
      │
      ▼
Identify Missing Evidence
      │
      ▼
Establish First / Last Seen
      │
      ▼
Build Master Timeline
      │
      ▼
Reconstruct Incident

The core principle is:

The timeline must follow the evidence. The evidence must never be rearranged to fit the analyst’s preferred story.

Part 1 — Understand Why Timelines Matter

Consider these isolated observations:

Phishing email delivered

Suspicious domain queried

File downloaded

Endpoint alert generated

Unexpected authentication detected

Individually, they provide limited context.

Chronologically correlated:

Email Delivered
      ↓
User Interaction
      ↓
DNS Resolution
      ↓
Web Access
      ↓
File Download
      ↓
Process Execution
      ↓
Endpoint Detection
      ↓
Network Activity
      ↓
Authentication Anomaly

they may reveal the broader incident sequence.

But every arrow must be supported by evidence.

Part 2 — Create the Investigation Workspace

Create:

SOC-Labs/
└── Lab-12/
    ├── 01-Scope/
    ├── 02-Source-Cases/
    ├── 03-Raw-Events/
    │   ├── Email/
    │   ├── Identity/
    │   ├── Windows/
    │   ├── Linux/
    │   ├── Endpoint/
    │   ├── DNS/
    │   ├── Proxy/
    │   ├── Firewall/
    │   └── SIEM/
    ├── 04-Time-Normalization/
    ├── 05-Correlation/
    ├── 06-Duplicates/
    ├── 07-First-Last-Seen/
    ├── 08-Gaps/
    ├── 09-Master-Timeline/
    ├── 10-Incident-Phases/
    ├── 11-Scope/
    ├── 12-Evidence/
    ├── 13-Findings/
    └── 14-Report/

Create:

Lab-12-Incident-Timeline-Reconstruction.md

Part 3 — Open the Case

Example:

CASE ID:
GHC-SOC-2026-012

CASE TITLE:
Incident Timeline Reconstruction

STATUS:
Investigating

ANALYST:

DATE:

MASTER TIMEZONE:
UTC

Part 4 — Define the Mission Scope

Record:

INCIDENT SCOPE

Primary Host:
WIN-FIN-02

Primary User:
finance-user

Initial Alert:
Suspicious Endpoint and Network Activity

Initial Alert Time:
15:24 UTC

Known Domain:
account-update.example.test

Known File:
InvoiceViewer.exe

Initial Investigation Window:
15:00–16:00 UTC

Do not assume this is the final window.

Part 5 — Identify Available Data Sources

Create a source inventory.

Source	Available	Timeline Value
Email Gateway	Yes	Message delivery
Identity	Yes	Authentication
Windows	Yes	Host events
Endpoint/EDR	Yes	Process/file activity
DNS	Yes	Domain resolution
Proxy	Yes	Web interaction
Firewall	Yes	Network communication
SIEM	Yes	Central correlation
Threat Intelligence	Yes	Context

Part 6 — Preserve Raw Evidence

Before transforming timestamps or consolidating events, preserve the original records.

Use:

03-Raw-Events/

Keep:

• original timestamp

• original timezone

• event identifier

• data source

• raw description

• host

• user

• source/destination

• evidence ID

Never overwrite original evidence with normalized versions.

Part 7 — Create the Raw Event Register

Event ID	Original Time	Source	Host	User	Event
EVT-001		Email			Message delivered
EVT-002		Identity			Authentication
EVT-003		DNS			Query
EVT-004		Proxy			Web request

Part 8 — Understand Timestamp Problems

Different systems may report:

2026-08-28 15:21 UTC

2026-08-28 20:51 IST

2026-08-28T15:21:00Z

These can represent the same moment.

If the analyst does not normalize them correctly, the timeline may become misleading.

Part 9 — Preserve Original Timestamp

For every important event record:

TIME RECORD

Event ID:

Original Timestamp:

Original Timezone:

Normalized UTC:

Event Time:

Ingestion Time:

Source:

Notes:

Part 10 — Understand Event Time

Event time represents when the activity occurred according to the source system.

Example:

Event Time:
15:21:05 UTC

Part 11 — Understand Ingestion Time

The SIEM may receive the same event later:

Event Time:
15:21:05 UTC

SIEM Ingestion:
15:24:17 UTC

The activity belongs at approximately:

15:21:05

not 15:24:17.

Therefore:

Event Time ≠ Ingestion Time

Part 12 — Create the Time Normalization Register

Event	Original Time	TZ	UTC Time	Ingestion
Email delivery
DNS query
Endpoint event

Part 13 — Select a Master Timezone

For this lab use:

UTC

Record:

MASTER TIMELINE TIMEZONE:
UTC

Using one consistent timezone makes cross-source correlation easier.

Part 14 — Preserve Timestamp Precision

Do not change:

15:21:05.327

into:

15:21

when millisecond precision may matter.

Preserve the precision supplied by the evidence.

Part 15 — Consider Clock Skew

Two systems may not have perfectly synchronized clocks.

Example:

Proxy:
15:21:05

Endpoint:
15:21:02

If evidence indicates known clock drift, document it.

Do not silently rearrange timestamps.

Part 16 — Create the Clock Validation Register

Source	Time Sync Status	Known Offset	Impact
Endpoint	Synchronized	0 sec	None
Legacy Server	Unknown	Unknown	Sequence uncertainty

Part 17 — Collect Email Events

Example:

15:18:10
Email delivered to finance-user

Record:

• sender

• recipient

• subject

• message ID

• URL

• attachment

• delivery action

• gateway verdict

Part 18 — Collect Authentication Events

Example:

15:20:04
finance-user successfully authenticated to WIN-FIN-02

Record:

• user

• host

• source

• authentication result

• method

• privilege context

• session information where available

Part 19 — Collect DNS Events

Example:

15:21:02
WIN-FIN-02 queried account-update.example.test

Then:

15:21:03
DNS returned 203.0.113.50

These are separate events.

Part 20 — Collect Proxy/Web Events

Example:

15:21:05
HTTPS request to account-update.example.test

and:

15:22:11
File download recorded

Preserve:

• user

• client

• URL

• method

• response

• action

• file metadata

Part 21 — Collect Endpoint Events

Example:

15:22:12
InvoiceViewer.exe created in Downloads

15:23:17
InvoiceViewer.exe process creation recorded

15:24:01
EDR alert generated

15:26:10
EDR terminated suspicious process

15:27:02
File quarantined

Part 22 — Collect Network Events

Example:

15:25:08
WIN-FIN-02 connected to 203.0.113.50:443

Record:

• source

• destination

• port

• protocol

• direction

• allowed/blocked

• related process if supplied

Part 23 — Collect Windows/Linux Events

Relevant events may include:

• authentication

• account changes

• process activity

• privilege events

• service activity

• system events

Only include events relevant to the investigation.

Part 24 — Collect Threat Intelligence Context

Threat intelligence may show:

Domain:
High-confidence malicious

Hash:
Known malicious

IP:
Suspicious shared infrastructure

But threat intelligence is generally context, not a timeline event.

Do not insert reputation checks into the attack sequence unless the reputation event itself matters operationally.

Part 25 — Assign Evidence IDs

Example:

EV-TL-001
Email delivery

EV-TL-002
Authentication

EV-TL-003
DNS query

EV-TL-004
DNS response

EV-TL-005
Proxy request

Every important timeline entry should be traceable to evidence.

Part 26 — Build the Initial Event Pool

UTC Time	Event	Source	Evidence
15:18:10	Email delivered	Email	EV-TL-001
15:20:04	Authentication	Identity	EV-TL-002
15:21:02	DNS query	DNS	EV-TL-003
15:21:03	DNS response	DNS	EV-TL-004
15:21:05	Web request	Proxy	EV-TL-005

At this stage, do not write the incident story yet.

Part 27 — Correlate by User

Search:

finance-user

across:

Email
Identity
Endpoint
Proxy
Windows
SIEM

Create:

Time	User	Source	Activity
	finance-user	Email
	finance-user	Identity
	finance-user	Proxy

Part 28 — Correlate by Host

Search:

WIN-FIN-02

across:

• endpoint

• DNS

• firewall

• proxy

• authentication

• Windows events

Part 29 — Correlate by Domain

Search:

account-update.example.test

across:

Email → DNS → Proxy → Threat Intelligence

Part 30 — Correlate by IP

Search:

203.0.113.50

across:

DNS → Firewall → Endpoint → Proxy

Part 31 — Correlate by File

Search:

InvoiceViewer.exe

and its supplied hash across:

Email
Proxy
Endpoint
EDR
SIEM

Remember:

Same Filename ≠ Same File

A matching cryptographic hash provides stronger file identity.

Part 32 — Create the Correlation Register

Correlation ID	Entity	Sources	Result
COR-001	finance-user	Email + Identity + Proxy
COR-002	WIN-FIN-02	DNS + EDR + Firewall
COR-003	Domain	Email + DNS + Proxy
COR-004	Hash	Proxy + EDR

Part 33 — Correlate by Multiple Attributes

A relationship is stronger when several attributes align.

For example:

Same User
+
Same Host
+
Same Domain
+
Close Timestamp

is stronger than:

Close Timestamp Only

Part 34 — Create a Correlation Strength Matrix

Relationship	Confidence
Same timestamp only	Low
Same domain	Medium
Same host + user	Medium/High
Same host + user + domain + session	High
Exact file hash	High

Part 35 — Identify Duplicate Representations

Suppose at 15:25:

Firewall:
Outbound connection observed

EDR:
Network connection observed

SIEM:
Suspicious connection alert

These may represent one underlying connection.

Do not report:

Three outbound connections

unless evidence supports three distinct connections.

Part 36 — Build the Duplicate Event Register

Activity	Source 1	Source 2	Source 3	Consolidated
Network connection	Firewall	EDR	SIEM	One activity

Part 37 — Preserve Duplicate Evidence

Duplicate telemetry is still valuable.

It may provide:

• corroboration

• different fields

• different perspectives

• control outcome

Consolidate the activity in the timeline while retaining all evidence references.

Part 38 — Distinguish Correlation from Causation

Suppose:

15:21
Web access

15:23
Process execution

The timing is consistent with a relationship.

But you should not automatically write:

“The web request caused the process execution.”

You need stronger evidence, such as:

Web download
+
matching filename/hash
+
file creation
+
process creation

Part 39 — Use Evidence Language

Prefer:

“Endpoint telemetry recorded execution of the file whose hash matched the file downloaded through the proxy.”

Avoid:

“The attacker infected the computer through the website.”

unless the evidence actually establishes that conclusion.

Part 40 — Classify Timeline Entries

Use three useful categories:

Observed

Directly supported by telemetry.

Correlated

Supported by multiple related observations.

Inferred

Reasonable interpretation, but not directly observed.

Create:

Entry	Classification	Confidence
DNS query	Observed	High
User clicked URL	Correlated	Medium
Credentials entered	Inferred/Unknown	Low

Part 41 — Never Present Inference as Fact

If evidence shows:

Email delivered
+
DNS query
+
web request

you may reasonably state:

“Activity is consistent with user interaction with the URL.”

But if click telemetry is unavailable, avoid stating:

“The user clicked the phishing link.”

as an established fact.

Part 42 — Identify the Earliest Relevant Event

Search backward from the alert.

Example:

Alert:
15:24

Search backward...

You may find:

15:18
Phishing email delivery

Continue until you reach a defensible boundary.

Part 43 — Establish First Seen

Record:

FIRST SEEN

Time:
15:18:10 UTC

Event:
Related phishing email delivered

Evidence:
EV-TL-001

Confidence:
High

First seen means:

earliest relevant activity found within available telemetry.

It does not necessarily mean the absolute beginning of the incident.

Part 44 — Search Before First Seen

Expand backward where justified.

For example:

15 minutes
↓
1 hour
↓
24 hours

Stop when:

• no additional relevant evidence appears

• retention limits are reached

• scope is sufficiently established

Document the boundary.

Part 45 — Identify Last Seen

Search forward from the latest known event.

Example:

15:27
File quarantined

But you may later discover:

15:32
Unexpected authentication

Therefore, 15:27 was not the true last-seen event.

Part 46 — Establish Last Seen

Record:

LAST SEEN

Time:
15:32:18 UTC

Event:
Unexpected authentication activity

Evidence:
EV-TL-012

Confidence:
High

Part 47 — Build the First/Last Seen Register

Entity	First Seen	Last Seen	Confidence
Domain
Hash
Host activity
User anomaly
Incident overall

Part 48 — Determine Incident Duration

Once boundaries are established:

Incident Duration =
Last Relevant Event - First Relevant Event

Document this as the observed investigation window, not necessarily the total attacker dwell time.

Part 49 — Identify Missing Events

Suppose evidence shows:

15:21 Web request
      ↓
      ?
      ↓
15:23 Process execution

The missing stage may be:

Download

But if download telemetry is absent, do not invent it.

Record:

Potential Evidence Gap:
File delivery mechanism not directly observed.

Part 50 — Create the Evidence Gap Register

Gap ID	Missing Evidence	Impact
GAP-001	User click telemetry	Cannot prove explicit click
GAP-002	File creation telemetry	Delivery mechanism uncertain
GAP-003	Process command line	Reduced execution context

Part 51 — Distinguish Missing Evidence from Negative Evidence

These are different.

Missing Evidence

Endpoint telemetry unavailable

Negative Evidence

Endpoint telemetry was available and showed no execution

This distinction materially affects confidence.

Part 52 — Validate Data Source Health

Before stating:

No activity observed

verify the source was reporting.

Create:

Source	Healthy	Coverage	Gap
EDR	Yes	Full window	None
Proxy	No	Missing 15:20–15:25	Significant

Part 53 — Identify Positive Security-Control Events

Timeline reconstruction should include defensive activity.

Example:

15:24
EDR detected suspicious process

15:26
EDR terminated process

15:27
File quarantined

These events are important to understanding impact.

Part 54 — Distinguish Detection from Prevention

Example:

File Download
     ↓
Execution
     ↓
EDR Detection
     ↓
Process Termination

means the control detected activity after execution began.

Compare:

File Download
     ↓
Execution Attempt
     ↓
EDR Block

where execution may have been prevented.

Do not describe both scenarios as identical.

Part 55 — Build the Security Control Timeline

Time	Control	Action	Outcome
	Email Security	Delivered/Blocked
	DNS Security	Allowed/Blocked
	Proxy	Allowed/Blocked
	EDR	Detected
	EDR	Terminated

Part 56 — Group Events into Incident Phases

A useful defensive model is:

Phase 1 — Initial Exposure

Phase 2 — User / System Interaction

Phase 3 — Execution

Phase 4 — Post-Execution Activity

Phase 5 — Detection

Phase 6 — Containment

Phase 7 — Follow-On Investigation

Only use phases supported by evidence.

Part 57 — Phase 1: Initial Exposure

Example:

15:18
Phishing email delivered

Evidence:

Email gateway

Part 58 — Phase 2: Interaction

Example:

15:21
DNS query

15:21
Web request

Evidence may support interaction with the domain.

Do not overstate exact user actions if unavailable.

Part 59 — Phase 3: Execution

Example:

15:23
Process creation recorded

This can establish execution if telemetry is reliable.

Part 60 — Phase 4: Post-Execution Activity

Example:

15:25
Outbound network communication

Further evidence may include:

• child process activity

• file changes

• service activity

• authentication activity

Part 61 — Phase 5: Detection

Example:

15:24
EDR alert generated

Detection time is not necessarily incident start time.

Alert Time ≠ Incident Start Time

Part 62 — Phase 6: Containment

Example:

15:26
Process terminated

15:27
File quarantined

Record what the control actually accomplished.

Part 63 — Phase 7: Follow-On Activity

Suppose:

15:32
Unexpected authentication

This must be investigated separately.

Do not automatically state that malware caused the authentication event.

Correlate identity evidence.

Part 64 — Build the Incident Phase Register

Phase	Start	End	Evidence
Initial Exposure
Interaction
Execution
Post-Execution
Detection
Containment
Follow-On

Part 65 — Construct the Master Timeline

Example:

UTC Time	Source	Entity	Event	Evidence	Confidence
15:18:10	Email	finance-user	Related email delivered	EV-TL-001	High
15:20:04	Identity	finance-user	Successful login	EV-TL-002	High
15:21:02	DNS	WIN-FIN-02	Domain query	EV-TL-003	High
15:21:03	DNS	WIN-FIN-02	Domain resolved	EV-TL-004	High
15:21:05	Proxy	finance-user	HTTPS request	EV-TL-005	High
15:22:11	Proxy	WIN-FIN-02	File download	EV-TL-006	High
15:22:12	Endpoint	WIN-FIN-02	File observed	EV-TL-007	High
15:23:17	Endpoint	WIN-FIN-02	Process execution	EV-TL-008	High
15:24:01	EDR	WIN-FIN-02	Alert generated	EV-TL-009	High
15:25:08	Firewall	WIN-FIN-02	Outbound connection	EV-TL-010	High
15:26:10	EDR	WIN-FIN-02	Process terminated	EV-TL-011	High
15:27:02	EDR	WIN-FIN-02	File quarantined	EV-TL-012	High

Part 66 — Add Analyst Interpretation Separately

Do not overload the evidence column.

Create:

Time	Observed Event	Analyst Interpretation
15:21	DNS + web activity	Consistent with interaction with email URL
15:23	Process creation	Confirms file execution
15:25	Network connection	Post-execution communication observed

Part 67 — Create an Evidence Confidence Scale

High

Direct, reliable telemetry supports the event.

Medium

Multiple observations support the interpretation, but direct evidence is incomplete.

Low

Inference depends on limited or ambiguous evidence.

Unknown

Evidence cannot support a meaningful confidence assessment.

Part 68 — Identify Contradictory Evidence

Suppose:

Proxy:
Download successful

EDR:
File never observed

Do not ignore the conflict.

Investigate:

• different host?

• proxy cache?

• user attribution?

• endpoint sensor gap?

• file deleted?

• timestamp mismatch?

Part 69 — Build the Contradiction Register

Evidence A	Evidence B	Conflict	Resolution
Proxy download	No endpoint file	File presence unclear	Investigate

Part 70 — Create the Activity Chain

After validation:

Email Delivery
      │
      ▼
DNS Resolution
      │
      ▼
Web Request
      │
      ▼
File Download
      │
      ▼
File Creation
      │
      ▼
Process Execution
      │
      ▼
Endpoint Detection
      │
      ▼
Network Activity
      │
      ▼
Process Termination
      │
      ▼
Quarantine

Only include proven or clearly labeled correlated stages.

Part 71 — Build an Evidence-Backed Incident Narrative

Example:

At 15:18:10 UTC, the email gateway recorded delivery of a simulated phishing message to finance-user. At 15:21:02, the user’s workstation queried the domain contained in the message, followed by a proxy-recorded HTTPS request three seconds later. Proxy telemetry subsequently recorded a file download, and endpoint telemetry identified the matching file on the workstation. At 15:23:17, process telemetry confirmed execution. EDR generated an alert at 15:24:01, after which network telemetry recorded outbound communication. EDR subsequently terminated the process and quarantined the file.

Notice that the narrative follows evidence rather than assumptions.

Part 72 — Determine Host Scope

Create:

Host	Evidence	Status	Confidence
WIN-FIN-02	Execution + network	Confirmed affected	High
WIN-HR-04	DNS query only	Exposed	High

Do not classify both identically.

Part 73 — Determine User Scope

Create:

User	Evidence	Status
finance-user	Email + web + endpoint	Affected
hr-user	Email only	Exposed

Part 74 — Separate Campaign Timeline from Incident Timeline

A campaign might involve:

50 emails

while the confirmed incident involves:

1 endpoint

Create separate views where necessary.

Campaign Timeline

Email deliveries
Domain observations
Multiple recipients

Incident Timeline

Affected user
Affected endpoint
Execution
Network activity
Containment

Part 75 — Determine Known Impact

Record only established impact.

Example:

KNOWN IMPACT

Email Delivered:
Yes

Web Interaction:
Confirmed

File Download:
Confirmed

Execution:
Confirmed

Outbound Communication:
Confirmed

Persistence:
Not Established

Credential Exposure:
Not Established

Additional Hosts:
Not Established

Data Exfiltration:
Not Established

Part 76 — Distinguish “Not Observed” from “Did Not Happen”

Prefer:

Persistence:
Not observed in available telemetry.

over:

Persistence:
Did not occur.

unless your evidence genuinely supports the stronger statement.

Part 77 — Determine Severity and Confidence

Example:

SEVERITY:
High

CONFIDENCE:
High

But you may separately record:

Execution:
High confidence

Persistence:
Low confidence / Not established

Credential exposure:
Medium confidence / Potential

Part 78 — Build the Incident Reconstruction Summary

INCIDENT RECONSTRUCTION

First Seen:

Last Seen:

Observed Duration:

Primary User:

Primary Host:

Initial Exposure:

Interaction:

Execution:

Network Activity:

Identity Activity:

Detection:

Containment:

Confirmed Impact:

Potential Impact:

Affected Hosts:

Affected Users:

Evidence Gaps:

Severity:

Confidence:

Part 79 — Determine Remaining Questions

Examples:

Was credential information submitted?

Did the process establish persistence?

Did the process communicate before EDR termination?

Were additional endpoints exposed?

Was sensitive information accessed?

Was the unexpected authentication related?

A professional timeline can contain unresolved questions.

Part 80 — Determine Escalation Readiness

The timeline should give the incident responder:

• what happened

• when it happened

• who was involved

• which systems were involved

• what is confirmed

• what remains uncertain

• what controls responded

• what needs containment

Part 81 — Create the Escalation Timeline Summary

ESCALATION TIMELINE

15:18 — Initial exposure

15:21 — Suspicious domain interaction

15:22 — File download

15:23 — Execution confirmed

15:24 — Endpoint detection

15:25 — Network activity

15:26 — Process terminated

15:27 — File quarantined

Current Status:
Contained / Partially Contained / Investigating

Outstanding Concern:
Identity activity requires further investigation.

Part 82 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
Incident Timeline Reconstruction

Case ID:

Analyst:

Date:

Master Timezone:
UTC


INCIDENT SCOPE

Primary Host:

Primary User:

Initial Alert:

Alert Time:

Initial Window:


DATA SOURCES

Email:

Identity:

Windows:

Linux:

Endpoint:

DNS:

Proxy:

Firewall:

SIEM:

Threat Intelligence:


TIME NORMALIZATION

Source:

Original Time:

Timezone:

Normalized UTC:

Ingestion Time:

Known Clock Offset:


FIRST SEEN

Time:

Event:

Source:

Evidence:

Confidence:


INITIAL EXPOSURE

Time:

Event:

Evidence:


USER / SYSTEM INTERACTION

Time:

DNS Activity:

Web Activity:

Evidence:

Directly Observed / Correlated / Inferred:


FILE ACTIVITY

Download Time:

Filename:

Hash:

Endpoint Presence:

Evidence:


EXECUTION

Time:

Process:

Parent Process:

User:

Host:

Evidence:

Confidence:


NETWORK ACTIVITY

Time:

Source:

Destination:

Port:

Action:

Process:

Evidence:


DETECTION

Time:

Control:

Alert:

Evidence:


CONTAINMENT

Process Terminated:

Time:

File Quarantined:

Time:

Endpoint Isolated:

Time:

Evidence:


IDENTITY ACTIVITY

User:

Event:

Time:

Source:

Relationship to Incident:

Confidence:


LAST SEEN

Time:

Event:

Evidence:

Confidence:


SCOPE

Confirmed Hosts:

Exposed Hosts:

Confirmed Users:

Exposed Users:

Domains:

IPs:

Files:

Processes:


EVIDENCE GAPS

Gap 01:

Impact:

Gap 02:

Impact:


CONTRADICTORY EVIDENCE

Evidence A:

Evidence B:

Assessment:


KNOWN IMPACT

Email Exposure:

Web Interaction:

File Download:

Execution:

Network Communication:

Persistence:

Credential Exposure:

Data Exposure:

Additional Hosts:


FINAL ASSESSMENT

First Seen:

Last Seen:

Observed Duration:

Disposition:

Severity:

Confidence:

Containment Status:

Remaining Questions:

Ready for Incident Scoping & Escalation:
Yes / No

Part 83 — What Not to Do

Do not:

Sort only by SIEM ingestion time

Discard original timestamps

Ignore time zones

Round timestamps unnecessarily

Assume every system clock is synchronized

Treat multiple logs as multiple activities automatically

Invent missing events

Present inference as observed fact

Assume temporal correlation proves causation

Assume alert time equals incident start

Assume detection means prevention

Assume quarantine means nothing happened beforehand

Assume no event means no activity

Ignore data-source health

Ignore contradictory evidence

Hide uncertainty

Force evidence into a preferred attack narrative

Overstate incident duration

Overstate affected-host count

Overstate impact

The professional rule is:

If an event is not directly supported by evidence, either label it as an inference or leave it out of the factual timeline.

Troubleshooting

Events Appear Out of Order

Check:

• timezone

• clock skew

• ingestion delay

• timestamp precision

• event-time field selection

Do not manually reorder events simply because another order “makes more sense.”

SIEM Event Arrived Later

Use event time for the activity timeline and preserve ingestion time separately.

Two Sources Report the Same Connection

Consolidate it as one underlying activity while referencing both evidence sources.

User Click Is Not Logged

Do not write:

User clicked phishing link.

Instead:

DNS and proxy activity from the user's endpoint is consistent with interaction with the URL.

File Execution Is Unclear

Use:

Execution:
Unconfirmed

until process or equivalent telemetry establishes execution.

Logs Are Missing

Document the telemetry gap and its impact on confidence.

A Timeline Gap Exists

Do not fill it with an assumed event.

Record:

Activity between 15:22 and 15:23 could not be fully reconstructed
from available telemetry.

Evidence Requirements

Capture:

Evidence 01

Incident scope.

Evidence 02

Data Source Inventory.

Evidence 03

Raw Event Register.

Evidence 04

Original timestamp records.

Evidence 05

Time Normalization Register.

Evidence 06

Clock Validation Register.

Evidence 07

Email timeline evidence.

Evidence 08

Authentication evidence.

Evidence 09

DNS evidence.

Evidence 10

Proxy/web evidence.

Evidence 11

Endpoint evidence.

Evidence 12

Network evidence.

Evidence 13

Windows/Linux evidence where applicable.

Evidence 14

Threat-intelligence context.

Evidence 15

Evidence ID Register.

Evidence 16

Initial Event Pool.

Evidence 17

User correlation.

Evidence 18

Host correlation.

Evidence 19

Domain correlation.

Evidence 20

IP correlation.

Evidence 21

File/hash correlation.

Evidence 22

Correlation Register.

Evidence 23

Correlation Strength Matrix.

Evidence 24

Duplicate Event Register.

Evidence 25

Observed/Correlated/Inferred classification.

Evidence 26

First-Seen record.

Evidence 27

Last-Seen record.

Evidence 28

First/Last Seen Register.

Evidence 29

Evidence Gap Register.

Evidence 30

Data Source Health Matrix.

Evidence 31

Security Control Timeline.

Evidence 32

Incident Phase Register.

Evidence 33

Master Incident Timeline.

Evidence 34

Analyst Interpretation Register.

Evidence 35

Contradiction Register.

Evidence 36

Activity Chain.

Evidence 37

Incident Narrative.

Evidence 38

Host Scope.

Evidence 39

User Scope.

Evidence 40

Known Impact Assessment.

Evidence 41

Incident Reconstruction Summary.

Evidence 42

Remaining Questions.

Evidence 43

Escalation Timeline.

Evidence 44

Mission Challenge worksheet.

Mission Deliverables

Complete:

• case opened

• investigation scope established

• data sources inventoried

• original evidence preserved

• raw events registered

• original timestamps preserved

• time zones identified

• timestamps normalized to UTC

• event time separated from ingestion time

• clock synchronization considered

• email events collected

• authentication events collected

• DNS events collected

• proxy/web events collected

• endpoint events collected

• network events collected

• relevant host events collected

• evidence IDs assigned

• initial event pool created

• events correlated by user

• events correlated by host

• events correlated by domain

• events correlated by IP

• events correlated by file/hash

• correlation strength evaluated

• duplicate telemetry consolidated

• observed events distinguished from inference

• first seen established

• last seen established

• search window expanded where justified

• evidence gaps documented

• missing evidence distinguished from negative evidence

• data-source health validated

• security-control events included

• detection distinguished from prevention

• incident phases identified

• Master Incident Timeline completed

• contradictory evidence documented

• activity chain reconstructed

• incident narrative completed

• host scope determined

• user scope determined

• campaign scope separated from compromise scope

• known impact documented

• uncertainty documented

• severity assigned

• confidence assigned

• remaining questions documented

• escalation timeline completed

Lab Report Template

# Lab 12 — Incident Timeline Reconstruction

## Executive Summary

## Mission Objective

## Case Information

## Investigation Scope

## Data Source Inventory

## Evidence Preservation

## Raw Event Collection

## Timestamp Analysis

## Timezone Normalization

## Clock Validation

## Event Time vs Ingestion Time

## Email Evidence

## Authentication Evidence

## Host Evidence

## Endpoint Evidence

## DNS Evidence

## Web / Proxy Evidence

## Network Evidence

## Threat Intelligence Context

## Correlation Analysis

## Duplicate Event Analysis

## First Seen Analysis

## Last Seen Analysis

## Evidence Gaps

## Data Source Health

## Contradictory Evidence

## Security Control Timeline

## Incident Phases

## Master Incident Timeline

## Activity Chain

## Incident Narrative

## Host Scope

## User Scope

## Campaign Scope

## Known Impact

## Potential Impact

## Severity

## Confidence

## Remaining Questions

## Escalation Timeline

## Evidence Register

## Limitations

## Conclusion

Knowledge Check

Question 1 — Why preserve original timestamps?

Because normalization errors must be traceable and the original evidence should remain unchanged.

Question 2 — Is SIEM ingestion time the same as event time?

No.

Event time represents when the source says the activity occurred; ingestion time represents when the SIEM received it.

Question 3 — Does temporal correlation prove causation?

No.

Additional relationships and evidence are required.

Question 4 — Should missing events be added to make the timeline complete?

No.

Missing evidence must remain documented as a gap.

Question 5 — Why identify duplicate telemetry?

Several security products may describe the same underlying event.

Question 6 — Does first seen prove that it was the beginning of the incident?

No.

It is the earliest relevant activity found within available evidence.

Question 7 — Why include defensive-control events?

They show when detection and containment occurred and help establish actual exposure and impact.

Question 8 — Why distinguish observed, correlated, and inferred activity?

It prevents analyst interpretation from being presented as direct evidence.

Question 9 — What should you do when evidence conflicts?

Document the contradiction and investigate it rather than hiding or arbitrarily resolving it.

Question 10 — What is the central question?

“Can you reconstruct the incident accurately enough that another analyst can understand what happened, in what order, which evidence proves each step, and where uncertainty still remains?”

Skills Achieved

After completing this lab, you should understand:

• multi-source evidence collection

• timestamp preservation

• timezone normalization

• event vs ingestion time

• clock-skew considerations

• cross-source correlation

• duplicate-event consolidation

• correlation-strength assessment

• observed vs inferred evidence

• first-seen analysis

• last-seen analysis

• telemetry-gap analysis

• data-source health validation

• security-control timeline analysis

• incident-phase reconstruction

• Master Incident Timeline creation

• evidence-backed narrative writing

• incident scoping

• impact assessment

• SOC escalation preparation

Professional Takeaway

A weak timeline looks like:

Alert
  ↓
Malware
  ↓
Compromise
  ↓
Containment

A professional timeline looks like:

Preserve Raw Evidence
        ↓
Normalize Time
        ↓
Validate Data Sources
        ↓
Correlate User / Host / IOC
        ↓
Consolidate Duplicates
        ↓
Sequence Observed Events
        ↓
Separate Observation from Inference
        ↓
Identify Evidence Gaps
        ↓
Establish First Seen
        ↓
Establish Last Seen
        ↓
Map Security Controls
        ↓
Determine Scope
        ↓
Reconstruct Incident
        ↓
Document Uncertainty

Always distinguish:

Event Time
   ≠
Ingestion Time

Alert Time
   ≠
Incident Start Time

Temporal Correlation
   ≠
Causation

Multiple Logs
   ≠
Multiple Activities

First Seen
   ≠
Absolute Beginning

Last Seen
   ≠
Guaranteed End

Missing Evidence
   ≠
Negative Evidence

No Event Found
   ≠
Activity Did Not Occur

Detection
   ≠
Prevention

Inference
   ≠
Observed Fact

The strongest SOC analyst does not simply create a chronological list.

They create an evidence-backed reconstruction that explains:

What happened, when it happened, which user and systems were involved, which events are directly observed, which conclusions are correlated or inferred, what security controls responded, what impact is confirmed, and what remains unknown.

What’s Next?

➡️ Lab 13 — Incident Scoping, Containment & Escalation

In the next lab, you will take the reconstructed timeline and turn it into an actionable incident-response decision.

You will determine:

• which hosts are confirmed affected

• which hosts are merely exposed

• which identities are affected

• earliest and latest activity

• incident boundaries

• confirmed vs potential impact

• asset criticality

• identity privilege

• severity

• confidence

• containment priorities

• evidence-preservation requirements

• endpoint isolation recommendations

• identity containment recommendations

• network containment recommendations

• IOC blocking recommendations

• operational impact of containment

• escalation thresholds

• handoff requirements

The methodology becomes:

Evidence → Scope → Impact → Priority → Containment → Escalation

And the central question will be:

“How far does the incident actually extend, what must be contained first, and what evidence does the next response team need in order to act safely and decisively?”