Lab 02 Disk Image & Filesystem Investigation

Mission Overview

Welcome to Lab 02 — Disk Image & Filesystem Investigation.

In Lab 01, you learned how to identify, preserve, hash, label, and document digital evidence while maintaining a clear chain of custody.

Now you will begin examining the evidence itself.

A forensic disk image can contain:

• partitions

• filesystems

• user files

• system files

• deleted artifacts

• metadata

• timestamps

• application data

• hidden content

• operating system structures

Your job is not simply to browse files.

Your job is to determine:

What exists inside the image, how the filesystem is structured, which artifacts are relevant, and what conclusions can be supported by the evidence?

Mission Goal: Verify a forensic disk image, identify partitions and filesystems, examine directory and file structures, review timestamps and metadata, extract relevant artifacts safely, and produce a structured Disk Forensics Investigation Report.

Mission Information

Item	Details
Difficulty	Beginner–Intermediate
Estimated Time	90–120 minutes
Primary Skill	Disk Forensics
Secondary Skill	Filesystem Analysis
Environment	GoHackersCloud Digital Forensics Lab
Evidence Type	Training forensic disk image
Testing Type	Read-Only Examination
Primary Outcome	Disk & Filesystem Evidence Register
Safety Level	Authorized Training Evidence Only

Learning Objectives

By completing this lab, you will be able to:

• verify forensic-image integrity

• distinguish physical disks from forensic images

• identify disk-image formats

• identify partitions

• identify filesystem types

• understand filesystem hierarchy

• examine directories

• inspect file metadata

• interpret basic timestamps

• review file permissions and ownership

• identify hidden/system files

• understand file signatures

• compare file extension with file content

• identify potentially relevant artifacts

• extract evidence from a working image

• maintain evidence lineage

• document findings professionally

Disk Forensics Methodology

Use:

Image → Verify → Partition → Filesystem → Directory → File → Metadata → Evidence → Conclusion

Conceptually:

Forensic Image
      │
      ▼
Integrity Verification
      │
      ▼
Partition Table
      │
      ▼
Filesystem
      │
      ▼
Directory Structure
      │
      ▼
Files
      │
      ▼
Metadata
      │
      ▼
Relevant Evidence
      │
      ▼
Investigation Conclusion

The core rule remains:

Examine the verified working copy, not the preserved original.

Part 1 — Confirm the Evidence

Before examination, document:

Case ID:

Evidence ID:

Original Evidence:

Working Copy:

Expected SHA-256:

Working Copy SHA-256:

Hash Match:

Investigator:

Examination Date:

Examination Start Time:

Do not continue if the working copy cannot be verified.

Part 2 — Verify the Working Copy

Run:

sha256sum Working-Copies/E01-working.dd

Compare it with the hash recorded during Lab 01.

Record:

Recorded Hash:

Current Hash:

Match:
Yes / No

Expected:

Match:
Yes

If not, stop and investigate the discrepancy.

Part 3 — Create the Lab Workspace

Create:

Digital-Forensics-Labs/
└── Lab-02/
    ├── Notes/
    ├── Evidence/
    │   ├── Disk/
    │   ├── Partitions/
    │   ├── Filesystem/
    │   ├── Metadata/
    │   └── Extracted/
    ├── Screenshots/
    ├── Hashes/
    ├── Findings/
    └── Report/

Create:

Lab-02-Disk-Investigation-Journal.md

Suggested structure:

# Lab 02 — Disk Image & Filesystem Investigation

## Mission Objective

## Evidence Information

## Integrity Verification

## Image Format

## Partition Structure

## Filesystem Identification

## Directory Structure

## File Inventory

## Metadata Analysis

## Timestamp Analysis

## Hidden/System Files

## File Signature Analysis

## Extracted Evidence

## Findings

## Limitations

## Evidence Register

## Conclusion

Part 4 — Understand Disk Images

A forensic disk image is a representation of storage media.

Common formats include:

RAW / DD

E01

AFF

RAW / DD

A sector-by-sector representation with little additional metadata.

E01

A forensic evidence format that can include metadata and compression.

AFF

Another forensic image format designed for forensic workflows.

For this lab, use the format provided by the training environment.

Part 5 — Understand Disk Structure

A simplified disk can look like:

Physical / Forensic Disk
        │
        ▼
Partition Table
        │
   ┌────┼────┐
   ▼    ▼    ▼
 Part1 Part2 Part3
   │
   ▼
Filesystem
   │
   ▼
Directories
   │
   ▼
Files

You must first understand the structure before examining individual files.

Part 6 — Identify the Image

Use:

file Working-Copies/E01-working.dd

Record:

Evidence File:

Detected Type:

Tool:

Observation:

The file command may not always provide complete disk-layout information.

Treat it as an initial observation.

Part 7 — Examine the Partition Table

Where available, use a read-only inspection tool such as:

fdisk -l Working-Copies/E01-working.dd

or the forensic tool provided in the lab.

Record:

Disk Size:

Sector Size:

Partition Table Type:

Partitions Identified:

Possible partition-table types include:

MBR

GPT

Part 8 — Build the Partition Register

Create:

Partition	Start	End	Size	Type	Notes
P01
P02

Do not assume every partition contains a mountable filesystem.

Part 9 — Understand MBR vs GPT

MBR

Older partitioning model commonly associated with traditional BIOS environments.

GPT

Modern partitioning model commonly used with UEFI systems.

The presence of either is not a finding.

It is structural evidence.

Part 10 — Identify Filesystem Types

Depending on the lab image, you may encounter:

NTFS

FAT32

exFAT

ext4

XFS

Record:

Partition:

Filesystem:

Detected By:

Evidence:

The filesystem determines which artifacts and metadata are available.

Part 11 — Understand Why Filesystem Type Matters

Different filesystems store metadata differently.

For example:

NTFS

May contain forensic artifacts such as:

Master File Table

Alternate Data Streams

NTFS timestamps

File attributes

ext4

May contain:

Inodes

Permissions

Ownership

Filesystem timestamps

Journal information

You do not need to master every internal structure in this lab.

Focus on correct examination.

Part 12 — Mount Only the Working Copy

If mounting is part of the lab, use the working copy and mount read-only.

Conceptually:

Working Image
     │
     ▼
Read-Only Mount
     │
     ▼
Filesystem Examination

The exact mount procedure depends on:

• image format

• filesystem

• partition offset

• training environment

If the course provides a forensic GUI, use its read-only examination mode.

Part 13 — Understand Partition Offsets

A RAW image may contain multiple partitions.

The filesystem may begin at an offset determined by:

Starting Sector × Sector Size

Example:

Starting Sector:
2048

Sector Size:
512

Conceptually:

2048 × 512
=
Partition Offset

Do not guess offsets.

Use the partition information from the image.

Part 14 — Create a Directory Inventory

Once the filesystem is accessible, record the top-level directories.

Example Linux-style image:

/bin
/etc
/home
/opt
/tmp
/usr
/var

Example Windows-style image:

Users
Windows
Program Files
ProgramData

Create:

Directory	Purpose	Investigation Priority
Users/Home	User activity	High
Windows/etc	System	High
Temp	Temporary activity	Medium
ProgramData/var	Application data	Medium/High

Part 15 — Identify User Profiles

User directories are often valuable forensic areas.

Examples:

/home/alice
/home/bob

or:

C:\Users\Alice
C:\Users\Bob

Record:

User Profile:

Path:

Home Directory Present:

Relevant Subdirectories:

Do not infer who physically used the system solely from a directory name.

Part 16 — Build the User Directory Register

User/Profile	Path	Relevant Artifacts	Notes
User01		Documents/Downloads
User02		Browser/Profile

This provides a starting point for later investigations.

Part 17 — Examine Important Directories

Depending on the scenario, prioritize:

Desktop

Documents

Downloads

Temporary Directories

Application Data

Logs

Configuration Directories

Ask:

Which locations are most likely to contain evidence relevant to the case?

Do not copy every file blindly.

Part 18 — Build the File Inventory

Create:

Evidence ID	File	Path	Size	Type	Relevance
F-001
F-002

Initially, classify relevance as:

High

Medium

Low

Unknown

Part 19 — Review File Metadata

For an extracted training file:

stat filename

Record:

Filename:

Size:

Owner:

Permissions:

Access Time:

Modify Time:

Change Time:

Other Time:
If available

The exact timestamp fields depend on the filesystem.

Part 20 — Understand Timestamps Carefully

Common timestamp concepts include:

Created

Modified

Accessed

Metadata Changed

These meanings differ across operating systems and filesystems.

Do not write:

“The user created this file at 10:00.”

when your evidence only shows:

“The filesystem creation timestamp is 10:00.”

That distinction matters.

Part 21 — Build a Timestamp Register

File	Timestamp Type	Value	Interpretation
file1	Modified		File content changed
file1	Accessed		Requires context
file1	Created		Filesystem creation

Avoid drawing conclusions from a single timestamp.

Part 22 — Understand Timestamp Manipulation

Timestamps can be:

• changed by normal operating-system activity

• modified by copying

• altered by applications

• intentionally manipulated

Therefore:

Timestamp ≠ complete proof of user activity.

Use correlation.

Part 23 — Review Ownership and Permissions

Linux example:

ls -l

Windows evidence may contain NTFS ownership and ACL information accessible through forensic tools.

Record:

Owner:

Group:

Permissions:

Security Relevance:

Permissions can help answer:

Who could access or modify this file?

Part 24 — Identify Hidden Files

Linux hidden files commonly begin with:

.

Example:

.bash_history

.ssh

.config

Windows may use hidden or system file attributes.

Hidden does not automatically mean suspicious.

Many legitimate applications use hidden files.

Part 25 — Build the Hidden/System File Register

File	Path	Attribute	Expected	Notes
.bashrc	Home	Hidden	Yes	Normal
<artifact>		Hidden	Unknown	Review

Part 26 — Understand File Extensions

A filename such as:

report.pdf

suggests a PDF document.

But the extension can be changed.

Therefore:

Extension
   ≠
Guaranteed File Type

Part 27 — Examine File Signatures

Use:

file extracted-file

Compare:

Filename Extension

with:

Detected File Type

Example:

invoice.pdf

but tool reports:

PNG image data

That mismatch deserves documentation.

Part 28 — Understand Magic Bytes

Many formats have recognizable file headers.

Conceptually:

File
 ↓
Header / Signature
 ↓
Actual Format

Examples include signatures associated with:

• PDF

• PNG

• JPEG

• ZIP

• executable files

The goal here is recognition, not binary reverse engineering.

Part 29 — Build the File Signature Register

File	Extension	Detected Type	Match	Review
report.pdf	PDF	PDF	Yes	Normal
image.jpg	JPG	ZIP	No	Investigate

Do not automatically call every mismatch malicious.

Part 30 — Review File Sizes

File size can provide context.

Examples:

0 bytes

Very large archive

Tiny executable-looking file

Unexpected size for document type

But file size alone rarely proves anything.

Use it as supporting evidence.

Part 31 — Search for Case-Relevant Files

Use the case scenario to define keywords.

For example:

project

invoice

download

backup

admin

Do not conduct unrestricted searches for unrelated personal information.

Search only what is relevant to the training case.

Part 32 — Understand Evidence Minimization

A forensic examiner should avoid collecting unnecessary information.

Ask:

Does this artifact help answer the investigation question?

If not, it may not need to be extracted.

This improves:

• privacy

• efficiency

• evidence management

• reporting quality

Part 33 — Extract Relevant Files

Extract only identified training artifacts from the working copy.

Store them under:

Evidence/Extracted/

Name them consistently.

Example:

E01-F001-report.pdf

E01-F002-browser-artifact.dat

Part 34 — Hash Extracted Artifacts

For each important extracted file:

sha256sum E01-F001-report.pdf

Record:

Parent Evidence:

Extracted Evidence ID:

Original Path:

Extracted Filename:

SHA-256:

Extraction Date:

Investigator:

Part 35 — Maintain Evidence Lineage

Example:

E01 — Disk Image
       │
       ▼
E01-W01 — Working Copy
       │
       ├────► E01-F001 — Document
       │
       ├────► E01-F002 — Image
       │
       └────► E01-F003 — Log

This makes every extracted item traceable to the source.

Part 36 — Build the Extracted Evidence Register

ID	Parent	Original Path	Type	Hash	Relevance
F001	E01		Document		High
F002	E01		Log		Medium

Part 37 — Identify Operating System Clues

A disk image may reveal its operating system through directories and files.

Examples:

Windows

Windows

Users

Program Files

Linux

/etc

/home

/var

/usr

Record:

Likely OS:

Evidence Supporting Conclusion:

Confidence:

Part 38 — Determine Hostname Where Possible

Configuration artifacts may provide a hostname.

Record:

Hostname:

Source Artifact:

Confidence:

Do not rely solely on one unverified filename.

Part 39 — Identify Timezone Information

Timezone context is critical in forensic timelines.

Look for system configuration evidence that indicates:

Timezone

UTC Offset

Time Synchronization

Record:

System Timezone:

Evidence Source:

Confidence:

This becomes important in later timeline reconstruction.

Part 40 — Identify Installed Applications

Applications can help explain user activity.

Examples:

Web Browser

Office Software

Compression Tools

Communication Applications

Do not interpret application installation alone as evidence of use.

Record:

Application:

Evidence Source:

Installed:

Executed:
Unknown unless separately supported

Part 41 — Distinguish Presence from Use

This is a major forensic principle.

Application Installed
        ≠
Application Used

Similarly:

File Exists
   ≠
User Opened It

and:

Browser Artifact Exists
        ≠
Current User Generated It

Corroborating artifacts are required.

Part 42 — Identify Potential Log Sources

Depending on the image, note locations containing:

Operating System Logs

Authentication Logs

Application Logs

Web Logs

Security Logs

Do not deeply analyze them yet unless relevant.

Later labs will cover host-specific artifacts.

Part 43 — Build the Artifact Map

Example:

Disk Image
   │
   ├── User Profiles
   │      ├── Desktop
   │      ├── Documents
   │      └── Downloads
   │
   ├── System Configuration
   │
   ├── Application Data
   │
   ├── Logs
   │
   └── Temporary Files

This helps organize the investigation.

Part 44 — Create Investigation Questions

Examples:

Which user profiles exist?

Which files appear relevant to the incident?

Which timestamps establish the likely activity period?

Which downloaded or recently modified files require further analysis?

Which system artifacts should be investigated next?

Use questions to guide analysis instead of browsing randomly.

Part 45 — Build the Investigation Question Register

ID	Question	Evidence Needed	Status
Q01	Which users exist?	Profile dirs	Answered
Q02	Which files changed?	Metadata	In progress
Q03	Was file X downloaded?	Browser artifacts	Future lab

Part 46 — Classify Evidence

Use:

Direct Evidence

Directly supports a specific fact.

Corroborating Evidence

Supports evidence from another source.

Contextual Evidence

Provides environmental or investigative context.

Unresolved Artifact

Potentially relevant but requires further examination.

Part 47 — Example Observation

Observation:
A document named project-plan.docx exists in the user's
Documents directory.

This is appropriate.

Avoid:

The user definitely created project-plan.docx.

unless supported by additional evidence.

Part 48 — Example Metadata Finding

Observation:
The file's filesystem modification timestamp falls within the
known incident period.

Security / Investigative Relevance:
The timing makes the file relevant for further examination.

Conclusion:
The timestamp alone does not establish who modified the file.

This is defensible forensic language.

Part 49 — Example File Signature Finding

Finding:
File extension does not match detected file type.

Observation:
The file was named evidence.jpg, but file-signature analysis
identified the content as a ZIP archive.

Investigative Relevance:
The mismatch may indicate renamed or incorrectly labeled content
and warrants additional examination.

Conclusion:
No malicious intent can be established from the mismatch alone.

Part 50 — Build the Filesystem Evidence Register

ID	Path	Artifact	Observation	Confidence	Follow-Up
FS-01
FS-02

This becomes the major deliverable of the lab.

Part 51 — Create the Preliminary Timeline

Using only filesystem evidence, create:

Time	Artifact	Timestamp Type	Observation
	File A	Created
	File A	Modified
	File B	Modified

Do not yet call this the complete incident timeline.

It is:

Filesystem Timeline Evidence

Part 52 — Understand Timeline Correlation

One file may show:

10:00 Modified

Another:

10:01 Created

A browser artifact later might show:

09:59 Downloaded

Eventually:

Browser
   +
Filesystem
   +
Logs
   =
Stronger Timeline

This is why later labs correlate multiple sources.

Part 53 — Preserve Investigation Outputs

Your examination creates derived artifacts such as:

File Listings

CSV Exports

Screenshots

Extracted Files

Timeline Files

Notes

These should also be documented.

Create:

Derived Evidence Register

ID	Source	Artifact	Purpose
D01	E01	Directory listing	Structure
D02	E01	Timeline CSV	Timestamp analysis

Part 54 — Reverify Evidence After Examination

At the end of the lab, rehash the working evidence if appropriate:

sha256sum Working-Copies/E01-working.dd

Compare with the initial working-copy hash.

Record:

Pre-Examination Hash:

Post-Examination Hash:

Match:

Evidence Integrity Status:

If examination was correctly read-only:

Match:
Yes

Part 55 — Verify the Preserved Original

Where the workflow calls for it, confirm the preserved original hash still matches the Lab 01 record.

Do not unnecessarily manipulate the original.

Document:

Original Integrity:

Verified / Not Reverified

Reason:

Part 56 — Mission Challenge

Analyze the provided forensic image and complete:

CASE

Case ID:

Evidence ID:

Working Copy:

Hash Verified:


DISK

Image Format:

Image Size:

Partition Table:

Number of Partitions:


PARTITION 01

Start:

Size:

Type:

Filesystem:


OPERATING SYSTEM

Likely OS:

Hostname:

Timezone:

Evidence Sources:


USERS

Profile 01:

Profile 02:


FILESYSTEM

Top-Level Directories:

Important User Directories:

Important System Directories:

Log Locations:


ARTIFACTS

Relevant File 01:

Path:

Type:

Size:

Timestamps:

Hash:

Reason Relevant:


Relevant File 02:

Path:

Type:

Metadata:

Reason Relevant:


FILE SIGNATURES

Mismatches Identified:

Explanation:


TIMELINE

Earliest Relevant Event:

Latest Relevant Event:

Important Timestamp Sequence:


EVIDENCE

Files Extracted:

Derived Evidence:

Evidence Lineage Complete:

Post-Analysis Hash Verified:


FINAL CONCLUSION

Most Important Artifact:

Most Important Timestamp:

Largest Evidence Gap:

Recommended Next Examination:

Overall Conclusion:

Part 57 — What Not to Do

Do not:

Modify original disk evidence

Mount original evidence read/write

Delete files from the image

Change filesystem metadata

Open unrelated private content unnecessarily

Extract every file without purpose

Treat hidden files as malicious automatically

Treat file-extension mismatch as proof of malware

Assume timestamp equals user action

Rename evidence without documentation

Lose evidence lineage

The core principle is:

Examine deliberately, preserve continuously, conclude cautiously.

Part 58 — Troubleshooting

Image Does Not Mount

Possible causes:

• image contains partitions

• wrong offset

• unsupported filesystem

• evidence format requires forensic software

Do not modify the image to make it mount.

Determine the image structure first.

No Filesystem Detected

The partition may be:

• unsupported

• encrypted

• unformatted

• damaged

• not a filesystem partition

Document the result.

Permission Denied

Do not change evidence permissions blindly.

Confirm your forensic environment and the training procedure.

Hash Changes After Analysis

Stop and determine whether the image was mounted or accessed in a writable manner.

Document the integrity concern.

Timestamps Look Inconsistent

Check:

• timezone

• filesystem semantics

• extraction effects

• clock configuration

• timestamp type

Do not force timestamps into a preferred story.

File Extension Does Not Match

Record it as an observation and analyze the file type.

Do not assume maliciousness.

Evidence Requirements

Capture:

Evidence 01

Working-copy hash verification.

Evidence 02

Image identification.

Evidence 03

Partition-table information.

Evidence 04

Partition Register.

Evidence 05

Filesystem identification.

Evidence 06

Top-level directory structure.

Evidence 07

User-profile inventory.

Evidence 08

File Inventory.

Evidence 09

Metadata evidence.

Evidence 10

Timestamp Register.

Evidence 11

Hidden/system-file review.

Evidence 12

File-signature comparison.

Evidence 13

Extracted Evidence Register.

Evidence 14

Hashes of important extracted artifacts.

Evidence 15

Evidence lineage.

Evidence 16

Filesystem Evidence Register.

Evidence 17

Preliminary filesystem timeline.

Evidence 18

Derived Evidence Register.

Evidence 19

Post-examination integrity verification.

Evidence 20

Final investigation report.

Mission Deliverables

Complete:

• working image verified

• lab workspace created

• image format identified

• disk size recorded

• partition table examined

• Partition Register created

• filesystem identified

• directory structure examined

• user profiles identified

• File Inventory created

• relevant metadata recorded

• timestamps analyzed

• hidden/system files reviewed

• file signatures compared

• relevant files extracted

• extracted files hashed

• Evidence Lineage created

• operating-system clues documented

• hostname reviewed where available

• timezone documented where available

• artifact map created

• Filesystem Evidence Register completed

• preliminary timeline created

• derived evidence documented

• post-examination hash verified

• final report completed

Lab Report Template

# Lab 02 — Disk Image & Filesystem Investigation

## Executive Summary

## Mission Objective

## Case Information

## Evidence Information

## Integrity Verification

## Disk Image Format

## Disk Structure

## Partition Analysis

## Filesystem Identification

## Operating System Identification

## User Profiles

## Directory Structure

## File Inventory

## File Metadata Analysis

## Timestamp Analysis

## File Ownership and Permissions

## Hidden and System Files

## File Signature Analysis

## Extracted Evidence

## Evidence Integrity

## Evidence Lineage

## Filesystem Evidence Register

## Preliminary Timeline

## Findings

## Investigative Observations

## Limitations

## Recommended Follow-Up

## Conclusion

## Appendix A — Partition Register

## Appendix B — Extracted Evidence Register

## Appendix C — Hashes

## Appendix D — Derived Evidence Register

Knowledge Check

Question 1 — Why verify the working image before examination?

To confirm that the evidence being examined matches the verified forensic copy.

Question 2 — What is a partition?

A defined region of storage that may contain a filesystem or another data structure.

Question 3 — Why identify the filesystem?

Because filesystem type determines how files, metadata, permissions, timestamps, and other structures are stored.

Question 4 — Does a file extension prove file type?

No.

The extension should be compared with actual file-format evidence.

Question 5 — Does a modification timestamp prove which user changed a file?

No.

It establishes a filesystem timestamp, not necessarily the actor.

Question 6 — Why extract files from the working copy rather than the original?

To preserve original evidence integrity.

Question 7 — Why hash extracted artifacts?

To create integrity references and maintain traceability.

Question 8 — What is evidence lineage?

Documentation showing how derived or extracted evidence relates back to the original evidence source.

Question 9 — Is a hidden file automatically suspicious?

No.

Hidden files are commonly used legitimately by operating systems and applications.

Question 10 — Why create only a preliminary timeline in this lab?

Because filesystem timestamps represent only one evidence source. Strong incident timelines require correlation with logs, browser activity, network evidence, and other artifacts.

Skills Achieved

After completing this lab, you should understand:

• forensic disk images

• working-copy verification

• RAW/DD awareness

• E01/AFF awareness

• partition-table examination

• MBR/GPT concepts

• filesystem identification

• directory analysis

• user-profile identification

• file inventory

• file metadata

• timestamps

• ownership and permissions

• hidden/system artifacts

• file signatures

• evidence extraction

• artifact hashing

• evidence lineage

• filesystem evidence registers

• preliminary timeline development

• evidence integrity verification

• professional disk-forensics reporting

Professional Takeaway

Disk forensics is not:

“Open the image and look for suspicious files.”

A professional examiner works methodically:

Verified Image
     ↓
Disk Structure
     ↓
Partition
     ↓
Filesystem
     ↓
Directories
     ↓
Files
     ↓
Metadata
     ↓
Context
     ↓
Correlated Evidence

The key questions are:

What does the filesystem tell me?

Which artifacts are relevant to the case?

What exactly does the evidence prove?

What additional evidence is required before I reach a conclusion?

The best forensic examiner is not the person who makes the strongest claim.

It is the person who makes the strongest claim the evidence can actually support.

What’s Next?

➡️ Lab 03 — Deleted Files & Metadata Investigation

In the next lab, you will move deeper into filesystem evidence and investigate:

• deleted-file artifacts

• recycle/trash mechanisms

• recoverable files

• file signatures

• document metadata

• image metadata

• creation/modification/access timestamps

• original file locations

• deletion indicators

• metadata correlation

• evidence recovery

• forensic timeline relationships

The methodology becomes:

Deleted Artifact → Recover → Verify → Metadata → Timestamp → Original Location → Correlation → Evidence

By the end of Lab 03, you should be able to answer:

“What deleted artifacts can still be identified, what metadata survives, and what can that evidence reliably tell us about prior file activity?”