Practice file system analysis before moving to reading resources.

Opening Framing

When users delete files, they believe those files are gone forever. In reality, deletion typically only removes the pointer to the data— the actual content remains on disk until overwritten by new data. This gap between user perception and technical reality is the foundation of file system forensics.

Understanding how file systems organize, track, and "delete" data enables forensic examiners to recover evidence that perpetrators thought was destroyed. The BTK serial killer was caught partly through deleted files recovered from a floppy disk. The Enron investigation recovered thousands of "deleted" emails that became key evidence. Every major digital investigation relies on these techniques.

This week covers how major file systems work internally, where forensic artifacts hide, and techniques to recover deleted data. You'll work with Autopsy, The Sleuth Kit, and file carving tools to extract evidence from disk images.

Key insight: File systems are designed for performance and reliability, not for secure deletion. This design choice creates opportunities for forensic recovery.

1) File System Fundamentals

Before diving into specific file systems, understand the universal concepts that apply to all storage media:

Storage Hierarchy:

Physical Level:
┌─────────────────────────────────────────────┐
│ Hard Drive / SSD / USB                      │
│ ┌─────────────────────────────────────────┐ │
│ │ Sector (512 bytes or 4096 bytes)        │ │
│ │ - Smallest addressable unit             │ │
│ │ - Hardware-level addressing             │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘

Logical Level:
┌─────────────────────────────────────────────┐
│ Cluster / Block (4KB typical)              │
│ - Group of sectors                          │
│ - File system's allocation unit             │
│ - Smaller = less waste, more overhead       │
│ - Larger = more waste, faster access        │
└─────────────────────────────────────────────┘

File Level:
┌─────────────────────────────────────────────┐
│ File = Metadata + Data                      │
│ - Metadata: name, size, timestamps, perms   │
│ - Data: actual file contents                │
│ - May span multiple clusters                │
└─────────────────────────────────────────────┘

Disk Partitioning:

Partition Schemes:

MBR (Master Boot Record) - Legacy:
- 512 bytes at sector 0
- Max 4 primary partitions
- Max 2TB disk size
- Partition table at offset 446

GPT (GUID Partition Table) - Modern:
- Protective MBR for compatibility
- 128 partitions typical
- Supports disks larger than 2TB
- Primary and backup partition tables
- CRC32 checksums for integrity

Examining partitions:
# Linux - mmls from Sleuth Kit
$ mmls disk.img
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   0104857599   0104855552   NTFS (0x07)
003:  -------   0104857600   0104857600   0000000001   Unallocated

Forensic Significance:

Why Understanding Structure Matters:

1. Locate hidden partitions
   - Gaps in partition table
   - Overlapping partitions
   - HPA (Host Protected Area)
   - DCO (Device Configuration Overlay)

2. Identify file system type
   - NTFS signature: "NTFS    " at offset 3
   - ext4 signature: 0xEF53 at offset 1080
   - FAT32 signature: "FAT32   " at offset 82

3. Calculate offsets for analysis
   - Partition start × sector size = byte offset
   - Essential for manual examination
   - Required for carving operations

4. Detect anti-forensics
   - Wiped partition tables
   - Encrypted volumes
   - Non-standard configurations

Key insight: Every forensic tool abstracts these details, but understanding the underlying structure helps when tools fail or when dealing with damaged media.

2) NTFS Deep Dive

NTFS (New Technology File System) is Windows' primary file system since Windows NT. Its rich metadata makes it forensically valuable:

NTFS Key Structures:

$MFT (Master File Table):
- Database of all files and directories
- One record per file (typically 1024 bytes)
- Contains all metadata attributes
- First 16 entries are system files

$MFT Entry Structure:
┌─────────────────────────────────────┐
│ Header (48 bytes)                   │
│ - Signature "FILE" or "BAAD"        │
│ - Sequence number                   │
│ - Link count                        │
│ - Attribute offset                  │
├─────────────────────────────────────┤
│ Attribute 1: $STANDARD_INFORMATION  │
│ - Created, modified, accessed times │
│ - DOS attributes (hidden, system)   │
├─────────────────────────────────────┤
│ Attribute 2: $FILE_NAME             │
│ - File name (can have multiple)     │
│ - Parent directory reference        │
│ - Timestamps (separate from $SI)    │
├─────────────────────────────────────┤
│ Attribute 3: $DATA                  │
│ - File contents (resident/non-res)  │
│ - Run lists for large files         │
├─────────────────────────────────────┤
│ Attribute 4: Other attributes...    │
└─────────────────────────────────────┘

Forensically Important System Files:

NTFS Metadata Files:

$MFT (Entry 0):
- Master File Table itself
- Parse to enumerate all files

$MFTMirr (Entry 1):
- Backup of first 4 MFT entries
- Recovery if $MFT corrupted

$LogFile (Entry 2):
- Transaction journal
- Records file system operations
- Can recover recent changes
- Typically last 2-4 hours of activity

$Volume (Entry 3):
- Volume name and NTFS version
- Volume serial number

$AttrDef (Entry 4):
- Attribute type definitions

$Root (Entry 5):
- Root directory

$Bitmap (Entry 6):
- Cluster allocation bitmap
- Shows allocated vs unallocated

$Boot (Entry 7):
- Boot sector backup

$BadClus (Entry 8):
- Bad cluster tracking

$Secure (Entry 9):
- Security descriptors

$UsnJrnl (Entry varies):
- Update Sequence Number Journal
- Records all file changes
- MASSIVE forensic value

$UsnJrnl - The Change Journal:

USN Journal Structure:

Location: $Extend\$UsnJrnl:$J

Records every change:
- File creation
- File deletion
- File rename
- File modification
- Attribute changes

Record contents:
- Timestamp
- Reason code (what changed)
- File reference number
- Parent directory reference
- File name at time of change

Forensic value:
- Shows file activity timeline
- Reveals deleted file names
- Tracks file movements
- Survives file deletion
- Can contain months of history

Parsing with MFTECmd:
$ MFTECmd.exe -f "C:\$Extend\$UsnJrnl:$J" --csv output/
$ MFTECmd.exe -f "$MFT" --csv output/

Alternate Data Streams (ADS):

NTFS Alternate Data Streams:

Concept:
- Files can have multiple $DATA attributes
- Default stream: filename
- Named streams: filename:streamname

Creating ADS:
> echo "hidden data" > file.txt:hidden.txt
> notepad file.txt:hidden.txt

Detecting ADS:
> dir /r
> Get-Item -Path file.txt -Stream *

Forensic uses of ADS:
- Malware hiding payloads
- Zone.Identifier (download source)
- Data exfiltration

Zone.Identifier example:
> more < file.exe:Zone.Identifier
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://malicious.site/
HostUrl=https://malicious.site/malware.exe

Zone IDs:
0 = Local machine
1 = Local intranet
2 = Trusted sites
3 = Internet
4 = Restricted sites

NTFS Timestamps:

NTFS Has Two Sets of Timestamps:

$STANDARD_INFORMATION (SI):
- Modified, Accessed, Changed, Birth
- Updated by Windows normally
- Can be modified by user tools
- Often timestomped by attackers

$FILE_NAME (FN):
- Same MACB timestamps
- Updated only by Windows kernel
- Much harder to modify
- More reliable for forensics

Timestamp comparison reveals:
- If SI times < FN times = timestomping
- Anti-forensics detection
- True file creation time

Tools:
- MFTECmd (Eric Zimmerman)
- Autopsy timeline
- istat (Sleuth Kit)

Key insight: NTFS was designed for reliability and recoverability, not privacy. These features create a rich forensic goldmine.

3) ext4 Forensics

ext4 is Linux's default file system. While different from NTFS, it offers similar forensic opportunities:

ext4 Key Structures:

Superblock:
- File system metadata
- Block size, inode count, etc.
- Located at offset 1024 bytes
- Backup copies throughout disk
- Magic number: 0xEF53

Block Groups:
- Disk divided into groups
- Each group has:
  - Group descriptor
  - Block bitmap
  - Inode bitmap
  - Inode table
  - Data blocks

Inodes:
- Metadata for each file
- Fixed size (typically 256 bytes)
- Contains:
  - File type and permissions
  - Owner UID/GID
  - Size
  - Timestamps (atime, mtime, ctime, crtime)
  - Block pointers (direct/indirect or extents)
- Does NOT contain filename

Inode Structure:

ext4 Inode Contents:

┌─────────────────────────────────────┐
│ Mode (permissions + type)           │
│ UID (owner)                         │
│ Size                                │
│ Access time (atime)                 │
│ Change time (ctime) - metadata      │
│ Modification time (mtime) - data    │
│ Deletion time (dtime)               │
│ GID (group)                         │
│ Links count                         │
│ Blocks count                        │
│ Flags                               │
│ Block pointers / Extent tree        │
│ Generation number                   │
│ Extended attributes                 │
│ Creation time (crtime) - ext4 only  │
└─────────────────────────────────────┘

Forensic Note:
- dtime (deletion time) preserved on delete
- Reveals when file was deleted
- Links count = 0 means deleted
- Inode may persist after deletion

Examining inodes:
$ istat disk.img -o 2048 12345
inode: 12345
Allocated
Group: 0
uid / gid: 1000 / 1000
mode: -rw-r--r--
size: 4096
num of links: 1
Modified:       2024-03-15 14:30:22 (UTC)
Accessed:       2024-03-15 14:30:22 (UTC)
Changed:        2024-03-15 14:30:22 (UTC)
Created:        2024-03-10 09:15:00 (UTC)

Directory Entries:

ext4 Directory Structure:

Directory = special file containing entries

Entry format:
┌─────────────────────────────────────┐
│ Inode number (4 bytes)              │
│ Entry length (2 bytes)              │
│ Name length (1 byte)                │
│ File type (1 byte)                  │
│ Name (variable length)              │
└─────────────────────────────────────┘

Deletion behavior:
- Inode number set to 0
- Entry merged with previous
- Name may remain readable
- Inode still contains metadata

Recovery opportunity:
- Deleted entry names in directory
- Orphan inodes (no directory entry)
- Journal contains old directories

ext4 Journal:

ext4 Journaling:

Journal modes:
- journal: Data + metadata journaled (slowest, safest)
- ordered: Metadata journaled, data written first (default)
- writeback: Only metadata journaled (fastest, least safe)

Journal location:
- Hidden inode 8
- Or external journal device

Forensic value:
- Previous versions of metadata
- Deleted file information
- Recent file system operations
- Inode states before deletion

Examining journal:
$ jls disk.img -o 2048
$ jcat disk.img -o 2048 [journal_block]

Tools for journal analysis:
- extundelete
- ext4magic
- Sleuth Kit jls/jcat

Sleuth Kit Commands for ext4:

Essential Sleuth Kit Commands:

# File system statistics
$ fsstat disk.img -o 2048

# List files in directory
$ fls disk.img -o 2048 2
r/r 12:   file1.txt
d/d 13:   subdir
r/r * 14: deleted_file.txt    # Asterisk = deleted

# List recursively with paths
$ fls -r -p disk.img -o 2048

# Examine specific inode
$ istat disk.img -o 2048 14

# Extract file by inode
$ icat disk.img -o 2048 14 > recovered_file.txt

# Extract deleted file
$ icat disk.img -o 2048 14 > deleted_recovered.txt

# List all deleted
$ fls -d -r disk.img -o 2048

Key insight: ext4's deletion behavior—setting inode number to zero but preserving inode content—makes recovery possible until the inode is reallocated.

4) FAT/exFAT and File Recovery

FAT (File Allocation Table) file systems are simpler but still common on removable media. Understanding deletion and recovery applies across all file systems:

FAT Structure Overview:

Boot Sector → FAT1 → FAT2 (copy) → Root Dir → Data Area

Boot Sector:
- Bytes per sector
- Sectors per cluster
- Reserved sectors
- Number of FATs
- Root directory entries (FAT12/16)

FAT (File Allocation Table):
- Cluster chain tracking
- One entry per cluster
- Values:
  - 0x0000 = Free cluster
  - 0x0002-MAX = Next cluster
  - 0xFFF7 = Bad cluster
  - 0xFFF8-FFFF = End of chain

Directory Entry (32 bytes):
- Filename (8.3 format)
- Attributes
- Creation time/date
- First cluster
- File size

FAT Deletion Behavior:

What Happens When FAT Deletes a File:

1. First character of filename → 0xE5
2. FAT chain entries → 0x0000 (free)
3. Data in clusters → UNCHANGED

Example:
Before: DOCUMENT.TXT  Cluster: 1000 → 1001 → 1002 → EOF
After:  σOCUMENT.TXT  Cluster: free, free, free (data intact)

Recovery opportunity:
- Filename partially preserved
- Directory entry has first cluster
- File size preserved
- Data intact until overwritten

Challenges:
- FAT chain lost
- Fragmented files harder to recover
- Must find all clusters manually

Tools:
- PhotoRec (signature-based)
- Recuva
- TestDisk
- Autopsy

File Carving Techniques:

File Carving - Signature-Based Recovery:

Concept:
- Search for file headers (magic bytes)
- Extract data until footer or size limit
- Works on any file system or raw disk
- Ignores file system metadata

Common File Signatures:
┌──────────────┬────────────────────┬─────────────────┐
│ File Type    │ Header (Hex)       │ Footer          │
├──────────────┼────────────────────┼─────────────────┤
│ JPEG         │ FF D8 FF           │ FF D9           │
│ PNG          │ 89 50 4E 47        │ AE 42 60 82     │
│ PDF          │ 25 50 44 46        │ %%EOF           │
│ ZIP/DOCX     │ 50 4B 03 04        │ 50 4B (varies)  │
│ RAR          │ 52 61 72 21        │                 │
│ GIF          │ 47 49 46 38        │ 00 3B           │
│ EXE/DLL      │ 4D 5A              │                 │
│ ELF          │ 7F 45 4C 46        │                 │
└──────────────┴────────────────────┴─────────────────┘

Scalpel configuration (scalpel.conf):
# type   case   size       header              footer
jpg      y      20000000   \xff\xd8\xff        \xff\xd9
png      y      20000000   \x89PNG             \xaeB`\x82
pdf      y      50000000   %PDF                %%EOF

Running Scalpel:
$ scalpel -c scalpel.conf -o output/ disk.img

PhotoRec (interactive):
$ photorec disk.img

Slack Space Analysis:

Slack Space - Data Between the Cracks:

Types of Slack:

1. File Slack (RAM Slack + Drive Slack):
   ┌────────────────────────────────────────┐
   │ Cluster (4096 bytes)                   │
   │ ┌──────────────────┬─────────────────┐ │
   │ │ File Data        │ Slack Space     │ │
   │ │ (2500 bytes)     │ (1596 bytes)    │ │
   │ └──────────────────┴─────────────────┘ │
   └────────────────────────────────────────┘

   - RAM Slack: Sector padding (may contain RAM data)
   - Drive Slack: Remaining sectors in cluster
   - Contains data from previously deleted files

2. Volume Slack:
   - Space between end of file system and partition end
   - May contain deleted partition data

3. Partition Slack:
   - Space between partitions
   - Hidden data opportunity

Forensic value:
- Fragments of deleted files
- Partial documents
- Old file content
- Anti-forensics detection

Extracting slack:
$ blkls disk.img -o 2048 > slack.bin
$ blkcat disk.img -o 2048 [cluster] > cluster.bin

Unallocated Space Analysis:

Unallocated Space:

What it contains:
- Deleted files not yet overwritten
- Previous file system remnants
- Carved artifacts

Extracting unallocated:
$ blkls -A disk.img > unallocated.bin

Searching unallocated:
$ strings unallocated.bin | grep -i password
$ grep -obaP "[\w.-]+@[\w.-]+" unallocated.bin

Carving unallocated:
$ foremost -i unallocated.bin -o carved/
$ photorec unallocated.bin

Common finds:
- Deleted documents
- Cached web content
- Temporary files
- Partial files (fragmented)
- Email artifacts
- Database fragments

Key insight: File carving works even when the file system is completely destroyed—it's signature-based recovery from raw data.

5) Practical Tools: Autopsy and Sleuth Kit

Autopsy provides a GUI for forensic analysis, while Sleuth Kit offers command-line tools. Both are essential skills:

Autopsy Workflow:

1. Create New Case:
   - Case name, number, examiner
   - Base directory for case files
   - Case opens in browser interface

2. Add Data Source:
   - Disk image (E01, raw, etc.)
   - Local disk (careful!)
   - Logical files

3. Configure Ingest Modules:
   □ Hash Lookup (NSRL, known bad)
   □ File Type Identification
   □ Embedded File Extractor
   □ EXIF Parser
   □ Keyword Search
   □ Email Parser
   □ Extension Mismatch Detector
   □ Interesting Files Identifier
   □ PhotoRec Carver
   □ Recent Activity

4. Analysis Views:
   - File System: Browse like Explorer
   - File Types: By MIME type
   - Deleted Files: Only deleted
   - File Size: Size ranges
   - Timeline: Temporal view
   - Keyword Search: Search results
   - Hash Sets: Known files
   - Tags: Your markings
   - Reports: Generate output

Sleuth Kit Command Reference:

Sleuth Kit Tools:

Volume System (Partition) Layer:
mmls     - Display partition layout
mmcat    - Extract partition data
mmstat   - Display volume system info

File System Layer:
fsstat   - Display file system details
fls      - List files and directories
ffind    - Find file by inode
istat    - Display inode details
icat     - Extract file by inode
ifind    - Find inode by file/block

Block/Cluster Layer:
blkstat  - Display block details
blkls    - List blocks (allocated/unallocated)
blkcat   - Extract specific block
blkcalc  - Map between images

Hash Database:
hfind    - Lookup hash in database
sorter   - Sort files by type/hash

Complete Workflow Example:
# 1. Identify partitions
$ mmls evidence.E01
      Slot    Start      End          Length       Description
000:  000     0000002048 0488396799   0488394752   NTFS

# 2. Get file system info
$ fsstat -o 2048 evidence.E01

# 3. List root directory
$ fls -o 2048 evidence.E01
r/r 4-128-4:    $AttrDef
r/r 8-128-2:    $BadClus
d/d 11-144-4:   Users
d/d 21-144-2:   Windows

# 4. List specific directory (inode 11)
$ fls -o 2048 evidence.E01 11
d/d 15-144-2:   Administrator
d/d 16-144-2:   Default

# 5. Find deleted files recursively
$ fls -r -d -o 2048 evidence.E01

# 6. Extract interesting file
$ icat -o 2048 evidence.E01 12345 > extracted_file.docx

Integration Example:

Full Investigation Workflow:

# Initial triage
$ mmls case.E01 > case_partitions.txt
$ fsstat -o 2048 case.E01 > case_fsstat.txt

# Catalog all files
$ fls -r -p -o 2048 case.E01 > all_files.txt

# Find deleted files
$ fls -r -d -p -o 2048 case.E01 > deleted_files.txt

# Extract specific file types
$ tsk_recover -e -o 2048 case.E01 recovered/

# Keyword search in unallocated
$ blkls -A -o 2048 case.E01 > unallocated.bin
$ strings -a -t d unallocated.bin > strings.txt
$ grep -n "password\|secret\|confidential" strings.txt

# Carve deleted files
$ scalpel -c /etc/scalpel/scalpel.conf -o carved/ case.E01

# Generate hash list
$ fls -r -m "/" -o 2048 case.E01 | while read line; do
    inode=$(echo $line | cut -d'|' -f3)
    icat -o 2048 case.E01 $inode 2>/dev/null | md5sum
done > hashes.txt

Eric Zimmerman Tools (Windows):

Eric Zimmerman Tools Suite:

MFTECmd - Parse $MFT and $UsnJrnl:
> MFTECmd.exe -f "$MFT" --csv output/
> MFTECmd.exe -f "$UsnJrnl:$J" --csv output/

LECmd - Parse LNK files:
> LECmd.exe -d "C:\Users\*\Recent" --csv output/

PECmd - Parse Prefetch:
> PECmd.exe -d "C:\Windows\Prefetch" --csv output/

JLECmd - Parse Jump Lists:
> JLECmd.exe -d "C:\Users\*\AppData" --csv output/

SBECmd - Parse ShellBags:
> SBECmd.exe -d "C:\Users\*" --csv output/

AmcacheParser:
> AmcacheParser.exe -f "Amcache.hve" --csv output/

Timeline Explorer - View CSV results:
> Open CSV files with filtering/sorting

All output to CSV for correlation and timeline building

Key insight: Command-line tools enable scripting and batch processing. GUI tools like Autopsy provide visualization. Professional examiners use both.

Real-World Context

Case Study: Dennis Rader (BTK Killer)

In 2005, Dennis Rader sent police a floppy disk containing a Word document. Standard file examination revealed little, but forensic analysis of the disk's deleted files and file system metadata led investigators to Christ Lutheran Church and the name "Dennis." Cross-referencing with church records identified Rader, ending a 30-year investigation. The metadata he thought he'd removed—file author name, organization—was recovered from disk artifacts.

Case Study: Enron Investigation

When Enron collapsed in 2001, investigators faced the challenge of recovering emails that executives had "deleted." Using file carving techniques and backup tape recovery, forensic teams recovered over 600,000 emails, many from deleted states. These emails, recovered through slack space analysis and file carving, became crucial evidence in prosecuting executives for fraud.

MITRE ATT&CK Alignment:

File System Forensics Maps to MITRE ATT&CK:

Defense Evasion - T1070 (Indicator Removal):
- T1070.004: File Deletion
  Forensic counter: File carving, slack space analysis
  
- T1070.006: Timestomping
  Forensic counter: $FN vs $SI timestamp comparison

- T1070.009: Clear Persistence
  Forensic counter: USN Journal analysis, $LogFile

Persistence Detection via File System:
- Startup folder modifications
- Hidden files (ADS, system attributes)
- Registry run keys (via hive analysis)

Collection Detection:
- T1074: Data Staged
  Forensic indicator: Unusual file clusters, temporary directories

Exfiltration Detection:
- T1041: Exfiltration Over C2
  Forensic indicator: Archive files, encrypted containers

These techniques are fundamental to incident response—understanding how attackers try to hide helps you find what they left behind.

Guided Lab: Deleted File Recovery

In this lab, you'll recover deleted files from a forensic image using multiple techniques, demonstrating that "deleted" data persists until overwritten.

Lab Environment:

• SIFT Workstation or Linux with Sleuth Kit installed
• Autopsy (GUI forensic tool)
• Practice image: Digital Corpora or CFReDS sample

Exercise Steps:

1. Use mmls to identify partitions in the image
2. Use fsstat to determine file system type and parameters
3. Use fls -d to list deleted files
4. Use istat to examine a deleted file's inode
5. Use icat to extract a deleted file
6. Verify file type with file command
7. Run file carving with Scalpel or PhotoRec
8. Compare results: file system recovery vs carving

Reflection Questions:

• What additional files did carving find that fls -d missed?
• Why might carving produce false positives?
• How would you document this recovery for court?

Week Outcome Check

By the end of this week, you should be able to:

• Explain disk structure: sectors, clusters, partitions
• Navigate NTFS structures: MFT, $LogFile, $UsnJrnl, ADS
• Analyze ext4 internals: superblock, inodes, journal
• Understand FAT deletion behavior and recovery potential
• Perform file carving using signature-based techniques
• Identify and extract slack space data
• Use Sleuth Kit commands: mmls, fsstat, fls, istat, icat
• Navigate Autopsy for forensic analysis

🎯 Hands-On Labs (Free & Essential)

Practice file system analysis before moving to reading resources.

💡 Lab Tip: Compare recovered files with filesystem metadata to confirm authenticity.

🛡️ SOC Metrics & Evidence Quality

Metrics drive improvement. Forensics outcomes improve when the SOC tracks what it detects and what it misses.

Metrics to watch:
- MTTD / MTTR by incident type
- Evidence completeness per case
- False positive rates by rule
- Dwell time before containment

📚 Building on CSY201: SOC KPI design and alert tuning fundamentals.

Resources

Week 03 Quiz

Test your understanding of File System Forensics, NTFS, ext4, and Data Recovery.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Lab

Complete the following lab exercises to practice file system forensic techniques. Use the SIFT Workstation or equivalent forensic environment.