Forensics Analysis

Timeline Analysis and Report Generation Using Forensic Tools

Timeline analysis constitutes one of the most powerful reconstructive methodologies in digital forensics. By ordering heterogeneous artifacts along a single temporal axis, an examiner transforms a disordered corpus of evidence into a coherent narrative of who did what, when, and in what sequence. In advanced incident response and litigation, a well-constructed timeline is often the decisive artifact: it exposes causality, constrains attacker dwell time, and either corroborates or refutes witness testimony.

Foundations: The MACB Model and OS-Specific Semantics

Every file system records a small vector of timestamps for each file object. In the canonical forensic literature these are referred to as MACB timestamps:

• Modified (content modification time, mtime)
• Accessed (last read time, atime)
• Changed (metadata change time, ctime)
• Born (creation time, crtime or btime)

The semantic interpretation of this vector is not portable across operating systems. On NTFS and FAT/exFAT volumes, Windows records all four fields with 100-nanosecond resolution anchored to the UTC epoch of 1601-01-01. The ctime field on Windows denotes a metadata change (e.g., rename, permission change), while btime records the moment the inode was first allocated. On ext4, XFS, and APFS, by contrast, the traditional UNIX ctime is always a metadata-change field and there is no universally stored creation time—although ext4 and APFS do persist crtime/birthtime in the inode, older ext2/ext3 volumes do not. This asymmetry is a frequent source of examiner error: an analyst who treats a Linux ctime as a "creation time" will systematically misdate file births.

Formally, let $\mathbf{T}_f = (t_M, t_A, t_C, t_B)_f$ denote the timestamp vector associated with file $f$. A forensic timeline $\mathcal{L}$ is the ordered projection

$$\mathcal{L} = \{ (t_i, s_i, \alpha_i) \mid t_i \in \bigcup_f \mathbf{T}_f \cup \mathcal{E},\ s_i \in \mathcal{S},\ \alpha_i \in \mathcal{A} \}$$

where $\mathcal{E}$ is the set of event-log timestamps (Windows Event Log, syslog, $LogFile journal entries), $\mathcal{S}$ is the source artifact class (file system, registry hive, prefetch, browser history), and $\alpha_i$ is an attribution label (user SID, process ID, or $\varnothing$ if unknown). The timeline is sorted such that $t_1 \le t_2 \le \cdots \le t_n$.

Synthesizing Heterogeneous Artifact Sources

A defensible timeline is never built from a single artifact class. Modern examinations fuse at least the following sources:

1. File system metadata ($MFT on NTFS, inode tables on ext4/APFS) — provides MACB times and parent-child relationships.
2. Registry hives (NTUSER.DAT, SYSTEM, SOFTWARE, Amcache.hve) — each key carries a LastWriteTime that marks the most recent modification of that key or any of its values.
3. Event logs (.evtx) — structured records with SystemTime fields, correlated by EventRecordID and ProcessID.
4. Prefetch and ShimCache — evidence of program execution with embedded run counts and last-run timestamps.
5. Browser artifacts (History, Cookies, Web Data SQLite databases) — visit times in WebKit epoch (microseconds since 1601-01-01) or Chrome epoch.
6. LNK files and Jump Lists — embed target MACB times alongside the shortcut's own MACB times, enabling cross-validation.

The fusion problem is non-trivial because each source uses a different epoch and resolution. Let $t^{(k)}$ denote a timestamp reported by source $k$ in its native epoch $E_k$ with resolution $r_k$. Normalization to a common reference (typically POSIX/UTC) proceeds via

$$t_{\text{UTC}} = \frac{t^{(k)} - E_k}{r_k} - \Delta_k,$$

where $\Delta_k$ is the clock skew of the host that generated source $k$ relative to true UTC. Estimating $\Delta_k$ is itself a forensic sub-discipline: examiners compare NTP synchronization logs, DHCP lease timestamps, and Kerberos ticket times against known-good external references.

Tool-Assisted Construction: Autopsy, Plaso, and Timesketch

Autopsy provides an integrated GUI pipeline: after ingesting a forensic image, the analyst invokes Tools → Generate Timeline, which parses the $MFT (or equivalent), normalizes MACB fields, and emits a bodyfile—a pipe-delimited text format originating from The Sleuth Kit:

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

For enterprise-scale cases, the open-source plaso engine (the successor to log2timeline) is preferred. Plaso ships with over one hundred parsers and plugins that consume raw images, triage collections, and cloud exports, emitting a unified Plaso storage file. This file is typically loaded into Timesketch, a web-based collaborative analysis platform that supports tagging, filtering, and saved views—each view being a saved query over the timeline.

A typical plaso invocation is:

log2timeline.py --status_view window --partitions all \
    --parsers winreg,evtx,prefetch,mft,lnk \
    /cases/output.plaso /evidence/disk.E01

The resulting super timeline is the union $\mathcal{L} = \bigcup_k \mathcal{L}^{(k)}$ across all parsed sources, and may easily exceed $10^7$ events for a single workstation.

Detecting Temporal Anomalies

Adversaries routinely manipulate timestamps to frustrate analysis. Timestomping—the deliberate alteration of MACB fields via tools such as timestomp, SetMACE, or direct $MFT $STANDARD_INFORMATION edits—leaves detectable traces. A robust detection heuristic compares the $STANDARD_INFORMATION (attribute 0x10) timestamps against the $FILE_NAME (attribute 0x30) timestamps: the latter are updated only by the kernel during namespace operations and are not writable by user-mode APIs. If

$$\| t_M^{(SI)} - t_M^{(FN)} \| > \tau$$

for a threshold $\tau$ on the order of seconds, the file is flagged as potentially timestomped.

Other anomalies include:

• Time travel events: an event $e_i$ causally dependent on $e_j$ yet timestamped $t_i < t_j$, indicating clock rollback or log injection.
• Epoch confusion: timestamps that differ by exactly $11644473600$ seconds indicate a Windows-epoch/POSIX-epoch misinterpretation.
• DST ambiguity: timestamps falling in the autumn "fall-back" hour on systems that store local time (legacy FAT) are inherently two-valued; the examiner must report both candidate interpretations.

Quantitatively, one can define a timeline entropy over a sliding window $W$ of width $w$:

$$H(W) = -\sum_{c \in \mathcal{C}} p_c \log_2 p_c,$$

where $p_c$ is the proportion of events in $W$ belonging to artifact class $c$. Sudden collapses in $H(W)$—for example, a window containing only $MFT events and no registry or log events—often indicate artifact deletion or selective log clearing, a hallmark of anti-forensic activity.

Report Generation and Evidentiary Presentation

The terminal deliverable of timeline analysis is the forensic timeline report, which must satisfy both technical and legal audiences. Best practice structures the report in four layers:

1. Executive summary — a one-page narrative identifying the incident window $[t_{\text{initial}}, t_{\text{containment}}]$, the threat actor's TTPs mapped to MITRE ATT&CK, and the principal findings.
2. Methodology — tools and versions (e.g., Autopsy 4.21.0, plaso 20241205), hash values of all input images (SHA-256), and the normalization equations applied, establishing reproducibility and chain of custody.
3. Annotated timeline — a tabular or graphical rendering of the critical event sequence, with each row citing the source artifact, its hash or inode, and the confidence level of the timestamp (high for kernel-written $FILE_NAME entries, moderate for user-writable registry LastWriteTime, low for application logs on unsynchronized hosts).
4. Appendices — the raw bodyfile or CSV export, parser logs, and a glossary of artifact classes.

For

Advanced File Recovery and Data Carving Techniques

The transition from logical file system analysis to physical media exploitation represents a critical threshold in digital forensics. Advanced File Recovery encompasses the methodologies used to reconstruct data that has been intentionally obfuscated, fragmented, or marked for deletion by the operating system. When logical pointers are severed, investigators must rely on Data Carving (or file carving), a process that extracts files from Unallocated Space based on structural artifacts and data semantics rather than file system metadata.

Recycle Bin Artifacts and Metadata Structures

Before engaging in raw sector carving, an investigator must exhaust logical and semi-logical artifacts. In modern Windows environments, the Recycle Bin is managed via the hidden $Recycle.Bin** directory. When a user deletes a file, the NTFS file system generates two corresponding artifacts: an **$I (index) file and an **$R** (recycled) file. The$I file contains a binary structure housing the deletion timestamp (encoded as a Windows FILETIME 64-bit integer), the original file size, and the absolute path of the file prior to deletion. The $R file contains the raw data stream.

Analyzing these artifacts requires parsing the $I header, which varies between Windows Vista/7 (version 1) and Windows 10/11 (version 2). In forensic triage, recovering a deleted $I file from unallocated space can yield the original path of a malicious payload even if the$R data file has been securely overwritten, demonstrating the asymmetric persistence of metadata versus payload data.

Unallocated Space Analysis and Algorithmic Carving

When files bypass the Recycle Bin or are permanently purged, their Master File Table (MFT) or inode entries are marked as available, and the clusters they occupied are returned to the Unallocated Space. Data Carving operates on the principle that file contents persist until physically overwritten. Traditional carving relies on File Signatures (magic numbers) to identify the header and footer of a file. For instance, a JPEG file is bounded by the hex signatures FF D8 FF and FF D9.

However, sequential header-footer carving fails catastrophically when dealing with fragmented files. To address this, graduate-level forensics employs algorithmic approaches such as Bifragment Gap Carving and Graph-Theoretic Carving. Let a fragmented file be modeled as a sequence of non-contiguous blocks $B = \{b_1, b_2, \dots, b_n\}$. The carving algorithm constructs a directed graph $G=(V,E)$ where vertices represent unallocated blocks, and a directed edge $e_{i,j}$ exists if block $b_j$ is a statistically probable successor to $b_i$. This probability is calculated using n-gram language models, byte-level entropy analysis, and structural constraints specific to the target file format.

The Economics of Forensic Triage and Carving Utility

In large-scale investigations, computational resources and investigator time are strictly bounded. We can frame Forensic Triage as an economic optimization problem, applying microeconomic utility theory to allocate carving resources efficiently. Let the investigator's utility be a function of carving depth $x_1$ (computational cycles spent on deep heuristic and graph-based analysis) and signature breadth $x_2$ (the number of distinct file types and custom signatures targeted).

The utility function is defined as $U(x_1,x_2) = V \cdot P(x_1, x_2) - (c_1 x_1 + c_2 x_2)$, where $V$ represents the expected evidentiary value of the recovered data, $P(x_1, x_2)$ is the probability of successful recovery, and $c_1, c_2$ are the marginal costs of computation and analyst time, respectively.

Assume the probability of recovery follows a Cobb-Douglas-inspired saturation function: $P(x_1, x_2) = 1 - e^{-\lambda (x_1 x_2)^{1/2}}$, where $\lambda$ is a constant representing the underlying data density and fragmentation severity. To find the optimal allocation of forensic resources, we derive the marginal utility with respect to carving depth:

$$\frac{\partial U}{\partial x_1} = V \left( \frac{\lambda}{2} \left(\frac{x_2}{x_1}\right)^{1/2} e^{-\lambda (x_1 x_2)^{1/2}} \right) - c_1 = 0$$

The economic intuition here is rooted in the principle of diminishing marginal returns. An investigator should only increase the computational depth of graph-theoretic carving ($x_1$) as long as the marginal expected evidentiary value exceeds the marginal cost of compute and time. If, during an active investigation, the condition $\frac{\partial U}{\partial x_i} > 0$ holds for a specific carving dimension $i$, the forensic laboratory is economically under-investing in that dimension and should reallocate resources toward it until equilibrium is reached. This formal derivation prevents the common forensic pitfall of expending thousands of CPU hours on deep carving for low-value, high-fragmentation sectors.

Fragmentation, Overwriting, and Solid-State Storage

The necessity of advanced algorithmic carving is dictated by the file system's utilization factor, $\rho$. The probability of a file of size $k$ blocks being allocated contiguously is approximately $P_{contig} \approx (1 - \rho)^{k-1}$. As a drive approaches maximum capacity ($\rho \to 1$), $P_{contig}$ approaches zero, and the reassembly of fragmented files becomes computationally NP-hard, effectively reducing the carving process to a constrained Hamiltonian path problem.

Furthermore, the advent of Solid State Drives (SSDs) introduces severe complications regarding partially overwritten digital evidence. SSDs utilize a Flash Translation Layer (FTL) to map Logical Block Addresses (LBAs) to Physical Page Addresses (PPAs). Because NAND flash memory cannot overwrite data without first performing an expensive block erase operation, the FTL employs Wear-Leveling algorithms.

From an economic perspective, the FTL acts as a rational agent minimizing the hardware depreciation cost (wear) by distributing erase cycles evenly across all physical cells. Consequently, when an operating system issues an overwrite command to an LBA, the FTL simply writes the new data to a fresh, erased physical page and updates the mapping table, leaving the original data intact in an Unmapped Physical Block. Therefore, traditional logical overwriting does not destroy evidence on SSDs; it merely orphaned the physical pages. Advanced recovery in this context requires bypassing the storage controller, performing a raw NAND chip-off extraction, and mathematically reverse-engineering the FTL's proprietary mapping and XOR-based RAID parity algorithms to reconstruct the orphaned physical pages into coherent logical evidence.

Windows Registry Architecture and Forensic Artifact Extraction

The Windows Registry is a hierarchical, centralized database that stores low-level configuration settings for the Microsoft Windows operating system and for applications that opt to use it. For the digital forensic investigator, the registry is arguably the most prolific source of evidentiary artifacts, capturing a granular history of user activity, hardware connections, software execution, and system configuration.

Hierarchical Architecture of the Registry

At the logical level, the registry is organized into a tree structure comprising five root keys, commonly referred to as hives: HKEY_LOCAL_MACHINE (HKLM), HKEY_CURRENT_USER (HKCU), HKEY_CLASSES_ROOT (HKCR), HKEY_USERS (HKU), and HKEY_CURRENT_CONFIG (HKCC).

At the physical level, the registry is stored on disk as a set of binary files known as Registry Hives. The primary system hives (SAM, SECURITY, SOFTWARE, and SYSTEM) reside in %SystemRoot%\System32\config\, while user-specific hives (NTUSER.DAT) are located in each user's profile directory (%UserProfile%). The binary structure of a hive file begins with a regf header, followed by hive bins (hbin), which are further subdivided into cells. These cells contain named keys (nk), value keys (vk), and security descriptors. Understanding this binary layout is critical for advanced forensic tasks, such as carving deleted keys from unallocated hive space.

Acquisition Methodologies: Live vs. Offline

Extracting registry hives requires careful handling to preserve cryptographic hashes and metadata.

• Live Acquisition: When a system is powered on, registry files are locked by the Windows kernel. Investigators utilize specialized APIs (such as RegSaveKey) or forensic triage tools (e.g., FTK Imager, KAPE) to bypass file locks and copy the hives to an external medium. Live acquisition also allows for the dumping of volatile memory, which contains the active, in-memory registry state, including ephemeral keys that have not yet been flushed to disk.
• Offline Acquisition: In post-mortem forensics, hives are extracted from raw disk images. Because the system was not running, the on-disk hives may be "dirty" (missing recent transactions). Investigators must parse the accompanying Transaction Logs (*.LOG1, *.LOG2) and replay them to reconstruct the most recent state of the hive. Furthermore, investigators should extract hives from Volume Shadow Copies (VSS) to obtain historical snapshots of the registry, enabling the analysis of system states prior to anti-forensic wiping or malware infection.

Extracting Critical Forensic Artifacts

USB Device Forensics

Windows maintains a comprehensive history of connected Universal Serial Bus (USB) devices, which is vital for investigating data exfiltration or the introduction of contraband. This history is distributed across several registry keys:

1. HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR: Records all USB mass storage devices connected since OS installation. It reveals the Vendor ID (VID), Product ID (PID), and the device serial number. Forensic heuristic: If the second character of the device serial number is an ampersand (&), the device lacks a unique hardware serial number, and the OS has generated a synthetic identifier.
2. HKLM\SYSTEM\MountedDevices: Maps the unique serial number of a USB device to a specific drive letter or volume GUID (Globally Unique Identifier) that was allocated upon insertion.
3. HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2: Records the specific user context logged in when the device was connected, alongside the Last Write Time of the key, which serves as a proxy for the device's last connection time.
4. HKLM\SYSTEM\CurrentControlSet\Enum\USB: Stores deep technical descriptors for the USB hub and device interfaces, providing supplementary timestamps and hardware properties.

Limitations with MTP: Not all devices populate the USBSTOR key. Devices utilizing the Media Transfer Protocol (MTP)—such as modern Android smartphones, Windows Phones, and BlackBerry devices—do not mount as standard mass storage devices and thus leave no traces in USBSTOR. Investigating MTP artifacts requires specialized parsing of Windows Portable Devices (WPD) logs and tools like USB Detective, which can reconstruct timelines of MTP connection, disconnection, and deletion events.

Execution Evidence and Most Recently Used (MRU) Lists

To determine what software a suspect executed, investigators analyze the UserAssist key (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist). UserAssist tracks Graphical User Interface (GUI) program executions, recording the run count and the last execution timestamp. To prevent casual tampering, Windows obfuscates the program names using the ROT13 substitution cipher; forensic tools must automatically decode these strings during analysis.

Additionally, Windows maintains Most Recently Used (MRU) lists across various applications. Keys such as RunMRU, RecentDocs, and OpenSaveMRU log the paths of files accessed via Windows Explorer, standard open/save dialog boxes, or the MS-DOS prompt. These lists are invaluable for proving a user had knowledge of and interacted with specific files, even if those files have since been deleted from the filesystem.

Automatic Startup Locations (Persistence)

Malicious actors frequently abuse the registry to establish persistence, ensuring their malware (e.g., keyloggers, botnets, ransomware) executes automatically upon system boot. Investigators must scrutinize common Automatic Startup Locations, including:

• HKLM\Software\Microsoft\Windows\CurrentVersion\Run and RunOnce
• HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• HKLM\System\CurrentControlSet\Services (used to install malicious code as a background Windows Service)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellServiceObjects
• HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\SharedTaskScheduler

Identifying unauthorized entries in these keys, particularly those pointing to hidden directories or masquerading as legitimate system processes, is a primary indicator of compromise (IOC).

Advanced Techniques: Recovery and Timeline Correlation

When an offender attempts to cover their tracks by deleting registry keys, the data is not immediately overwritten. The nk and vk cells are simply marked as unallocated within the hbin block. By parsing the hive slack and unallocated space using specialized carvers (e.g., RegRipper, Registry Explorer), investigators can recover deleted USB histories and persistence mechanisms.

Reconstructing a comprehensive system timeline requires correlating registry artifacts with other system logs. For instance, correlating the Last Write Time of a USBSTOR key with network connection artifacts (e.g., HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces) and printer spooler artifacts (HKLM\SYSTEM\CurrentControlSet\Control\Print\Printers) allows the investigator to prove that a specific user printed a sensitive document immediately after inserting a specific USB drive. Shutdown and boot artifacts (HKLM\SYSTEM\CurrentControlSet\Control\Windows\ShutdownTime) provide the temporal boundaries necessary to anchor these events in real-world time.

Formal Derivation and Economic Intuition in Forensic Triage

In graduate-level forensic analysis, investigators must often operate under strict temporal and computational constraints. We can model the extraction of registry artifacts using a microeconomic framework of resource allocation. Let $x_1$ represent the investigative effort (time and computational resources) allocated to extracting USB connection artifacts (e.g., USBSTOR), and let $x_2$ represent the effort allocated to extracting volume mounting artifacts (e.g., MountedDevices).

We define the investigative utility function as $U(x_1, x_2)$, which represents the total evidentiary value derived from the analysis. We assume that extracting more data yields positive marginal utility, such that $\frac{\partial U}{\partial x_1} > 0$ and $\frac{\partial U}{\partial x_2} > 0$.

Crucially, we must evaluate the cross-partial derivative of the utility function:

$$\frac{\partial^2 U}{\partial x_1 \partial x_2} > 0$$

Economic Intuition: In microeconomic theory, a positive cross-partial derivative signifies that the two inputs are complementary goods. In the context of digital forensics, this mathematical property formalizes the concept of artifact correlation. The evidentiary weight of identifying a USB serial number ($x_1$) is vastly amplified when correlated with the specific drive letter ($x_2$) it was assigned, proving not just that a device was connected, but that it was actively mounted and accessible to the user.

If an investigator treats these artifacts as independent substitutes (where $\frac{\partial^2 U}{\partial x_1 \partial x_2} = 0$), they will severely under-allocate resources to correlation, resulting in a suboptimal investigative outcome. Therefore, when optimizing a time budget $B$ subject to the cost of extraction $c_i$ for each artifact $i$, the investigator must maximize:

$$$$