28.7 Red vs Blue, Project and Real Incidents

By Ravindra Bagale Last updated: 27 September 2026

Chala mitrano, disk image, hash, write blocker, Autopsy, chain of custody, Section 65B awareness – aata Purple Team loop. Red lab madhe anti-forensics awareness (wipe / quick reboot / "just reinstall") dakhavto – pan kadhihi dusryacha data nahi; Blue pahila image + hash + custody log, copies var Autopsy, original untouched. Tumhi Sahyadri Traders style OWN USB/VM disk madhe build → hack → fix karun Purple report liha. Purava jopasun; fix + prove = career. Samjla ka? Dusryacha phone/USB/laptop – kadhi nahi.

Red Team vs Blue Team – digital forensics

Red team (attacker) does	Blue team (defender) detects / stops
Panic wipe / format / "just reinstall Windows" after a scare	Preserve first: isolate, then bit-for-bit image before rebuild
Reboot immediately (RAM volatile evidence gone)	Capture memory when policy/tools allow; document why if you cannot
Anti-forensics awareness: timestomp, secure-delete concepts (OWN lab only)	Write blocker / read-only mount; never analyse the original media
Plant or hide files, then delete (recycle / `rm`) on OWN USB	Image with `dd`/`dc3dd`, hash before and after, Autopsy on the copy
Dispute "this USB was swapped" with no paperwork	Chain-of-custody log: who held media, when, hash values, sealed bag notes
Claim "logs prove nothing" without integrity	Hash (MD5/SHA-256) + Section 65B awareness for electronic records (no legal advice – verify current rules)

Defender chi simple checklist: isolate → write-protect / write-blocker → image (dd/dc3dd) → hash (before + after) → analyse ONLY the copy (Autopsy/TSK) → custody log → report → then rebuild. Wipe = last step after evidence plan, not first panic. Interview madhe "I deleted malware and rebooted" peksha "I imaged and hashed the disk, recovered evidence on a copy, documented custody, then rebuilt" jast strong.

# OWN lab only – practice USB or VM disk YOU own (example host-only helper 192.168.56.20)
mkdir -p ~/labs/sahyadri-forensics
# 1) Plant a known deleted file on YOUR practice USB/VM disk (example idea):
#    echo 'Sahyadri secret lab note – DELETE ME' > /mnt/practice-usb/deleted-note.txt
#    sync; rm /mnt/practice-usb/deleted-note.txt
# 2) Image the practice device (DOUBLE-CHECK if= and of= – wrong of= destroys data):
#    sudo dc3dd if=/dev/sdX of=~/labs/sahyadri-forensics/usb.img hash=sha256 log=~/labs/sahyadri-forensics/dc3dd.log
#    # or: sudo dd if=/dev/sdX of=~/labs/sahyadri-forensics/usb.img bs=4M status=progress
# 3) Hash the image (Blue integrity proof):
sha256sum ~/labs/sahyadri-forensics/usb.img | tee ~/labs/sahyadri-forensics/usb.sha256
# 4) Open the IMAGE (not the USB) in Autopsy / TSK; try to recover deleted-note.txt
# 5) Custody notes (fill by hand in the same folder):
cat > ~/labs/sahyadri-forensics/custody.txt << 'EOF'
Case: Sahyadri Traders lab practice
Media: OWN practice USB/VM disk
Image: usb.img
SHA-256: (paste from usb.sha256)
Handler: (your name) – date/time acquired – sealed/stored where
EOF
# Amazon Linux helper VM (if you use one for notes/tools): package style
#   sudo yum install -y Autopsy   # only if packaged for your AMI; else use Kali GUI Autopsy
#   sudo service <helper> status  # confirm services you run stay up; never image the wrong disk

Ravindra Bagale's Tip

Students pahila reboot / format kartat – RAM ani volatile logs gayle. Dusri chuk: original USB Autopsy madhe mount karun "analyse" – original change hoto, court/report madhe integrity debate. Rule: OWN media only → write-blocker/read-only mindset → image + hash → Autopsy on copy → custody log same day → rebuild later. Forensics chapter = patience chapter. Ghabru naka, process ne yetay.

Lab

Swatahcha practice USB kiwa lab VM disk ghyayla. Ek known file create → delete. dc3dd/dd ne image, sha256sum donhi vela (image create nantar + Autopsy adhi). Autopsy case madhe deleted file recover karun screenshot/notes ~/labs/sahyadri-forensics/. Custody.txt bhara. Public/friend cha phone nahi. Wrong of= – kadhi nahi; command donhi vela vacha.

Project: Build it, hack it, fix it

Build: For fictional Sahyadri Traders (Pune) on a practice USB or VM disk you own:

Create a small "incident" story: e.g. staff USB left on desk; plant deleted-note.txt with a known string, then delete it
Prepare custody template + hash worksheet before you touch imaging tools
Ethics card: OWN media only; no examining family/friend devices "for practice"; IT Act / privacy reminder

Hack (lab awareness – OWN systems only): From Kali 192.168.56.10 (or your forensics workstation):

Demonstrate what a hurried responder might do wrong (concept only): reboot / format would destroy your planted trail – do not wipe the evidence disk until after imaging
Optional anti-forensics awareness on OWN copy only: note how deletion hides names in the folder view but content may remain recoverable
Do not run wipers on anything you still need; the "hack" here is the attacker/sloppy-IR mindset you will defeat with Blue process

Do not image third-party phones, do not take workplace disks home, do not publish real customer data in reports.

Fix (Blue forensics process):

Isolate the practice media; use write-blocker or read-only habits
Bit-for-bit image with dd/dc3dd; record SHA-256 of the image
Open only the image in Autopsy; recover the deleted note; export a short HTML/PDF report
Fill chain-of-custody; note Section 65B awareness for electronic records (verify current Indian Evidence Act guidance – this book is not legal advice)
After evidence pack is complete: rebuild/wipe the practice USB if you want a clean shop device

Re-verify: Second hash of usb.img matches the first; Autopsy still shows the recovered file on the image; custody log has no gaps. 1-page Purple report for owner Shraddha: finding → risk of panic-wipe → image/hash/Autopsy/custody fix → evidence. Peer-review with Amir / Ravina. IT Act: only systems and media you own or are authorised to examine.

Real incident: Sony Pictures Entertainment wiper attack (2014)

In November–December 2014, Sony Pictures Entertainment suffered a destructive intrusion publicly linked to wiper malware (reported under names such as Destover / related tooling) that overwrote master boot records and data, while attackers also leaked stolen internal files. FBI and US-CERT style alerts described malware capable of making recovery with ordinary forensic methods extremely difficult or costly once wiping completed. Weakness: deep network compromise plus destructive payload that attacks the evidence itself – so "we will just look at the disk later" fails if the disk was wiped. What would have reduced impact: earlier detection and containment, segmented backups offline from the wiped estate, IR playbooks that image critical systems before mass rebuild where still possible, and hardened privileged access so wipers cannot reach every host. Lab lesson: your Sahyadri project practices image-then-analyse because real incidents may try to erase the crime scene. Source: FBI FLASH / US-CERT indicators and major technical reporting on the 2014 Sony Pictures wiper (2014); verify current summaries.

Real incident: NotPetya and Maersk – preserve and recover (2017)

In June 2017, NotPetya spread widely (publicly tied in reporting to a compromised Ukrainian accounting-software update ecosystem) and hit many organisations including shipping giant Maersk. Analyses described NotPetya as destructive (wiper-like) rather than reliable ransomware for paying to unlock. Maersk publicly and in later CISO talks described a near-total Windows estate outage and a rebuild measured in reported costs of hundreds of millions of dollars; recovery famously depended on a domain controller that had been offline (power outage) and thus escaped infection – a clean identity source to rebuild from. Weakness: flat trust and identity systems that let a wipe race across the estate, plus recovery plans that assumed not every domain controller would die together. What would have reduced it: network segmentation, offline/immutable backups of identity and critical data, tested IR rebuild drills, and a habit of preserving forensic images of representative hosts before mass reimaging when investigating how the wipe arrived. Lab lesson: panic format without imaging loses both business data and the story of the attack; Blue preserves, then rebuilds. Source: contemporaneous CERT/vendor advisories, Wired and major outlet NotPetya reporting, and public Maersk post-incident talks (2017); verify current summaries.

Interview model (clean English): "On my own practice USB I plant a known deleted file, image the media with dd or dc3dd, record SHA-256, recover the file in Autopsy on the copy only, and document chain of custody before any rebuild."

Thodkyaat: forensics shika, pan image + hash + custody + Autopsy-on-copy shika. Aata pudhe OWASP Top 10 – web app defects. Chala pudhe, mitrano!

Thodkyaat sangaycha tar

Digital forensics identifies, preserves, analyses and presents digital evidence in a documented, reproducible way.
Core rules: never touch the original, work on a bit-for-bit image, prove integrity with hashing, keep chain of custody, use a write blocker.
Types: disk, memory, network and mobile; deleted files and RAM contents are often recoverable.
Image disks with dd/dc3dd (double-check if=/of=); examine with The Sleuth Kit and Autopsy.
Forensics is part of incident response; in India, integrity and a Section 65B certificate keep evidence admissible.

Samjla ka? He hote Part 10 – Kali ani tila tools. Aata Part 11: ethical hacking cha purna course, OWASP Top 10 pasun suru. Chala pudhe, mitrano!