Lab 03 Deleted Files & Metadata Investigation

Mission Overview

Welcome to Lab 03 — Deleted Files & Metadata Investigation.

In Lab 02, you learned how to verify a forensic image, identify partitions and filesystems, examine directory structures, and review file metadata.

Now you will investigate one of the most important questions in digital forensics:

What evidence remains after a file has been deleted?

Deleting a file usually does not immediately mean that every trace of it disappears.

Depending on the filesystem, operating system, application, and subsequent activity, investigators may still recover or identify:

• filenames

• original paths

• timestamps

• metadata

• file signatures

• partial file contents

• recycle/trash artifacts

• filesystem references

• related application artifacts

The goal of this lab is not just to recover files.

The goal is to determine:

What existed, where it existed, when it was used or modified, what happened to it, and what conclusions the surviving evidence can actually support.

Mission Goal: Identify deleted-file artifacts in a controlled forensic image, recover relevant training files where possible, analyze surviving metadata and timestamps, determine original locations, and create a defensible Deleted File & Metadata Evidence Register.

Mission Information

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

Learning Objectives

By completing this lab, you will be able to:

• explain what happens when files are deleted

• understand logical deletion

• distinguish deleted references from recovered content

• identify recycle/trash artifacts

• identify filesystem deletion indicators

• recover approved deleted training artifacts

• compare file signatures with extensions

• analyze document metadata

• analyze image metadata

• review creation, modification, access, and metadata-change times

• determine probable original file locations

• assess metadata reliability

• correlate deleted-file evidence with other artifacts

• distinguish direct evidence from inference

• document limitations

• preserve recovered artifacts and hashes

• create a preliminary deleted-file timeline

Investigation Methodology

Use:

Deleted Artifact → Identify → Recover → Verify → Metadata → Timestamp → Original Location → Correlate → Evidence → Conclusion

Conceptually:

Deleted File Reference
        │
        ▼
Filesystem Artifact
        │
        ▼
Recovery Attempt
        │
        ▼
Recovered Content
        │
        ▼
Hash / Signature
        │
        ▼
Metadata
        │
        ▼
Timestamps
        │
        ▼
Original Location
        │
        ▼
Correlation
        │
        ▼
Supported Conclusion

The key rule is:

Recovery does not automatically explain who deleted a file, why it was deleted, or whether the deletion was malicious.

Part 1 — Confirm the Evidence

Start by documenting:

Case ID:

Evidence ID:

Working Image:

Expected SHA-256:

Current SHA-256:

Hash Match:

Investigator:

Date:

Start Time:

Verify the working image before examination.

For example:

sha256sum Working-Copies/E01-working.dd

Expected:

Hash Match:
Yes

If the hash does not match, stop and investigate.

Part 2 — Create the Lab Workspace

Create:

Digital-Forensics-Labs/
└── Lab-03/
    ├── Notes/
    ├── Evidence/
    │   ├── Deleted-Artifacts/
    │   ├── Recovered-Files/
    │   ├── Metadata/
    │   ├── File-Signatures/
    │   └── Timeline/
    ├── Screenshots/
    ├── Hashes/
    ├── Findings/
    └── Report/

Create:

Lab-03-Deleted-Files-Journal.md

Suggested structure:

# Lab 03 — Deleted Files & Metadata Investigation

## Mission Objective

## Evidence Information

## Integrity Verification

## Filesystem Type

## Deleted Artifacts

## Recycle / Trash Artifacts

## Recovered Files

## File Signatures

## Document Metadata

## Image Metadata

## Timestamp Analysis

## Original Locations

## Timeline

## Correlation

## Findings

## Limitations

## Evidence Register

## Conclusion

Part 3 — Understand What “Deleted” Means

In many filesystems, deleting a file does not immediately erase every byte of content.

A simplified model:

File Exists
   │
   ▼
Directory Entry / Metadata
   │
   ▼
File Content Blocks

After deletion:

Directory Entry
    Marked Deleted
         │
         ▼
Storage Space
Marked Available

The content may remain until overwritten.

Therefore:

Deleted does not always mean destroyed.

Part 4 — Understand Logical Deletion

A file may disappear from a normal directory listing while its data or metadata still remains recoverable.

Conceptually:

Visible File
    ↓
Delete
    ↓
Reference Removed / Marked
    ↓
Data May Remain
    ↓
Recovery May Be Possible

Recovery success depends on:

• filesystem

• deletion method

• subsequent disk activity

• storage type

• TRIM behavior

• overwrite activity

• encryption

• corruption

Part 5 — Understand Why SSDs Are Different

On modern SSDs, mechanisms such as TRIM may reduce the recoverability of deleted data.

Therefore:

Deleted File on HDD
        ≠
Deleted File on SSD

in terms of recovery expectations.

Do not promise recoverability without examining the evidence.

Part 6 — Identify the Filesystem

Use the filesystem information from Lab 02.

Record:

Filesystem:

Partition:

Mount / Examination Method:

Relevant Deleted-File Structures:

Examples:

NTFS

Potentially relevant structures can include:

• Master File Table

• $Recycle.Bin

• metadata entries

• unallocated space

• file-record remnants

Linux Filesystems

Potentially relevant evidence may include:

• inodes

• directory entries

• trash folders

• unallocated space

• journal data

The exact recovery possibilities vary.

Part 7 — Review Recycle Bin / Trash Artifacts

Deleted files may first move into an operating-system-managed recycle or trash location.

Windows

Common location:

$Recycle.Bin

Linux Desktop Environments

Trash locations may exist under a user’s home directory.

For example:

~/.local/share/Trash/

depending on desktop environment.

The presence of such structures is normal.

Part 8 — Build the Recycle / Trash Register

Create:

Artifact	User	Original Name	Original Path	Deletion Time	Status

Do not fill fields unless the evidence supports them.

Part 9 — Understand Windows Recycle Bin Evidence

Modern Windows Recycle Bin entries often include metadata associated with:

Original Filename

Original Path

Deletion Time

File Size

The exact artifact structure depends on Windows version.

Your job is to record what the forensic tool or artifact actually shows.

Do not infer more than the artifact provides.

Part 10 — Identify Deleted Entries

Use the forensic tool provided in the lab to list deleted filesystem entries.

Possible training tools may include:

• Autopsy

• The Sleuth Kit

• FTK Imager

• another read-only forensic viewer

The workflow should remain:

Working Image
      ↓
Filesystem
      ↓
Deleted Entries
      ↓
Relevant Artifact

Do not work from the preserved original.

Part 11 — Build the Deleted Artifact Register

Create:

ID	Filename	Original Path	Size	Deletion Indicator	Recoverable
DEL-001
DEL-002

Classify recoverability as:

Complete

Partial

Metadata Only

Not Recoverable

Unknown

Part 12 — Select Relevant Deleted Files

Do not recover everything.

Use the investigation scenario.

Prioritize artifacts that are relevant to:

• known incident period

• case keywords

• suspicious downloads

• documents under investigation

• user activity

• application usage

• identified attack timeline

This supports evidence minimization.

Part 13 — Recover an Approved Training Artifact

Recover one designated deleted training file into:

Evidence/Recovered-Files/

Example naming:

DEL-001-recovered-document.bin

Do not replace the original filename without documenting both names.

Record:

Deleted Artifact ID:

Original Filename:

Original Path:

Recovered Filename:

Recovery Tool:

Recovery Date:

Investigator:

Part 14 — Hash the Recovered File

Run:

sha256sum Evidence/Recovered-Files/DEL-001-recovered-document.bin

Record:

Artifact ID:

SHA-256:

Size:

Recovery Status:

The recovered file is now derived evidence.

Part 15 — Maintain Evidence Lineage

Create:

E01 — Original Disk Evidence
        │
        ▼
E01-W01 — Working Image
        │
        ▼
DEL-001 — Deleted File Reference
        │
        ▼
REC-001 — Recovered Artifact

Every recovered artifact should be traceable back to the source evidence.

Part 16 — Verify the Recovered File Type

Use:

file Evidence/Recovered-Files/DEL-001-recovered-document.bin

Record:

Original Extension:

Recovered Filename:

Detected File Type:

Match:
Yes / No / Unknown

A recovered file may lack its original extension.

Use the file signature rather than the filename alone.

Part 17 — Understand File Carving

When filesystem metadata is incomplete, forensic tools may identify files based on recognizable signatures.

This is commonly called:

File carving

Conceptually:

Unallocated Data
      ↓
Known File Header
      ↓
Potential File Content
      ↓
Recovered / Carved Artifact

Carving can recover content without complete original metadata.

Part 18 — Understand Limitations of Carved Files

A carved file may lack:

• original filename

• original directory

• filesystem timestamps

• owner information

• full content

• correct ending

• surrounding context

Therefore:

Recovered Content
       ≠
Complete Original File Record

Document the difference.

Part 19 — Build the Recovery Status Register

Artifact	Recovery Method	Completeness	Original Metadata	Confidence
REC-001	Filesystem	Complete	Available	High
REC-002	Carving	Partial	Missing	Medium

Part 20 — Analyze Document Metadata

For a training document, metadata may contain fields such as:

Author

Title

Subject

Application

Created

Modified

Last Saved By

Use the approved forensic or metadata viewer.

Record only case-relevant fields.

Part 21 — Understand Metadata Carefully

Metadata can help answer:

What does the document itself say about its history?

But metadata may be:

• changed by applications

• removed

• copied

• manually edited

• altered through conversion

• inherited from templates

Therefore:

Metadata is evidence, not unquestionable truth.

Part 22 — Build the Document Metadata Register

Field	Value	Investigative Relevance	Confidence
Author
Created
Modified
Last Saved By
Application

Part 23 — Analyze Image Metadata

Training image files may contain metadata such as:

• creation information

• camera details

• software information

• dimensions

• timestamps

• EXIF fields

• GPS data where intentionally included in the lab

Do not assume all images contain metadata.

Part 24 — Handle Location Metadata Carefully

If a training image intentionally contains GPS coordinates, treat them as sensitive investigative data.

Record only what is necessary for the exercise.

In a real investigation:

location metadata requires careful privacy handling.

Part 25 — Build the Image Metadata Register

Field	Value	Relevance
Filename
Dimensions
Date/Time
Device
Software
GPS	If training evidence

Part 26 — Understand Filesystem Metadata vs Embedded Metadata

These are different.

Filesystem Metadata

Stored by the filesystem.

Examples:

Filename
Path
Size
Filesystem timestamps
Permissions

Embedded Metadata

Stored inside the file.

Examples:

Document author
Camera model
Document creation field
Editing software
EXIF timestamps

Compare the two rather than treating them as identical.

Part 27 — Compare Metadata Sources

Example:

Filesystem Modified:
10:20

while:

Document Last Modified:
10:05

This discrepancy may have legitimate explanations, such as:

• copying

• extraction

• download

• application behavior

• filesystem conversion

Do not automatically classify the difference as tampering.

Part 28 — Build a Metadata Comparison Matrix

Artifact	Filesystem Time	Embedded Time	Match	Explanation
REC-001

Part 29 — Understand Common Timestamp Categories

You may encounter:

Created

Modified

Accessed

Metadata Changed

Deleted

Different filesystems and applications define these differently.

Always record the timestamp type, not just the time.

Poor:

File time: 11:00

Better:

NTFS filesystem modification timestamp: 11:00

Part 30 — Create the Timestamp Register

Artifact	Timestamp Type	Time	Source
DEL-001	Deletion		Recycle artifact
REC-001	Modified		Filesystem
REC-001	Created		Embedded metadata

Part 31 — Normalize Timezone Context

Record:

Evidence System Timezone:

Investigator Timezone:

Timeline Standard:
Local / UTC

If timestamps come from different systems, normalize them before correlation.

Do not silently mix timezones.

Part 32 — Identify the Original Location

If the evidence provides it, record:

Original Filename:

Original Directory:

Full Original Path:

User Profile:

Evidence Source:

An original path can be highly valuable for understanding context.

For example:

Downloads

suggests a different context from:

Documents

But location alone does not prove how the file arrived there.

Part 33 — Original Location vs User Action

Avoid:

“The user downloaded the file because it was in Downloads.”

Instead:

“The deleted artifact’s original path was the user’s Downloads directory.”

Then seek browser or application evidence in later labs.

Part 34 — Determine the Deletion Indicator

Possible evidence may include:

Recycle Bin Metadata

Filesystem Deleted Flag

Missing Directory Reference

Unallocated File Record

Trash Metadata

Record exactly which artifact indicates deletion.

Part 35 — Distinguish Delete from Secure Erase

A normal delete and secure deletion are different.

Normal Delete
     ↓
Reference Removed
     ↓
Data May Remain

versus:

Secure Erasure
      ↓
Data Intentionally Overwritten / Removed

This lab does not perform secure deletion.

Part 36 — Understand Partial Recovery

You may recover a file that:

• opens partially

• has missing bytes

• lacks its ending

• contains corruption

• contains only fragments

Document:

Recovery Completeness:

Readable:

Missing Data:

Usable Metadata:

Limitations:

Do not describe a partial recovery as complete.

Part 37 — Build the Deleted File Evidence Matrix

ID	Deleted Ref	Original Path	Recovered	Metadata	Timeline Value
DEL-001	Yes	Known	Complete	Available	High
DEL-002	Yes	Unknown	Partial	Limited	Medium

Part 38 — Search Unallocated Space Conceptually

Deleted content may reside in storage areas marked available for reuse.

This is referred to as:

Unallocated space

Your forensic tool may allow inspection of this data.

Do not manually alter the image.

Part 39 — Understand Slack Space Conceptually

A file may not fill the final allocated storage unit completely.

The unused portion can sometimes contain residual data.

This concept is known as:

File slack

For this lab, understand the concept rather than conducting deep low-level recovery.

Part 40 — Correlate Deleted Files with Existing Files

Suppose:

Deleted:
draft-report.docx

and:

Existing:
final-report.docx

Compare relevant metadata.

Questions:

• Are the names related?

• Are the creation/modification times related?

• Are document authors the same?

• Is the final file newer?

• Is there evidence of document progression?

Do not claim one was derived from the other without sufficient evidence.

Part 41 — Correlate Hashes

If two recovered/existing files are identical, SHA-256 may establish that their content matches.

Example:

File A SHA-256:
ABC...

File B SHA-256:
ABC...

Conclusion:

Their hashed contents are identical at the time of hashing.

This does not by itself prove how one file was copied to the other.

Part 42 — Identify Duplicate Artifacts

Create:

File A	File B	Hash Match	Interpretation

Possible interpretation:

Identical Content

not automatically:

File B was copied from File A.

Part 43 — Build the Preliminary Deleted-File Timeline

Example:

Time	Artifact	Event Type	Evidence
09:12	report.docx	Created	Embedded metadata
09:45	report.docx	Modified	Filesystem
10:02	report.docx	Deleted	Recycle metadata

This is still a preliminary timeline.

Part 44 — Add Confidence to Timeline Events

Use:

Confirmed

Direct artifact provides the timestamp/event.

Supported

Multiple artifacts support the interpretation.

Possible

Evidence is incomplete.

Example:

Event	Confidence
File deletion timestamp	Confirmed
User manually deleted file	Possible

The second conclusion requires actor evidence.

Part 45 — Understand Deletion Attribution

A deleted artifact may tell you:

A file was deleted.

It may not tell you:

Exactly who deleted it.

To attribute deletion, you may need:

• user session evidence

• application logs

• shell history

• endpoint telemetry

• audit logs

• other correlated artifacts

Do not overstate attribution.

Part 46 — Create an Investigation Hypothesis

Example:

Hypothesis:
The training document was downloaded, modified, and later deleted during the incident period.

Now identify evidence required:

Download evidence

Filesystem timestamps

Document metadata

Deletion timestamp

User/session evidence

Do not promote the hypothesis to conclusion until the evidence supports it.

Part 47 — Build the Hypothesis Register

Hypothesis	Supporting Evidence	Contradicting Evidence	Status
File was deleted during incident	Recycle time	None	Supported
User X deleted it	None	Actor unknown	Unconfirmed

Part 48 — Example Deleted File Observation

Observation:
A deleted training document named finance-plan.docx was identified
in the user profile's recycle metadata.

Evidence:
The recycle artifact records the original path and deletion time.

Conclusion:
The evidence supports that the file existed at the recorded path
and was deleted at approximately the recorded time.

Limitation:
The artifact does not independently identify the person who
performed the deletion.

Part 49 — Example Metadata Observation

Observation:
Embedded document metadata lists "Lab User" as the author and
contains an internal document creation timestamp.

Interpretation:
The metadata provides additional context regarding the document's
history.

Limitation:
Embedded metadata can be modified and should be correlated with
filesystem and application evidence.

Part 50 — Example File Signature Finding

Finding:
Deleted file extension does not match recovered file content.

Observation:
The deleted artifact was named report.jpg, while file-signature
analysis identified the recovered content as a ZIP archive.

Investigative Relevance:
The mismatch warrants further examination of the artifact.

Conclusion:
The mismatch alone does not establish malicious intent.

Part 51 — Build the Deleted File & Metadata Evidence Register

Create:

ID	Artifact	Original Path	Deleted	Recovery	Metadata	Confidence
DF-01			Yes	Complete	Available	High
DF-02			Yes	Partial	Limited	Medium

Add:

• SHA-256

• timestamps

• relevance

• follow-up action

Part 52 — Build the Evidence Lineage Register

Derived ID	Parent Evidence	Source Location	Method
REC-001	E01-W01	Deleted entry	Filesystem recovery
CARVE-001	E01-W01	Unallocated	File carving
META-001	REC-001	Embedded metadata	Metadata extraction

Part 53 — Preserve Recovered Evidence

Recovered artifacts should not be casually edited.

Use:

Recovered-Files/

as preserved derived evidence.

If you need to open or process them, create an analysis copy where appropriate.

Part 54 — Hash Important Derived Evidence

For example:

sha256sum Evidence/Recovered-Files/REC-001.docx

Record hashes in:

Hashes/

This supports integrity during subsequent labs.

Part 55 — Reverify the Working Image

At the end of examination:

sha256sum Working-Copies/E01-working.dd

Compare with the pre-examination hash.

Record:

Pre-Examination Hash:

Post-Examination Hash:

Match:

Integrity Status:

Expected:

Match:
Yes

Part 56 — Mission Challenge

Complete the following for at least two deleted training artifacts.

CASE

Case ID:

Evidence ID:

Working Copy:

Hash Verified:


DELETED ARTIFACT 01

Deleted Artifact ID:

Original Filename:

Original Path:

File Size:

Filesystem:

Deletion Indicator:

Deletion Timestamp:

Recovered:
Yes / No / Partial

Recovered Filename:

Detected File Type:

File Extension Match:

SHA-256:

Filesystem Created Time:

Filesystem Modified Time:

Filesystem Accessed Time:

Embedded Metadata Available:

Author:

Embedded Created Time:

Embedded Modified Time:

Recovery Completeness:

Investigative Relevance:

Confidence:

Limitations:


DELETED ARTIFACT 02

Deleted Artifact ID:

Original Filename:

Original Path:

Deletion Indicator:

Recovered:

Metadata:

Relevant Timestamps:

SHA-256:

Investigative Relevance:

Confidence:


CORRELATION

Existing Related File:

Hash Match:

Related Metadata:

Timeline Relationship:

Supported Conclusion:


FINAL ANALYSIS

Deleted Artifacts Identified:

Fully Recovered:

Partially Recovered:

Metadata-Only:

Most Important Deleted File:

Most Important Metadata Field:

Most Important Timestamp:

Strongest Correlation:

Largest Evidence Gap:

Further Evidence Required:

Overall Conclusion:

Part 57 — What Not to Do

Do not:

Modify original evidence

Recover files directly into original evidence storage

Treat deletion as proof of malicious intent

Claim a user deleted a file without actor evidence

Assume metadata is always accurate

Assume file extension equals file type

Treat partial recovery as complete

Search unrelated private information

Alter recovered evidence without documentation

Lose parent-child evidence lineage

Ignore timezone context

Create unsupported timeline conclusions

The guiding principle is:

Recover carefully. Interpret cautiously. Correlate continuously.

Part 58 — Troubleshooting

Deleted File Is Not Recoverable

Record:

Recovery Status:
Not Recoverable

Possible reasons:

• content overwritten

• TRIM

• fragmented content

• incomplete image

• filesystem behavior

• secure deletion

• corruption

Do not force recovery.

Filename Exists but Content Does Not

You may have:

Metadata-only evidence

This is still useful.

Document what remains.

Recovered File Will Not Open

Check:

• file signature

• recovery completeness

• fragmentation

• corruption

Do not modify the recovered artifact just to make it open.

No Recycle Bin Record Exists

The file may have:

• bypassed the recycle mechanism

• been deleted through another process

• come from another operating system

• had metadata overwritten

Absence of recycle data does not prove the file was never deleted.

Timestamps Conflict

Check:

• filesystem timestamp type

• embedded metadata

• timezone

• copy/extraction effects

• application behavior

Document the discrepancy.

Metadata Is Missing

Record:

Embedded Metadata:
Not Available

Do not invent values.

Evidence Requirements

Capture:

Evidence 01

Working-image hash verification.

Evidence 02

Filesystem identification.

Evidence 03

Deleted Artifact Register.

Evidence 04

Recycle/trash artifacts.

Evidence 05

First deleted-file reference.

Evidence 06

First recovered artifact.

Evidence 07

Recovered artifact SHA-256.

Evidence 08

File-signature evidence.

Evidence 09

Document metadata.

Evidence 10

Image metadata where applicable.

Evidence 11

Filesystem timestamps.

Evidence 12

Original-path evidence.

Evidence 13

Second deleted artifact.

Evidence 14

Recovery Status Register.

Evidence 15

Metadata Comparison Matrix.

Evidence 16

Deleted-file timeline.

Evidence 17

Hypothesis Register.

Evidence 18

Deleted File & Metadata Evidence Register.

Evidence 19

Evidence lineage.

Evidence 20

Post-examination hash verification.

Mission Deliverables

Complete:

• working image verified

• lab workspace created

• filesystem confirmed

• recycle/trash artifacts reviewed

• deleted entries identified

• Deleted Artifact Register created

• relevant deleted files selected

• deleted artifacts recovered where possible

• recovered artifacts hashed

• file signatures checked

• recovery completeness documented

• document metadata analyzed

• image metadata reviewed where applicable

• filesystem vs embedded metadata compared

• timestamp types documented

• timezone context recorded

• original file locations identified where available

• deletion indicators documented

• related files correlated

• duplicate hashes compared

• preliminary deleted-file timeline created

• hypotheses separated from conclusions

• Deleted File & Metadata Evidence Register completed

• evidence lineage maintained

• working image integrity reverified

• final report completed

Lab Report Template

# Lab 03 — Deleted Files & Metadata Investigation

## Executive Summary

## Mission Objective

## Case Information

## Evidence Information

## Integrity Verification

## Filesystem Context

## Deleted Artifact Discovery

## Recycle / Trash Analysis

## Deleted Artifact Register

## File Recovery

## Recovery Status

## Recovered Evidence Integrity

## File Signature Analysis

## Document Metadata Analysis

## Image Metadata Analysis

## Filesystem Metadata

## Timestamp Analysis

## Original Location Analysis

## Metadata Comparison

## Deleted File Timeline

## Evidence Correlation

## Investigation Hypotheses

## Deleted File & Metadata Evidence Register

## Findings

## Limitations

## Recommended Follow-Up

## Conclusion

## Appendix A — Hashes

## Appendix B — Evidence Lineage

## Appendix C — Timeline

## Appendix D — Recovered Evidence Register

Knowledge Check

Question 1 — Does deleting a file always immediately erase its data?

No.

Depending on the storage system and subsequent activity, file content or metadata may remain recoverable.

Question 2 — What is logical deletion?

A condition where the filesystem stops presenting a file as active while some associated data or metadata may remain.

Question 3 — What is file carving?

Recovering file content by identifying known data signatures rather than relying entirely on filesystem metadata.

Question 4 — Does a recovered file always retain its original filename and path?

No.

Particularly with carved files, original metadata may be lost.

Question 5 — What does recycle/trash metadata potentially provide?

Depending on the platform, it may provide details such as original filename, path, size, and deletion time.

Question 6 — Can metadata be trusted absolutely?

No.

Metadata should be treated as evidence that requires context and correlation.

Question 7 — Does a deletion timestamp prove which user deleted the file?

No.

Actor attribution requires additional evidence.

Question 8 — Why compare file signatures with extensions?

Because extensions can be changed while the actual file structure may reveal a different format.

Question 9 — Why hash recovered artifacts?

To maintain integrity and traceability for the derived evidence.

Question 10 — What is the most important forensic rule for deleted-file analysis?

Distinguish what the evidence proves from what you think may have happened.

Skills Achieved

After completing this lab, you should understand:

• deleted-file fundamentals

• logical deletion

• deleted filesystem entries

• recycle/trash artifacts

• deleted-file recovery

• partial recovery

• metadata-only evidence

• file carving concepts

• unallocated-space concepts

• slack-space concepts

• file signatures

• document metadata

• image metadata

• filesystem metadata

• embedded metadata

• timestamp interpretation

• deletion timestamps

• original-path analysis

• recovery integrity hashing

• metadata correlation

• evidence lineage

• timeline reconstruction

• hypothesis management

• professional deleted-file reporting

Professional Takeaway

A deleted file is not simply:

“Something that used to exist.”

It can be a collection of forensic evidence:

Deleted Reference
      +
Original Path
      +
File Content
      +
Filesystem Metadata
      +
Embedded Metadata
      +
Timestamps
      +
Related Artifacts
      =
Investigative Context

But professional forensic analysis requires restraint.

A deletion timestamp may prove:

The artifact was recorded as deleted at a particular time.

It does not necessarily prove:

A specific person intentionally destroyed evidence.

The correct workflow is:

Identify → Recover → Verify → Examine → Correlate → Qualify → Conclude

The strongest investigator is not the person who tells the most dramatic story.

It is the person who can clearly explain:

what existed, what survives, what the evidence proves, and what remains unknown.

What’s Next?

➡️ Lab 04 — Windows Forensic Artifact Investigation

In the next lab, you will examine one of the richest forensic evidence sources in enterprise environments: the Windows endpoint.

You will investigate:

• Windows user profiles

• Event Logs

• authentication activity

• Registry artifacts

• Prefetch

• recent-file evidence

• shortcut files

• Jump Lists

• USB/device artifacts

• services

• scheduled tasks

• filesystem activity

• program execution evidence

• timeline relationships

• cross-artifact correlation

The methodology becomes:

User → Authentication → Execution → File Activity → Device Activity → System Change → Timeline → Correlation → Evidence

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

“What does the Windows endpoint evidence reveal about user activity, program execution, file access, device activity, and the sequence of events relevant to the investigation?”