28. Introduction to Digital Forensics

By Ravindra Bagale Last updated: 15 October 2026

Chala mitrano, Part 10 cha shevatcha chapter – digital forensics. Aataparyant aapan attack ani defence shiklo. Pan ghatna ghadun geli tar? Koni kela, ksa kela, kay gela – he shodhne mhanje forensics. He mhanje digital detective cha kaam: purava (evidence) gola karne, to kharab na hou deta tapasne, ani report banavne jo court madhe suddha chalel. Ha ek changla career marg pan aahe. Aaj basics baghu – concepts ani Autopsy tool. Sagle fakt tumchya swatahchya lab data var. Samjla ka? Chala!

What you will learn in this chapter

What digital forensics is and where it is used
The core principles: preserve, chain of custody, work on copies
Types: disk, memory, network and mobile forensics
Key ideas: disk images, hashing for integrity, write blockers
Autopsy and The Sleuth Kit (introduction)
Where forensics fits in incident response and a note on Indian law

Lab scope for this whole chapter

Practise only on your own disks, images and files, or on deliberately shared practice images. Examining someone else's device or data without authorisation breaches privacy law and the IT Act. Real investigations are done by authorised people following legal process.

Concepts in this chapter

The chapter recap is at the end of the last concept page.

Chapter 28: Introduction to digital forensics — practice tasks

Open chapter lessons · Full guided lab: hash evidence sha256 build timeline (not repeated here)

28.1 Hash evidence before you open it

EasyIT

Why: A changed hash means the file changed.

What: Hash a sample evidence file twice.

How:

echo 'case note' > evidence.txt; sha256sum evidence.txt | tee hash1.txt
Copy the file; hash again; compare.

Expected output: Both hashes match.

Hint

Always hash before analysis.

Answer / how to check

diff hash1.txt hash2.txt is empty.

28.2 Build a simple timeline

MediumBanking

Why: Order of events proves what happened.

What: Use the data file to sort events.

Data file: events.csv

Time	Event
10:01	Failed SSH from 203.0.113.7
10:05	Successful SSH as ravi
10:12	scp of customers.csv
10:15	USB device mounted

About this file: Made-up event list. Each row is one event. Columns: Time = clock time; Event = what happened.

How:

Sort by time.
Write a 4-line story.

Expected output: Login fail → success → file copy → USB mount.

Hint

ISO times sort correctly as text.

Answer / how to check

Story matches the sorted order.

28.3 Read file metadata

EasyLogistics

Why: Metadata shows created/modified times.

What: Inspect a photo or PDF you own.

How:

Linux: stat file.pdf or exiftool file.jpg.
Note Created, Modified, Author if present.

Expected output: Times and optional Author.

Hint

Don't trust times alone — clocks can be wrong.

Answer / how to check

You recorded at least two timestamps.

Extended teaching notes

Why this lesson matters

Use this lesson to strengthen systems you own: understand the risk, practise safely in a lab, then write and apply the fix.

Apply the fix across stacks

Same class of bug, same idea in every language.

Java / Spring Boot

Parameterise queries, encode output, CSRF tokens, limited Actuator, dependency scanning.

ASP.NET Core

EF Core / parameterised SQL, Razor encoding, HTTPS, Data Protection.

Node.js / Express

helmet, parameterised SQL, npm audit, avoid eval and shell concat.

Python / Django / Flask / FastAPI

ORM, autoescape, pip-audit, Bandit; never shell=True with user input.

PHP / Laravel

PDO/Eloquent, Blade escaping, composer audit.

Go / Ruby

database/sql placeholders / ActiveRecord; html/template / ERB escaping; govulncheck / Brakeman.

nginx / Apache / Tomcat

Hide versions, TLS, security headers, least-open ports.

MySQL / PostgreSQL / MongoDB / Redis

Private networks, auth on, least-privilege users, no 0.0.0.0/0.

AWS / Azure / GCP

Roles not long-lived keys, private data stores, cloud audit logs on.

Mini case study

Suppose we are on a purple-team exercise for an Indian mid-size company (sample data). Red notes a technique from this lesson against a lab clone. Blue must show the control that stops it, the log that would have fired, and the ticket that hardens production. That is the standard this course trains you for.

Defender's worksheet (do this today)

Write the lesson title, date and the exact lab target you are allowed to use.
List three owned systems (VMs, apps, or cloud accounts) where this lesson applies.
Run one safe check from the lesson on a lab system only. Paste the command and output.
Write a two-sentence fix you would give a teammate.
Name one related public advisory (CERT-In, CISA, NVD, or a vendor bulletin) with its date.

Indian workplace (sample data)

Suppose we are a junior analyst at Infosys, TCS, Wipro or a fintech SOC in Bengaluru/Pune. Turn this lesson into one checklist item with an owner, a due date and a place to store evidence (ticket + screenshot).

Global practice

Compare your notes with OWASP, CIS Benchmarks, NIST CSF/IR guidance or a cloud Well-Architected security question. Write five lines on what overlaps.

Everyday analogy

Explain the risk and the fix to a family member without jargon. If they can repeat the warning, you understand it well enough to teach juniors.

Key terms

Control: a safeguard (patch, config, process, detection).
Finding: a weakness backed by evidence.
Remediation: the fix plus how you verified it.
Scope: systems you have written permission to touch.
Least privilege: only the access the task needs.
Defence in depth: several layers so one failure does not end the story.

Common mistakes

Skipping written permission "just for a quick scan".
Practising on hostel, office or public targets without authorisation.
Collecting tool output without writing the fix.
Copying attack steps onto production to "verify". Defenders verify with versions, configs and patches.
Publishing screenshots that contain secrets, cookies or internal hostnames.

Recap

Evidence, fix, owner, date.
Own lab only.
Fix > spectacle.