The Sleuth Kit
- 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:
- Find the inode from
fls(marked with*) orils - Determine the likely file type from context or the file name in the directory entry
- Run
icatand redirect output to a file with the appropriate extension - Verify with
fileand 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:
blkfindis not included in the TSK package shipped with Kali/Debian (sleuthkit4.x). If the binary is not present, useblklsto extract unallocated space and thengreporstringsto 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:
- Verifying that Autopsy’s automated analysis is interpreting results correctly
- Running targeted queries that Autopsy’s interface does not expose
- Scripting repetitive analysis across many images
- Explaining methodology in court without depending on a proprietary GUI
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
- The Sleuth Kit wiki
- The Sleuth Kit source and releases on GitHub
- Brian Carrier, File System Forensic Analysis (Addison-Wesley, 2005) — the definitive reference; TSK was written to accompany this book