Log2timeline was conceived by Kristinn Guðjónsson in conjunction with his GIAC Certified Forensic Analyst (GCFA) Gold Certification research at SANS. Inspired by discussions with SANS Faculty Fellow Rob Lee, who identified the operational necessity for aggregating disparate temporal data sources into a unified timeline artifact, Guðjónsson developed a modular framework capable of ingesting and normalizing a wide array of digital artifacts. The resulting tool surpassed initial expectations, emerging as a transformative contribution to the digital forensics community by enabling comprehensive super timeline construction—correlating filesystem metadata with application artifacts, registry entries, logs, and other evidential sources that had previously required disparate, labor-intensive parsing methods.

Guðjónsson’s project remains a cornerstone of forensic timeline analysis, providing investigators with a centralized reference for event reconstruction and temporal correlation across complex datasets. While not the sole utility for artifact parsing, it distinguishes itself through its breadth of supported parsers and its role as the de facto standard for super timeline generation. Development has been continuous and community-supported, with ongoing enhancements encouraged through contributions, issue reporting, or feature suggestions.

The original implementation was a Perl-based framework (log2timeline 0.x). Its successor is Plaso (Plaso Langar Að Safna Öllu—“Plaso wants to collect everything”), a robust Python-based backend engine that now underpins the toolset. In contemporary usage, the terms "Plaso" and "log2timeline" (specifically "log2timeline.py") are frequently employed interchangeably, with the latter serving as a primary frontend for storage file creation (e.g., .plaso repositories) that can subsequently be processed via tools such as psort.py. Analysts should utilize the current Plaso distribution for optimal performance, extensibility, and compatibility with modern forensic workflows.

Important Components of Plaso (log2timeline)

log2timeline.py: This serves as the primary single-machine frontend to the Plaso backend engine. It is the core acquisition tool employed to recursively extract timestamped events from individual files, directories (including mount points), or full forensic images. The extracted events are consolidated into a structured Plaso storage file (.plaso), which functions as a centralized repository for subsequent examination and analysis.

pinfo.py: The Plaso storage file encapsulates comprehensive metadata regarding the collection process, including execution parameters, timestamps, source information, and any preprocessing artifacts applied during acquisition. The pinfo utility provides a straightforward mechanism to inspect and display this metadata, enabling analysts to validate the integrity, scope, and provenance of the stored data.

psort.py: This post-processing utility is responsible for filtering, sorting, tagging, and transforming the contents of a Plaso storage file into actionable output. It supports advanced operations such as time-based filtering, keyword searches, sessionization, and custom tagging. Because the native Plaso storage format is a binary/SQLite-based repository optimized for performance rather than direct human inspection, psort is typically required to generate human-readable exports (e.g., CSV, JSON, dynamic timelines) suitable for detailed forensic review and reporting.

These components form the foundational workflow for super timeline creation and analysis within the Plaso framework.

Plaso (Plaso Log2Timeline) is a digital forensic framework designed to automate the extraction, normalization, and correlation of timestamped artifacts from a wide range of forensic evidence sources. Originally developed to streamline timeline generation for Windows-based investigations, the framework has evolved to support numerous Windows, Linux, macOS, browser, cloud, and application-specific artifacts. Through targeted parser modules, it extracts and normalizes registry hive data; browser activity; shell-item artifacts (LNK files and jump lists); and execution evidence (Prefetch and Amcache), among other artifact classes—sources that frequently constitute the bulk of an investigator's evidentiary corpus during host-based analysis.

The principal strength of the framework lies in its robust normalization engine, which harmonizes disparate, heterogeneous data sources into a single, consistent chronological view. This unified super timeline significantly enhances an analyst’s ability to correlate events, identify behavioral patterns, and achieve rapid situational awareness regarding system activity.

Windows Parsers

Plaso supports a comprehensive collection of parsers capable of extracting evidentiary metadata from numerous native and application-specific artifacts. Common Windows-relevant parsers include the following:

bencode: Parses bencoded data files.
bencode_transmission: Parses Transmission bencoded files.
bencode_utorrent: Parses uTorrent bencoded files.
custom_destinations: Parses .customDestinations-ms Jump List files.
esedb: Parses Extensible Storage Engine (ESE) database files.
filestat: Extracts filesystem metadata and stat information.
hachoir: Wrapper for the Hachoir binary file parser framework.
lnk: Parses Windows Shortcut (LNK) files.
mcafee_protection: Parses McAfee AntiVirus Access Protection logs.
olecf_document_summary / olecf_summary: Parses OLE Compound File (OLECF) DocumentSummaryInformation and SummaryInformation streams.
onedrive_log / skydrive_log: Parses OneDrive (formerly SkyDrive) log files.
onedrive_log_error / skydrive_log_error: Parses OneDrive/SkyDrive error logs.
openxml: Parses OpenXML (Office document) metadata.
pe: Parses Portable Executable (PE) file metadata.
powershell_transcript: Parses PowerShell transcript events.
prefetch: Parses Windows Prefetch files.
recycle_bin: Parses Windows Recycle Bin ($I) metadata.
sqlite: Generic parser for SQLite database files.
symantec_scanlog: Parses Symantec AntiVirus scan logs.
winevt: Parses legacy Windows Event Log (EVT) files.
winevtx: Parses Windows XML Event Log (EVTX) files.
windefender_history: Parses Windows Defender Detection History files.
winfirewall: Parses Windows Firewall log files.
winiis: Parses Microsoft IIS web server logs.
winjob: Parses Windows Scheduled Task (*.job) and AT-job files.
winreg: Parses Windows NT Registry (REGF) hive files.
google_drive: Parses Google Drive SQLite databases.
skype: Parses Skype SQLite databases.

These parsers, among many others, enable Plaso to ingest and contextualize a wide range of Windows artifacts critical to modern digital forensic investigations. The modular architecture allows for continuous expansion as new artifact formats emerge.

One of Plaso/Log2Timeline's greatest strengths is its comprehensive support for the acquisition, parsing, and normalization of Windows Registry artifacts. The Windows Registry constitutes one of the richest repositories of forensic evidence on a Windows system, preserving persistent records of user activity, application execution, system configuration, and device interaction. Among its constituent hive files, NTUSER.DAT is particularly valuable because it stores user-specific configuration data and numerous artifacts that reveal user behavior and interaction with the operating system. Plaso automatically extracts and timestamps these artifacts, enabling investigators to incorporate them into a unified forensic timeline for event reconstruction and correlation.

High-value Registry artifacts parsed by Plaso include ShellBags (BagMRU), RecentDocs, Open/SaveMRU, RunMRU, UserAssist, AppCompatCache (ShimCache), BAM, AMCache, NetworkList, USB device history, Mounted Devices, Task Scheduler cache, Run/RunOnce, Winlogon, and numerous Most Recently Used (MRU) artifacts. Collectively, these artifacts provide evidence of program execution, folder traversal, file access, removable media usage, Remote Desktop connections, persistence mechanisms, software installation, user logon activity, and system configuration changes. Their temporal correlation significantly enhances an examiner's ability to reconstruct user actions, establish investigative timelines, identify attacker tradecraft, and validate forensic hypotheses with a high degree of evidentiary confidence.

Registry Artifact Parsers

amcache: Parses AMCache (AMCache.hve) data.
appcompatcache: Parses Application Compatibility Cache (ShimCache) Registry data.
bagmru: Parses BagMRU / ShellBags Registry data.
bam: Parses Background Activity Moderator (BAM) Registry data.
ccleaner: Parses CCleaner Registry data.
explorer_mountpoints2: Parses Windows Explorer mountpoints Registry data.
explorer_programscache: Parses Windows Explorer Programs Cache Registry data.
microsoft_office_mru: Parses Microsoft Office MRU Registry data.
microsoft_outlook_mru: Parses Microsoft Outlook search MRU Registry data.
mrulist_shell_item_list / mrulistex_shell_item_list: Parses Most Recently Used (MRU) shell item list Registry data.
mrulist_string / mrulistex_string: Parses Most Recently Used (MRU) string-based Registry data.
mrulistex_string_and_shell_item / mrulistex_string_and_shell_item_list: Parses combined MRU string and shell item Registry data.
msie_zone: Parses Microsoft Internet Explorer zone settings Registry data.
mstsc_rdp / mstsc_rdp_mru: Parses Terminal Server Client (RDP) connection and MRU Registry data.
network_drives: Parses Windows network drives Registry data.
networks: Parses Windows NetworkList Registry data.
userassist: Parses UserAssist Registry data.
windows_boot_execute: Parses Boot Execution Registry data.
windows_boot_verify: Parses Windows boot verification Registry data.
windows_run: Parses Run and RunOnce Registry data.
windows_sam_users: Parses Security Accounts Manager (SAM) users Registry data.
windows_services: Parses Windows drivers and services Registry data.
windows_shutdown: Parses Windows last shutdown time Registry data.
windows_task_cache: Parses Windows Task Scheduler cache Registry data.
windows_timezone: Parses Windows time zone Registry data.
windows_typed_urls: Parses Windows Explorer typed URLs Registry data.
windows_usb_devices / windows_usbstor_devices: Parses Windows USB device and USBStor Plug and Play Registry data.
windows_version: Parses Windows version and product information Registry data.
winlogon: Parses Windows logon-related Registry data.
winrar_mru: Parses WinRAR history Registry data.
winreg_default: Generic parser for Windows Registry data.

The extensive registry parsing support, when combined with Plaso’s other artifact modules, positions the framework as a premier solution for Windows-based digital forensic investigations.

Plaso/Log2Timeline provides extensive support for the acquisition, parsing, and normalization of web browser artifacts, making it an invaluable framework for browser forensic analysis. The framework extracts timestamped evidence from legacy and modern web browsers, enabling investigators to reconstruct browsing activity, download history, cookie creation, cache utilization, extension usage, and user interaction across multiple platforms. Browser artifacts are normalized into Plaso's unified super timeline, allowing web activity to be correlated with Registry artifacts, Event Logs, file system metadata, Prefetch files, and other evidentiary sources for comprehensive event reconstruction.

Plaso supports legacy Internet Explorer 6–9 cache (index.dat) files, Internet Explorer 10/11 WebCacheV01.dat Extensible Storage Engine (ESEDB) databases, Chromium-based browser SQLite databases, Mozilla Firefox SQLite databases, Opera history databases, and Java download cache (IDX) files. These artifacts provide valuable evidence of website visitation, cached content, cookies, downloads, typed URLs, browser extensions, and user browsing behavior, all of which contribute to accurate timeline reconstruction and attribution.

Web History Parsers

chrome_cache — Parses Google Chrome cache files.
chrome_cookies — Parses Chrome cookies SQLite database files.
chrome_extension_activity — Parses Chrome extension activity SQLite databases.
chrome_history — Parses Chrome browsing history SQLite databases.
firefox_cache — Parses Mozilla Firefox cache files.
firefox_cookies — Parses Firefox cookies SQLite database files.
firefox_downloads — Parses Firefox download history SQLite databases.
firefox_history — Parses Firefox browsing history (places.sqlite) databases.
java_idx — Parses Java IDX download cache files.
msiecf — Parses Microsoft Internet Explorer cache (index.dat) files.
msie_webcache — Parses Internet Explorer 10/11 WebCacheV01.dat ESE database files.
opera_global — Parses Opera global_history.dat history files.
opera_typed_history — Parses Opera typed_history.xml typed URL history.

Collectively, these parsers enable forensic analysts to establish user browsing behavior, identify downloaded content, recover web navigation patterns, correlate browser activity with other host-based artifacts, and construct a comprehensive chronology of user and adversary actions during an investigation.

Modern versions of Plaso/Log2Timeline have evolved beyond their original focus on Windows artifact analysis to provide comprehensive support for Linux, Android, Unix, macOS, cloud applications, network captures, and numerous cross-platform file formats. This expanded parser ecosystem enables investigators to acquire, normalize, and correlate timestamped artifacts from heterogeneous operating systems and applications into a single chronological super timeline. Consequently, analysts can reconstruct user activity, application execution, system events, and network interactions across diverse environments using a unified forensic framework.

Linux / Android / Cross-Platform Parsers

android_app_usage — Parses Android usage-history.xml application usage artifacts.
android_calls — Parses Android call history SQLite databases.
android_sms — Parses Android SMS/MMS SQLite databases.
bencode — Parses generic bencoded files.
bencode_transmission — Parses Transmission BitTorrent metadata.
bencode_utorrent — Parses uTorrent metadata.
filestat — Parses file system metadata (stat information).
google_drive — Parses Google Drive SQLite databases.
openxml — Parses Microsoft OpenXML (OOXML) document metadata.
pls_recall — Parses PL/SQL Recall files.
popularity_contest — Parses Linux popularity-contest logs.
selinux — Parses SELinux audit logs.
syslog — Parses standard Unix/Linux syslog files.
skype — Parses Skype SQLite databases.
utmp — Parses Linux/Unix UTMP login records.
utmpx — Parses UTMPX login records.
xchatlog — Parses XChat log files.
xchatscrollback — Parses XChat scrollback files.
zeitgeist — Parses Zeitgeist activity SQLite databases.
mactime — Parses The Sleuth Kit mactime bodyfiles.
pcap — Parses packet capture (PCAP) files.

The breadth of these parsers enables Plaso to correlate operating system artifacts, mobile device activity, cloud synchronization metadata, chat histories, authentication records, file system events, and network traffic into a unified forensic timeline. This cross-platform capability significantly enhances digital investigations involving multi-device environments, insider threats, malware analysis, and incident response.

Modern Plaso/Log2Timeline provides extensive support for macOS forensic artifacts, enabling investigators to parse and normalize evidence from Apple-specific operating system components, application databases, security logs, property list (plist) files, browser histories, and cloud synchronization artifacts. By consolidating these heterogeneous data sources into a single chronological timeline, Plaso facilitates comprehensive reconstruction of user activity, application execution, authentication events, software installation, removable device usage, wireless connectivity, and system configuration changes across macOS environments.

macOS Artifact Parsers

appusage — Parses macOS application usage SQLite databases.
asl_log — Parses Apple System Log (ASL) files.
bencode — Parses generic bencoded files.
bencode_transmission — Parses Transmission BitTorrent metadata.
bencode_utorrent — Parses uTorrent metadata.
bsm_log — Parses Basic Security Module (BSM) audit logs.
cups_ipp — Parses CUPS Internet Printing Protocol (IPP) spool files.
filestat — Parses file system metadata (stat information).
google_drive — Parses Google Drive SQLite databases.
ipod_device — Parses iPod, iPhone, and iPad property list (plist) files.
ls_quarantine — Parses Launch Services quarantine event databases.
mac_appfirewall_log — Parses macOS Application Firewall logs.
mac_keychain — Parses macOS Keychain databases.
mac_securityd — Parses securityd authentication logs.
macwifi — Parses Wi-Fi connection logs.
mac_document_versions — Parses document version history SQLite databases.
mackeeper_cache — Parses MacKeeper cache SQLite databases.
olecf — Parses OLE Compound File (OLECF) structures.
olecf_automatic_destinations — Parses Windows Jump List *.automaticDestinations-ms files.
olecf_default — Generic OLECF parser.
olecf_document_summary — Parses DocumentSummaryInformation streams.
olecf_summary — Parses SummaryInformation streams.
openxml — Parses Microsoft OpenXML (OOXML) documents.
plist_airport — Parses AirPort Wi-Fi configuration plist files.
plist_appleaccount — Parses Apple account configuration plists.
plist_bluetooth — Parses Bluetooth configuration plists.
plist_default — Generic Apple property list parser.
plist_install_history — Parses installation history plist files.
plist_macuser — Parses macOS user preference plists.
plist_softwareupdate — Parses software update history.
plist_spotlight — Parses Spotlight indexing configuration.
plist_spotlight_volume — Parses Spotlight volume metadata.
plist_timemachine — Parses Time Machine backup configuration.
skype — Parses Skype SQLite databases.
webhist — Parses macOS browser history databases.

Collectively, these parsers enable forensic practitioners to correlate macOS operating system artifacts with browser history, Keychain records, audit logs, wireless connectivity, application usage, cloud synchronization, and file system metadata, providing a comprehensive timeline for incident response, insider threat investigations, malware analysis, and post-compromise forensic reconstruction.

The mactime parser enables Plaso/Log2Timeline to ingest forensic bodyfiles generated in The Sleuth Kit (TSK) mactime format and convert them into Plaso's native storage format. Rather than parsing a disk image directly, the parser imports pre-existing bodyfile records—containing timestamped file system metadata—and incorporates them into a Plaso storage (.plaso) database. This capability allows investigators to integrate file system timelines produced by external forensic tools with the extensive collection of artifacts extracted by Plaso, resulting in a unified super timeline for comprehensive event reconstruction. The parser is particularly useful for importing timelines generated by tools that export mactime-compatible bodyfiles, including The Sleuth Kit (fls/mactime) and memory forensic frameworks such as Volatility's Timeliner plugin.


log2timeline.py --parsers mactime --storage-file output.plaso bodyfile.body

When the above command is executed, the mactime parser reads the bodyfile and writes its events directly into a specified .plaso database. If the destination database already exists, the imported events are appended, allowing investigators to consolidate evidence from multiple forensic sources into a single normalized repository for subsequent analysis with psort.py, pinfo.py, or visualization platforms such as Timesketch.

Plaso functions as the core backend parsing engine and requires a frontend to operate as a standalone forensic tool. log2timeline.py serves as the primary and canonical frontend. Originally a Perl-based tool (log2timeline 0.x), it was succeeded by the modern Python-based Plaso framework, with log2timeline.py now acting as the main interface for creating Plaso storage files that can be further processed with tools such as psort.py. Operating as a single-host collection utility, it ingests evidentiary sources — directory structures, mounted volumes, forensic images (e.g., raw/dd, E01), and virtual disk formats — with recursive traversal applied automatically across all nested subdirectories.

Despite its extensive capabilities, basic usage of log2timeline.py is straightforward. A small number of critical options should be understood to ensure accurate parsing and optimal performance. A complete list of available parameters can be viewed by executing:

log2timeline.py --help

Two mandatory parameters govern invocation:

Storage File (--storage-file or -o): Specifies the path to the Plaso storage file (.plaso). This is a structured SQLite-based database that stores all normalized events and associated metadata extracted during processing. It can be newly created or appended to in subsequent runs.
Source: The target for artifact extraction—this may be a directory path, mount point, or a forensic image containing the subject system’s data.

Time Zone Handling

Accurate time zone management is a critical aspect of forensic timeline analysis. Plaso provides distinct controls for input (acquisition) and output (post-processing) stages. During acquisition with log2timeline.py, the --timezone option defines the local time zone of the subject system (not the desired analysis/output time zone). This adjustment is essential because certain artifacts store timestamps in local time rather than UTC. Plaso normalizes all events to UTC internally for consistency.

Best Practices:

When processing a full forensic image or properly mounted volume, Plaso’s preprocessor will typically auto-detect the system time zone.
When analyzing loose files, a triage collection, or when auto-detection is unreliable, explicitly specify the source system’s time zone as a matter of procedural rigor.
If no time zone is provided and none is detected, UTC is assumed for local-time artifacts (UTC-stored artifacts remain unaffected).
View available time zones with log2timeline.py --timezone list

For Windows systems, examine events parsed by the setupapi parser (included in default Windows presets). This is one of the few common artifacts that records timestamps in local time, making it an excellent indicator for verifying correct time zone normalization.

Plaso is a highly extensible and powerful framework offering numerous advanced features for filtering, tagging, analysis plugins, and output formatting. For comprehensive documentation, command references, and the latest updates, consult the official Plaso documentation.

Log2timeline exhibits exceptional source-agnosticism, ingesting nearly any evidentiary dataset an examiner might encounter. Supported inputs include:

Forensic disk images (raw/dd and Expert Witness Format/E01)
Virtual machine disk formats (VMDK, VHD/VHDX, QCOW2/3)
Physically attached or write-blocked devices
Individual volumes or partitions within a disk image
Loose file collections (triage data)

This flexibility makes it particularly valuable for partial data sets. For example, analysts can rapidly generate a meaningful timeline from limited triage artifacts—such as exported event logs, the Prefetch directory, browser databases, or other selected files—without requiring a full forensic image.

Command Examples

Raw Disk Image

log2timeline.py --storage-file /path-to/output.plaso /path-to/image.dd

EWF (E01) Image

log2timeline.py --storage-file /path-to/output.plaso /path-to/image.E01

Virtual Disk Image

log2timeline.py --storage-file /path-to/output.plaso /path-to/triage.vhdx

Physical Device (write-blocked drive or remote F-Response target)

log2timeline.py --storage-file /path-to/output.plaso /dev/sdd

Specific Volume(s) / Partition(s)

log2timeline.py --partitions 2 --storage-file /path-to/output.plaso image.dd

Triage Directory (loose files)

log2timeline.py --storage-file /path-to/output.plaso /triage/directory/

When a full forensic disk image is available, it is strongly recommended to parse the image file directly rather than mounting it to a local mount point. Mounting introduces several potential issues, including incomplete file system visibility (e.g., the NTFS $MFT may not be exposed depending on the mount driver and options used). Direct parsing via Plaso’s integrated dfVFS (Digital Forensics Virtual File System) library ensures maximum artifact coverage and consistency. For the most current list of supported storage media and virtual disk formats, refer to the official dfVFS documentation.

This broad source compatibility, combined with automatic recursion on directories and robust image handling, makes log2timeline.py one of the most powerful tools available for timeline generation in modern digital forensics.

Targeted Super Timeline Creation

Timeline analysis methodology bifurcates into two competing paradigms: exhaustive ("kitchen sink") super-timeline generation versus targeted, scope-constrained collection.

The exhaustive approach processes a disk image against the full parser corpus to extract every supported artifact and timestamp. Post-processing, filtering, and analysis are then performed on the resulting comprehensive dataset. This method is what most analysts envision when referring to a true super timeline. Subsets can be extracted later as needed.

Practitioners favoring targeted acquisition instead constrain data collection to artifact sources of known evidentiary relevance, often supplementing log2timeline with bespoke scripting and purpose-built parsing utilities. Analysts leverage advanced log2timeline.py options, custom filter files, parser selection, and complementary tools (including one-off scripts) to achieve this.

The determinative tradeoff is temporal efficiency against evidentiary completeness: exhaustive processing of a large volume may require 12–24 hours, whereas scope-constrained collection typically resolves in 5–30 minutes, at the residual risk of artifact omission—a risk generally justified by the value of early case orientation, given that supplemental collection remains available as investigative understanding matures.

Features Supporting Targeted Collection

Log2timeline furnishes native mechanisms for scope reduction:

Parser Selection (--parsers PARSER_LIST)

log2timeline.py allows explicit specification of the parsers to be used. This restricts processing to only the selected artifact types, significantly reducing scope and processing time. To view the complete list of available parsers, run:

log2timeline.py --parsers list

File Filter (-f FILTER_FILE, --file_filter FILTER_FILE, --file-filter FILTER_FILE )

Instead of limiting by parser, a filter file enables precise control by specifying individual files or paths (one per line) to be processed. Although manually curating such a list may appear laborious, in practice it closely mirrors the contents of a standard triage collection. This method is particularly efficient when working directly against a full disk image without first creating a separate triage subset.

Triage Image / Directory Processing

One of the simplest and most effective methods for scope reduction is to run log2timeline.py directly against a curated triage collection rather than an entire forensic image. Since triage collections already contain the artifacts deemed most relevant, generating a timeline from them requires no additional effort beyond specifying the correct source path.

By combining these capabilities, Plaso/log2timeline provides analysts with the flexibility to balance thoroughness and efficiency according to case priorities, time constraints, and investigative objectives.

Specifying individual parsers has long been the primary method for accelerating log2timeline.py execution by limiting the scope of artifact processing. To further streamline this process, Plaso now includes several curated preset collections of parsers in the default distribution. Presets can be invoked directly from the command line and combined with individual parsers using a comma-separated list. This provides granular control: analysts can expand a preset by adding specific parsers or reduce it by excluding unwanted ones.

Exclusion Syntax: Prepend the parser name with an exclamation mark (!) to exclude it from a preset.

log2timeline.py --parsers win7,!filestat --storage-file case.plaso /path-to/source

In this command, the win7 preset (a comprehensive set of parsers optimized for Windows 7 and later systems) is applied, with the exception of the filestat parser.

This preset-based approach significantly improves usability and efficiency, allowing forensic examiners to rapidly tailor artifact extraction to the specific operating system, investigation type, or performance requirements of the case. To enumerate the complete parser, plugin, and preset corpus supported by a given Plaso/log2timeline installation, the examiner invokes the --parsers list directive at the command line—surfacing the full taxonomy of available presets (organized by target operating system) alongside their constituent parsers and plugins.

For deeper technical exposition, including preset definitions contained in presets.yaml (the configuration file included in the Plaso installation) and the distinction between file-format parsers and their associated plugins—practitioners should consult Plaso's authoritative developer documentation.

Filter files in Plaso/log2timeline provide a powerful mechanism for restricting the scope of artifact acquisition by explicitly defining the files and directories to be processed, while disregarding all others. This capability enables analysts to perform rapid, focused extraction of only the most relevant forensic artifacts, irrespective of the underlying data source—whether a full forensic image, mounted volume, or triage collection.

By leveraging filter files, log2timeline.py can bypass the vast majority of non-pertinent files and directories within a filesystem. This optimization frequently reduces processing time by an order of magnitude, making it an essential technique when timely answers are required during time-sensitive investigations. Plaso supports two filter file formats: the legacy text-based format and the modern YAML-based format.

Text-Based Filter Files

The traditional text-based filter file consists of one entry per line, utilizing forward slashes as path separators. Entries support regular expressions, wildcards, and path expansion variables (e.g., {systemroot}) resolved during preprocessing.

Example:

/(Users|Documents And Settings)/.+/NTUSER\.DAT

This pattern instructs Plaso to parse the NTUSER.DAT registry hive for every user profile on the system.

Additional Example:

{systemroot}/winevt/Logs/.+\.evtx

This targets all Windows XML Event Log (EVTX) files located under the system root’s event logs directory.

Key Considerations:

Matching is performed case-insensitively.
Literal special characters should be escaped using square brackets (e.g., [$]).
Filter definitions are strictly inclusion-based: any file or path not explicitly matched is automatically excluded from processing.
Although path expansion variables offer convenience, they are not infallible. In practice, specifying full concrete paths is often more reliable for consistent results.

YAML-Based Filter Files

YAML-formatted filter files represent an enhancement over legacy text-based filtering, introducing exclusionary rule capability absent from the original schema. Whereas prior filter definitions could only specify inclusion criteria, YAML-based rules permit explicit designation of paths to be omitted from processing scope. Consider the inverse of a prior inclusion example—suppressing ingestion of Windows Event Log artifacts:

description: Exclude Windows Event Log files
type: exclude
path_separator: '\'
paths:
  - '%SystemRoot%\\System32\\config\\.+[.]evt'

In this example:

The type: exclude directive instructs the extraction engine to bypass any file or path matching the specified regular expression, foreclosing that artifact class from the resulting storage file.
The path-expansion syntax mirrors prior conventions, substituting percent-delimited variables (%SystemRoot%) for the curly-brace notation used in text-based filters.

YAML filters follow standard YAML syntax, providing a more structured and readable format for complex filtering logic.

Scope-constrained collection via filter files—whether text-based or YAML—grants forensic practitioners significant control over the scope of artifact extraction in log2timeline.py. By intelligently limiting processing to relevant data, analysts can achieve substantial gains in efficiency, often reducing full-disk image processing times by approximately 90% while conserving computational resources.

Combined with parser-level scope restriction, filter-file deployment constitutes a critical optimization for time-constrained investigations, enabling faster timeline generation without sacrificing the ability to expand scope iteratively as the case progresses. Examiners should consult current Plaso documentation for authoritative filter-file guidance, noting that the maintaining project furnishes canonical Windows-oriented exemplars in both legacy text and YAML formats via its public repository.

In the current landscape of large-scale intrusions and the sheer scale of contemporary datasets, comprehensive imaging of every system of interest is often impractical. While a full physical disk image—accompanied by a memory capture—remains the evidentiary gold standard, affording the broadest analytical latitude, its exhaustive application is precluded by practical constraints in the majority of engagements. This necessitates a triage-oriented acquisition strategy. The following prioritized set of artifacts is recommended:

Volatile Memory (RAM)
Registry Hives and associated backup files
Windows Shortcut (LNK) files
Jump Lists (*.automaticDestinations-ms and *.customDestinations-ms)
Prefetch files
Windows Event Logs and associated logging artifacts
Browser artifacts (Internet Explorer, Firefox, Chrome, and others)
Master File Table ($MFT)
System log files and filesystem journal data
Pagefile and hibernation files (hiberfil.sys)

This targeted collection supports critical forensic capabilities, including memory analysis, comprehensive registry examination, application execution history, event log correlation, and robust (though not exhaustive) timeline construction. In the majority of investigations, this curated dataset provides sufficient evidentiary material to address the core questions required during the initial response phase.

Case-specific considerations may warrant supplemental collection: browser database exports, cloud-storage synchronization artifacts, email stores, or complete user-profile acquisition for subjects of particular evidentiary interest. No canonical collection scope exists; expedited forensic methodology is bounded only by allotted time and the responder's technical acumen and investigative ingenuity.

While filter-file deployment and parser-scope restriction constitute effective throughput optimizations for log2timeline, the most parsimonious efficiency gain is often achieved simply by constraining the input corpus itself. Where a triage collection has already been assembled, further scope reduction at the timeline-generation stage is unnecessary — triage acquisition, by definition, isolates those artifacts of presumed highest evidentiary value, rendering direct timeline construction from that collection both methodologically sound and operationally frictionless, requiring no configuration beyond pointing log2timeline at the triage dataset.

log2timeline.py --storage-file output.plaso /triage-output/

The pairing of a triage-collection utility (e.g., KAPE) with Plaso/log2timeline for timeline synthesis thus constitutes a rapid-forensics capability, compressing the collection-to-analysis pipeline into a matter of minutes. The specific triage tool employed is immaterial to this methodology—log2timeline's capacity to synthesize a timeline from an arbitrary artifact collection is the operative principle; KAPE's utility lies merely in its efficiency as a collection mechanism. This represents a substantive departure from traditional full-volume acquisition paradigms, obviating the requirement for exhaustive disk imaging.

Critically, this capability need not supersede established forensic workflows: triage acquisition and processing may proceed in parallel with subsequent full-disk acquisition of target systems. Iterative application of this hybrid methodology is likely to substantially diminish reliance on full imaging as a default standard operating procedure.

Filtering the Super Timeline Using pinfo.py and psort.py

pinfo.py: Storage File Validation and Metadata Inspection

pinfo.py is an essential utility for validating and inspecting Plaso storage files (.plaso). It provides a comprehensive overview of the internal metadata contained within the database, enabling analysts to confirm critical details such as:

Which artifacts were successfully parsed
The date and time of processing
Preprocessor information
Active parsers and plugins utilized during acquisition

The tool is particularly valuable for ensuring the integrity and completeness of the generated storage file prior to detailed analysis. When invoked with the verbose flag (-v or --verbose), pinfo.py outputs significantly more detail, including comprehensive preprocessor results, system information, and extensive error or warning messages. This mode is highly recommended for troubleshooting or when thorough validation of the collection process is required. In practice, running pinfo.py should be a standard step immediately following storage file creation to verify successful artifact extraction and to document the provenance of the timeline data.

psort.py: Post-Processing and Timeline Generation

psort functions as the post-processing utility for Plaso storage files, providing filtering, chronological sorting, and deduplication against the serialized event corpus. The raw output of log2timeline—an SQLite-backed storage file containing serialized event objects, extraction metadata, tags, analysis reports, and derived contextual data—is not itself human-readable; psort performs the transformation from this intermediate representation into an analyst-consumable timeline. It supports post-hoc filtering across an extensive attribute set and critically performs deduplication of redundant event entries—a capability of particular evidentiary value when Volume Shadow Copies or backup registry hives introduce recurrence of substantively identical artifacts.

psort should be conceptualized as the timeline-synthesis stage proper: while exhaustive output (the default behavior) remains available, the tool equally supports rapid construction of scope-constrained mini-timelines via temporal or artifact-based filter expressions. Storage-file construction is comparatively time-intensive, whereas post-hoc filtering against an already-populated store executes with substantially greater efficiency.

General Command Syntax

psort.py [OPTIONS] STORAGE_FILE [FILTER]

Common Options:

--output-time-zone ZONE — Sets the timezone for output events (default is UTC).
-o FORMAT—Specifies the output format (e.g., dynamic, csv, json, l2tcsv, etc.).
-w OUTPUTFILE — Defines the path for the output file.

Time zone normalization: psort defaults to UTC for event output; this is overridden via --output-time-zone. The complete set of supported zone identifiers is enumerable via the following command.

psort.py --output-time-zone list

Minimal invocation: the tool requires only a storage-file path and an output destination (-w) to execute, in which case it returns the complete event corpus, UTC-normalized by default. Building the initial storage file can be time-intensive, particularly on large datasets; however, subsequent filtering and output generation with psort.py is typically much faster, enabling rapid creation of both comprehensive super timelines and focused mini-timelines as the investigation evolves.

Time-Slice Analysis

psort.py --slice '2023-08-30T20:00:00' -w slice.csv out.plaso

Time-slice extraction is a particularly effective technique when pivoting from a discrete point of interest within the dataset. Consider a workflow in which application-execution artifacts have been isolated via filter, and a specific execution event within that constrained result set is flagged as anomalous or warranting deeper scrutiny. Noting the associated timestamp, the examiner can invoke a time slice anchored to that moment — the tool extracts all events falling within the surrounding temporal window (5 minutes prior and subsequent, by default), yielding a contextualized mini-timeline for correlation analysis. This default window is user-configurable via the --slice_size parameter.

Alternative Output Formats

The default output format, dynamic, renders a CSV structure with an abbreviated field set. Additional output modules exist beyond flat-file formats, including direct ingestion into an Elasticsearch backend, a capability well-suited to analysis at scale. The complete enumeration of supported output modules is obtained via:

psort.py -o list

Example: Time-Range Filtered Export with psort.py.

Synthesizing this methodology into an applied scenario: consider a web-server compromise requiring investigation under time pressure and minimal contextual grounding. Rather than pursue full-volume acquisition, the responder opts for an expedited, scope-constrained timeline sufficient for alert validation and preliminary investigative triage. A triage file collection is remotely exported from the subject system via the network.

Step 1—Targeted Extraction: log2timeline is invoked against the triage collection, with processing scope constrained to Windows Event Logs and IIS web-server logs specifically.
```
log2timeline.py –-timezone 'UTC' --parsers 'winevtx,winiis' --storage-file out.plaso /cases/IIS_Triage_Files 
```
Step 2 — Supplemental MFT Ingestion: A Master File Table, parsed independently via the external utility MFTECmd, is appended to the out.plaso storage file. This step merits elaboration: while Plaso's native filestat parser furnishes filesystem-stat metadata, its coverage is limited to files already subject to active parsing by other engaged parsers—in this instance, only the ingested log artifacts. Comprehensive MFT coverage, therefore, requires external processing via MFTECmd, which emits output in mactime bodyfile format; this bodyfile is subsequently ingested and appended to the existing storage file via Plaso's mactime parser. This technique constitutes an effective mechanism for maximizing evidentiary yield from triage-scale collections absent full-disk acquisition and recurs throughout subsequent timeline-construction exercises.
```
log2timeline.py --parsers 'mactime' --storage-file out.plaso /cases/IIS_mft.body
```

Step 3—Timeline Synthesis: psort.py is applied to sort, filter, and render the composite dataset as a super timeline in CSV format for analytical review.

psort.py --output-time-zone 'UTC' –o l2tcsv –w supertimeline.csv out.plaso "date > datetime('2023-01-01T00:00:00') AND date < datetime('2023-01-27T00:00:00')"

Extending the preceding methodology to full-volume acquisition: consider constructing a super timeline from a complete disk image—whether a write-blocked physical drive, a raw or E01 forensic image, or a cloud-volume snapshot migrated to a forensic workstation instance within the same cloud environment. In this context, deployment of a filter file is the optimal scope-reduction mechanism. Rather than iterating exhaustively across hundreds of thousands of evidentially immaterial files, the Filter File constrains processing to core system artifacts of established investigative relevance. Critically, incorporating the $MFT bodyfile in the subsequent step preserves comprehensive file-level metadata references—including size and timestamp data—across the full artifact population, notwithstanding the narrowed initial parsing scope.

Step 1 — Scoped Extraction: log2timeline is executed against the full disk image, constrained via Filter File to designated files and directories. The default Windows parser preset (win7) is applied, with the filestat parser explicitly excluded (filesystem metadata being deferred to Step 2).
```
log2timeline.py –-timezone 'UTC' -f filter_windows.yaml --parsers 'win7,!filestat' --storage-file out.plaso /cases/cdrive/disk.E01 
```
Step 2 — MFT Integration: The Master File Table, independently parsed via the external utility MFTECmd, is appended to the out.plaso storage file. The mactime parser ingests the resulting bodyfile, converts it to Plaso-native format, and appends it to the existing datastore. Even against a full disk image, exhaustive parsing is deliberately foregone due to Filter File constraints — necessitating standalone MFT processing to recover comprehensive filesystem coverage. MFTECmd's filesystem-output formatting is additionally preferred over that of Plaso's native filestat parser.
```
log2timeline.py --parsers 'mactime’ --storage-file out.plaso /cases/mftecmd.body 
```

Step 3 — Timeline Synthesis: psort.py performs sorting, filtering, and rendering of the composite super timeline in CSV format for analytical review.

psort.py --output-time-zone 'UTC' –o l2tcsv –w supertimeline.csv out.plaso "date > datetime(‘2023-01-01T00:00:00') AND date < datetime(‘2023-01-27T00:00:00')"

Understanding and Parsing the Super Timeline Output File

Timeline analysis presents a formidable learning curve for the uninitiated practitioner. Yet just as an examiner is not obligated to individually enumerate every file among 100,000+ objects on a target volume, neither must every entry within a super timeline comprising hundreds of thousands of rows be examined in isolation. What follows constitutes the essential orientation for a first timeline-analysis engagement.

psort's default output—the dynamic module, rendering CSV—surfaces only an abbreviated subset of the fields the log2timeline parsing engine makes available. Given the sheer informational density inherent to a super timeline, the l2tcsv output module is preferred for its expanded field schema, providing greater descriptive granularity per event. The l2tcsv field structure is as follows:

date — event date, MM/DD/YYYY
time — 24-hour clock, HH:MM:SS
timezone — time zone applied during processing/output
MACB — Modification/Access/Change/Birth notation, relevant primarily to filesystem artifacts
source — abbreviated source designation (e.g., WEBHIST for browser history, REG for registry entries, LOG for generic log files)
sourcetype — expanded source description (e.g., "Chrome History" in lieu of WEBHIST; "Registry Key - UserAssist" in lieu of REG)
type — semantic description of the timestamp itself (e.g., "Last Access Time," "Content Modification Time," "Creation Time," "Last Time Executed," "Last Visited Time," "File Downloaded")
user — associated username, where applicable
host — associated hostname, where applicable
short — abbreviated event description (frequently insufficiently detailed for standalone analytical use)
desc — expanded description field; the primary repository of parsed interpretive content
version — version identifier of the timestamp object
filename — full path of the parsed artifact
inode — metadata address (inode/MFT entry) of the parsed file
notes — supplemental annotations inserted by certain input modules
format — identifier of the parser module used for extraction
extra — supplementary artifact-derived information

The Plaso super-timeline output schema encompasses a substantially broader column set than the conventional Sleuthkit-style "body" timeline format—a density that can prove cumbersome on constrained-resolution analysis workstations. To optimize available screen real estate, initial analysis is best conducted against a reduced core column set (shown in white in the above figure), with supplementary fields introduced as analytical sophistication increases. For instance, multi-system correlation analysis renders the user and host fields materially relevant, whereas single-system analysis may not require them displayed by default.

The inode field warrants inclusion when deeper examination of Master File Table entries or artifacts such as the $UsnJrnl (USN Change Journal) is anticipated but may be suppressed when display density takes priority. The extra field, while non-essential to baseline analysis, occasionally retains supplementary parser-derived context and merits situational inclusion. Optimal column configuration is inherently case-dependent and best refined through iterative practice.

The viewer employed in this article, Timeline Explorer, incorporates a "Details" view surfacing the complete field set for a given row in a unified display—a pane that can be relocated to a secondary monitor to maintain full evidentiary context alongside the primary grid during active analysis. Double-clicking any row invokes this comprehensive per-record view.

Note additionally that the column nomenclature presented reflects log2timeline's native field-naming convention. Timeline Explorer applies a bundled layout configuration that remaps select fields for improved analyst readability—for example, desc is rendered as "Long Description" and sourcetype as "Source Description." Timeline Explorer further suppresses a subset of low-priority columns by default, which remain accessible on demand via its Column Chooser feature.

Spreadsheet-based analysis constitutes a viable entry point, but purpose-built alternatives afford substantially greater analytical capability. SANS Instructor Eric Zimmerman developed one such alternative: Timeline Explorer, an application engineered specifically for timeline processing while remaining broadly applicable to arbitrary CSV or Excel input. Upon ingestion, the resulting grid view supports concurrent multi-timeline analysis via a tabbed interface, with automatic color-coded categorization by artifact type—a schema documented via an accessible legend under the Help menu. In representative usage, USB device activity renders in blue, file-open events in green, and process-execution events in red.

Timeline Explorer accepts virtually any CSV or Excel input (first worksheet only for the latter), rendering contents in a strictly read-only grid—no in-application data modification is possible. Supported formats span Autoruns output, Mactime-derived timelines, Plaso super timelines, and CSV output from the full suite of Eric Zimmerman's command-line forensic utilities.

Keyboard shortcuts:

CTRL-E — clear active filters
CTRL-T — tag/untag selected rows
CTRL-R — reset column widths
CTRL-D — invoke Details view (super-timeline context)
CTRL-C — copy selected cells and headers to clipboard (behavior configurable via Tools menu)
CTRL-F — invoke Find dialog
CTRL-Down — jump to final row
CTRL-SHIFT-A — select all values within active column

Wildcard syntax: column filters employing the LIKE operator support % (arbitrary-length match) and _ (single-character match). CONTAINS — the default operator — implicitly applies wildcard logic, though explicit LIKE-based wildcard construction frequently yields greater precision.

Tagging and export: row-level tagging enables isolation of a data subset, subsequent filtering against that subset, and export to Excel format via the File menu — a mechanism supporting both reporting deliverables and persistent annotation of investigatively significant entries for iterative review.

Details view: double-clicking any Plaso super-timeline entry invokes the Details window, presenting the full field set in vertical (non-horizontal) orientation—particularly advantageous when reviewing verbose Event Log entries. Configurable options include an always-on-top display mode and navigation controls for sequential record traversal.

Search-mode configuration: the location of the global search-behavior control varies across Timeline Explorer versions. This setting toggles between Filter mode (suppressing non-matching rows entirely) and Search mode (highlighting matches while preserving the full row set in view).

Layout persistence: layout files, maintained per supported file type within the installation's Layout directory, govern column visibility, ordering, and conditional-formatting (colorization) rules and are loaded automatically upon file ingestion.

Initial proficiency in timeline analysis is inherently effortful, requiring both procedural fluency in filtering large row sets and accumulated familiarity with artifact-pattern significance. One durable heuristic: absent specific investigative need, exclusion of temporary internet file artifacts is generally advisable given their sheer volumetric noise. Analyst-specific filtering preferences will develop with experience. Colorization should function as an attention-directing aid rather than an exhaustive index of relevance—numerous evidentially significant artifact classes (event logs among them) remain deliberately uncolored to preserve visual legibility.

Zimmerman maintains active receptivity to practitioner feedback and feature requests. For those interested in the technique's provenance, the original timeline-colorization methodology was distributed as an Excel template, documented alongside its associated workflow on the SANS website.

Timeline Analysis Process

Temporal-Scope Determination is established through analysis of the investigation's key questions in conjunction with case typology, generally yielding a bounded interval — activity occurring between Date A and Date B. Scope narrowing at this stage is foundational to effective data-volume management throughout subsequent analysis.

Pivot-Point Identification proceeds via one of two methodologies: temporal anchoring, wherein the examiner establishes the closest approximable window to the suspected incident timeframe, or artifact-based anchoring, wherein a specific file, user account, or other evidentiary object implicated in the activity under examination serves as the investigative fulcrum.

Timeline-Construction Methodology Selection is governed by the anticipated data-source requirements. Where the evidentiary target set remains undefined, a comprehensive super timeline is the appropriate default, ensuring no artifact class is prematurely excluded. Conversely, where the requisite data can be predicted with reasonable confidence, a scope-constrained super timeline or filesystem-only timeline may prove sufficient.

Timeline Filtering is executed against the established scope, incorporating de-duplication and elimination of evidentially immaterial data. Keyword-driven identification of relevant pivot points is a recommended technique at this stage to accelerate convergence on significant entries.

Timeline Analysis proceeds through contextual examination of discovered evidence, with particular attention to the temporal window immediately preceding and following each identified pivot point, in order to reconstruct user-activity patterns. The SANS Windows Forensic Analysis poster's "Evidence Of..." categorization framework serves as an authoritative reference to structure and validate this analytical process.

Scaling Timeline Analysis Across Multiple Systems

Having established the evidentiary utility of single-timeline analysis, the natural extension is applying that same interrogative capability across a multi-timeline corpus simultaneously. Two principal methodologies address this at-scale challenge.

1. Lightweight IOC-Based Scanning of Timelines

The first approach targets obvious indicators of compromise directly across a timeline collection — whether via regular-expression sweeps across a directory of timeline files or through IOC-framework integration such as YARA. Even elementary heuristic checks — executables residing in $Recycle.Bin, svchost.exe instantiated outside Windows\System32, execution signatures of known reconnaissance tooling, or matches against a known-bad file/registry-key corpus — can rapidly triage which timelines warrant deeper examination. Kristinn Guðjónsson, the creator of Plaso, developed the yara_match.py script specifically to enable efficient YARA signature scanning against super timelines.

2. Centralized Database and Collaborative Platforms

The second, more robust methodology centers on centralized database ingestion. Splunk (free or commercial tier) constitutes a capable platform for timeline indexing and search; Dave Herrald's purpose-built Splunk application facilitates direct ingestion of log2timeline-formatted output. The ELK stack (Elasticsearch, Logstash, Kibana) — a widely adopted, freely available framework for massive-scale data ingestion, indexing, and dashboard-driven visualization — is likewise supported natively, with Plaso providing a dedicated elastic output module for this purpose. Centralizing multiple timelines within such a database enables cross-timeline pattern search at scale.

Extending this paradigm further, Johan Berggren developed Timesketch, a purpose-built front-end unifying log2timeline output with Elasticsearch-backed search. Timesketch enables multi-investigator, real-time collaborative analysis across a shared timeline corpus, incorporating tagging, annotation, and data-enrichment capabilities. For practitioners prepared to scale beyond single-analyst, single-timeline workflows, these platforms represent the natural next step.

When an investigation demands enterprise-scale analysis and collaboration, these tools and techniques significantly enhance speed, efficiency, and analytical depth.

Facebook SDK

Super Timeline Analysis with Plaso/Log2timeline