Filesystem Timeline Forensic Creation and Analysis

 

The foundational and most prevalent modality of temporal reconstruction in digital forensics is the filesystem timeline. This artifact aggregates metadata from every file and directory resident within a volume, encompassing both allocated and unallocated structures. Unallocated metadata, in particular, frequently yields critical intelligence regarding deleted files, orphaned entries, and residual filesystem artifacts that persist beyond logical deletion.

Timeline Analysis in Digital Forensics

Timeline analysis is the systematic process of aggregating, correlating, and interpreting temporal event data to reconstruct the sequence and timing of activities on a system. Its primary objective is to establish a clear, chronological narrative of events for investigative and evidentiary purposes. This discipline typically consists of two distinct phases:

1. Timeline Creation (Data Collection): The methodical extraction of time-stamped events from diverse sources—including filesystem metadata (MACB timestamps), system and application logs, registry artifacts, event logs, USN Journal entries, prefetch files, and network or firewall records. These events are normalized and consolidated into a unified, queryable dataset (commonly a bodyfile or database).
2. Timeline Analysis (Organization and Interpretation): The refinement, filtering, and contextual enrichment of the collected data. Events are sorted chronologically, correlated across sources, and visualized or filtered according to investigative priorities. This phase transforms raw temporal data into actionable intelligence, enabling examiners to identify patterns, anomalies, and causal relationships.

By integrating multiple data sources, timeline analysis provides investigators with a powerful framework for understanding the when, what, and—through correlation—the how and why of system activity. When performed rigorously, it forms one of the most compelling and court-defensible components of a digital forensic examination.

Each filesystem implements its own timestamp schema; however, the predominant quartet—commonly denoted in MACB notation—includes the following:

• M (Modification): Recording the last alteration to file content.
• A (Access): Denoting the most recent access or read operation.
• C (Change): Capturing modifications to inode or MFT metadata (e.g., permissions, ownership, or naming).
• B (Birth/Creation): Reflecting the file’s creation (or birth) time on the specific volume.

Through correlative analysis of these temporal attributes, examiners can reconstruct pivotal events, including the creation of a file on a volume, its copying or relocation to a target location, and indicators of deletion or tampering.

A significant operational advantage of filesystem timelines lies in their broad compatibility across heterogeneous filesystem implementations. This versatility proves indispensable when encountering diverse evidentiary sources—ranging from embedded Linux filesystems in GPS devices to dual-boot configurations utilizing both NTFS and HFS+ (such as macOS Boot Camp environments). Contemporary timeline-generation tools reliably parse the following filesystems:

• NTFS
• FAT12/16/32
• EXT2/3/4
• ISO9660 (CD-ROM)
• HFS+
• UFS1 & UFS2

This capability enables comprehensive, cross-platform temporal analysis essential to thorough digital investigations.

NTFS Timestamp Semantics in Digital Forensics

The NTFS filesystem maintains four principal timestamps for files and directories within the Master File Table (MFT): last content modification (M), last access (A), MFT record modification (C), and file creation or birth time (B).

Among these, the metadata change timestamp (C)—reflecting alterations to the MFT entry itself—frequently presents the greatest interpretive challenge for practitioners. This attribute is updated in response to operations such as file renaming, changes in file size, modifications to security descriptors or permissions, and alterations in ownership.

The last access timestamp (A) has historically proven similarly problematic due to its sensitivity to a wide array of system activities. Windows implementations have variably deprioritized its precision, with certain versions introducing delays of up to one hour or disabling updates entirely via registry policy (e.g., NtfsDisableLastAccessUpdate).

Forensic Recommendation: Absent a compelling case-specific justification, examiners should prioritize analysis of the content modification (M) and creation/birth (B) timestamps. These values offer the greatest reliability and evidentiary value for addressing the majority of temporal reconstruction inquiries.

A key forensic advantage of NTFS lies in its consistent use of UTC-based storage for all timestamps, rendering them immune to time zone shifts or daylight saving time adjustments. This contrasts sharply with other filesystems, such as FAT, which records timestamps in local system time. Consequently, a file saved at 15:00 PST on an NTFS volume will correctly display as 18:00 EST when examined on an East Coast system, whereas the same file on a FAT volume may appear (incorrectly) as 15:00 EST.

NTFS employs a 64-bit FILETIME structure, encoding timestamps as the number of 100-nanosecond intervals elapsed since 00:00 UTC on 1 January 1601. This high-resolution format—far surpassing the second-level granularity of traditional UNIX epoch time—affords examiners critical precision in high-velocity environments where multiple significant events may occur within a single second. This architectural precision remains one of the enduring strengths of NTFS in modern Windows forensic examinations.

Figure 1: Windows 11 Time Rules
Source: Kathryn Hedley
Key:
- Values that are not highlighted are the same on Windows 10 and Windows 11.
- Values highlighted in an orange background are those that are different in Windows 11 compared to Windows 10.

Tracking the nuanced and often inconsistent effects of disparate operations on MACB timestamps across Windows versions can prove exceptionally challenging, even for seasoned examiners. Figure 1 above provides a pragmatic guideline for anticipated timestamp behavior under standard conditions. It should be treated as a reference framework rather than absolute doctrine, given the myriad execution paths, APIs, and tools available in Windows—many of which remain incompletely documented or tested. When timestamp provenance is pivotal to the investigation, empirical validation on a representative target system configuration is strongly advised, with repeated testing to ensure reproducibility.

NTFS MACB Timestamp Responses

• File Creation: All four timestamps (MACB) are initialized to the creation time, as expected.
• File Access: Last access time (A) updates were disabled by default beginning in Windows Vista. They were selectively re-enabled in later Windows 10 and 11 builds, though numerous exceptions (e.g., copy and move operations) continued to trigger updates even in earlier versions. Due to this inherent inconsistency, A timestamps should generally be deprioritized unless specific contextual justification exists.
• File Modification: Content alteration requires reading existing data, writing changes, and updating file size metadata. This reliably affects the modification (M), access (A), and MFT change (C) timestamps.
• Rename / Local Move (Same Volume): These operations primarily impact directory metadata (filename or parent reference), updating only the MFT change timestamp (C).
• Deletion: Unlike ext4, Windows does not maintain a dedicated deletion timestamp. No MACB values are updated upon deletion.

Cross-volume and copy operations introduce greater complexity and forensic value:

• Copy Operations and Inter-Volume Moves (especially via CLI) typically inherit the original file’s modification time (M) while assigning new creation/birth times (B). This produces a diagnostically significant pattern: a modification timestamp predating the creation timestamp on the destination volume—an artifact that is normally impossible under native filesystem behavior.

This M-before-B anomaly serves as a robust indicator of file provenance from an external source, with the B timestamp reliably approximating the time of the copy or move event. In the absence of explicit “copy” artifacts in most filesystems, this temporal signature is often the clearest evidence of file translocation.

Notably, GUI-based cut-and-paste operations (Explorer) frequently produce different timestamp outcomes compared to command-line equivalents (e.g., copy or move), further illustrating the intricate and context-dependent nature of timestamp propagation in Windows environments.

Always corroborate timeline findings with secondary sources (USN Journal, $LogFile, Prefetch, LNK files, etc.) and, where feasible, validate anomalous patterns through controlled experimentation on comparable systems.

Even with established behavioral models, timestamp propagation rules in Windows remain subject to evolutionary changes across operating system releases. Figure 1 illustrates the relatively minor divergences observed between Windows 10 and Windows 11. Notably, the core behaviors governing creation (B) and modification (M) timestamps exhibit no substantive differences between these versions. Only marginal variances appear in access (A) and MFT change (C) handling. This continuity is operationally significant: it ensures that standard forensic timeline analysis workflows remain largely consistent across both platforms.

In most investigations, focusing on creation and modification timestamps provides sufficient fidelity to address most temporal reconstruction questions. Over-analysis of access and metadata change times should be reserved for exceptional circumstances where greater granularity is required. When anomalous patterns demand deeper scrutiny, these comparative charts serve as effective aids in formulating testable hypotheses. Such hypotheses must incorporate corroborating contextual artifacts and, whenever feasible, be empirically validated through controlled experimentation on a system configuration closely mirroring the original evidence.

Special acknowledgment is due to Kathryn Hedley, SANS DFIR instructor, whose rigorous empirical research underpins the timestamp behavior graphics referenced herein. Her ongoing documentation and updates, available on her website, remain a valuable resource for the digital forensics community.

Caveats and Common Exceptions in Timestamp Interpretation

Modern operating systems and the layered applications executing atop them introduce substantial complexity to timestamp behavior. Numerous legitimate and adversarial actions can deviate from—or outright violate—standard MACB update rules. The following represent some of the most frequently encountered exceptions:

• Microsoft Office Applications: These have historically updated last access (A) timestamps even when disabled at the registry level (NtfsDisableLastAccessUpdate), due to their internal file-handling mechanisms.
• Malware and Anti-Forensic Tools: Adversaries frequently leverage low-level filesystem APIs (e.g., SetFileTime) to manipulate timestamps—either to align with surrounding artifacts (timestomping) or to obscure evidence of intrusion.
• Archiving and Extraction Utilities: Most compression tools (e.g., ZIP, RAR) preserve or backdate the modification (M) timestamp of extracted files to match the original archived state, creating patterns that closely resemble file copy operations.
• Security Tooling: Endpoint protection platforms, antivirus scanners, and system utilities routinely interact with files during scans, indexing, or integrity checks. Historically, many AV products triggered daily access time updates during full-system scans.

Timestamp analysis must never occur in isolation. All observed temporal artifacts should be interpreted within the broader context of system activity, application behavior, and corroborating sources (e.g., USN Journal, Prefetch, ShimCache, event logs, and security product artifacts). When ambiguity persists or timestamp provenance is case-critical, empirical hypothesis testing on a representative system remains the gold standard for validation.

Understanding Timestamps: Lateral Movement Analysis

One of the more compelling aspects of NTFS timestamp analysis is the preservation of standard MACB behavioral rules even during network-based file transfers, such as those conducted over SMB shares—provided both source and destination volumes are NTFS.

A prevalent lateral movement technique involves copying a tool or payload to a target host, followed by execution via Scheduled Tasks, WMI, or PsExec. These methods frequently establish an authenticated SMB session (often via net use). From the operating system’s perspective, a remotely mounted filesystem via SMB is largely indistinguishable from a locally attached volume. This transparency explains why the MountPoints2 registry key (under each user’s NTUSER.DAT hive) reliably records both local and remote volume mounts.

During SMB file transfers, the destination system inherits the source file’s modification time (M), while assigning a new creation/birth time (B) corresponding to the moment the file arrives on the target. This produces the classic forensic indicator: a modification timestamp that predates the creation timestamp on the destination—an otherwise anomalous condition signaling a copy operation. The B timestamp thus serves as a precise “time of arrival” for the transferred file. This pattern is particularly valuable when analyzing executable files (.exe, .dll, scripts, etc.), which are infrequently created natively on a system but commonly copied during intrusion activities.

Operational Value

• The creation timestamp functions as an excellent pivot point in timeline analysis of the compromised host.
• Correlating this time with proximate event log records can reveal associated user accounts, authentication events, and execution artifacts.
• Application prefetch, ShimCache, AmCache, and process creation logs often provide additional context around subsequent execution of the transferred payload.

A fundamental understanding of filesystem timestamp mechanics frequently yields powerful, high-confidence indicators of file movement and lateral spread—often with minimal additional processing. Such pivot points remain among the most reliable artifacts for reconstructing attacker activity across networked environments.

Understanding the Filesystem Timeline Format

Proficiency in timeline interpretation is developed through iterative practice and pattern recognition. The standard “body” file format used in filesystem timelines (as generated by tools such as The Sleuth Kit) and rendered through mactime comprises up to eight delimited fields/columns, with the core five displayed in the above figure.

• Column 1 – Timestamp: Records the event time to the nearest second. Given the volume of activity possible within a single second on modern systems, events occurring in close temporal proximity may appear slightly out of chronological order. This granularity limitation generally has minimal investigative impact and is easily resolved through contextual review.
• Column 2 – MACB Descriptor: This is the most analytically significant—and often most challenging—column. It specifies which timestamp value(s) the entry represents. The field contains combinations of the letters M (Modification), A (Access), C (Metadata/MFT Change), and B (Birth/Creation). Multiple letters may appear when timestamps coincide. A period (.) denotes an absent or inapplicable timestamp.

Consider the following entries for the file C:\calc.exe:

• 2021-10-03 16:20:37 | m.c. | ... → The modification (M) and metadata change (C) times for this file are the same, and both are represented by the time in column one (2021-10-03 16:20:37).
• 2021-10-03 16:25:12 | .a.b | ... → The access (A) and birth/creation (B) times are the same and correspond to this later timestamp.

This multiplicity is often one of the more difficult concepts for new analysts to internalize. Because each file maintains up to four distinct timestamps, a single file may generate as many as four separate entries in a comprehensive timeline. In this case, the file produces only two entries because the modification and metadata change times coincide, as do the access and birth times (though at a different moment). The macb column adheres to a fixed sequence (M A C B). Any timestamp not represented in a given entry is denoted by a period (.).

Additional Common Patterns

• m.cb — Modified, metadata changed, and born (created)
• .a.. — Accessed only
• mac. — Modified, accessed, and metadata changed

This structured notation allows examiners to rapidly correlate specific file system events with precise temporal context, forming the foundation for accurate timeline reconstruction.

Timelines reflect only the most recent value for each timestamp type. Historical modifications are not preserved. For instance, repeated edits to a Word document will overwrite the previous M time with each save, causing earlier activity to “age out” of the timeline.

• File Size: Useful for correlating files of identical size or identifying outliers such as large archives, containers, or encrypted volumes.
• Meta Column: Displays the metadata address of the source structure—MFT record number on NTFS or inode number on Linux/Unix filesystems. This value is critical when pivoting to deeper analysis of raw MFT or inode records.
• File Name: Provides the full path. Deleted/unallocated entries are typically annotated with (deleted). This column is among the most frequently filtered during investigations.
• Permissions / UID / GID: These fields contain security and ownership information, which are relevant primarily for Unix-based filesystems. They are commonly suppressed during Windows-centric examinations, as NTFS permissions and ownership are represented differently.

Mastering this format enables examiners to efficiently navigate high-volume timelines, identify behavioral patterns, and extract actionable intelligence from filesystem activity.

MAC Timeline Creation and Analysis with MFTECmd

Eric Zimmerman developed a highly efficient and reliable utility with MFTECmd, a command-line tool purpose-built for rapid extraction of forensic artifacts from the NTFS Master File Table ($MFT), USN Journal ($UsnJrnl), and other critical NTFS system files. For filesystem timeline construction, MFTECmd is employed to parse the $MFT and output data directly into the standardized bodyfile format. This intermediate format contains the essential temporal, metadata, and path information required for timeline generation.

The resulting bodyfile can then be efficiently processed, filtered, and converted into a human-readable timeline using mactime (part of The Sleuth Kit). This workflow—MFTECmd for extraction followed by mactime for formatting—represents one of the fastest and most effective methods for generating comprehensive NTFS filesystem timelines from raw $MFT data.

In addition to bodyfile generation, MFTECmd supports direct export of $MFT records to CSV format. This output mode provides significantly greater detail than the standard bodyfile, including expanded attribute information, full $STANDARD_INFORMATION and $FILE_NAME timestamp sets, and other metadata fields that are valuable for in-depth analysis. The CSV format serves as an excellent supplement to filesystem timelines, enabling deeper inspection, advanced filtering, and correlation with other artifacts. To generate CSV output instead of a bodyfile, simply use the --csv switch in place of --body:

This capability allows examiners to maintain both high-level temporal overviews (via bodyfile + mactime) and granular, record-level detail (via CSV) within the same investigative workflow.

MAC Timeline Creation and Analysis with TSK

The Sleuth Kit (TSK) remains one of the foundational open-source digital forensics frameworks. Its components are integrated into numerous commercial and free tool suites for robust filesystem parsing and analysis. The fls utility within TSK is specifically engineered to enumerate filename and metadata structures across a volume. When invoked with the -m option, it outputs this data in the standardized bodyfile format—the essential first stage in generating a filesystem timeline. fls collects three primary categories of filesystem artifacts:

1. Allocated Files: Active, visible files that appear in standard directory listings.
2. Deleted Files: Unallocated entries whose filename structures remain intact. Depending on the filesystem, these may retain full path information, timestamps, and permission details.
3. Orphan Files: Entries derived from unallocated metadata structures (e.g., MFT records or inodes) where the parent directory linkage has been lost. These reveal that a file with a given name and set of timestamps once existed, though its original folder location is no longer recoverable.

MFTECmd excels at high-speed extraction directly from a standalone $MFT file, enabling efficient timelining even when a full disk image is unavailable or impractical, while fls operates against complete filesystem volume images (or live systems), providing broader context and supporting a significantly wider range of filesystems beyond NTFS. While MFTECmd is NTFS-specific and optimized for MFT-centric workflows, fls offers greater filesystem versatility and the ability to process live-mounted volumes—making it particularly valuable for live response, triage, and multiplatform investigations. This complementary toolset allows examiners to select the most appropriate method based on the type of evidence available and the specific requirements of the case. Tools like log2timeline/Psort extend this into "super timelines," combining multiple artifact sources.

The timeline creation phase consists of two primary stages:

Stage 1: Bodyfile Generation

The bodyfile serves as an intermediate, platform-agnostic data structure used in the construction of filesystem timelines. It is a pipe-delimited ("|") text file containing one line per file system artifact (or other temporal event, such as log entries or registry keys). Tools within the Sleuth Kit (such as fls and ils) and MFTECmd generate output in this standardized format. Each line follows the structure:

MD5|name|inode|mode_as_string|UID|GID|size|atime|mtime|ctime|crtime

Timestamps within the bodyfile are recorded in Unix epoch format—the number of seconds elapsed since 00:00:00 UTC on 1 January 1970. While computationally efficient, epoch time is not inherently human-readable and requires conversion for effective analysis.

Stage 2: Human-Readable Timeline Generation

In the second stage, the mactime tool (also part of The Sleuth Kit) processes the bodyfile to produce a sorted, analyst-friendly timeline. This tool:

• Sorts all entries chronologically.
• Converts Unix epoch timestamps into readable date/time strings (typically in ISO 8601 or localized formats).
• Aggregates multiple timestamps per file into concise MACB notation entries.

The resulting output transforms raw metadata into a structured, chronological narrative, clearly associating specific events—such as file creation, modification, access, metadata changes, and deletions—with their respective times. This format significantly enhances an examiner’s ability to identify patterns and reconstruct system activity. This two-stage methodology (bodyfile → mactime) remains a cornerstone of efficient and defensible timeline analysis in digital forensics.

The mactime tool processes a bodyfile and transforms its raw contents into an organized, analyst-friendly timeline suitable for detailed forensic review. At minimum, mactime requires the path to a bodyfile via the -b option:

mactime -b bodyfile.txt

Key Options for Enhanced Analysis

• -d (CSV Output): Generates comma-delimited output instead of the default tabulated format. This is the recommended setting for most investigations, as CSV facilitates seamless import into spreadsheets, databases, timeline visualization tools, and custom scripts—offering superior scalability and interoperability.
• -z UTC (Timezone Control): By default, mactime converts timestamps to the local time zone of the forensic workstation. Because NTFS natively stores timestamps in UTC, it is strongly recommended to preserve this original format using the -z UTC flag. Maintaining UTC consistency across all artifacts eliminates time zone translation errors and daylight saving time complications.
• Date Range Filtering: Optional start and end dates can be specified to constrain the output to a relevant temporal window. Without this parameter (e.g., 2026-01-01..2026-6-01), mactime will process and output the entire bodyfile from the earliest to the latest event.

The figure below illustrates the processed output of the mactime utility as viewed in Eric Zimmerman’s Timeline Explorer, a powerful, free tool designed for efficient timeline review and analysis.

In this representation, the data is organized into clear, sortable columns, typically including:

• Timestamp — The normalized timestamp (in UTC when properly configured)
• MACB — The critical descriptor indicating which timestamp types apply to the entry (M = Modified, A = Accessed, C = Metadata Change, B = Birth/Creation)
• Size — File size in bytes
• Meta — MFT record number or inode
• File Name — Full path, with deleted entries clearly annotated

Timeline Explorer allows analysts to apply powerful filters, search across file names and paths, color-code MACB combinations, and quickly pivot between related artifacts. Its ability to handle large datasets while maintaining responsiveness makes it one of the preferred tools for reviewing mactime-generated timelines during forensic examinations. This view transforms the raw, line-by-line bodyfile data into an interactive, human-centric format that significantly accelerates the identification of relevant events, anomalous patterns, and attacker activity.

The Timeline Analysis Process

The initial step in timeline analysis involves proper preparation of the data source—typically a forensic image or verified copy of the target storage device. This image is imported into specialized analysis software to enable structured examination.

While many tools provide a broad overview of system activity, effective investigation usually requires focusing on a narrow temporal window. Analysts therefore employ zooming techniques to refine their view of the timeline. There are three primary forms of zooming:

• Temporal Zooming: Adjusts the time scale of analysis, allowing examiners to review activity at varying granularities—from broad multi-day overviews down to individual seconds.
• Event Type Zooming: Filters and groups events according to classification (e.g., file system operations, log entries, process execution, network activity), enabling targeted inspection of specific categories of behavior.
• Description Level Zooming: Controls the depth of information displayed for each event, revealing varying levels of contextual detail and associated metadata.

Once the appropriate scale is achieved, analysts apply filtering to reduce data volume and suppress irrelevant noise. Targeted events are isolated using a combination of timeline context analysis, cross-correlation with other artifacts, and hypothesis-driven queries. The process culminates in the documentation and visualization of findings, producing clear, defensible outputs suitable for reporting, peer review, or courtroom presentation.

This structured, iterative methodology—preparation, zooming, filtering, analysis, and visualization—forms the foundation of rigorous and efficient timeline-based digital forensic investigations.