๐Ÿ”Ž Digital forensics

Forensic Timelines: Reconstructing Events from Digital Data

How a forensic timeline is built: sources of dates and times, time zones, normalisation, super timelines and how to read sequences of events correctly.

Many questions in a digital investigation are about time. When was that file opened? Was the document changed before or after the email? Did the suspicious login happen while the user was at the office? A forensic timeline is the tool that puts events from different sources in chronological order and lets you read them as a coherent story.

Where dates and times come from

A single computer holds dozens of time sources. Each records different events, with different precision.

Source Examples of events
File system Creation, modification, access, metadata change of a file
System logs Start-ups, logins, installations, errors
Browser Pages visited, downloads, searches
Email Sending and receiving messages
Documents Internal creation and save dates
Applications Histories, recent files, synchronisations
External sources Router logs, cloud service logs, door badge records

Each of these, on its own, gives a partial view. Together they reveal sequences that no single source shows.

The time zone problem

This is the first obstacle and the trickiest. Some sources record times in UTC, Coordinated Universal Time; others in the device's local time; others in their own format. A server log in UTC and a message stamped in Italian time may appear one or two hours apart when they are actually simultaneous.

Daylight saving time must also be considered: the same local time corresponds to different UTC values in summer and winter. And if the device was set to a different time zone, for example a laptop used while travelling, local times can be misleading.

The practical rule is to convert everything to a single reference, usually UTC, and to state clearly in the report which time zone is used for presentation.

The device clock

A timestamp is only as reliable as the clock that produced it. A computer whose clock is ten minutes slow will record every event ten minutes off. That is why, during acquisition, the system time is noted and compared with a reliable source, and the logs are searched for any manual clock changes, which can themselves be a clue.

Building the timeline

Targeted timeline

You start from a precise question and a limited window, for example the two hours around an email being sent. You collect only the relevant events and put them in order. This is the quickest and most readable approach.

Super timeline

Specialised tools automatically extract events from every available source on a drive and merge them into a single sequence. The result can contain millions of lines. It is powerful for discovering the unexpected, but needs careful filtering to avoid getting lost in the noise.

In practice both are often used: the super timeline to find the interesting moments, the targeted timeline to explain them.

Reading events correctly

A timeline must be interpreted with care. Some examples:

  • a file access does not mean a person opened it: antivirus software, indexing and previews can "touch" files automatically;
  • events in very quick succession across many files often indicate an automated operation, such as a bulk copy, a synchronisation or an extraction;
  • the absence of events does not prove nothing happened: logs can be disabled, overwritten or never have existed;
  • timing is not causation: two close events are not necessarily linked.

An example

A company suspects that an employee copied a confidential file. The timeline shows, within a few minutes: the user logging on to the computer, a USB device being connected, the folder containing the file being opened, a series of rapid accesses to many files and finally the device being removed. Each event alone is harmless. The sequence tells a much more precise story, which must still be checked against other sources, such as whether the person was physically present at the time.

Presenting the timeline

Readers of the report should not have to wade through thousands of lines. It is best to:

  1. list only the relevant events in a table, with date, time, source and description;
  2. state the time zone used explicitly;
  3. distinguish certain events from inferred ones;
  4. attach the full extraction for anyone who wants to verify it.

A simple chart showing events along a time line greatly aids understanding.

In short

  • A timeline orders events from many sources to reconstruct a sequence.
  • Time zones, daylight saving and wrong clocks must be handled with a single reference.
  • Targeted timelines answer precise questions; super timelines help discovery.
  • A recorded event does not always correspond to a human action.
  • The report should state the time zone used and separate facts from inferences.
MM
Marco Marzaduri

Marco Marzaduri works in cybersecurity, digital forensics and web development. With degrees in computer science and psychology, he combines technical analysis with an understanding of the human factor.

Read also