The Sleuth Kit and Autopsy are used for digital forensics and incident investigation on disk evidence. They help analysts inspect file systems, recover deleted artefacts, and build timelines from a seized or imaged system. In security testing, they are used to validate what an attacker changed or accessed and to preserve evidence for later analysis.
What The Sleuth Kit and Autopsy actually do in an investigation
The Sleuth Kit is the underlying forensic toolkit, while Autopsy is the analyst-friendly interface built on top of it. In security testing, they are used to inspect disk images, recover deleted files, examine file system metadata, and reconstruct user and system activity. That makes them useful when you need to prove what changed, when it changed, and what evidence still remains.
They are not general-purpose vulnerability scanners. Their value is after collection, when a system has already been seized, imaged, or otherwise preserved for analysis. The question they answer is evidential: what artefacts exist on disk, how were they linked in time, and what activity can be supported with defensible findings rather than assumptions.
Used well, they turn a raw disk image into a readable case timeline. Analysts can review browser history, registry-style artefacts, logs, file timestamps, link files, and unallocated space to understand whether an incident was limited, repeated, or staged. The same workflow is also how testers validate whether a suspected attacker action actually left forensic traces.
Digital Forensics (DFIR) Guide
That workflow matters because disk evidence is often partial, not perfect. Deleted data may be recoverable, timestamps can be misleading if systems were tampered with, and some attacker activity may leave little or no on-disk trace. The best use of these tools is therefore disciplined evidence review, not overconfident conclusions from a single artefact.
What they help you verify after a suspected compromise
In security testing, The Sleuth Kit and Autopsy are especially useful for validating scope. You can compare the live story told by logs, alerts, or user reports with what actually exists on disk, then look for supporting evidence such as newly created files, altered configuration, persistence artefacts, or remnants of exfiltration tooling. That helps separate a noisy alert from an incident with real impact.
They also help answer whether an attacker merely touched a host or materially changed it. If the test goal is incident validation, the investigator wants signs of execution, staging, exfiltration, cleanup, or persistence. If the goal is post-incident review, the same evidence can show which files were accessed, which directories were modified, and what user activity preceded the compromise.
Because the tools operate on preserved disk data, they are also important for repeatability. A tester can re-run analysis, review the same artefacts from a clean image, and document findings in a way that another analyst can check later. That makes them especially valuable when the outcome may be used in reporting, escalation, or legal review.
Where they fit in the DFIR workflow
The Sleuth Kit and Autopsy sit in the evidence-analysis phase, after acquisition and before final reporting. They complement imaging, triage, and memory analysis, but they do not replace them. If volatile data is still available, it should usually be collected first, because memory, process state, and network connections can disappear long before disk evidence tells the full story.
They are most effective when the investigator starts with a clear question. For example, did the intruder create a new account, place a web shell, alter startup items, or remove logs? A focused question leads to a better examination path than broad browsing through the image, and it reduces the risk of missing the artefacts that matter most.
For teams building a defensible DFIR process, the key is to pair the tool output with sound evidence handling. If the image, timestamps, and case notes are not preserved carefully, the analysis may still be technically correct but hard to defend. In that sense, the toolset is only one part of a larger forensic method.
DFIR evidence handling and timeline analysis are the core ideas to keep tied to this workflow, because the analysis is only as good as the acquisition and documentation behind it.
Risk and Threat Considerations
These tools are often used after compromise, so the main risk is not misuse of the software itself but incomplete or biased interpretation of the evidence. An attacker may delete files, wipe logs, or use techniques that reduce on-disk visibility, which means the absence of evidence is not the same as evidence of absence.
Failure mechanism: Analysts over-trust a partial disk view, miss artefacts that were deleted or hidden, or fail to correlate disk findings with other evidence sources, leading to an incorrect scope or root-cause conclusion.
Impact: The organisation may understate the intrusion, preserve the wrong systems, rotate the wrong accounts, or miss the opportunity to contain lateral movement before the attacker re-enters.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Disk forensics relies on reviewing and correlating records and artefacts to reconstruct activity. |
| SI-4 — System Monitoring | The tools help validate suspected compromise by checking observable host artefacts and activity traces. | |
| IR-4 — Incident Handling | They support containment and investigation after a suspected incident on a seized or imaged system. | |
| Recommendation — Correlate forensic artefacts with AU-6 review to support defensible incident findings. Use SI-4 monitoring outputs to seed forensic examinations and confirm suspicious host activity. Apply IR-4 to guide evidence preservation and investigative analysis during incident response. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Forensic timeline building depends on logs and artefacts that support audit and investigation. |
| Recommendation — Preserve and review audit logs alongside disk artefacts to strengthen investigations. | ||
| MITRE ATT&CK | T1070 — Indicator Removal on Host | Deleted artefacts and cleanup on disk are central forensic concerns in compromise analysis. |
| Recommendation — Map cleanup artefacts to T1070 and hunt for evidence of attempted log or file removal. | ||
Practitioner Guidance
What to verify: Treat the tool output as evidence, not verdict. Confirm that the disk image is complete, the examination order is documented, and the timestamps you rely on are understood in context, especially when system time, time zones, or file system behaviour may distort the timeline.
What practitioners underestimate: Autopsy can make analysis look straightforward, but the hard part is deciding which artefacts are actually probative. Focus first on artefacts that prove execution, persistence, deletion, or staging, because those usually matter more than visually interesting but weakly connected files.
Practitioner takeaway: Use The Sleuth Kit and Autopsy to reconstruct defensible facts from disk evidence, then corroborate those facts with other sources before you make any containment or attribution decision.