timestamps

Overview

Timestamps are among the most powerful artifacts in forensics because they let you build a timeline — the sequence of events that reconstructs what happened and when. But timestamps are also subtle: a single file carries several different times, they can be recorded in different time zones, and some can be altered. This lesson explains the MAC timestamps (Modified, Accessed, Created), how file systems record them, and how to reason about them carefully.

Learning objectives

• Identify the three core file timestamps: Modified, Accessed, and Created (MAC).
• Explain what each timestamp records and when it updates.
• Understand time zones, epochs, and why normalization matters.
• Recognize that timestamps can be manipulated and how to reason about that.

Core concept

Most file systems track several timestamps for every file. The classic trio is abbreviated MAC:

• M — Modified — when the file's content last changed.
• A — Accessed — when the file was last read or opened.
• C — Created / Changed — depending on the file system, this is either when the file was created on this volume, or when its metadata last changed.

That last point is a frequent source of confusion. On Windows' NTFS, the trio is commonly Modified, Accessed, and Created (birth time). On Linux's ext4 and similar file systems, the traditional trio is Modified (mtime), Accessed (atime), and Changed (ctime), where ctime is the time the file's metadata (permissions, ownership, links) changed — not a creation time. Many modern Linux file systems also record a separate birth time (crtime). Knowing which "C" you are looking at is essential to interpreting it correctly.

How it works

Each timestamp updates on a specific trigger:

• Modified (mtime) updates when the file's data is written or changed.
• Accessed (atime) updates when the file is read. In practice, many systems disable or delay atime updates for performance (for example, the relatime or noatime mount options on Linux), so atime is less reliable than it sounds.
• Created (crtime / NTFS creation) records when the file first appeared on this volume. Copying a file to a new location can reset the creation time on the destination even though the content is old.
• Changed (ctime on Linux) updates when metadata changes — renaming, changing permissions, or changing ownership — as well as on content change.

Two more concepts are vital:

• Epoch and encoding. Internally, timestamps are stored as numbers, often as seconds (or finer units) since a fixed reference moment called an epoch (commonly midnight UTC on 1 January 1970, the "Unix epoch"). Tools convert this number to a human-readable date.
• Time zones. A stored time may be in UTC or in local time. If you read a timestamp as local time when it was actually UTC (or vice versa), your whole timeline shifts by hours. Serious examiners normalize everything to UTC and note the source time zone.

Finally, timestamps can be manipulated. Tools exist that deliberately set a file's times to arbitrary values (sometimes called timestomping). This means timestamps are strong evidence but not infallible: inconsistencies — such as a "created" time later than a "modified" time, or file-system metadata that disagrees with an application log — can reveal tampering.

Practical example

In an authorized lab you examine a suspicious file inside a disk image. The file system reports:

• Modified: 2024-03-10 09:15:00 UTC
• Accessed: 2024-03-10 09:20:00 UTC
• Created: 2024-03-10 09:14:30 UTC

This is internally consistent: the file was created, then written (modified) a few seconds later, then read (accessed) shortly after. It tells a plausible story.

Now imagine a second file shows a Created time of 2024-03-11 but a Modified time of 2024-01-02 — content older than the file's own creation. That is not impossible (copying preserves mtime while resetting crtime), but combined with other signals it might also hint at manipulation. You would not conclude "tampering" from the timestamps alone; you would treat the inconsistency as a lead and corroborate it with logs, application artifacts, and the timeline as a whole.

If the image came from a machine set to a non-UTC time zone, you would first convert each recorded time to UTC before comparing it against, say, a network capture logged in UTC — otherwise a genuine sequence could look scrambled.

Cybersecurity relevance

Timeline reconstruction is central to incident response: knowing the exact order of events — when a malicious file arrived, when it ran, when data was accessed — is how responders scope a breach and understand attacker behavior. MAC timestamps, correlated across many files and logs, are the raw material of that timeline.

Because timestamps can be altered, understanding their triggers and quirks also helps you spot anti-forensic activity. A defender who knows that atime is often unreliable, that ctime on Linux is not a creation time, and that all times must be normalized to a single zone will build accurate timelines and avoid false conclusions. In CTF forensics, challenges frequently hinge on reading a timestamp correctly, converting a raw epoch value, or noticing that times do not line up.

Common mistakes

• Confusing Linux ctime (metadata change) with a creation time — it is not the file's birth time.
• Trusting atime as "last opened" when the system may not update it.
• Ignoring time zones, shifting the entire timeline by hours and breaking correlation.
• Treating timestamps as unforgeable, forgetting they can be deliberately altered.
• Failing to convert raw epoch values correctly to human-readable UTC.

Key takeaways

• Files carry multiple timestamps; the MAC trio is Modified, Accessed, and Created/Changed, and each updates on a different trigger.
• The meaning of "C" differs by file system: NTFS Created is a birth time, while Linux ctime is a metadata-change time (with crtime as a separate birth time).
• Normalize all times to UTC and note the source time zone; raw values are stored relative to an epoch and must be converted correctly.
• Timestamps are powerful for building timelines but can be manipulated; inconsistencies are leads to corroborate, not proof on their own.

Check your understanding

• On a Linux ext4 file system, why is ctime not the same as the file's creation time, and what does it actually record?
• Why must an examiner normalize timestamps to UTC before correlating file times with a network capture?