Lab 09 Incident Timeline Reconstruction & Evidence Correlation

Mission Overview

Welcome to Lab 09 — Incident Timeline Reconstruction & Evidence Correlation.

This lab brings together the evidence examined across the previous Digital Forensics labs.

Until now, you investigated individual evidence sources:

• disk images

• deleted files

• Windows artifacts

• Linux artifacts

• volatile memory

• email and phishing

• browser activity

• DNS

• packet captures

• network sessions

Now you will combine them into one coherent incident timeline.

The central question is:

What happened first, what happened next, which evidence sources support each event, and where does uncertainty remain?

A professional forensic timeline is not simply a long list of timestamps.

It is a structured reconstruction built from multiple independent evidence sources.

Mission Goal: Normalize timestamps from multiple forensic sources, correlate related events, build a master incident timeline, distinguish confirmed events from hypotheses, identify evidence gaps, and produce a defensible Incident Reconstruction Report.

Mission Information

Item	Details
Difficulty	Intermediate–Advanced
Estimated Time	150–180 minutes
Primary Skill	Timeline Reconstruction
Secondary Skill	Cross-Evidence Correlation
Environment	GoHackersCloud Digital Forensics Lab
Evidence Type	Multi-source training evidence
Testing Type	Offline forensic correlation
Primary Outcome	Master Incident Timeline
Safety Level	Authorized Training Evidence Only

Learning Objectives

By completing this lab, you will be able to:

• consolidate multiple forensic evidence sources

• identify relevant events

• normalize timestamps

• handle timezone differences

• understand clock skew

• distinguish event time from collection time

• correlate independent evidence sources

• reconstruct sequences of activity

• identify causal assumptions

• assign confidence levels

• identify timeline gaps

• identify contradictory evidence

• separate facts from interpretations

• maintain evidence source attribution

• create a master incident timeline

• develop an incident narrative

• build an evidence correlation matrix

• document unresolved questions

• produce a professional reconstruction report

Timeline Reconstruction Methodology

Use:

Collect Events → Normalize Time → Attribute Source → Correlate → Sequence → Validate → Identify Gaps → Reconstruct → Report

Conceptually:

Evidence Sources
      │
      ▼
Relevant Events
      │
      ▼
Timestamp Normalization
      │
      ▼
Source Attribution
      │
      ▼
Cross-Evidence Correlation
      │
      ▼
Event Sequence
      │
      ▼
Confidence Assessment
      │
      ▼
Evidence Gaps
      │
      ▼
Incident Reconstruction

The key principle is:

A timeline should show what the evidence supports, not what the investigator expects happened.

Part 1 — Assemble the Case Evidence

For this lab, organize evidence from previous investigations.

Your evidence set may include:

Disk Evidence

Deleted File Evidence

Windows Event Logs

Windows Registry

Prefetch

LNK / Jump Lists

Linux Authentication Logs

Sudo / Shell History

Memory Image

Email Evidence

Browser History

Download Records

DNS Logs

PCAP

Firewall / Network Logs

Create a master evidence inventory.

Part 2 — Create the Lab Workspace

Create:

Digital-Forensics-Labs/
└── Lab-09/
    ├── Notes/
    ├── Evidence/
    │   ├── Disk/
    │   ├── Windows/
    │   ├── Linux/
    │   ├── Memory/
    │   ├── Email/
    │   ├── Browser/
    │   ├── DNS/
    │   └── Network/
    ├── Timeline/
    │   ├── Raw-Events/
    │   ├── Normalized/
    │   └── Master/
    ├── Correlation/
    ├── Findings/
    └── Report/

Create:

Lab-09-Incident-Timeline-Journal.md

Suggested structure:

# Lab 09 — Incident Timeline Reconstruction

## Mission Objective

## Case Information

## Evidence Sources

## Timezone Analysis

## Raw Event Collection

## Timestamp Normalization

## Event Classification

## Cross-Evidence Correlation

## Master Timeline

## Evidence Gaps

## Contradictions

## Hypotheses

## Incident Reconstruction

## Findings

## Limitations

## Conclusion

Part 3 — Build the Evidence Source Register

Create:

Evidence ID	Source	Type	Time Range	Reliability
E01	Disk image	Filesystem		High
E02	Security.evtx	Windows log		High
E03	Browser history	Application		Medium/High
E04	PCAP	Network		High
E05	Memory image	Volatile	Snapshot	High

The goal is to know where every timeline event originates.

Part 4 — Distinguish Event Time from Collection Time

These are not the same.

Example:

Event occurred:
09:15

but:

Evidence collected:
14:00

Record both when relevant.

Do not accidentally place acquisition time into the activity timeline.

Part 5 — Identify All Time Sources

Possible timestamps include:

Filesystem Created

Filesystem Modified

Filesystem Accessed

Filesystem Metadata Changed

Event Log Time

Authentication Time

Browser Visit Time

Download Start

Download Completion

Email Received

DNS Query

TCP Session Start

Memory Process Creation

Process Exit

File Deletion

USB Connection

Each timestamp has different meaning.

Part 6 — Build the Timestamp Source Register

Create:

Source	Timestamp Type	Meaning	Reliability
Security log	Event time	Logged Windows event	High
Filesystem	Modified	File content modification	Context
Browser	Visit time	Browser artifact	High
PCAP	Packet time	Observed network packet	High

This prevents incorrect interpretation.

Part 7 — Identify Timezones

Document:

Windows Timezone:

Linux Timezone:

Email Server Timezone:

Browser Timezone:

PCAP Timezone:

Memory Time Context:

Investigator Timezone:

Choose one master standard.

Recommended:

UTC

or a clearly documented local timezone.

Part 8 — Build the Time Normalization Register

Create:

Source	Original Time	Zone	Normalized Time
Browser		IST
PCAP		UTC
Email		UTC
Windows		IST

Never silently convert timestamps.

Part 9 — Understand Clock Skew

Systems may not have identical clocks.

Example:

Endpoint:
09:10:05

while:

Network Sensor:
09:10:13

An eight-second difference may represent clock skew.

Record:

Clock Difference:

Evidence Used to Estimate:

Correction Applied:
Yes / No

Part 10 — Do Not Overcorrect

Only apply clock corrections when evidence supports them.

If uncertain, report:

Approximately 8 seconds difference observed between endpoint
and network evidence.

Do not manipulate timestamps simply to make events align.

Part 11 — Collect Raw Events

Start collecting events without interpretation.

Create:

Event ID	Original Time	Source	Artifact	Observation
EVT-001		Email	Message	Email received
EVT-002		Browser	History	URL visited

The raw register should describe only observable facts.

Part 12 — Use One Event Per Row

Do not combine:

User clicked link and downloaded malware.

Instead:

EVT-001 — Email delivered
EVT-002 — URL present
EVT-003 — Browser visited URL
EVT-004 — Download began
EVT-005 — File created

This improves forensic precision.

Part 13 — Assign Event Categories

Useful categories:

Authentication

Email

Browser

DNS

Network

File

Process

Privilege

Device

Service

Scheduled Task

Deletion

Security Control

Create:

Event	Category
EVT-001	Email
EVT-002	Browser
EVT-003	Network

Part 14 — Normalize the Events

Convert relevant timestamps into your master standard.

Create:

Event ID	Original	Normalized	Source
EVT-001	14:30 IST	09:00 UTC	Email
EVT-002	14:35 IST	09:05 UTC	Browser

Preserve original values.

Part 15 — Sort Chronologically

Once normalized:

EVT-001
↓
EVT-002
↓
EVT-003
↓
EVT-004

Now the sequence begins to emerge.

But chronology alone does not prove causality.

Part 16 — Build the Preliminary Timeline

Example:

Time	Event	Evidence
09:01	Email delivered	Mail
09:06	URL visited	Browser
09:06	Domain resolved	DNS
09:07	Network connection	PCAP
09:08	File downloaded	Browser
09:08	File created	Filesystem

This is only the first reconstruction.

Part 17 — Correlate Email and Browser Evidence

Example:

Email:
URL-01

and:

Browser:
URL-01 visited

Correlated conclusion:

The endpoint browser accessed a URL contained in the message.

This is stronger than either source alone.

Part 18 — Correlate Browser and DNS

Example:

09:06:10 Browser URL visit
09:06:11 DNS query

This supports:

Browser interaction and name resolution occurred within the same activity period.

Do not state one necessarily caused the other unless context supports it.

Part 19 — Correlate DNS and Network Traffic

Example:

DNS:
training-site → 203.0.113.20

then:

PCAP:
endpoint → 203.0.113.20

This creates strong destination correlation.

Part 20 — Correlate Browser Downloads with Filesystem Evidence

Example:

Browser:
training.zip downloaded

and:

Filesystem:
C:\Users\lab-user\Downloads\training.zip

Compare:

• filename

• path

• size

• timestamps

• hash

A hash match provides particularly strong evidence.

Part 21 — Correlate File Evidence with Execution Artifacts

For Windows:

Downloaded File
      +
Prefetch
      +
UserAssist
      +
Event Log

For Linux:

Downloaded File
      +
Shell History
      +
Sudo
      +
Service Logs

For memory:

Downloaded File
      +
Process Record
      +
Command Line

Use whichever evidence is available.

Part 22 — Correlate Process and Network Evidence

Example:

Memory:
training-app.exe PID 4240
→ 203.0.113.20:443

and:

PCAP:
endpoint
→ 203.0.113.20:443

When timing aligns, this strongly supports process/network association.

Part 23 — Correlate Authentication with Process Activity

Example:

09:10 User logon

09:12 explorer.exe activity

09:15 training-app.exe

This provides user-session context.

But:

User session ≠ human intent.

Maintain that distinction.

Part 24 — Correlate Deleted Files

Suppose Lab 03 found:

10:15 report.docx deleted

and Lab 04 found:

10:10 report.docx referenced by LNK

The sequence supports:

File referenced
      ↓
File subsequently deleted

It does not automatically identify who deleted it.

Part 25 — Correlate USB Activity

Example:

11:00 USB connected

11:02 LNK references E:\report.docx

11:05 file appears in local Documents

This may raise a file-transfer hypothesis.

But copying should not be considered confirmed without stronger evidence.

Part 26 — Build the Cross-Evidence Correlation Matrix

Create:

Event	Disk	Windows/Linux	Memory	Browser	Network	Confidence
Email interaction				Yes	DNS	High
File download	File			Yes	HTTP	High
Process execution	File	Prefetch	Yes			High
Network communication			Process		PCAP	High

Part 27 — Assign Confidence Levels

Use:

Confirmed

Direct evidence strongly supports the event.

Supported

Multiple artifacts support the interpretation.

Probable

Evidence strongly suggests the event but has a meaningful gap.

Possible

Evidence is consistent but incomplete.

Unconfirmed

Insufficient evidence.

Example:

Event	Confidence
File downloaded	Confirmed
File executed	Supported
Human intentionally executed it	Unconfirmed

Part 28 — Build the Confidence Register

Create:

Event ID	Event	Confidence	Why
EVT-004	Download	Confirmed	Browser + file + hash
EVT-005	Execution	Supported	Prefetch + memory

Part 29 — Identify Evidence Gaps

A professional timeline should explicitly show what is missing.

Examples:

No browser history during 09:30–09:40

Missing authentication logs

No memory acquisition

PCAP starts after initial incident

No endpoint telemetry

Deleted file unrecoverable

Create:

Gap	Period	Impact	Follow-Up
No PCAP	09:00–09:05	Cannot validate initial communication	Proxy logs

Part 30 — Understand Why Gaps Matter

Without documenting gaps, an apparently complete timeline can give false confidence.

For example:

09:10 Event A
09:30 Event B

does not mean nothing happened during those twenty minutes.

Part 31 — Identify Contradictory Evidence

Examples:

Browser says download completed
but filesystem file absent.

or:

Endpoint timestamp differs substantially from network sensor.

Record contradictions rather than hiding them.

Part 32 — Build the Contradiction Register

Issue	Evidence A	Evidence B	Possible Explanation
File absent	Download record	Disk	Deleted/moved/incomplete image

Part 33 — Resolve Contradictions Carefully

Possible explanations include:

• timezone mismatch

• clock skew

• deletion

• evidence collection gap

• software behavior

• parser differences

• incomplete acquisition

Do not force a resolution when evidence remains uncertain.

Part 34 — Identify Anchor Events

Anchor events are particularly reliable events around which other activities can be organized.

Examples:

Email delivery

Successful authentication

File creation

Process creation

TCP session establishment

File deletion

Choose several anchors.

Part 35 — Build the Anchor Event Register

Anchor	Time	Source	Reliability
Email received		Mail server	High
File created		Filesystem	High
Process created		Memory	High

Part 36 — Build Activity Phases

Instead of viewing hundreds of events independently, group them.

Possible incident phases:

Phase 1 — Initial Contact

Phase 2 — User Interaction

Phase 3 — File Acquisition

Phase 4 — Execution

Phase 5 — Network Activity

Phase 6 — Privileged/System Activity

Phase 7 — Cleanup / Deletion

Only include phases supported by evidence.

Part 37 — Example Phase 1 — Initial Contact

Possible evidence:

Email Received

Sender Information

URL Present

Attachment Present

Conclusion:

The suspicious training message was delivered to the target mailbox.

Part 38 — Example Phase 2 — Interaction

Possible evidence:

Browser History

DNS Query

Network Connection

Conclusion:

Evidence supports interaction with the case-relevant destination.

Part 39 — Example Phase 3 — File Acquisition

Possible evidence:

Browser Download

Network Transfer

Filesystem Creation

Hash Match

Conclusion:

The designated training file was downloaded to the endpoint.

Part 40 — Example Phase 4 — Execution

Possible evidence:

Prefetch

Memory Process

Command Line

Event Log

Conclusion:

The available artifacts support execution of the training application.

Part 41 — Example Phase 5 — Network Activity

Possible evidence:

Memory Connection

DNS

PCAP

Proxy Log

Conclusion:

The process or endpoint communicated with the observed external destination.

Part 42 — Example Phase 6 — System Changes

Possible evidence:

Sudo

Service Modification

Scheduled Task

Registry

Filesystem Change

Conclusion depends on what evidence is present.

Part 43 — Example Phase 7 — Deletion

Possible evidence:

Recycle Metadata

Deleted Files

Filesystem Metadata

LNK References

Conclusion:

Relevant file deletion activity occurred during the investigation period.

Do not automatically call this anti-forensics.

Part 44 — Build the Master Incident Timeline

Your master timeline should include:

Normalized Time	Event ID	Phase	Source	Event	Confidence
09:01	EVT-001	Contact	Email	Message delivered	Confirmed
09:06	EVT-002	Interaction	Browser	URL visited	Confirmed
09:08	EVT-003	Acquisition	Browser	Download	Confirmed

Part 45 — Add Source Attribution

Never write:

09:08 — File downloaded

without source context.

Prefer:

09:08:21 UTC — Browser download database records completion of
training.zip.
Source: Browser Evidence E07-02.

This makes the timeline auditable.

Part 46 — Create a Compact Analyst Timeline

In addition to the detailed forensic timeline, create an analyst-readable version.

Example:

09:01 Email received

09:06 Link interaction supported

09:08 File downloaded

09:10 Execution evidence identified

09:11 External communication observed

09:30 File deleted

Use this for executive reporting.

Part 47 — Distinguish Sequence from Causation

Suppose:

09:10 File executed
09:11 External connection

The correct statement may be:

Network communication occurred shortly after file execution.

Not necessarily:

File execution caused the network communication.

Causality needs connecting evidence.

Part 48 — Build Causal Relationship Ratings

Use:

Directly Linked

Strongly Correlated

Temporally Related

Possible Relationship

No Proven Relationship

Create:

Event A	Event B	Relationship
Download	File creation	Directly Linked
Execution	Network connection	Strongly Correlated

Part 49 — Build an Incident Graph

Conceptually:

Email
  ↓
URL
  ↓
Browser
  ↓
DNS
  ↓
Download
  ↓
File
  ↓
Execution
  ↓
Process
  ↓
Network
  ↓
System Activity
  ↓
Deletion

Mark uncertain relationships with:

?

Example:

File
  ?
  ↓
Execution

if execution evidence is incomplete.

Part 50 — Create the Evidence Relationship Map

For each major event:

Event
├── Primary Evidence
├── Supporting Evidence
├── Contradicting Evidence
├── Confidence
└── Remaining Question

Example:

File Execution
├── Prefetch
├── Memory Process
├── Event Log
├── Confidence: High
└── Actor Intent: Unknown

Part 51 — Build the Event Evidence Matrix

Create:

Event	Primary Evidence	Corroborating Evidence	Confidence
Email received	Mail server	mailbox	High
URL visited	Browser	DNS + PCAP	High
File downloaded	Browser	filesystem + network	High
Executed	Prefetch	memory	High

Part 52 — Separate Fact, Interpretation, Hypothesis

Fact

Browser history contains the training URL at 09:06.

Interpretation

The endpoint browser accessed the URL around 09:06.

Hypothesis

The employee intentionally clicked the phishing link.

Do not collapse these levels.

Part 53 — Build the Hypothesis Register

Create:

Hypothesis	Supporting Evidence	Contradiction	Status
Link clicked	Browser + DNS	None	Supported
File executed	Prefetch + memory	None	Confirmed
User intentionally executed it	Session context	No direct intent evidence	Unconfirmed

Part 54 — Reevaluate Earlier Hypotheses

Review hypotheses from Labs 03–08.

Some may now move from:

Possible

to:

Supported

or:

Confirmed

Others may become disproven.

Update them.

Part 55 — Identify Negative Evidence

Examples:

No execution artifact found

No network connection after download

No privilege activity

No persistence configuration

No relevant USB activity

Security control blocked file

Negative evidence is useful.

But remember:

Absence of evidence is not always evidence of absence.

Part 56 — Build the Negative Evidence Register

Question	Expected Evidence	Found	Interpretation
Was file executed?	Prefetch/process	No	Not confirmed
Was USB used?	Registry/LNK	No	No supporting evidence

Part 57 — Determine the Earliest Supported Event

Ask:

What is the earliest event directly supported by the collected evidence?

Record:

Earliest Relevant Event:

Time:

Source:

Confidence:

This becomes the beginning of your reconstruction.

Part 58 — Determine the Latest Supported Event

Record:

Latest Relevant Event:

Time:

Source:

Confidence:

This defines the observed investigation window.

Part 59 — Define the Incident Window

Create:

Incident Start:

Incident End:

Pre-Incident Context Window:

Post-Incident Context Window:

For example:

Incident:
09:00–10:30

Context:
08:30–11:00

Context windows help identify lead-up and follow-up activity.

Part 60 — Identify the Most Important Event

Ask:

Which event changes the interpretation of the case most?

Examples:

• successful execution

• privileged action

• external communication

• file deletion

• confirmed download

Document why.

Part 61 — Identify the Strongest Correlation

Example:

Browser Download
      +
Network Transfer
      +
Filesystem Hash Match

This may establish a download with very high confidence.

Record:

Strongest Correlation:

Evidence Sources:

Conclusion:

Confidence:

Part 62 — Identify the Largest Evidence Gap

Example:

No endpoint telemetry between 09:20 and 09:45.

Explain:

• why it matters

• which conclusions it limits

• what evidence could reduce uncertainty

Part 63 — Build the Unanswered Questions Register

Create:

Question	Why Important	Needed Evidence
Who initiated execution?	Attribution	User/session telemetry
Was data transferred externally?	Impact	Proxy/PCAP/file logs

This helps define follow-up investigation.

Part 64 — Reconstruct the Incident Narrative

Now convert the timeline into a concise narrative.

Example:

At approximately 09:01 UTC, the training mailbox received the
case-relevant email.

At 09:06 UTC, browser evidence records a visit to the URL contained
in the message. DNS and network evidence independently support
communication with the corresponding destination.

At 09:08 UTC, the browser download database records acquisition
of the designated training file. The endpoint filesystem contains
a file with a matching SHA-256 value.

At 09:10 UTC, endpoint and memory evidence support execution of
the associated training application.

Shortly afterward, network evidence records communication with
the designated external training endpoint.

Notice the language:

evidence supports

rather than dramatic assumptions.

Part 65 — Add Confidence to the Narrative

Example:

Email delivery:
Confirmed

URL interaction:
Confirmed

File download:
Confirmed

Execution:
High confidence

External communication:
Confirmed

Human intent:
Unconfirmed

This makes the report more defensible.

Part 66 — Create the Executive Incident Sequence

Create:

1. Suspicious email delivered.

2. Case-relevant URL accessed.

3. Domain resolved and external connection established.

4. Training file downloaded.

5. Endpoint evidence supports execution.

6. Relevant network communication followed.

7. Later file deletion activity observed.

Only include events actually supported by the lab evidence.

Part 67 — Build the Final Incident Reconstruction Matrix

Phase	Event	Evidence	Confidence	Gap
Initial Contact	Email delivered	Mail	Confirmed	None
Interaction	URL accessed	Browser + DNS	Confirmed	Human intent
Acquisition	File downloaded	Browser + disk	Confirmed	None
Execution	App executed	Prefetch + memory	High	Actor
Network	External connection	Memory + PCAP	High	Content
Cleanup	File deleted	Filesystem	Confirmed	Actor

Part 68 — Maintain Evidence Lineage

Your final reconstruction may combine many artifacts.

Conceptually:

CASE-001
   │
   ├── E01 Disk
   ├── E02 Windows
   ├── E03 Linux
   ├── E04 Memory
   ├── E05 Email
   ├── E06 Browser
   ├── E07 DNS
   └── E08 PCAP
          │
          ▼
      Timeline Events
          │
          ▼
   Incident Reconstruction

Every important timeline event must be traceable to one or more original evidence sources.

Part 69 — Create the Timeline Evidence Register

Event ID	Evidence ID	Artifact	Source Path	Hash
EVT-001	E05	Email
EVT-002	E06	Browser DB
EVT-003	E08	PCAP

Part 70 — Validate the Timeline

Before finalizing, ask:

Are all times normalized?

Are timestamp meanings correct?

Does every event have evidence?

Did I accidentally treat sequence as causation?

Are confidence levels appropriate?

Are contradictions documented?

Are gaps visible?

Can another investigator reproduce the timeline?

If not, revise.

Part 71 — Mission Challenge

Using the complete training evidence set, complete:

CASE INFORMATION

Case ID:

Incident Name:

Primary Endpoint:

Primary User Context:

Incident Start:

Incident End:

Timeline Standard:


EVIDENCE SOURCES

Disk:

Windows:

Linux:

Memory:

Email:

Browser:

DNS:

Network:


INITIAL CONTACT

Email Received:

Sender:

URL / Attachment:

Confidence:


USER / ENDPOINT INTERACTION

URL Visit:

Browser Evidence:

DNS Evidence:

Network Evidence:

Confidence:


FILE ACQUISITION

Downloaded File:

Download Time:

Destination:

Network Transfer:

Hash Match:

Confidence:


EXECUTION

Program/File:

Execution Time:

Prefetch:

Memory:

Event Log:

User Context:

Confidence:


NETWORK ACTIVITY

Process:

Destination:

Domain:

IP:

Protocol:

Time:

PCAP Evidence:

Confidence:


SYSTEM ACTIVITY

Privilege Activity:

Service Activity:

Scheduled Task:

File Changes:

Confidence:


DELETION / CLEANUP

Deleted Artifact:

Deletion Time:

Evidence:

Actor Identified:
Yes / No

Confidence:


MASTER TIMELINE

Event 01:

Event 02:

Event 03:

Event 04:

Event 05:

Event 06:

Event 07:

Event 08:


CORRELATION

Strongest Correlation:

Evidence Sources:

Highest-Confidence Event:

Lowest-Confidence Event:

Largest Evidence Gap:

Contradictory Evidence:


FINAL RECONSTRUCTION

What Is Confirmed:

What Is Strongly Supported:

What Is Possible:

What Is Unconfirmed:

What Is Disproved:

Most Important Finding:

Remaining Questions:

Recommended Next Investigation:

Part 72 — What Not to Do

Do not:

Mix timezones silently

Treat collection time as event time

Treat filesystem timestamps as user actions

Treat sequence as causation

Invent missing events

Hide contradictions

Ignore evidence gaps

Assume an account identifies a human

Assume email delivery proves interaction

Assume download proves execution

Assume execution proves compromise

Assume external traffic is malicious

Assume deletion proves anti-forensics

Create false timestamp precision

Remove inconvenient evidence

Write conclusions stronger than the evidence

The rule is:

Time → Source → Correlation → Confidence → Conclusion

Part 73 — Troubleshooting

Timestamps Do Not Align

Check:

• timezone

• UTC conversion

• daylight saving

• clock skew

• parser semantics

• log delays

Document unresolved differences.

Browser Time Is Very Different

Check whether the browser stores timestamps in:

• UTC

• Unix epoch

• another application-specific format

Use the forensic parser carefully.

No Evidence Exists Between Two Events

Create an explicit evidence gap.

Do not fill it with assumptions.

Two Sources Contradict

Record both.

Investigate source reliability and timestamp semantics.

Too Many Timeline Events

Prioritize:

• incident-relevant events

• anchor events

• authentication

• execution

• network

• file changes

• security-control activity

Keep low-value noise outside the primary timeline.

Evidence Requirements

Capture:

Evidence 01

Evidence Source Register.

Evidence 02

Timestamp Source Register.

Evidence 03

Timezone Register.

Evidence 04

Raw Event Register.

Evidence 05

Normalized Event Register.

Evidence 06

Preliminary Timeline.

Evidence 07

Cross-Evidence Correlation Matrix.

Evidence 08

Confidence Register.

Evidence 09

Evidence Gap Register.

Evidence 10

Contradiction Register.

Evidence 11

Anchor Event Register.

Evidence 12

Activity Phase Map.

Evidence 13

Master Incident Timeline.

Evidence 14

Causal Relationship Register.

Evidence 15

Event Evidence Matrix.

Evidence 16

Hypothesis Register.

Evidence 17

Negative Evidence Register.

Evidence 18

Unanswered Questions Register.

Evidence 19

Incident Reconstruction Matrix.

Evidence 20

Timeline Evidence Register.

Evidence 21

Executive Incident Sequence.

Evidence 22

Final Incident Reconstruction Report.

Mission Deliverables

Complete:

• all evidence sources inventoried

• timestamp meanings documented

• timezone information identified

• timestamps normalized

• clock-skew issues documented

• raw events collected

• events categorized

• preliminary timeline built

• email/browser evidence correlated

• browser/DNS evidence correlated

• DNS/network evidence correlated

• download/filesystem evidence correlated

• execution evidence correlated

• process/network evidence correlated

• deleted-file evidence incorporated

• confidence levels assigned

• gaps identified

• contradictions documented

• anchor events selected

• incident phases built

• master incident timeline completed

• sequence separated from causation

• hypotheses reevaluated

• negative evidence documented

• incident window defined

• unanswered questions recorded

• evidence lineage maintained

• incident narrative written

• executive sequence created

• final report completed

Lab Report Template

# Lab 09 — Incident Timeline Reconstruction & Evidence Correlation

## Executive Summary

## Mission Objective

## Case Information

## Evidence Sources

## Evidence Integrity

## Timeline Methodology

## Timezone and Clock Analysis

## Timestamp Normalization

## Raw Event Collection

## Event Classification

## Preliminary Timeline

## Cross-Evidence Correlation

### Email and Browser
### Browser and DNS
### DNS and Network
### Download and Filesystem
### Execution Evidence
### Process and Network
### Authentication and User Context
### Deleted File Activity

## Anchor Events

## Incident Phases

## Master Incident Timeline

## Confidence Assessment

## Evidence Gaps

## Contradictory Evidence

## Negative Evidence

## Investigation Hypotheses

## Unanswered Questions

## Incident Reconstruction

## Executive Incident Sequence

## Findings

## Limitations

## Recommended Follow-Up

## Conclusion

## Appendix A — Evidence Register

## Appendix B — Master Timeline

## Appendix C — Correlation Matrix

## Appendix D — Evidence Lineage

Knowledge Check

Question 1 — Why normalize timestamps?

To place evidence from different systems into a common chronological reference.

Question 2 — Does an earlier event automatically cause a later event?

No.

Chronology establishes sequence, not necessarily causality.

Question 3 — What is an anchor event?

A particularly reliable event used to organize other timeline evidence.

Question 4 — Why retain original timestamps after normalization?

To preserve the source evidence and make conversions auditable.

Question 5 — What is clock skew?

A difference between the clocks of evidence-generating systems.

Question 6 — Why identify evidence gaps?

Because missing visibility limits the conclusions that can be drawn.

Question 7 — Should contradictory evidence be removed?

No.

It should be documented and investigated.

Question 8 — What creates a high-confidence event?

Usually multiple independent evidence sources consistently supporting the same activity.

Question 9 — Does a complete-looking timeline mean the investigation has complete evidence?

No.

A timeline is limited by the available evidence.

Question 10 — What is the goal of forensic timeline reconstruction?

To produce the most defensible sequence of events supported by the available evidence while clearly identifying uncertainty.

Skills Achieved

After completing this lab, you should understand:

• multi-source evidence correlation

• timestamp semantics

• timezone normalization

• clock-skew handling

• raw event collection

• event categorization

• chronological sorting

• anchor events

• cross-evidence correlation

• confidence assessment

• evidence gaps

• contradictory evidence

• negative evidence

• incident phases

• master timeline construction

• causality limitations

• hypothesis validation

• event-source attribution

• evidence lineage

• incident narrative writing

• executive timeline creation

• professional forensic reconstruction

Professional Takeaway

Timeline reconstruction is where individual forensic artifacts become an investigation.

The workflow is:

Email
   +
Browser
   +
Disk
   +
Windows / Linux
   +
Memory
   +
DNS
   +
Network
   =
Incident Timeline

But simply stacking timestamps is not enough.

You must understand:

What happened?

When?

Which artifact says so?

How reliable is it?

Which other evidence supports it?

What contradicts it?

What remains unknown?

Always distinguish:

Event A Before Event B
        ≠
Event A Caused Event B

Account Activity
        ≠
Human Identity Proven

File Downloaded
        ≠
File Executed

Process Executed
        ≠
Compromise Proven

File Deleted
        ≠
Anti-Forensics Proven

The professional reconstruction model is:

Time → Artifact → Source → Correlation → Confidence → Narrative

And the strongest forensic report is not the one that claims to know everything.

It is the one that clearly distinguishes:

what happened, what probably happened, what may have happened, and what the evidence cannot establish.

What’s Next?

➡️ Lab 10 — Enterprise Digital Forensics Capstone

This is the final lab in the Digital Forensics track.

You will receive a simulated enterprise incident involving multiple evidence sources and will conduct the investigation end to end.

You will bring together:

• evidence handling

• chain of custody

• disk forensics

• deleted-file investigation

• Windows artifacts

• Linux artifacts

• memory

• browser/email evidence

• network forensics

• timeline reconstruction

• evidence correlation

• findings

• executive reporting

The final methodology becomes:

Case Intake → Preserve → Verify → Triage → Examine → Correlate → Reconstruct → Find → Report → Defend

The final challenge will be:

“Can you independently investigate a multi-system enterprise incident and produce conclusions that another investigator, technical team, or management stakeholder can understand, verify, and defend?”