Skip to content
Pre-launch / First modules December 14, 2026.Lessons and community run on Skoolhttps://www.skool.com/dfir
DFIR
Forensic methods

Timeline analysis

Author: Rob T. Lee

Drafted with AI assistance for Rob’s review. Not yet reviewed or signed by Rob; the personal statement below awaits his own words.

What timeline analysis does

Timeline analysis reconstructs activity by comparing events and timestamps from digital evidence. An examiner starts with a question, identifies relevant records, interprets their time fields, and tests whether independent sources support the proposed sequence. The result is an explanation of what happened, when, and with what uncertainty, not simply a spreadsheet sorted by date. A timeline can narrow an initial-access window, connect execution to a logon, or show where the available evidence cannot distinguish competing explanations.

Why it works

Different components record activity for different reasons. A file system maintains metadata, a browser stores visits and downloads, and an event provider records selected system activity. When these records agree, they can support an explanation more strongly than any one record alone. When they disagree, that disagreement may reveal a clock problem, copying behavior, missing collection or manipulation.

Independence matters. Two parser outputs derived from the same underlying record are not two separate confirmations. Nor are timestamps necessarily independent just because they appear in different files: both may depend on the same incorrect system clock. Keep the original source, timestamp field and interpretation attached to each important event.

The two kinds of timeline

File system timeline

A file system timeline organizes metadata such as creation, modification and access-related times. In the Ashgrove Mutual investigation, it helps locate files around the first suspicious activity. It cannot by itself establish who operated the computer, whether a program executed, or why a file changed. Copying, extraction, restoration and timestamp manipulation can all complicate the apparent sequence.

Super timeline

A super timeline adds other artifact families, including event logs, registry records, browser activity and execution-related traces. This broader view supports corroboration but also adds irrelevant events and duplicates. It does not repair missing evidence or turn every timestamp into a user action. Filter by the question and preserve enough context to revisit an interpretation.

Common mistakes

  • Ignoring time zones and clock differences. Preserve original values and record conversions, offsets and daylight-saving assumptions. Normalizing display to UTC does not correct a source clock that was wrong.
  • Ignoring timestamp semantics. Ask what operation updates the field, which object it describes, and its precision. A modification time, registry key last-write time and log event time do not mean the same thing.
  • Assuming order from one source. Closely spaced or equal timestamps may not establish causal order. Seek independent corroboration and report a range when the evidence cannot support an exact instant.
  • Treating missing events as proof of absence. Collection scope, retention, disabled logging and parsing limitations can all hide relevant activity. Document those gaps alongside the findings.

Worked example: Ashgrove Mutual

Module 06, Build the first timeline, starts with three confirmed hosts and counsel asking when the intrusion began. The assigned deliverable is a file-system timeline of the claims workstation with the initial-access window bracketed. The steps below use that case question and the sample commands shown on the homepage.

Illustrative walkthrough, not a report from the lab files. The Ashgrove evidence files, trusted acquisition hashes and measured results have not been supplied here. The filename case01.E01 is a sample name; no event times, file hashes or row counts below are claimed as observations from that evidence set.

  1. Verify and scope the input. Work from an examination copy and compare its container hash with the corresponding trusted acquisition record. Record the tool versions and time-zone settings. For source-media integrity, also use the evidence format’s verification procedure; a container hash is not automatically the source-media hash.
  2. Extract and export timestamps. These are the homepage’s illustrative commands. Check the installed Plaso version’s help and the installation guide before running them. Default parser selection can create a broader timeline than module 06’s file-system view; retain source labels and filter to the relevant file-system artifacts.
$ sha256sum case01.E01
# build a timeline from the image
$ log2timeline.py case01.plaso case01.E01
$ psort.py -o l2tcsv case01.plaso > timeline.csv

The dollar sign marks the shell prompt; do not type it. These commands are not a claim that the sample exists or that this walkthrough has been executed.

  1. Test a sequence rather than invent one. Suppose the collected records show a suspicious file appearing before a known beacon. That would identify a candidate window, not prove the file caused the connection. Check which timestamp field supports the appearance, whether copying could explain it, and whether the sources’ clocks can be compared.
  2. Corroborate and report limits. Compare that candidate window with the case’s proxy or DNS records and available execution evidence. If only file metadata supports the claim, report a file activity window, not a proven initial compromise. Record the sources, normalization steps, filters and remaining alternative explanations.

Module 07 expands the analysis into a super timeline. The defensible output is a reasoned sequence with supporting evidence and limitations, not the largest possible export.

From the person who pioneered it

These prompts await Rob T. Lee’s own words. No personal statement has been supplied or approved.

Last reviewed