Reconstructing Events: Timelines, File Systems and Logs

What you'll be able to do

By the end of this lesson you will be able to reconstruct what happened, and in what order, from the traces a system keeps.

• Build a simple timeline from file-system timestamps and logs.
• Read the four common file timestamps and explain their limits.
• Recognize signs that timestamps or logs have been tampered with.

Three Techniques, One Goal

The book presents three techniques that work together to answer the investigator's favorite question: what happened, and when?

• Timeline analysis constructs a timeline of events to establish the sequence of activities leading up to or during an incident, by analyzing metadata and system logs.
• File system analysis examines the structure and contents of file systems to find suspicious activity, hidden files or unauthorized data: for example, file creation and modification times, or signs of tampering such as hidden partitions or encrypted areas.
• Log file analysis reviews system and application logs for anomalies, unauthorized access or signs of attack, such as repeated failed logins or malware indicators, and correlates logs from several sources to build a complete picture.

File Timestamps: MACB

Most file systems record several times for each file. Examiners often summarize them as MACB:

• M — Modified: when the file's contents last changed.
• A — Accessed: when the file was last read or opened.
• C — Changed: when the file's metadata record last changed (on NTFS, its entry in the Master File Table).
• B — Born: when the file was created on this volume.

Two cautions turn a beginner into a careful examiner:

• Copying changes the story. A file copied to a new drive usually gets a new "born" time on that drive, while its "modified" time may be carried over from the original. It can look as if a file was modified before it was created. That is normal, and it is itself a clue that the file was copied.
• Access times are unreliable. Windows can defer or turn off updates to the Last Access time for performance; Microsoft documents a setting that does exactly this. Never treat an access time on its own as proof that someone opened a file.

Logs: The System's Diary

Operating systems, applications, firewalls and cloud services all write logs. On Windows, the Security log records sign-in events. Two of the most used are event 4624, an account successfully logged on, and event 4625, an account failed to log on. A burst of 4625 events followed by a single 4624 for the same account is a classic pattern of a password being guessed and then found.

Correlation is where logs become powerful. A firewall log shows a connection; a Windows log shows a sign-in at the same moment; a file system timestamp shows a document modified a minute later. Each source alone is weak, and together they tell a story.

Always normalize time. Different systems record time in different time zones, and clocks drift. Convert everything to UTC, and record any clock difference you find on each device, before you put events side by side.

Building a Timeline

A simple method:

1. List every relevant event from every source, each with its time, time zone, source and what it shows.
2. Convert to a single time zone (usually UTC).
3. Sort, then look for sequences (this happened, then that), gaps and contradictions.
4. Mark anything uncertain, and never let one unreliable timestamp carry a conclusion alone.

Tools can merge thousands of sources into one "super timeline". Autopsy, for example, includes a timeline viewer and a module for Plaso, an open-source timeline engine.

Tampering: When Times Lie

Attackers know examiners rely on time. MITRE ATT&CK, the widely used knowledge base of attacker techniques, lists timestomping ("adversaries may modify file time attributes to hide new files or changes to existing files") and indicator removal, such as clearing logs. On NTFS, each file carries more than one set of timestamps, chiefly in its $STANDARD_INFORMATION and $FILE_NAME attributes, and tools that change times do not always change every set consistently, so examiners compare them for discrepancies. MITRE notes that some attackers change both sets (sometimes called double timestomping). Gaps in a log, or a log cleared at a suspicious moment, can be evidence in their own right. NIST's 2022 review warns that deliberate changes meant to mislead an examiner may be hard to detect, which is why no single timestamp should carry a case.

Real-World Example

Imagine (a fictional scenario) a law firm that suspects someone logged into a partner's workstation overnight. The examiner's timeline, in UTC:

Each line comes from a different source, and they agree. The examiner reports a sequence consistent with a password-guessing attack followed by access and data upload. She notes that the account name alone does not prove which person was at the keyboard.

From the Book to 2026

What the book teaches. Build timelines from metadata and logs; analyze file system metadata such as creation and modification times; parse and correlate logs.

Why it made sense. These techniques remain the backbone of almost every investigation.

What has changed. Two developments. Anti-forensics is better documented and more common: MITRE ATT&CK catalogs timestomping and log clearing, and attackers increasingly target every timestamp, not just the obvious ones. More of the timeline lives outside the device: identity providers, email services and cloud platforms keep their own audit logs, often for limited retention periods, so investigators must request or export them quickly. Lesson 3.2's "forensic readiness" (logging switched on, clocks synchronized, logs retained) decides whether a timeline can be built at all.

What to do now. Build timelines from several independent sources, normalize all times to UTC, treat access times and any single source with caution, and look actively for gaps and inconsistencies that suggest tampering.

Watch: Windows MACB Timestamps

This video from 13Cubed, a well-known digital forensics education channel, explains Windows MACB timestamps on NTFS.

Questions to keep in mind as you watch:

• What exactly does each of the four timestamps record?
• Which everyday actions, such as copying, moving or editing, change which timestamps?
• How could an examiner spot timestamps that have been altered deliberately?

The video complements what you just read. The lesson is complete without it.

What Would You Do?

A file's NTFS times show it was modified in 2023 but born on this laptop in 2026. The suspect's lawyer says this proves the file was planted after seizure. What is the more likely explanation, and how would you check it? Decide, then compare with the model answer in the note below.

Knowledge Check

Key Takeaways

• Timelines combine file system metadata and logs to show what happened and in what order.
• MACB: Modified, Accessed, Changed, Born. Copying changes born times, and access times are unreliable.
• Correlate several independent sources and normalize everything to UTC.
• Watch for timestomping and cleared logs. No single timestamp should carry a conclusion.

Sources

• Dr. Tahseen Al-Doori — IT Forensics Essentials: Concepts, Tools, and the Practice of Digital Investigation, Chapter 5 (c, d, g)
• Microsoft Learn — Event 4624: An account was successfully logged on
• Microsoft Learn — Event 4625: An account failed to log on
• Microsoft Learn — fsutil behavior (Last Access Time updates)
• MITRE ATT&CK — T1070.006 Indicator Removal: Timestomp
• MITRE ATT&CK — T1070 Indicator Removal
• NIST — IR 8354: Digital Investigation Techniques: A NIST Scientific Foundation Review (November 2022)
• Autopsy User Documentation (Timeline viewer; Plaso module)