Disk images still answer questions that live telemetry cannot, such as what was deleted, what a user browsed and which files were staged for theft, but many teams lack a licensed forensic suite or the skills to use the free one properly. The Sleuth Kit (TSK) is a library and set of command-line tools for analysing disk images and file systems, and Autopsy is the graphical platform built on it. Together they are the most widely taught open source disk forensics stack. This guide explains what each part does, where it fits in an investigation, how to deploy it safely (including multi-user cases), what it can feed back into detection, and when another tool is the better choice. It goes deeper than the Open Source DFIR Tools Landscape Guide and is written for DFIR analysts, incident responders and investigators. Features were checked against the Autopsy 4.23.0 user documentation and the sleuthkit.org manual pages on 27 October 2026.
Key takeaways
- Two layers, one stack. TSK provides command-line tools and a library for volume, file system and metadata analysis; Autopsy wraps TSK in a case-based GUI with ingest modules, viewers and reporting.
- Ingest modules do the heavy lifting. Autopsy 4.23.0 ships modules for hash lookup, keyword search, recent activity, email parsing, carving (PhotoRec), encryption detection, Plaso, YARA and mobile analysis (iLEAPP, aLEAPP); choose them per case rather than running everything.
- Time zones matter on FAT. Autopsy asks for the time zone of each disk image because FAT stores no zone information; set it correctly or every FAT timestamp is wrong.
- Integrity is built in but optional. You can record known hashes when adding an image and verify them with the Data Source Integrity module; make it mandatory in your procedure.
- Multi-user cases need real infrastructure. Shared cases require shared storage, PostgreSQL, Solr and ActiveMQ, which then become evidence systems to secure and back up.
What the tool does
The Sleuth Kit
TSK is a collection of command-line tools and a C library for forensic analysis of disk images, which can also be built into larger tools. Its core code is licensed under the IBM Public License or the Common Public License; other utilities carry their own non-copyleft licences. The tools are organised by layer, which mirrors how a disk is structured:
| Layer | Tools | Typical question |
|---|---|---|
| Image | img_stat, img_cat | What format is this image and is it complete? |
| Volume | mmls, mmstat, mmcat | What partitions exist and at which sector offsets? |
| File system | fsstat | What file system, cluster size and layout? |
| File name | fls, ffind | Which files and directories exist, including deleted entries? |
| Metadata | istat, icat, ils, ifind | What are this file's timestamps and attributes, and what is its content? |
| Data unit | blkls, blkcat, blkstat, blkcalc | What is in unallocated space or a specific cluster? |
| Journal | jls, jcat | What does the file system journal hold? |
| Timeline and utilities | mactime, tsk_recover, tsk_loaddb, tsk_gettimes, tsk_comparedir, sigfind, hfind, sorter | Build a timeline, export files, load into a database, look up hashes |
- fls: lists file and directory names, including recently deleted entries;
-rrecurses,-dshows deleted only,-osets the sector offset of the file system and-mwrites body file format for timelines.fls -f listandfls -i listshow the file system and image types your build supports. - mactime: turns a body file from
fls -morils -minto an ASCII timeline;-dgives comma-delimited output,-yISO 8601 dates and-za time zone (the two cannot be combined), and a date range argument limits output.
Autopsy
Autopsy 3 and 4 are licensed under Apache 2.0 (bundled libraries carry their own licences, listed in the README). It is distributed as a Windows installer and as ZIP files for Linux and macOS. The project recommends a minimum of 16 GB of RAM; Autopsy uses up to 4 GB by default (excluding the Solr index server), adjustable in Tools, Options, Application.
| Data source type | Formats or examples | Notes |
|---|---|---|
| Disk image or VM file | Raw (.img, .dd, .raw, .bin), split raw (.001, .aa), EnCase .e01, VMDK, VHD and VHDX | Select the first segment; Autopsy finds the rest. Enter known hashes for later verification |
| Local disk | An attached drive, for example through a hardware write blocker | Autopsy must run as Administrator to see all devices |
| Logical files | Folders, files or L01 logical evidence files | File timestamps are ignored by default unless you opt in |
| Unallocated space image | Raw data with no file system | Chunking speeds processing but can miss keywords or carved files across chunk boundaries |
| Logical imager results and XRY exports | Output of Autopsy's logical imager; XRY text export folders | For triage collections and mobile extractions |
Defender use cases
Choosing ingest modules
| Investigation need | Ingest modules | Output to review |
|---|---|---|
| Separate known from unknown files | Hash Lookup (known-good sets such as NSRL, plus notable sets), File Type Identification, Extension Mismatch Detector | Notable hits, files whose content type does not match the extension |
| User activity and execution | Recent Activity (browser history, registry-based artefacts, recent documents) | Web history, downloads, USB devices, installed programs |
| Find terms, indicators and data types | Keyword Search (with regular expressions), Interesting Files Identifier | Keyword hits, files matching rule sets (for example archives in user folders) |
| Malware triage | YARA Analyzer, Cyber Triage Malware Scanner, Embedded File Extraction | Rule matches, extracted content from archives and documents |
| Deleted and hidden data | PhotoRec Carver, Encryption Detection, Virtual Machine Extractor | Carved files, encrypted volumes or containers, nested VM disks |
| Email and communications | Email Parser (PST, MBOX, EML), Android and iOS analysers | Messages, contacts and the Communications Visualization Tool |
| Full timeline | Plaso module, plus Autopsy's Timeline viewer | Merged events across artefact types |
| Cross-case correlation | Central Repository | "Previously Notable" and "Previously Seen" results |
Start with Hash Lookup, File Type Identification, Recent Activity and Interesting Files for triage, then add Keyword Search, carving and Plaso where the questions require them. Each extra module costs hours on large images.
Command line or GUI?
- Use TSK directly when you need a quick answer from one image (partition layout, one deleted file, a file system timeline), when scripting across many images, or when you want every step to be a reproducible command in your notes.
- Use Autopsy for full case work: multiple data sources, tagging and commenting, reporting, viewers for images, geolocation and communications, and analysts who are less comfortable on the command line.
- Combine them: the Plaso module and the Plaso Guide cover super timelines; Autopsy can also run headless through Command Line Ingest for batch processing.
The central repository
The central repository stores correlation properties across cases: file MD5 hashes and paths, domains, email addresses, phone numbers, USB devices, wireless networks, MAC addresses, IMEI, IMSI, ICCID, credit card numbers, OS accounts, installed programs and app-specific accounts. Tagging an item as notable marks its property so that later cases raise "Previously Notable" results, and the "Previously Seen" setting flags devices and accounts found in earlier cases. SQLite is for a single client only; PostgreSQL is required when several users share the repository. Because it holds personal data across cases, define retention and access rules for it.
Deployment and safe use
- Dedicated workstation: install on an isolated forensic workstation with at least 16 GB of RAM, fast local storage for the case directory and no general browsing or email.
- Antivirus exclusions by design: the installation guide warns that antivirus can quarantine extracted results; exclude the case output directory on the forensic workstation rather than disabling protection, and never open extracted executables outside a sandbox.
- Acquire first, analyse a copy: work from a verified image, not the original media. Use a hardware write blocker for local disks. See the Disk Imaging and Forensic Acquisition Guide.
- Record and verify hashes: enter the acquisition hashes when adding the image and run the Data Source Integrity module; file the result with the case.
- Set the time zone per image: record the source system's time zone in case notes and in the data source settings.
- Control network use: configure proxy settings explicitly and review which modules contact external services before enabling them on sensitive cases.
- Pin and record versions: note the Autopsy and TSK versions, enabled modules and hash sets in the case file so results can be reproduced.
- Protect case data: case directories, Solr indexes, exports and reports contain everything on the image; store and share them under the same controls as the evidence. See the Evidence Handling and Chain of Custody Guide.
Multi-user clusters
Multi-user cases let several analysts open the same case at once. The documented setup order is: choose hardware or virtual machines, choose service accounts, set up shared storage, then install and configure PostgreSQL, Solr and ActiveMQ before the Autopsy clients. Treat these as evidence infrastructure: restrict network access to analyst workstations, use named service accounts with strong, stored-in-a-vault passwords, back up the database and index, and apply the multi-user case security guidance in the documentation.
Detection and hardening value
| Finding in Autopsy or TSK | What it shows | Improvement |
|---|---|---|
| Attacker tools found in user folders by Hash Lookup or YARA | Ingress tool transfer that endpoint controls missed | Application control and EDR rules for the paths and hashes |
| Archives staged before exfiltration (Interesting Files, Recent Activity) | Collection and staging | Data loss prevention and egress monitoring for archive uploads |
Deleted files recovered with fls -d or carving | Cleanup activity; see the Anti-Forensics Detection Guide | Off-host logging of file deletion and process creation |
| Unknown USB devices from Recent Activity | Removable media use | Device control policy and USB auditing |
| Encrypted containers detected | Data hidden from inspection | Policy on approved encryption tools and key escrow |
| Saved credentials, keys or tokens found by keyword search | Secrets on disk that an attacker could reuse | Rotate them and move to a vault; see the Secrets Management Guide |
The last row is where identity fits: images routinely contain cloud CLI credential files, SSH private keys, browser-saved passwords and API tokens. Build a keyword list for common credential patterns, record every secret found, and treat each one as exposed until rotated.
Measuring the capability
- Time to triage: hours from verified image to first findings with the standard triage module set.
- Integrity verification rate: percentage of cases with a recorded Data Source Integrity result.
- Reproducibility: percentage of cases whose notes record tool versions, modules and hash sets.
- Detection feedback: number of new detections or control changes raised from disk findings per quarter.
Common failure patterns
- Running every module on every image: processing takes days and the first answer arrives too late; use a triage set first.
- Wrong time zone: FAT timestamps from a USB stick are misread by hours, breaking the timeline.
- Skipping integrity checks: no record shows the analysed image matches the acquired one.
- Analysing on a daily-use laptop: extracted malware is quarantined or, worse, executed; case data mixes with personal files.
- Unsecured multi-user services: PostgreSQL and Solr with default credentials on a flat network expose every case.
Alternatives
| Option | Choose it when | Trade-off |
|---|---|---|
| Autopsy and TSK | Free, case-based disk forensics with a GUI and scriptable tools | Slower on very large images; community support |
| Triage collectors (KAPE, Velociraptor) | Many hosts, targeted artefacts, live response | No full disk view; see the KAPE and Triage Collection Guide and the Velociraptor Guide |
| Single-artefact parsers (EZ Tools) | Precise Windows artefact parsing to CSV | No case management; see the EZ Tools Guide |
| Plaso and Timesketch | Collaborative super timelines | Timeline only, not file review |
| Commercial forensic suites | Vendor support, broad mobile and cloud parsing, court-tested reporting | Licence cost; see the Digital Forensics Tools Buyer's Guide |
Small teams can run single-user Autopsy on one workstation and keep TSK for scripted checks; larger teams and law enforcement units often run a multi-user cluster alongside a commercial suite and validate key findings in both.
Practitioner checklist
- Install Autopsy on an isolated forensic workstation with at least 16 GB of RAM and record the version.
- Define a standard triage ingest module set and a deep-dive set.
- Enter acquisition hashes for every image and run the Data Source Integrity module.
- Set and record the source time zone for each disk image.
- Maintain known-good and notable hash sets and a credential keyword list.
- Exclude only the case directory from antivirus and keep extracted executables in a sandbox.
- Secure multi-user PostgreSQL, Solr and ActiveMQ services as evidence systems.
- Feed findings (tools, staging paths, exposed secrets) back into detection and rotation.
Standards and references
- Sleuth Kit Labs: Autopsy 4.23.0 User Documentation
- sleuthkit.org: The Sleuth Kit
- sleuthkit.org: fls manual page
- sleuthkit.org: mactime manual page
- Sleuth Kit Labs: Autopsy Central Repository
- sleuthkit.org: Sleuth Kit licences
- NIST: SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
Related NHI Mgmt Group resources: Open Source DFIR Tools Landscape Guide · Digital Forensics (DFIR) Guide · Disk Imaging and Forensic Acquisition Guide · Windows Forensic Artefacts Guide