§ Trackr.Live

Timeline Analysis

Timeline analysis is the cross-artifact analytical discipline that takes the timestamps preserved across every other forensic surface (disk artifacts, memory events, network captures, application logs, cloud audit logs) and assembles them into a coherent chronological reconstruction of what happened on the system or systems under investigation. The work is the connective tissue of digital forensics: each individual artifact source produces evidence of specific events at specific times, but the analytical question “what actually happened during the incident” requires the events to be ordered, correlated, and presented in a form that supports narrative reconstruction. Timeline analysis is the discipline that turns the artifact catalog into a story.

This page covers the discipline as it actually exists: the timeline event model that the analytical tools converge on, the major artifact sources that timeline consumes from each forensic surface, the plaso / log2timeline ecosystem that is the de facto standard for cross-artifact timeline construction, the supertimeline pattern that consolidates events from many sources into a unified view, the Timesketch analytical front-end that presents the supertimeline for analyst interaction, the time normalization challenges that complicate every multi-source timeline (UTC versus local, time zones, clock skew, granularity mismatches), and the analytical workflow that turns the chronological data into a defensible narrative.

Timeline analysis depends on the artifact-extraction work covered in the other forensic subpages. It does not produce new artifacts; it organizes existing ones. The output feeds the report-level work covered in incident response and admissibility. The discipline is conceptually simple (collect timestamps, sort by time, examine the result) and operationally difficult (the volume is large, the timestamps lie, the time zones do not agree, the analytical question is rarely as simple as “what happened at 14:32”). The methodology has matured around the operational difficulties; the analytical depth is increasingly automation-supported rather than purely manual.

The timeline event model

A timeline event is the atomic unit of timeline analysis: a single artifact at a single moment in time, with enough context to be interpretable in isolation and useful in aggregation. The major timeline tools converge on a similar event structure, with minor variations:

Timestamp. The moment the event occurred, normalized to a consistent time zone (almost always UTC) and a consistent granularity (typically nanoseconds for modern timelines).
Timestamp description. What the timestamp represents: creation time, modification time, access time, event time, log entry time. Several timestamp types may apply to the same artifact (a file has creation, modification, and access times that all matter), which is why a single file typically produces multiple timeline events.
Source. The artifact source that produced the event: NTFS MFT, Windows EVTX log, Chrome browser history, the AWS CloudTrail log, the Cobalt Strike beacon configuration extraction. The source identifies which analytical confidence the event carries.
Source type. A finer-grained classification. Within EVTX, which channel. Within MFT, which timestamp. Within network logs, which protocol.
Description. Human-readable text describing the event: “File created: C:\Users\victim\Downloads\invoice.zip”, “Process started: cmd.exe by user victim”, “Network connection: 192.0.2.42:443 from svchost.exe”.
Additional fields that depend on the source type: the user, the source IP, the affected resource, the process name, the registry key, the file path, the byte count, the parent process. Each source type produces its own characteristic fields.

The atomic event is the building block. A timeline is the chronologically-ordered sequence of events, optionally filtered by time range, source, or other criteria. The supertimeline is the consolidation of events from many sources into a unified view that supports cross-source correlation.

The mactime convention. The historical naming convention for file system timestamps uses single-letter codes (M for modification, A for access, C for inode/MFT change, B for birth/creation, E for entry-modified on NTFS) producing four-letter timestamp tuples per file. The mactime convention from The Sleuth Kit (mac is a tuple of M, A, and C times; the modern variant adds B for creation/birth) is the basis for several timeline tool naming patterns. Modern timeline output typically expands the codes into named descriptions for readability, but the underlying tuple structure persists in the tooling.

Artifact sources for timelines

Each forensic surface contributes its own timeline-relevant artifacts. A consolidated tour, extending what the prior subpages covered.

From file system forensics:

MFT entries. The dual NTFS timestamps from $STANDARD_INFORMATION and $FILE_NAME, with the dual model exposing timestomping when present. Each MFT entry produces multiple timeline events (creation, modification, MFT entry modification, access on $STANDARD_INFORMATION; the same four on $FILE_NAME).
ext4 inodes. The four timestamps per inode (atime, mtime, ctime, crtime), with the crtime added in ext4.
APFS file metadata. The corresponding timestamps from the APFS object map.
$LogFile and $UsnJrnl. The NTFS journals, which preserve transaction-level file system events over a rolling window (hours to weeks of history depending on activity).
File system change journals. ext4’s jbd2 journal, APFS’s snapshot history, the equivalent on other file systems.

From Windows-specific artifacts:

Event logs (EVTX). Security, system, application, and the long tail of per-channel logs. Process creation (4688), authentication (4624/4625/4648), service installation, scheduled task creation, PowerShell logging, Sysmon events, and many others.
Registry artifacts. UserAssist (program execution), ShimCache (binaries the AppCompat subsystem has observed), AmCache (additional program execution detail), RunMRU (run dialog history), TypedURLs, USB connection history (USBSTOR), and many others.
Prefetch files. The .pf files that record program execution with the last eight run times each.
Jump lists. Recent file access per application.
ShellBags. Folder browse history.
LNK files. Shortcut targets with their MAC times and the volume serial numbers.
Recycle Bin. Deletion events with the original file metadata.
Browser artifacts. History (per-URL access timestamps), cache (downloaded content timing), cookies (creation and access times), downloads (file timestamps).

From macOS and Linux artifacts:

macOS FSEvents (the file system change log used by Time Machine and Spotlight).
macOS Unified Logging (the modern macOS log system, structured events from the system and applications).
macOS knowledgeC.db (covered in mobile forensics as the iOS equivalent; macOS has the same database, with the same usage event structure).
Linux journald (the systemd structured log system).
Linux /var/log/ (the historical syslog-format logs).
Linux wtmp / utmp (login records).
Linux audit logs (the kernel audit subsystem output, when auditd is configured).

From memory:

Process creation events captured in windows.pslist and windows.psscan, with the start time per process.
Network connections from windows.netscan, with the connection state and the timing.
Loaded modules with their load times.
Bash history events from linux.bash with the timestamps preserved by the in-memory history buffer.

From network captures:

Pcap timestamps at the packet level (microsecond or nanosecond granularity on modern captures).
Zeek logs with per-protocol event timing.
NetFlow / IPFIX records with flow start and end times.
DNS query timestamps.

From cloud audit logs:

CloudTrail events with the eventTime field.
Azure Activity Log entries with the timeGenerated field.
GCP Cloud Audit Logs with the timestamp field.
Microsoft Entra ID sign-in events with the createdDateTime field.
The SaaS audit logs (Microsoft 365 Unified Audit Log, Google Workspace Reports, GitHub Audit Log, and so on) each with their own timestamp fields.

From mobile devices:

iOS knowledgeC.db events as covered in mobile forensics.
iOS sms.db, Photos.sqlite, and the other per-database timestamps.
Android per-app database timestamps.
The mobile-specific artifact catalogs that iLEAPP and ALEAPP extract.

From malware analysis output:

IOC observations with the time the malware was observed performing each behavior.
Configuration extraction that includes timing parameters (sleep intervals, scheduled execution times).

The aggregate is enormous. A modest Windows endpoint with a week of activity easily produces millions of timeline events when all sources are pulled. The volume challenge is one of the binding constraints on timeline workflow.

plaso and log2timeline

The de facto standard tool for cross-artifact timeline construction is plaso (Plaso Langar Að Safna Öllu, Icelandic for “Plaso Aims To Collect Everything”), the Python-based successor to the original log2timeline Perl tool. The project has been the central infrastructure for forensic timeline analysis for over a decade, with active development and a substantial parser ecosystem.

Architecture. Plaso operates on a forensic image or extracted artifact directory and runs a collection of parsers, each of which knows how to extract events from a specific artifact source. The parser ecosystem is the project’s primary value: over a hundred parsers covering Windows registry hives, EVTX files, NTFS MFT, browser databases, macOS plists, Linux journald, mobile databases, and a long tail of less common sources. Parsers convert source-specific artifacts into the unified plaso event format; the resulting events are written to a plaso database (.plaso, a SQLite-based format) for subsequent analysis.

The command-line workflow. The primary tools:

log2timeline.py runs the parsers against a source (an image, a directory, a specific file) and produces the .plaso storage file with the extracted events.
psort.py reads a .plaso file, applies filters (time range, source type, event field criteria), and produces output in a specified format (CSV, JSON, L2tCsv, ELK-formatted, and several others).
pinfo.py displays metadata about a .plaso file: the parsers that ran, the event counts per source, the time range covered.
psteal.py combines extraction and output into a single command, for situations where the intermediate .plaso storage is not needed.

The plaso event format. Plaso events have the structure described in the timeline event model section above: timestamp, source, source type, description, and source-specific additional fields. The format is the foundation for the cross-source correlation that downstream analytical tools support.

Parser coverage. The plaso parsers cover the major artifact sources from each forensic surface. The coverage is not complete (new artifact types appear faster than parsers are written, and parsers for specific artifact types vary in maturity), but the breadth is the project’s strength. Custom parsers are straightforward to write in Python and contribute back; the community maintenance pattern has kept the parser library current.

Performance characteristics. Plaso operates on raw artifact sources and produces normalized timeline events. The performance is acceptable for moderate-sized investigations (a single workstation image processes in tens of minutes to a few hours depending on artifact volume) but becomes burdensome for large-scale investigations. The mitigation is parser selection (running only the parsers relevant to the case) and parallelization (plaso supports multiple worker processes).

The supertimeline pattern

A supertimeline is the consolidation of events from many sources into a unified chronological view. The pattern is the central analytical artifact in modern forensic timeline work, and the structure deserves separate treatment from the tools that produce it.

The motivation. A timeline that includes only file system events surfaces file activity but misses authentication events. A timeline that includes only authentication events surfaces logons but misses what the logged-in user did. A timeline that combines both gives the analyst the cross-source view: at 14:32 the user authenticated, at 14:33 the user executed cmd.exe, at 14:34 a new file appeared in the user’s profile, at 14:35 a network connection went out from the cmd.exe process. The combination is what supports narrative reconstruction.

Construction. The supertimeline is typically built by running plaso against all available artifact sources (or by running multiple specialized tools and concatenating their outputs into a unified format), normalizing the events to a single time zone (UTC) and a single format, and storing the result in a structure that supports filtered querying. The structure is increasingly the input to a graph database, a SIEM, or a purpose-built timeline analysis tool like Timesketch.

Granularity considerations. Supertimelines mix sources with different timestamp granularities: NTFS at 100-nanosecond precision, ext4 at nanosecond precision, EVTX at second or millisecond precision (depending on Windows version), FAT/exFAT at 2-second precision, log4j-style application logs at millisecond or second precision. The mixed granularity produces ordering ambiguity at the sub-granularity level. A millisecond-precise event and a second-precise event in the same second cannot be reliably ordered against each other. The analytical methodology has to acknowledge the ambiguity.

Volume. A supertimeline for a single Windows workstation with a week of activity easily runs to tens of millions of events. The volume is unmanageable for raw inspection; the workflow filters aggressively (time bracket of interest, source types of interest, user accounts of interest) before any meaningful analysis.

Timesketch

Timesketch is the open-source analytical front-end for supertimelines, developed within Google and used widely in DFIR practice. The tool takes plaso output (or other timeline data) and presents it through a web interface that supports collaborative analysis, structured tagging, hypothesis tracking, and the typical timeline analytical workflow.

Key features. Timesketch supports:

Sketches. A sketch is a per-case timeline workspace. Multiple analysts can work on the same sketch with their analytical observations visible to each other.
Filtering and querying. Lucene-style query syntax allows filtering by time range, source, field values, and combinations. The query datetime >= 2026-04-29T00:00:00 AND data_type:windows:registry:run returns registry Run-key events from April 29 onward.
Tagging. Analysts tag events with structured labels (suspicious, malware, c2-traffic, lateral-movement, persistence) that survive across the sketch.
Stories. A story is a structured narrative that an analyst writes about the timeline, with embedded references to specific events. The story is the bridge between the chronological data and the narrative report.
Analyzers. Timesketch ships with built-in analyzers that scan timeline data for known patterns: suspicious PowerShell command lines, ATT&CK technique matches, common indicator-of-compromise patterns. The analyzers add their tags to the events they identify.

The analytical workflow in Timesketch typically involves loading the supertimeline, filtering to the time window of interest, running the built-in analyzers for initial triage, manually examining the events around the time of interest, tagging suspicious events, and writing the narrative story as the picture becomes clear. The result is a structured analytical workspace that supports the eventual incident report.

Time normalization challenges

The single largest practical challenge in timeline analysis is the normalization of timestamps from sources that disagree about what time it actually is. The challenges are well-documented but persistent.

UTC versus local time. Different sources record time in different reference frames. Windows event logs are stored in UTC but often displayed in local time by analytical tools. The Linux journald stores in UTC; older syslog implementations stored in local time. Mobile artifact timestamps mix formats (Unix epoch in UTC, ISO 8601 with timezone offsets, NSDate Mach timestamps with timezone context). The normalization step converts everything to UTC and labels the original time zone where it matters. The methodology has to be honest about which sources required conversion and what assumptions were made.

Time zones. A user in a New York office produces artifacts whose interpretation depends on the New York time zone. A user traveling to Tokyo and working from there produces artifacts that the New York-anchored analysis may misinterpret. Modern systems handle time zones reasonably well (recording in UTC and adjusting for display), but the artifact-by-artifact handling varies.

Daylight saving transitions produce timestamp anomalies: in the U.S. fall-back transition, the local time 01:30 occurs twice (once in EDT and once in EST), and timestamps that record local time without UTC offset are ambiguous in that window. The mitigation is to use UTC throughout; the failure mode is when historical sources stored only local time and the data is now ambiguous.

Clock skew. Each system in an environment has its own clock, and the clocks are not perfectly synchronized. NTP keeps modern systems within tens of milliseconds of each other (when configured); systems without NTP can drift by hours over months. Forensic timeline correlation across multiple systems has to account for the skew. The mitigation is to record the clock skew of each source system (as observed at acquisition time, by comparing to a known good clock) and to factor the skew into cross-system event ordering.

Clock manipulation. Adversaries sometimes set the system clock backward or forward to confuse forensic analysis. The artifacts produced under the manipulated clock have the manipulated timestamp; the cross-source correlation breaks because other sources (network captures from external systems, cloud audit logs from a synchronized system) record the actual time. The discrepancy is itself a signal. When local file system events show 2026-01-15T03:00:00 and the network capture from the same activity shows 2026-04-29T03:00:00, the system clock has been manipulated. The forensic methodology has to look for the inconsistency.

Granularity mismatches. Mixing nanosecond-precise sources with second-precise sources produces ordering ambiguity. The mitigation is to acknowledge the ambiguity in the analysis and to use multiple-source confirmation for events that matter.

NTP and the broader timing infrastructure. Environments without NTP synchronization produce systems whose clocks differ significantly. The forensic methodology has to verify the NTP configuration before relying on cross-system correlation. If NTP is misconfigured or pointed at a malicious time source, the timestamps are not what they appear.

The 1970-01-01 problem. Unix epoch zero (1970-01-01 00:00:00 UTC) appears in timestamps when a system fails to set its clock correctly. The “1970” timestamp is rarely meaningful (the artifact existed at some other time) and has to be filtered out or treated as a known-bad value during analysis.

The 2038 problem. 32-bit Unix timestamps roll over on 2038-01-19. The problem will produce timestamp anomalies in 32-bit systems and applications still in deployment at that date. The mitigation is migration to 64-bit timestamps before 2038; the forensic implication is that legacy systems in 2038+ may produce timestamps that confuse the analysis.

Cross-source correlation

The strongest analytical use of supertimelines is cross-source correlation: confirming an observed event by finding evidence of the same event in multiple independent sources.

The principle. A single source can be wrong, can be missing context, can have been tampered with. Multiple independent sources agreeing on the same event provide stronger evidence than any single source. The forensic methodology often weights conclusions by the number and independence of corroborating sources.

Examples in practice.

A user login event in the security log (EVTX 4624) is corroborated by a session entry in wtmp on the same system, by the corresponding entry in the domain controller’s authentication log, and by the source-system network connection in NetFlow. Four independent sources agreeing on the login produce high analytical confidence.
A program execution observed in Prefetch is corroborated by the corresponding event in AmCache, by the registry’s UserAssist entry, by the EVTX process creation event (4688), and by the process’s network connection if it made one. Five independent sources for the same execution.
A file creation observed in the MFT is corroborated by the corresponding entry in $UsnJrnl, by the prefetch entry if the file was an executable subsequently run, and by the network connection if the file was downloaded. The combination is stronger than any single source.

The methodology for correlation. The analytical workflow in Timesketch or equivalent tools includes filtering the supertimeline to the time bracket around the event of interest (typically 30 seconds to a few minutes on either side), identifying all events from all sources in that bracket, and identifying which events plausibly relate to the event of interest. The result is a multi-source reconstruction of what was happening at that moment.

The strength of disagreement. When sources disagree, the disagreement is itself informative. The disagreement may indicate timestomping (when only one timestamp source has been altered), system clock manipulation (when an entire system’s timestamps are offset), or genuine tooling errors (when a parser produces incorrect output). The methodology investigates disagreements rather than ignoring them.

Filtering and reducing volume

The volume of a supertimeline makes raw inspection impractical. The analytical workflow depends on aggressive filtering to reduce the data to a manageable size.

Time bracket filtering. The most common filter. Restrict the timeline to the time window of interest (the incident time bracket, plus context windows on either side). A multi-week supertimeline filtered to a six-hour window typically reduces to a few hundred thousand events.

Source filtering. Restrict to specific artifact sources relevant to the analytical question. An investigation focused on lateral movement may filter to authentication events, network events, and process execution events. An investigation focused on data exfiltration may filter to file access events, network events, and external storage activity.

User and process filtering. Restrict to specific user accounts or process names. Filtering out the user accounts and processes known to be irrelevant (the system service accounts that produce high event volume, the legitimate administrative tooling) substantially reduces the noise.

Field value filtering. Restrict to events with specific field values: events involving a specific file path, registry key, network destination, or other identifier. The filter is the standard approach when an IOC from malware analysis or threat intelligence anchors the investigation.

The “every record” problem. Some artifact sources produce one event per record (the typical case); others produce multiple events per record (an MFT entry produces eight or more events for the dual timestamp sets). Volume-aware filtering accounts for the source’s productivity; filtering by source alone may not reduce volume as much as expected when the source is multi-eventing.

The filtered-supertimeline workflow. The practical pattern is to load the full supertimeline once, filter to the analytical question’s scope (time window, sources, principals), examine the filtered result, refine the filter as the picture emerges, and iterate. Skilled analysts move through filter combinations rapidly.

SIEM-based timeline analysis

Modern operational environments use SIEM platforms (Splunk, Elastic Security, Microsoft Sentinel, Chronicle / Google SecOps) that ingest the same logs that forensic timeline analysis consumes, but in real time rather than after-the-fact extraction. The SIEM-side equivalent of timeline analysis is the routine analytical workflow that SOC analysts use; the forensic timeline analysis is the post-hoc reconstruction.

The overlap. Both involve querying timestamped events for specific patterns. The SIEM’s data is the same logs that plaso would extract (EVTX, Sysmon, network telemetry, cloud audit logs, application logs), just ingested in real time. The forensic timeline analysis can use the SIEM as a data source when the SIEM’s retention covers the period of interest, sometimes avoiding the need to run plaso at all.

The differences. SIEMs typically lack the disk-side artifact sources that forensic timeline analysis depends on: the MFT entries, the file system journals, the registry artifacts, the prefetch and ShellBags. Forensic timeline analysis fills this gap. SIEMs typically have better real-time alerting and dashboards; forensic timeline tools have better cross-source correlation across the artifact families.

The integration pattern. Mature incident response practice uses the SIEM for the operational time window (the last 30 days where the SIEM has retention) and the forensic timeline for the disk and memory artifacts that the SIEM does not capture. The two views are complementary; the analytical workflow pulls from both depending on the question.

Specific tools beyond plaso

A short tour of other timeline tools that show up in DFIR work.

Eric Zimmerman’s tools. MFTECmd, EvtxECmd, AmcacheParser, AppCompatCacheParser, JLECmd, LECmd, PECmd, RBCmd, RECmd, ShellBagsExplorer: each produces timeline-ready CSV output for the specific artifact it parses. The output can be loaded into Timesketch, into a SIEM, or analyzed with shell utilities. The toolset complements plaso (which uses some of the same parsers) and is the standard for analysts who prefer the direct parser output over plaso’s normalization.

KAPE. Kroll Artifact Parser and Extractor (covered in Forensic Acquisition and Imaging) produces structured artifact collections that include the timestamps each artifact carries. KAPE output can be loaded directly into Timesketch or processed with downstream tools.

Velociraptor. The endpoint visibility platform produces structured artifact collections at scale across an enterprise. The timeline-relevant output is the per-endpoint artifact data that Velociraptor extracts; the analytical workflow processes the output through plaso, Timesketch, or a SIEM.

Commercial forensic tools. Magnet AXIOM, EnCase, FTK, X-Ways, Belkasoft: each includes timeline functionality with the analytical features tuned to the tool’s overall workflow. The timeline output varies in completeness and analytical depth; the integration with the rest of the tool’s artifact extraction is the main value.

Cloud-specific timeline tools. Cloud audit log analysis happens through the cloud provider’s analytics tools (CloudWatch Logs Insights, Azure Monitor Logs / KQL, Cloud Logging) and through SIEMs that ingest the audit logs. The forensic-style timeline view of cloud audit logs is straightforward to construct with the provider’s query language; the supertimeline integration with non-cloud artifacts requires the cloud audit log to be exported to a format plaso or the SIEM can consume.

The narrative construction phase

The output of timeline analysis is not the timeline itself. It is the narrative reconstruction of what happened that the timeline supports. The methodology for moving from the chronological data to the narrative is worth covering.

Identifying the pivot events. Specific events in the timeline anchor the narrative: the initial intrusion, the privilege escalation, the lateral movement, the credential theft, the data exfiltration, the deployment of the destructive payload. The analyst identifies these pivot events by examining the timeline for activity that matches known intrusion patterns or specific IOCs.

Building the chain. Each pivot event has predecessors (what allowed this) and successors (what this enabled). The analyst traces the chain backward and forward, using the cross-source correlation to confirm each link. The result is a directed chain of events that connects the entry point to the eventual impact.

Identifying gaps. Some links in the chain are clear; others are inferred from indirect evidence. The methodology has to acknowledge the gaps: “the malware executed at 14:32 and the C2 connection began at 14:35; the activity between is not directly visible but the timing is consistent with the malware’s known startup behavior.”

Writing the narrative. The final output is a written narrative that describes what happened, supported by specific timeline events as evidence. The narrative is the audience-appropriate version of the timeline analysis. SOC analysts want IOCs and detection content. Executives want impact and exposure. Legal counsel wants admissible findings.

The ATT&CK technique mapping. Modern timelines increasingly map observed activity to MITRE ATT&CK techniques. The mapping supports the detection-engineering work that follows the analysis and provides a standardized vocabulary for the narrative.

What stalls the reconstruction

The structural problems timeline analysis is currently working through:

Volume. The largest practical problem. A supertimeline for a moderate Windows environment with a week of activity easily exceeds 10 million events. The analytical workflow depends on aggressive filtering; investigations that try to analyze the raw supertimeline stall on volume.

Granularity mismatches. Mixing nanosecond-precise sources with second-precise sources produces ordering ambiguity. The mitigation is to acknowledge the ambiguity; the failure mode is when analysts treat sub-granularity ordering as reliable.

Time zone confusion. Persistent across the discipline. The mitigation is rigorous UTC normalization; the failure mode is when normalization is applied incorrectly to specific sources.

Clock manipulation. Adversary clock manipulation produces timestamps that lie. The mitigation is multi-source correlation to detect the inconsistency; the failure mode is when only one source is examined.

Missing artifact sources. A timeline missing a key artifact source produces an incomplete picture. The methodology has to track which sources were included and which were excluded, and the report has to acknowledge the gaps.

Parser bugs. Plaso and other timeline tools depend on parsers that may have bugs in specific edge cases. The mitigation is to verify suspicious findings against the underlying artifact source; the failure mode is when parser output is treated as ground truth.

The retention window mismatch. Different artifact sources have different retention windows. The MFT preserves the current file system state; $LogFile preserves hours to days; EVTX preserves what the rotation allows (typically weeks); browser history preserves months; cloud audit logs preserve whatever the customer configured. A timeline assembled from sources with different retentions has the integrated retention of the shortest-retained source.

The “first event in the timeline” problem. When the earliest visible event is the entry point of an intrusion, the analyst sees the entry point. When the earliest visible event is the deployment of the destructive payload (because the entry-point evidence has aged out), the analyst sees the destruction without the entry-point context. The retention windows determine what the timeline can establish.

The cross-environment correlation problem. Modern intrusions span environments: on-premises Windows, cloud workloads, SaaS applications, mobile devices. The timeline correlation across environments requires integrating sources whose audit conventions, identifiers, and time-handling differ. The integration is operationally hard and frequently incomplete.

Anti-forensics. Timestomping, log clearing, and the broader anti-forensics toolkit (covered in Anti-Forensics) complicate timeline construction. The mitigations are partial; the cross-source correlation is the strongest defense against per-source tampering.

Timeline analysis is the discipline that turns the artifact catalog into a story. The work is conceptually simple and operationally hard. Collect timestamps, sort them, examine the result. But the volume is large, the timestamps disagree across sources, the time zones complicate every cross-system correlation, and the analytical question is rarely as direct as “what happened at 14:32.” The methodology has matured around these difficulties, with plaso providing the cross-artifact extraction, Timesketch providing the analytical front-end, and the supertimeline pattern providing the unified view that supports narrative reconstruction. The discipline is the connective tissue of digital forensics; the other forensic subpages produce the artifacts that timeline analysis assembles into the story the engagement is ultimately built around.

The connected pages cover the artifact sources that timeline consumes and the broader analytical context the timeline supports: Disk and File System Forensics covers the file system and Windows artifact catalogs that produce the largest fraction of timeline events; Memory Forensics covers the in-memory artifact sources that supplement the disk-side picture; Network Forensics covers the network-side events that anchor the cross-system correlation; Mobile Forensics covers the mobile artifact catalog that feeds mobile-specific timelines; Cloud Forensics covers the cloud audit logs that cover the cloud-side picture; Anti-Forensics covers the adversary techniques that complicate timeline construction; and Incident Response and DFIR Workflow covers the operational context that the timeline serves. The Digital Forensics hub covers the discipline as a whole.