Labs · Cyber Security

Lab: Collect Evidence Safely: Hash Files with SHA-256, Prove Nothing Changed, and Build a Timeline from Logs

By Ravindra Bagale Last updated: 8 October 2026

Beginner40 minsha256sum (Linux), shasum (Mac) or Get-FileHash (Windows PowerShell) · Text editor · Spreadsheet (optional)

Course: Cyber Security · Chapter 28: Introduction to Digital Forensics

Chapter 28 introduces digital forensics; this lab practises the two first habits of every investigator: hash the evidence and build a timeline.

Download evidence_pack.zip (3 sample files)

Chala mitrano! In forensics, two habits come first. One: prove the evidence was not changed, using a hash, a fingerprint of the file. Two: put events in time order, because the story only makes sense on a timeline. Today we do both with a small sample evidence pack. Chala, investigator banuya!

Suppose we are…

Suppose we are on the incident response team at Lenskart. At 09:15 IST store operations reports that a customer order export appeared on a public paste site. The server team has copied the logs from the shop's admin server web01. Our job: secure the evidence so nobody can later claim it was edited, and build a timeline of what happened. (All data in the pack is sample data with reserved IP addresses.)

Goal of this lab

By the end you will be able to:

Verify a downloaded file against a published SHA-256 hash.
Hash every evidence file, then prove a working copy is identical with sha256sum -c.
Build a timeline from an SSH log and a web access log and answer "what happened, when, from where".

What you need (all free)

Your own laptop: Linux, Mac or Windows (PowerShell).
The sample evidence pack below. About 40 minutes.

Download evidence_pack.zip

Safety and ethics

Practise only on this sample pack or on your own systems. Real evidence must be collected by authorised people, with permission, and handled with a written chain of custody (who had it, when, and what they did).

Part 1: verify and hash

Hash the downloaded zip. Linux: sha256sum evidence_pack.zip · Mac: shasum -a 256 evidence_pack.zip · Windows PowerShell: Get-FileHash .\evidence_pack.zip -Algorithm SHA256

What you should see: aaa3eec05b37ef090255cea61111e9ce65cdf6845228650bb57f2c9e3cd5834d. If even one character differs, the file is not the original.
Start a chain-of-custody note in a text file custody.txt: your name, date and time, "downloaded evidence_pack.zip, SHA-256 aaa3eec0…834d, verified".
Extract the zip. You get a folder evidence_pack with 3 files.

Hash every file and save the result. Linux (on Mac use shasum -a 256 instead of sha256sum):

cd evidence_pack && sha256sum * > ../hashes.txt && cd ..
cat hashes.txt

Windows PowerShell:

Get-ChildItem .\evidence_pack | Get-FileHash -Algorithm SHA256 | Format-Table Hash, Path -AutoSize | Out-File hashes.txt

What you should see: three lines, one 64-character hash per file. web01_auth.log starts with 80e61322.

Make a working copy, so the original is never touched: copy the evidence_pack folder to a new folder named working.
Prove the copy is identical. Linux (Mac: shasum -a 256 -c ../hashes.txt):
```
cd working && sha256sum -c ../hashes.txt && cd ..
```
What you should see: ticket_INC-2026-1006.txt: OK, web01_auth.log: OK, web01_nginx_access.log: OK. On Windows run Get-ChildItem .\working | Get-FileHash -Algorithm SHA256 and compare each hash with hashes.txt.
See what a change does: add one space to working/web01_nginx_access.log, save, and hash it again.

What you should see: a completely different hash. One space changes everything; that is why hashes prove integrity.

Part 2: build the timeline

Open ticket_INC-2026-1006.txt (what was reported), then web01_auth.log and web01_nginx_access.log from the original folder (read-only viewing is fine).
Make a table: Time (IST), Source log, Event, IP/User. Add one row per important line and sort by time.

What you should see: the SSH log events at 02:15–02:24 come before the web events at 02:25–02:40, from the same IP 203.0.113.77.
Answer four questions in your notes: When did the attacker first succeed? What did they do to stay in (persistence)? What data left the server, and how big was it? What tool did they use for the web requests?

Check your answer

02:15:13 SSH password login as deploy from 203.0.113.77 succeeded after failed attempts. 02:18:13 created user support2 and 02:18:33 added it to sudo (persistence). 02:26:30 logged in to /admin, 02:27:03 downloaded /admin/orders/export.csv, 1,843,302 bytes (about 1.8 MB): the leaked file. User-Agent curl/8.5.0 shows a command-line tool, not a browser. Logout at 02:40:09; reported at 09:15.
Add your timeline and answers to custody.txt with the time you finished.

Ravindra Bagale's Tip

Always write the time zone. These logs are in IST; many cloud logs are in UTC, 5 hours 30 minutes behind. Mixing them makes a wrong story. And never work on the original, always on a hashed copy. Original jasa cha tasa!

Common mistakes

Mistake	What happens	Fix
Opening and saving the original log in an editor	Its hash changes and the evidence is questionable	Work only on the copy; hash before and after
Comparing only the first few characters of a hash	Two different files can look similar at a glance	Compare the full 64 characters (or use `sha256sum -c`)
Mixing IST and UTC times	Events appear in the wrong order	Write the time zone on every row
Using MD5 for new work	MD5 is broken for integrity	Use SHA-256
No notes on who did what	The chain of custody is broken	Keep `custody.txt` updated

Self-check checklist

The zip's SHA-256 matched the published value.
I saved hashes.txt for all three files.
I proved my working copy matched, and saw a hash change after an edit.
My timeline has times with time zone, source, event and IP/user.
I answered the four questions.

0 of 5 done

Try-at-home challenge

Your timeline shows support2 was added to sudo. Write the three containment actions you would recommend first, in order, and explain why the order matters.

Check your answer

1) Preserve: take a disk snapshot/backup of web01 first, so evidence survives. 2) Contain: lock support2 (usermod -L, remove from sudo) and change the deploy password, switch SSH to keys only, block 203.0.113.77. 3) Check scope: look for other new users, SSH keys, cron jobs and changed files. Preserving first means containment does not destroy the clues.

Samjla ka? Hash first, work on a copy, and let the timeline tell the story. Aata pudhe jaauya: Chapter 29 fixes a real bug in code.