15.2 Open-Source Forensic Platforms: Autopsy, The Sleuth Kit (TSK) & SIFT/CAINE Workstations

15.2 Open-Source Forensic Platforms: Autopsy, TSK & SIFT/CAINE Workstations

Quick Answer: Open-source digital forensics platforms provide transparent, scientifically verifiable, and cost-effective alternatives to commercial suites. At the core of open-source disk analysis is Brian Carrier's The Sleuth Kit (TSK), which decomposes file systems into four hierarchical abstractions: the File System Layer (fsstat), the Inode/Metadata Layer (istat, ils), the Data Unit Layer (blkcat, blkls), and the File Name Layer (fls, ffind, icat). Autopsy provides an enterprise-ready graphical user interface over TSK, featuring an Ingest Module pipeline for automated artifact extraction and a Central Repository for cross-case correlation. These tools are packaged within dedicated DFIR Linux distributions: SANS SIFT (curated incident response and super-timeline toolset), CAINE (featuring automated system-wide write-blocking via mounter), and Kali Linux Forensic Mode (preventing internal drive mounting and swap space contamination).

---

Brian Carrier's The Sleuth Kit (TSK) Architecture

Derived from Dan Farmer and Wietse Venema's historic The Coroner's Toolkit (TCT), The Sleuth Kit (TSK) is a collection of C/C++ command-line tools and a C library developed by Brian Carrier. TSK allows investigators to analyze disk images, examine low-level file system data structures, and recover deleted artifacts across NTFS, FAT, exFAT, EXT2/3/4, HFS+, and ISO 9660 file systems.

The Four-Layer Abstraction Model

To ensure consistency across diverse operating systems and file system structures, TSK abstracts all storage media into four distinct functional layers:

+-------------------------------------------------------------------------+
|               THE SLEUTH KIT (TSK) 4-LAYER ABSTRACTION MODEL            |
+-------------------------------------------------------------------------+
|  1. FILE SYSTEM LAYER: Structural geometry, block size, volume serial   |
|     Tools: fsstat                                                       |
+-------------------------------------------------------------------------+
|  2. INODE / METADATA LAYER: Pointers, sizes, MACB timestamps, attributes|
|     Tools: istat, ils, ifind                                            |
+-------------------------------------------------------------------------+
|  3. DATA UNIT / BLOCK LAYER: Raw content clusters, allocation tracking  |
|     Tools: blkcat, blkls, blkstat                                       |
+-------------------------------------------------------------------------+
|  4. FILE NAME LAYER: Directory entries, filenames, path hierarchies     |
|     Tools: fls, ffind, icat                                             |
+-------------------------------------------------------------------------+

Layer 1: File System Layer Tools

The File System layer contains global metadata describing the volume's architecture, cluster sizing, sector boundaries, and journaling structures.

• fsstat: Displays file system architecture details, block and fragment sizes, total and allocated cluster counts, inode ranges, volume label, serial numbers, and metadata journal attributes (e.g., NTFS $LogFile or Linux ext4 journal).

# Inspecting file system geometry on an NTFS partition at sector offset 2048
fsstat -o 2048 -f ntfs evidence.raw

Layer 2: Inode / Metadata Layer Tools

The Inode (or Metadata) layer describes file attributes, permissions, file size, timestamps, and cluster pointer runs, completely independent of the file's human-readable name or directory location.

• istat: Displays detailed metadata for a specific inode (Linux) or Master File Table (MFT) record number (Windows). It outputs the file's MACB timestamps (Modified, Accessed, Changed/MFT Modified, Born/Created), file size, link count, attribute headers, and direct/indirect block allocations.
• ils: Lists metadata entries/inodes. By default, running ils -o lists only unallocated (deleted) inodes, generating structured output ideal for identifying recently unlinked files.
• ifind: Finds the metadata inode or MFT record that corresponds to a specific file name path or data unit.

# Displaying MFT Record 42 metadata (NTFS) at sector offset 2048
istat -o 2048 evidence.raw 42

Layer 3: Data Unit / Block Layer Tools

The Data Unit layer represents the physical or logical storage blocks (sectors, clusters) where actual file contents and slack space reside.

• blkcat: Extracts and outputs the raw data contents of a specific cluster or block number, bypassing directory and inode structures.
• blkls: Extracts unallocated data units from the file system, generating an image containing only unallocated space (formerly known as dls). This extracted unallocated image is fed directly into signature-based carving tools like Scalpel or Foremost.
• blkstat: Displays the allocation status (allocated vs. unallocated) of a specific data unit or cluster.

# Extracting all unallocated clusters to a file for data carving
blkls -o 2048 evidence.raw > unallocated_space.bin

Layer 4: File Name Layer Tools

The File Name layer maps human-readable directory structures and filenames to metadata addresses (inodes/MFT records).

• fls: Lists directory contents, subdirectories, and deleted files. Crucially, deleted files are designated with an asterisk (*) preceding their directory entry. Useful flags include -r (recursive traversal), -d (list deleted entries only), -p (display full file path), and -m <dir> (generate a mactime body file).
• ffind: Finds the directory entry and file name that points to a specific inode number.
• icat: Extracts the raw file data corresponding to an inode number. Critical Exam Fact: Even if a threat actor securely renames or obfuscates a file name to disguise its contents, icat extracts the original data directly via its inode pointer.

# List all deleted files recursively on partition offset 2048
fls -o 2048 -r -d evidence.raw

# Extract file contents directly from MFT record 14528 without using its filename
icat -o 2048 evidence.raw 14528 > extracted_payload.exe

---

Timeline Generation with TSK: The Body File & Mactime

One of the most critical investigative capabilities provided by The Sleuth Kit is the generation of forensic super-timelines through the body file workflow:

[Evidence Image (.raw / .E01)]
              │
              ▼
   fls -o 2048 -r -m "C:/" evidence.raw > bodyfile.txt
              │
              ▼
   [Intermediate Body File (Pipe-Delimited Metadata)]
              │
              ▼
   mactime -b bodyfile.txt -d -y 2026-01-01..2026-12-31 > timeline.csv
              │
              ▼
   [Normalized Chronological Activity Timeline (CSV)]

1. Body File Generation: Running fls with the -m switch recursively inspects the entire directory hierarchy and outputs an intermediate, pipe-delimited text file containing: MD5 hash, file path, inode number, file mode/permissions, UID, GID, file size, and MACB timestamps in Unix epoch format.
2. Mactime Processing: The mactime Perl script parses the body file, converts Unix epoch timestamps into human-readable UTC dates, and sorts all file system events chronologically.

# 1. Generate body file from NTFS partition
fls -o 2048 -r -m "/" evidence.raw > body.txt

# 2. Compile chronological timeline covering the attack window in CSV format
mactime -b body.txt -d 2026-03-01..2026-03-15 > breach_timeline.csv

---

Autopsy Digital Forensics Platform

Autopsy is a high-performance, graphical digital forensics platform built upon The Sleuth Kit's underlying C/C++ libraries. Engineered using the Java NetBeans platform, Autopsy serves as an open-source counterpart to commercial platforms like EnCase and FTK.

+-------------------------------------------------------------------------+
|                    AUTOPSY INGEST MODULE PIPELINE                       |
+-------------------------------------------------------------------------+
| Data Source: Disk Image (.E01 / .RAW), VHD, Logical Directory, Memory   |
+-------------------------------------------------------------------------+
                                     │
                                     ▼
  ┌────────────────────────────────────────────────────────────────────┐
  │                       Ingest Modules Pipeline                      │
  │                                                                    │
  │  1. Hash Lookup Module        ──> NSRL RDS (Filter Benign Files)   │
  │                               ──> Known-Bad Hash Sets (Alerts)     │
  │  2. Keyword Search Module     ──> Apache Solr Full-Text Indexing   │
  │  3. Recent Activity Parser    ──> Browser History, Downloads, LNK  │
  │  4. Data Carving Module       ──> PhotoRec / Scalpel File Carving  │
  │  5. Media Analyzer / EXIF     ──> Video Frames, GPS Coordinates    │
  │  6. Central Repository Module ──> Cross-Case Correlation Matching  │
  └────────────────────────────────────────────────────────────────────┘
                                     │
                                     ▼
  ┌────────────────────────────────────────────────────────────────────┐
  │                    Examiner Interface & Views                      │
  │   • Directory Tree     • File Meta Details    • Hex / String View  │
  │   • Geolocation Maps   • Timeline Viewer      • Communication Graph│
  └────────────────────────────────────────────────────────────────────┘

The Ingest Modules Pipeline

When evidence is added to Autopsy, it passes through configurable Ingest Modules that execute concurrently:

1. Hash Lookup Module:
   • Calculates MD5 and SHA-256 hashes for every extracted file.
   • Compares hashes against the National Software Reference Library (NSRL) Reference Data Set (RDS) to mark known-good operating system binaries, hiding them from the examiner's default view.
   • Evaluates hashes against custom known-bad threat lists (e.g., ransomware executables, child exploitation hashes) to generate immediate high-priority alerts.
2. Keyword Search Module:
   • Powered by an embedded Apache Solr indexer.
   • Extracts text from documents, PDFs, metadata, and unallocated strings, updating the search index in real time.
   • Supports regular expression searching for Social Security Numbers (SSNs), credit card numbers, email addresses, and IP subnets.
3. Recent Activity Parser:
   • Parses web browser histories, cookies, bookmarks, and downloads from Google Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari.
   • Parses operating system user activity artifacts including Windows Prefetch, UserAssist, Jump Lists, LNK shortcut files, and ShellBags.
4. Picture and Video Analysis Module:
   • Extracts EXIF metadata from JPEG, TIFF, and HEIC files, extracting camera manufacturer, exposure settings, and embedded GPS coordinates (which Autopsy automatically plots on an interactive map).
   • Generates video thumbnails at fixed time increments to allow rapid visual inspection without playing complete video files.
5. Data Artifact Carving Module:
   • Automatically invokes an embedded version of PhotoRec to carve unallocated clusters for deleted files based on file headers and footers.

Central Repository: Cross-Case Correlation

A signature enterprise feature of Autopsy is the Central Repository (backed by SQLite or PostgreSQL):

• As investigations are conducted, the Central Repository stores identified properties across disparate cases: MD5/SHA-256 file hashes, email addresses, phone numbers, domain names, MAC addresses, and USB storage device serial numbers.
• When a new case is ingested, Autopsy queries the Central Repository. If an extracted artifact matches an indicator from an inquiry handled six months prior, Autopsy alerts the analyst, revealing links between suspects or repeated intrusion campaigns.

Python & Java Extensibility

Autopsy supports modular extensibility via Python (Jython) and Java APIs. Analysts can write custom scripts for specialized artifact decoding (e.g., proprietary IoT databases or emerging chat clients) and register them directly as Ingest Modules, Content Viewers, or Report Generators.

---

Dedicated DFIR Linux Distributions

Rather than manually configuring forensic utilities on a generic workstation, digital forensic practitioners utilize hardened, standardized Linux distributions pre-configured with thousands of DFIR packages.

1. SANS SIFT (SANS Investigative Forensic Toolkit) Workstation

Created and maintained by the SANS Institute, the SIFT Workstation is an Ubuntu LTS-based digital forensics and incident response environment:

• Pre-Installed Forensic Toolset: Packages The Sleuth Kit, Volatility 2 and Volatility 3 (memory forensics), Plaso / log2timeline (super-timeline generation), bulk_extractor, hashdeep, RegRipper (registry parsing), YARA, Ghidra (reverse engineering), and foremost/scalpel.
• Image Mounting Utilities: Features dedicated scripts such as mount_image.sh and ewfmount (part of libewf) to mount raw images, EnCase .E01 files, and virtual disks (.vmdk, .vhd) as read-only loopback devices.
• SIFT-REMnux Integration: SIFT can be installed alongside REMnux (Reverse Engineering Malware Linux), allowing an investigator to pivot seamlessly from disk and memory forensics to static and dynamic malware dissection.

# Mounting an E01 image as a raw device in SIFT
ewfmount /evidence/suspect_disk.E01 /mnt/ewf_mount/

# Mounting the first NTFS partition (offset 1048576 bytes) read-only
mount -o ro,loop,show_sys_files,offset=1048576 /mnt/ewf_mount/ewf1 /mnt/analysis/

2. CAINE (Computer Aided Investigative Environment)

Developed by Nanni Bassetti, CAINE is an Italian GNU/Linux live distribution engineered specifically for forensically sound evidence processing:

• Strict Automated Write-Blocking: Standard Linux distributions automatically mount newly detected USB drives or hard disks with read-write permissions, modifying disk access times, updating journaling logs, or mounting swap partitions. CAINE resolves this through a policy called system-wide write-blocking.
• The Mounter Utility: All block storage devices attached to a CAINE workstation are kept unmounted by default. When an investigator mounts a disk via CAINE's mounter GUI or command line, the system enforces a strict Read-Only (ro) mode controlled by modified /etc/fstab rules (rbfstab). Disks cannot be written to accidentally.
• Included Software: Features Guymager (a high-speed, multi-threaded graphical bit-stream imager supporting raw/dd and E01 formats with real-time hash verification), Autopsy, TSK, NirSoft triage tools, SQLite parsers, and X-Ways Forensics (operable via WINE).

3. Kali Linux Forensic Mode

While Kali Linux is universally recognized as a penetration testing distribution, its live boot menu features a dedicated Forensic Mode:

+-------------------------------------------------------------------------+
|                    KALI LINUX LIVE FORENSIC MODE                        |
+-------------------------------------------------------------------------+
| 1. Internal Storage Disks: NEVER automatically mounted or touched       |
| 2. Swap Partitions:        STRICTLY disabled (no memory paging to disk) |
| 3. File System Probing:    Read-only device discovery                   |
| 4. System Operation:       Runs entirely inside volatile RAM            |
+-------------------------------------------------------------------------+

• Forensic Mode Invariants: When selected from the GRUB boot menu, Kali completely disables auto-mounting daemons. Internal solid-state drives, NVMe drives, and hard disks remain unmounted.
• Swap Space Suppression: Under standard Linux boot, the kernel detects and activates local swap partitions on attached disks, overwriting potentially vital evidence. Forensic Mode strictly disables swap activation, preserving the pristine state of the suspect drive during on-scene triage.