timestamps

Overview

Almost every file carries timestamps — recorded moments describing when it was created, modified, or accessed. In metadata analysis, timestamps are among the most valuable clues: they let you build a timeline, order events, spot inconsistencies, and answer "when did this happen?" But timestamps come from several different sources that do not always agree, and understanding those sources is what separates a careful analyst from someone who is easily misled. This lesson explains the kinds of timestamps you will meet and how to reason about them.

All work is on files you own or that a challenge provides, in an authorized, isolated setting.

Learning objectives

• Distinguish content (metadata) timestamps from filesystem timestamps.
• Explain the MAC timestamps (Modified, Accessed, Created/Changed).
• Understand how time zones and formats affect interpretation.
• Use timestamps to build a timeline and detect inconsistencies.

Core concept

A timestamp is a recorded point in time, but the essential idea is that a single file can have many timestamps from different layers, and they answer different questions:

• Content/embedded timestamps live inside the file's own metadata — for example, EXIF DateTimeOriginal in a photo or CreationDate in a PDF. They describe events meaningful to the content (when the photo was captured, when the document was authored).
• Filesystem timestamps are kept by the operating system about the file on disk, independent of the file's contents.

Because these layers are separate, they can disagree — and the disagreement is often the clue.

How it works

Filesystem timestamps are commonly summarized as MAC:

• M — Modified: when the file's contents last changed.
• A — Accessed: when the file was last read/opened.
• C — Changed or Created: on many systems this is the metadata change time (permissions, ownership, rename); on others (and in some tools) it represents the creation time. The exact meaning depends on the operating system and filesystem, so always confirm which one you are looking at.

Embedded timestamps, by contrast, are written by the application into the file's metadata (EXIF, document core properties, PDF info dictionary).

Two practical wrinkles matter constantly:

• Time zones. A timestamp may be stored in UTC, in local time, or with an explicit offset. Reading 09:31:07 without knowing the zone can put an event hours away from where it really happened. Prefer the UTC or offset-qualified value when available, and note the zone in your analysis.
• Formats. Timestamps appear in many textual formats (for example 2023:04:12 09:31:07 in EXIF versus ISO-style 2023-04-12T09:31:07Z) and as numeric epoch values (seconds since 1970). Normalize everything to one consistent format before comparing.

Practical example

A challenge gives you a document and asks you to establish its history. You collect timestamps from two layers (illustrative):

Embedded (document metadata):
  created  : 2023-02-03 14:22:10Z
  modified : 2023-02-09 08:05:41Z

Filesystem (as delivered):
  Modified : 2023-02-09 08:05:41Z
  Accessed : 2023-03-01 10:12:00Z
  Changed  : 2023-02-09 08:05:41Z

Normalizing to UTC, you build a timeline: the document was authored on Feb 3, last edited on Feb 9 (embedded and filesystem Modified agree, a good consistency check), then merely read on Mar 1. If instead the embedded created were later than the embedded modified, that impossible ordering would flag tampering — a common "spot the inconsistency" challenge design.

Cybersecurity relevance

Timestamps are foundational to digital forensics and incident response: analysts build timelines to reconstruct what an attacker did and when, correlating file MAC times with log entries. They are equally central to detecting anti-forensics: attackers sometimes alter timestamps ("timestomping") to hide activity, and an analyst catches this by finding layers that disagree — a filesystem time that contradicts an embedded time, or a "created" time that is after a "modified" time. For defenders, reliable timestamps (with synchronized clocks and consistent time zones across systems) are what make forensic timelines trustworthy in the first place.

Common mistakes

• Assuming one timestamp is the whole story rather than gathering content and filesystem times from every layer.
• Ignoring time zones, so events land at the wrong hour or even the wrong day.
• Confusing "Changed" with "Created" — their meaning varies by OS and filesystem.
• Trusting timestamps as unforgeable — they can be edited, and the next lesson explains why that limits how much you should rely on them.

Key takeaways

• Files carry timestamps in two layers: embedded content timestamps (in metadata) and filesystem timestamps (kept by the OS); they can disagree.
• Filesystem MAC times are Modified, Accessed, and Changed/Created — and the third's exact meaning depends on the system.
• Always normalize time zones and formats before comparing; unnormalized times mislead.
• Timestamps drive forensic timelines, and contradictions between layers are a key signal of tampering.

Check your understanding

• Why might the embedded creation time in a document differ from the file's filesystem "Modified" time, and what would each tell you?
• How could comparing timestamps across layers reveal that a file's times were tampered with?