courses

The Sleuth Kit

The Sleuth Kit (TSK) is an open-source collection of command-line tools for forensic analysis of disk images and file systems. It provides access to each structural layer of a storage volume independently, which allows examiners to analyze evidence at any level of abstraction — from raw sectors to individual file names — without relying on the operating system’s normal filesystem driver. Autopsy is a graphical frontend to TSK; this page covers the command-line tools directly.

Install on Debian/Kali:

sudo apt install sleuthkit

The Layered Model

TSK organizes analysis into five layers, each with its own set of tools. Understanding the layers is necessary to use the tools correctly.

Layer What it represents TSK tools
Image The raw disk image file itself img_stat, img_cat
Volume Partition table; maps partitions to sector ranges mmls, mmstat, mmcat
File System Superblock, block groups, free space fsstat
Metadata Inodes: ownership, timestamps, block pointers ils, istat, icat, ifind
Data Unit Individual blocks/clusters and their allocation state blkstat, blkls, blkcat, blkfind
File Name Directory entries linking names to inodes fls, ffind

Most tools that operate below the volume layer require an offset (-o) specifying which sector the partition begins on. Get this from mmls first.

Nearly all TSK tools accept the same core flags:

Flag Meaning
-o <sectors> Partition start offset (in sectors)
-f <fstype> File system type (ntfs, fat32, ext4, hfs, etc.)
-i <imgtype> Image format (raw, ewf, aff) — usually auto-detected

Image Layer

img_stat

Displays details about the image file itself: format, sector size, and total image size.

img_stat evidence.dd

Use this to confirm the image type is recognized correctly before proceeding. If TSK misidentifies an image format, pass -i raw explicitly.

img_cat

Outputs raw image bytes to stdout. Useful for piping image segments to other tools.

img_cat -s 0 -e 2047 evidence.dd | hexdump -C

Volume Layer

mmls

Lists the partition layout of a disk image. This is usually the first command run on a new image.

mmls evidence.dd

Example output:

DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000001   0000002047   0000002047   Unallocated
002:  000:000   0000002048   0000206847   0000204800   Linux (0x83)
003:  000:001   0000206848   0000411647   0000204800   Linux (0x83)

The Start column gives the sector offset to pass to all subsequent tools with -o.

mmstat

Displays the type of volume system (MBR, GPT, APM).

mmstat evidence.dd

mmcat

Outputs the raw bytes of a single partition to stdout. Use this to extract a partition from a full-disk image for analysis as a standalone image.

mmcat evidence.dd 2 > partition2.raw

The argument 2 refers to the slot number from mmls output (not the partition number).


File System Layer

fsstat

Displays detailed file system metadata: type, block size, inode count, journal location, and last mount time.

fsstat -o 2048 evidence.dd

Key fields to check:

Field Forensic relevance
Last mount time When the volume was last accessed
Last written time When content was last modified
Volume name / serial number Can corroborate device identity
Inode range Bounds for ils and istat
Journal inode Starting point for journal analysis

If the file system type is not detected automatically, pass -f ntfs, -f fat32, etc.


File Name Layer

fls

Lists file and directory names from directory entries, including deleted entries that still appear in the directory structure. Analogous to ls but operates on the image directly.

fls -o 2048 evidence.dd

Useful flags:

Flag Effect
-r Recurse into subdirectories
-d Show only deleted entries
-u Show only undeleted entries
-p Display full path for each entry
-m <mountpoint> Output in body file format for mactime
-z <timezone> Set timezone (e.g., PST8PDT) for timestamps

Output format:

r/r 32-128-1:   passwd
r/r * 45-128-1: shadow
d/d 12-144-4:   etc

The prefix indicates entry type (r = regular file, d = directory, l = symlink) and allocation status (* = deleted). The number before the colon is the inode address.

ffind

Finds the file name(s) associated with a given inode.

ffind -o 2048 evidence.dd 45

Useful when icat or istat gives you an inode but you need to know where in the directory tree the file lived.


Metadata Layer

istat

Displays the contents of a single inode: file type, permissions, owner, timestamps (MACB), and the block addresses where content is stored.

istat -o 2048 evidence.dd 45

MACB timestamps for a deleted inode are preserved in the inode structure until the inode is reallocated. This makes istat useful for establishing when a file was modified, accessed, or created even after deletion.

For NTFS, istat displays all $MFT attributes for the file record, including $STANDARD_INFORMATION and $FILE_NAME timestamps separately — useful for detecting timestamp manipulation (timestomping), since the two attribute sets are modified by different mechanisms.

ils

Lists inodes. By default lists only unallocated (deleted) inodes.

# List all deleted inodes
ils -o 2048 evidence.dd

# List all inodes (allocated and unallocated)
ils -e -o 2048 evidence.dd

The output is one inode per line with its address, link count, timestamps, and size. Pipe to istat for details on any specific inode.

icat

Extracts the content of a file by inode number. The file does not need to be allocated — content can be recovered as long as the blocks have not been overwritten.

icat -o 2048 evidence.dd 45 > recovered_file

To recover a deleted file:

  1. Find the inode from fls (marked with *) or ils
  2. Determine the likely file type from context or the file name in the directory entry
  3. Run icat and redirect output to a file with the appropriate extension
  4. Verify with file and examine

ifind

Finds the inode(s) associated with a given file name or data block address.

# Find inode by file name
ifind -o 2048 -n "/etc/shadow" evidence.dd

# Find inode(s) that reference a specific block
ifind -o 2048 -d 81920 evidence.dd

The block-to-inode direction is useful when you find suspicious content in unallocated space and want to determine whether any still-allocated file references it.


Data Unit Layer

blkstat

Displays the allocation status of a single block/cluster.

blkstat -o 2048 evidence.dd 81920

Reports whether the block is allocated to a file, unallocated, or reserved. Allocated blocks include the inode of the owning file.

blkls

Extracts data unit content. The most common use is extracting all unallocated space for carving.

# Extract all unallocated blocks to a file for carving
blkls -o 2048 evidence.dd > unallocated.raw

Flags:

Flag Effect
-a Extract allocated (live) blocks only
-e Extract every block, including file system metadata blocks
-s Extract slack space only
(default) Extract unallocated blocks

The output from blkls can be passed directly to photorec, foremost, or scalpel for file carving.

blkcat

Outputs the raw content of a single block to stdout.

blkcat -o 2048 evidence.dd 81920 | hexdump -C

Useful for examining specific blocks by address, particularly when blkstat shows a block is allocated and istat gives you its address.

blkfind

Searches unallocated space for a specific data pattern (hex or ASCII). Useful for identifying blocks that contain known-bad content or specific strings without carving the entire image.

Note: blkfind is not included in the TSK package shipped with Kali/Debian (sleuthkit 4.x). If the binary is not present, use blkls to extract unallocated space and then grep or strings to search it:

# Search for MZ header in unallocated space (blkfind equivalent)
blkls -o 2048 evidence.dd | grep -c $'\x4d\x5a'
# or extract and search with strings
blkls -o 2048 evidence.dd > unalloc.raw && strings unalloc.raw | grep -i "pattern"

If blkfind is available:

blkfind -o 2048 evidence.dd "4D5A9000"

Timeline Analysis

Timeline analysis reconstructs file system activity in chronological order from MACB timestamps. TSK’s fls with the -m flag generates a body file in a standard format that mactime then converts to a sorted, human-readable timeline.

Body file format

fls -r -m "/" -z UTC -o 2048 evidence.dd > body.txt

The -m "/" argument sets the mount point prefix for all file paths. For multi-partition images, run fls once per partition with the appropriate -o offset and append all output to a single body file:

fls -r -m "/windows" -z UTC -o 2048 evidence.dd >> body.txt
fls -r -m "/data"    -z UTC -o 206848 evidence.dd >> body.txt

Generating the timeline

mactime -b body.txt -d > timeline.csv

The -d flag outputs CSV. The output contains one row per timestamp event with fields: date, size, type (m/a/c/b), permissions, UID/GID, inode, and file name.

To scope the timeline to a date range:

mactime -b body.txt -d -z UTC 2025-01-01..2025-03-31 > q1_timeline.csv

Interpreting MACB timestamps

Letter Timestamp Triggered by
m Modified File content written
a Accessed File content read
c Changed (inode) Metadata change (permissions, owner, link count)
b Born (created) File creation (not all file systems record this)

Timestomping detection: on NTFS, $STANDARD_INFORMATION timestamps are easily modified by user-space tools; $FILE_NAME timestamps are updated only by the NTFS kernel driver and are much harder to fake. istat shows both. A discrepancy between the two sets — particularly $STANDARD_INFORMATION timestamps predating the $FILE_NAME created time — is a strong indicator of tampering.


Hash Databases

TSK can query hash databases to identify known-good (NSRL) or known-bad files by MD5, SHA-1, or SHA-256.

Setting up the NSRL database

Download the NSRL RDS from the NIST National Software Reference Library. Then index it:

hfind -i nsrl-md5 NSRLFile.txt

Querying

# Look up a single hash
hfind NSRLFile.txt d41d8cd98f00b204e9800998ecf8427e

# Sort image files by hash category (known-good, known-bad, unknown)
sorter -o 2048 -h NSRLFile.txt evidence.dd

sorter also classifies files by type (images, documents, executables, archives) and writes them to category directories — useful for triaging a large image quickly.


Practical Workflow

A complete TSK examination of a raw disk image follows this order:

# 1. Confirm image details
img_stat evidence.dd

# 2. List partition layout, note Start sector for each partition
mmls evidence.dd

# 3. Examine the file system (using offset from mmls)
fsstat -o 2048 evidence.dd

# 4. List all files including deleted
fls -r -p -o 2048 evidence.dd

# 5. Recover a deleted file by inode (inode from fls output)
icat -o 2048 evidence.dd 45 > recovered.docx

# 6. Examine inode details (timestamps, block addresses)
istat -o 2048 evidence.dd 45

# 7. Build body file and generate timeline
fls -r -m "/" -z UTC -o 2048 evidence.dd > body.txt
mactime -b body.txt -d > timeline.csv

# 8. Extract unallocated space for carving
blkls -o 2048 evidence.dd > unallocated.raw

Autopsy

Autopsy is a web-based graphical frontend to The Sleuth Kit. It wraps the same underlying tools in a case-management interface with automatic hash lookup, keyword search, and report generation.

sudo apt install autopsy
autopsy
# Then open http://localhost:9999/autopsy in a browser

Autopsy is useful for investigations involving large images or multiple partitions where manual fls/istat workflows would be slow. However, understanding the underlying TSK tools is essential for:


Quick Reference

Task Command
List partitions mmls evidence.dd
File system details fsstat -o <offset> evidence.dd
List all files (inc. deleted) fls -r -p -o <offset> evidence.dd
List only deleted files fls -r -d -o <offset> evidence.dd
Examine an inode istat -o <offset> evidence.dd <inode>
Recover file by inode icat -o <offset> evidence.dd <inode> > out
Find file name for inode ffind -o <offset> evidence.dd <inode>
Extract unallocated space blkls -o <offset> evidence.dd > unalloc.raw
Build timeline body file fls -r -m "/" -z UTC -o <offset> evidence.dd > body.txt
Generate timeline CSV mactime -b body.txt -d > timeline.csv

References