Timeline Analysis

• Timeline Analysis
  • Timestamps and What They Record
    • MACB: The Four Filesystem Timestamps
    • NTFS: Two Timestamp Sets per File
  • Timestamp Sources by Platform
    • Windows
      • File System (NTFS)
      • Windows Event Logs
      • Registry
      • Prefetch
      • Browser History
      • LNK Files (Shell Link)
      • Shellbags
      • Volume Shadow Copies
    • Linux
    • macOS
  • Timestamp Reliability
    • Clock Skew
    • FAT Timestamp Precision and the Two-Second Anomaly
    • Timestamp Anti-Forensics
  • Methodology: Building a Timeline
    • Phase 1 — Establish the Incident Window
    • Phase 2 — Collect Artifacts by Source Type
    • Phase 3 — Normalize to UTC
    • Phase 4 — Merge and Sort
    • Phase 5 — Reduce Noise
  • Analysis Techniques
    • Pivot-Point Analysis
    • Pattern Identification
    • Correlation Across Sources
  • Connecting Timeline Analysis to ATT&CK
  • Tools Quick Reference
  • Further Reading

Timeline analysis is the process of reconstructing the sequence of events on a system from timestamp evidence scattered across dozens of artifact sources. A single compromised Windows host can contain tens of millions of timestamped events: file system metadata, event log entries, registry writes, browser history records, prefetch execution times, USB connection logs, and more. The investigator’s task is to assemble those events into a coherent chronological narrative, identify the attacker’s actions, and determine what data may have been exposed or destroyed.

A super-timeline is a unified, time-sorted record of events drawn from all available artifact sources simultaneously — file system, event logs, registry, browser history, prefetch, LNK files, and more — as opposed to analyzing each source separately. Combining sources matters because an attacker action (e.g., running a tool) may leave a trace in only one artifact type; cross-correlating artifact types both increases detection probability and allows independent corroboration of the same event.

This page covers the theory and methodology. Tool references:

• For filesystem-only timelines using The Sleuth Kit: The Sleuth Kit
• For multi-source super-timelines using Plaso: Plaso: Super-Timeline Forensics

Timestamps and What They Record

A timestamp records when an event occurred according to the system clock at the time. This sounds simple. In practice it is not, because:

• Different artifact sources record different kinds of events under the same label “time”
• The system clock may be wrong (clock skew, time zone misconfiguration, deliberate manipulation)
• Different storage formats have different timestamp precision
• Virtualization, dual-boot, and sleep/hibernate all introduce anomalies
• Skilled attackers deliberately falsify timestamps (timestomping)

Understanding what each timestamp actually measures — and its limitations — is a prerequisite to interpreting a timeline correctly.

MACB: The Four Filesystem Timestamps

File system metadata typically provides four timestamps per file, referred to collectively as MACB:

Common misconceptions:

• The M timestamp does not move when a file is copied — only when its contents are written. A copied malware binary will have the M timestamp from the original build, not from when it was placed on the victim system. The B timestamp reveals when it arrived.
• The A timestamp is frequently disabled or unreliable on modern Windows (NtfsDisableLastAccessUpdate is set by default since Vista). Do not rely on A timestamps on NTFS to prove file access.
• The C timestamp moves when timestamps are manually changed. On NTFS, changing the M, A, or B timestamps with a user-space tool automatically updates C — which is one reason timestomping leaves traces.
• On FAT32, timestamps have 2-second granularity (M/A/B all rounded to the nearest even second). On exFAT and NTFS, precision is 100 nanoseconds. A file with a suspiciously round timestamp (exactly 2024-03-15 10:00:00.000) on an NTFS volume may have been timestomped.

NTFS: Two Timestamp Sets per File

NTFS stores timestamps in two separate attributes, and this asymmetry is the foundation of timestomping detection:

When a file is created, both attribute sets are written with the same timestamps. Afterward:

• Normal file operations update $SI only (Windows only exposes $SI through the Win32 API)
• $FN is updated only by the kernel when the file is renamed, moved, or linked

This means a file that was created at T=100, used until T=200, then timestomped at T=300 to make it look like T=50 will show:

$SI timestamps:  M=T+50  A=T+50  C=T+300  B=T+50
$FN timestamps:  M=T+100 A=T+100 C=T+100  B=T+100

The $SI C timestamp reveals when the timestomp was performed. The $FN timestamps are unaffected. A $SI B timestamp earlier than the corresponding $FN B timestamp is the canonical timestomping indicator — files cannot exist before they were created.

Use istat from The Sleuth Kit, or the MFT parser in Plaso, to see both attribute sets for any file.

Timestamp Sources by Platform

A complete investigation draws from every available source. No single source tells the full story.

Windows

Windows is the richest environment for timeline evidence. Dozens of subsystems record timestamps independently, which is why Windows investigations benefit most from super-timeline tools like Plaso.

File System (NTFS)

The USN journal is particularly valuable: unlike $MFT timestamps (which are overwritten on reuse), the journal entries are append-only and include the reason for each change (FILE_CREATE, RENAME_OLD_NAME, RENAME_NEW_NAME, DATA_OVERWRITE, FILE_DELETE, etc.). It does not retain data indefinitely — the journal is a circular buffer, typically 32–64 MB — but it often covers the past several days of file activity.

Windows Event Logs

Event logs are timestamped to 100-nanosecond precision in UTC. They are the most direct record of security-relevant system events.

The Security log is cleared by attackers to remove evidence; its absence is itself evidence. Security event ID 1102 records when the Security log was cleared (written to the Security log itself, so it may also be absent). System event ID 104 records the same event in the System log, which is harder to suppress simultaneously — check both.

Registry

Registry key and value timestamps record the last write time of a registry key. Only the key-level timestamp is stored — individual value timestamps are not available. This is coarser than event logs but still valuable.

Key hive locations and their forensic significance:

ShimCache (AppCompatCache): Records executables that ran on the system, including their path, file size, and last-modified timestamp. Stored in SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache. Cleared only on reboot; provides execution history across reboots.

AmCache.hve: Stores SHA-1 hashes and metadata for every executed binary. Located at \Windows\AppCompat\Programs\Amcache.hve. More complete than ShimCache; survives clearing of ShimCache.

Prefetch

Windows Prefetch files (C:\Windows\Prefetch\*.pf) record:

• The executable’s name and path
• Up to 8 timestamps of the last 8 runs (Windows 8+; only the last run on XP/Vista/7)
• A run count
• The files and directories loaded during execution

Prefetch is disabled on server editions of Windows and on systems with SSDs (configurable). When present, it is among the strongest execution evidence available — a prefetch file proves a binary ran, even if the binary itself has since been deleted.

Browser History

All major browsers store history in SQLite databases in the user profile:

Each database records URL, title, visit count, and first/last visit timestamps. Download history is separate: Chrome stores downloads in the same History database; Firefox uses downloads.sqlite. These records survive browser cache clearing in most configurations.

LNK Files (Shell Link)

Windows automatically creates .lnk shortcut files when a user opens a file. These are stored in:

• %APPDATA%\Microsoft\Windows\Recent\ (recently opened files)
• %APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\ (Jump List entries)

Each LNK file records:

• The target file’s original path (even on a different drive or network share)
• The target’s size, timestamps, and volume serial number at the time of access
• The host’s MAC address and volume label

LNK files survive deletion of the original file and are powerful evidence that a user accessed a specific file on a specific date. They are created automatically by the shell regardless of the application used to open the file.

Shellbags

Shellbags are registry entries (UsrClass.dat and NTUSER.DAT) that Windows creates to preserve the display preferences (icon size, sort order, column widths) of each Explorer folder a user has opened. They persist long after the folder or file is deleted.

Forensic value: shellbags prove that a specific folder path was browsed by a specific user, with timestamps. They can reveal access to USB drives, network shares, and deleted directories when no other evidence survives.

Volume Shadow Copies

VSS snapshots are point-in-time copies of an NTFS volume. They preserve the state of all files — including $MFT, event logs, registry hives, and prefetch files — at the time of the snapshot.

On a system with VSS enabled, a deleted file may be recoverable from a shadow copy even though it no longer appears in the live file system. Similarly, an event log that was cleared on the live volume may survive intact in a shadow copy taken before the clearing.

# List available VSS snapshots on a Windows image
vshadowinfo evidence.dd

# Mount a specific VSS snapshot for examination
vshadowmount -o <offset> evidence.dd /mnt/vss

Linux

Linux systems record less structured metadata than Windows but provide detailed textual logs.

Inode timestamps on ext4: ext4 stores M, A, C timestamps with nanosecond precision and a separate “creation time” (crtime) that is preserved in the inode but not exposed by stat — use debugfs to retrieve it:

debugfs -R 'stat <inode_number>' /dev/sda1

macOS

macOS uses a combination of HFS+/APFS filesystem metadata and the Unified Log.

The quarantine extended attribute is often underutilized. A binary delivered via browser download retains the URL it was fetched from:

xattr -p com.apple.quarantine /path/to/downloaded/file
# Output: 0083;65f1a3b2;Safari;uuid
# The second field is a hex timestamp (seconds since 2001-01-01)

Timestamp Reliability

Clock Skew

All timestamps are only as accurate as the system clock. If a machine’s clock was wrong when an event occurred, every timestamp from that period is offset by the same amount. To measure skew:

• Compare the system’s last known NTP sync (recorded in the Windows System event log, event ID 37; or in /var/log/syslog on Linux) to a trusted external time source
• Look for event pairs with known sequences — a boot event followed immediately by a login event cannot predate the boot event; if it does, the clock jumped
• On Windows, examine HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters for the NTP server configuration and last sync results

All timestamps in your final timeline should be normalized to UTC. Note the evidence system’s configured time zone and record it explicitly in your case notes — it affects every timestamp interpretation.

FAT Timestamp Precision and the Two-Second Anomaly

FAT32 stores M timestamps with 2-second granularity. Created (B) timestamps on FAT include a 10ms precision field, making them more precise. Accessed (A) timestamps on FAT are date-only (no time component).

A common scenario: a file is copied from a FAT-formatted USB drive to an NTFS volume. The M timestamp is preserved from FAT (rounded to 2 seconds) while the B timestamp is newly set to the current time. If the B timestamp is more recent than M, and M has a suspiciously even-second value, the file likely came from a FAT source.

Timestamp Anti-Forensics

Timestomping: Manually setting file timestamps to mislead investigators. Tools like touch (Linux/macOS) and SetFileTime-based utilities (Windows) can set all four MACB timestamps to arbitrary values.

Detection:

• On NTFS: compare $SI and $FN timestamps; discrepancies reveal tampering (see above)
• Timestamps that predate the OS installation date on a system partition are impossible
• Timestamps that predate the compile timestamp embedded in the binary itself are impossible
• A $SI C timestamp more recent than M/A/B on NTFS indicates the other timestamps were changed after creation

Log clearing: Event logs can be cleared with wevtutil cl Security. Indicators:

• Event ID 1102 in the Security log (if the log was not entirely deleted)
• Event ID 104 in the System log records Security log clearing
• A gap in sequence numbers in the surviving event log (EVTX files embed a sequence counter)
• VSS copies may contain uncleaned logs

Log tampering: Individual EVTX records can be deleted with tools like Invoke-Phant0m or danderspritz. The result is a gap in event record numbers within the log file. The istat output for the EVTX file’s $MFT record will show a C timestamp update at the time of tampering.

Clock manipulation: Changing the system clock before performing malicious actions shifts all subsequent timestamps. Cross-reference with network packet timestamps (PCAPs use the NIC’s hardware clock), NTP event logs, and external sources like firewall logs.

Methodology: Building a Timeline

Phase 1 — Establish the Incident Window

Before collecting anything, establish a rough time window. Sources:

• Earliest known alert or detection (IDS, AV, user report)
• Earliest IOC timestamp from threat intelligence
• Last known clean backup
• Customer or user reports (“I noticed the system was slow starting last Tuesday”)

This window drives collection priorities. A 2-week window may produce 50 million events; a 4-hour window after focused triage may produce 5,000. Work from the specific toward the general — start tight and expand.

Phase 2 — Collect Artifacts by Source Type

Extract all relevant artifacts before building the timeline. Preserve originals; work from copies.

Priority order for Windows (most to least time-sensitive):

1. Memory image (volatile; if not already captured, capture first)
2. $MFT, $LogFile, $UsnJrnl:$J (file system metadata)
3. Event logs (*.evtx from \Windows\System32\winevt\Logs\)
4. Registry hives (SYSTEM, SOFTWARE, SAM, NTUSER.DAT for each user)
5. Prefetch files (\Windows\Prefetch\*.pf)
6. Browser history databases
7. LNK and Jump List files
8. VSS snapshots (if relevant to the window)
9. Full image for Plaso processing

Phase 3 — Normalize to UTC

Every artifact source must be in UTC before merging. Common pitfalls:

• Windows event logs are stored in UTC natively — no conversion needed
• NTFS timestamps are in UTC — no conversion needed
• The Windows display of timestamps in Event Viewer applies the local time zone; the raw values are UTC
• Browser SQLite databases store times in varying epochs: Chrome uses microseconds since 1601-01-01; Firefox uses microseconds since 1970-01-01 (Unix epoch); Safari uses seconds since 2001-01-01
• Log files that embed human-readable timestamps (syslog, IIS logs, Apache logs) may be in local time — check the system’s configured time zone
• FAT timestamps are in local time, not UTC — they must be converted

When in doubt, cross-reference two events whose relative order is known (e.g., a process creation event in the Security log and the same process’s prefetch file creation) to verify timezone alignment.

Phase 4 — Merge and Sort

Once normalized, merge all sources into a single chronological stream. Tools:

• TSK mactime: file-system-only; fast; body file format
• Plaso log2timeline + psort: multi-source; handles dozens of artifact types; produces CSV or JSON output (see Plaso)
• Timesketch: web-based; multi-analyst; search and annotation (accepts Plaso .plaso files directly)
• Timeline Explorer (Eric Zimmerman): Windows GUI; excellent for CSV browsing and filtering

For targeted analysis, a Plaso export filtered to the incident window is usually the right starting point. For a full investigation, run Plaso against the entire image and use psort filters to extract windows of interest.

Phase 5 — Reduce Noise

A raw Windows super-timeline may contain 5–50 million rows. Strategies:

Filter by time window. If you know the incident occurred between March 10 and March 12, filter to that range with a ±12-hour buffer.

Filter by data type. Separate filestat events (file system timestamps) from winevtx events (Windows logs) from winreg events (registry). Analyze each category focused on its own patterns before merging.

Eliminate known-good files. Any file whose SHA-256 hash appears in the NSRL (National Software Reference Library) is a known system or application file. Events involving these files during normal system operation are almost always noise.

Focus on user profile paths first. Malware that persists via user-space mechanisms (Run keys, %APPDATA%) and attacker activity involving user accounts will be visible in user profile paths before it appears in system paths.

Look for temporal clustering. A burst of unusual activity in a 2-minute window is more interesting than isolated events spread over hours. Look for clusters of events that do not match the normal baseline rhythm of the system (see patterns below).

Analysis Techniques

Pivot-Point Analysis

Once you have any known-bad event — a detected malware execution, a suspicious process creation, an IOC match — use it as a pivot point and work outward.

What happened immediately before? The minutes before a known malicious event often reveal initial access (phishing email opened, browser exploit, lateral movement from another host).

What happened immediately after? Post-execution activity shows the malware’s first actions: persistence installation, discovery commands, credential access.

What else involves the same process? Filter the timeline to the process’s PID or executable name. What files did it touch? What network connections did it make? Did it spawn children?

What else involves the same file paths? If a suspicious file was written to %TEMP%\svchost.exe, search the entire timeline for that path — when was it first created, when was it executed (prefetch), when was it accessed (LNK), when was it deleted (USN journal)?

Pattern Identification

Attackers and their tools leave recognizable patterns:

Beaconing: Regular network connections at fixed intervals (e.g., DNS queries every 60 seconds). In a file system timeline, regular writes to a log file or temp file at fixed intervals may indicate the same pattern without network visibility.

Staging and exfiltration: A sudden spike in file reads from document directories followed by archive creation (zip, rar, 7z) followed by a large file appearing in a staging path. The USN journal will show the reads; the MFT will show the archive’s creation timestamp.

Lateral movement preparation: Discovery commands cluster together: net user, net group, net view, ipconfig /all, tasklist. These appear in prefetch or process creation events. Lateral movement itself follows within minutes to hours.

Defense evasion: Look for event log clears (event ID 1102), firewall rule additions (audit policy for MPSSVC), AV exclusion additions (registry writes to Defender exclusion paths), or a sudden gap in file system activity that should be continuous.

Living-off-the-land (LOLBins): Legitimate Windows binaries (certutil.exe, bitsadmin.exe, mshta.exe, regsvr32.exe, wscript.exe) used for malicious purposes. Their presence in prefetch or event ID 4688 is not suspicious by itself — but certutil with a -decode or -urlcache argument, or mshta loading a remote URL, is a strong indicator.

Correlation Across Sources

The most compelling timeline entries are those supported by multiple independent sources. A single prefetch file proves execution; a prefetch file plus an event ID 4688 plus a matching registry run key write within the same 30-second window proves intentional persistence installation.

Build a table of corroborating evidence for each suspicious event:

Each row in this table is a link in the chain of evidence. Multiple sources corroborating the same sequence make the reconstruction resistant to challenge.

Connecting Timeline Analysis to ATT&CK

Every event in a timeline can be annotated with an ATT&CK technique. This transforms a chronological list into a behavioral narrative aligned with a shared vocabulary.

The ATT&CK Navigator can then visualize the technique coverage of your timeline, making the attack pattern visible at a glance and identifying gaps where additional investigation is needed.

Tools Quick Reference

The Eric Zimmerman tools (MFTECmd, PECmd, LECmd, etc.) each output CSV and are designed to feed directly into Timeline Explorer. They are collectively known as EZTools and are the standard for Windows artifact parsing on Windows analysis machines.

Further Reading

• B. Carrier. (2005). File System Forensic Analysis. Addison-Wesley. — Chapters 7–11 cover NTFS and FAT timestamps in detail.
• S. L. Garfinkel. (2012). “Digital media triage with bulk data analysis and bulk_extractor.” Computers & Security, vol. 32.
• SANS FOR508: Advanced Incident Response, Threat Hunting, and Digital Forensics — covers super-timeline analysis in depth; Plaso and Timeline Explorer labs.
• Eric Zimmerman’s tools — all EZTools are free and actively maintained.
• Plaso documentation
• Timesketch
• MITRE ATT&CK Navigator — for annotating timeline findings with technique IDs.