18.7 Red vs Blue, Project and Real Incidents

By Ravindra Bagale Last updated: 27 September 2026

Chala mitrano, ethics ani lab chapters madhe aapan kayda aani host-only isolation shiklo. Aata Purple Team najrene ekda jodun gheuya: Red kay chukun karto, Blue kay rokto, tumhi OWN lab madhe kay build → hack → fix karta, ani real incidents kay shikvtat. He lakshat theva – CEH exam modules pan authorization first sangtat.

Unauthorized scanning vs ethical path – fark ekdum clear: permission + defined scope + logging + isolation. Criminal path ani ethical path madhe tool same asel – discipline vegla aahe. "Bas practice aahe" mhanun classmate laptop kiwa institute Wi-Fi scan karne = risk. Samjla ka?

Red Team vs Blue Team – permission, scope, isolation

Red team (attacker) does	Blue team (defender) detects / stops
Scans classmate laptops / institute Wi-Fi "for practice" without written permission	Written scope + host-only only; refuse out-of-scope; IT Act awareness (s. 43 / 66 – verify current text)
Bridges Metasploitable / DVWA so the weak VM reaches the internet or LAN	Adapter check before every session: vulnerable VMs = host-only; prove with `ip a` + ping tests
Runs tools with no engagement letter, no logging, no snapshot	Pre-engagement checklist (18.6); `script` logging; clean snapshots; signed fictional scope note
Treats "I am a student" as a legal shield	Same action without permission = unauthorized access risk; with signed scope + isolation = ethical path
Skips patching Kali / leaves weak lab VMs forever online on bridged NIC	Snapshot + update habit; lab VMs powered off when unused; never expose practice targets publicly
Copies exploits from random sites onto a bridged practice VM	Keep practice targets off the real LAN; snapshots before experiments; review what you run

Why host-only + snapshots matter (classroom reminder): Host-only mhanje Kali ani Metasploitable fakt ekmekaishi boltat – gharacha Wi-Fi / college LAN / internet var weak services disat nahi. Snapshot mhanje "undo button" – chuk zali tar clean state. Bridged adapter = tumcha deliberately weak lab LAN var open invitation. Ghabru naka – checklist follow kela ki safe.

# OWN VirtualBox / VMware – prove Metasploitable is host-only only
# On the vulnerable VM (192.168.56.20):
ip a
# Expect ONLY a host-only adapter (e.g. eth0 → 192.168.56.20), NOT a second bridged IP
ping -c 2 192.168.56.10    # Kali should reply
ping -c 2 8.8.8.8          # should FAIL if truly isolated (no default route / no NAT)
# On Kali:
ip a
ping -c 2 192.168.56.20    # should work on host-only
# On the hypervisor GUI: Adapter 1 = Host-only; Adapter 2 = Not attached
# Optional Amazon Linux helper in the same host-only net:
# sudo yum update
# sudo service sshd status

Allowed lab IPs (fictional Raja-Rani / Sahyadri style): Kali 192.168.56.10, Metasploitable 192.168.56.20, optional AD 192.168.56.30, optional IoT/helper 192.168.56.50. Baherche IP = out of scope. Always.

Ravindra Bagale's Tip

Many students start with "just one nmap on my classmates" – and then there's trouble. Both your career and the law are at risk. There's only one rule: written permission + host-only lab. Forgetting the snapshot is also a common mistake – an experiment breaks the lab. Clean snapshot = one-click rollback. Running tools without an engagement letter = red flag. Remember this, friends.

Practice task

Tumchya notebook madhe 1-page Pre-Session Ethics Card banva (Raja-Rani Traders fictional engagement style):

In-scope IPs only: 192.168.56.10 / .20 (optional .30 / .50)
Out-of-scope: everything else – classmates, institute Wi-Fi, public IPs
Snapshot names (Kali + Metasploitable clean)
script log path under ~/labs/
Signature line for you + study buddy (Shraddha / Ruhi / Shahrukh / Amir)

Mag Red vs Blue table madhun 3 rows pick karun "how Blue stops it in my lab" column bhara. Pair with Zoya or Salman (study buddy) – ek ethics question, ek lab-isolation answer.

Project: Build it, hack it, fix it

Build (deliberately weak lab hygiene – YOUR machines only): For fictional Raja-Rani Traders (Nashik warehouse IT practice), create a short fake engagement letter in ~/labs/raja-rani-scope.txt:

Owner Rani authorises testing only host-only range 192.168.56.0/24
Targets: Kali 192.168.56.10 and Metasploitable 192.168.56.20
Explicit bans: no internet targets, no classmate devices, no bridged weak VMs

Then intentionally misconfigure the lab the way a BAD student might: attach a bridged (or second NAT) adapter to Metasploitable so it gets a LAN/routable address in addition to host-only. Document both IPs with ip a. Take snapshot pre-scope-violation.

Hack (lab demo of the mistake – not a real attack on others): From Kali, show that the weak VM is now reachable on an unexpected interface; from the host, note that a bridged practice VM can be discovered by others on the same LAN. Do not scan any real third-party host. Goal = prove why bridged vulnerable VMs are dangerous.

Fix: Remove bridged/NAT from Metasploitable and DVWA; leave host-only only; power off when idle; keep the engagement letter and checklist. On Amazon Linux lab helpers if any: sudo yum update and sudo service <name> status – never expose practice services on 0.0.0.0/0.

Re-verify: ip a on .20 shows only 192.168.56.20; ping 8.8.8.8 fails from the vulnerable VM; Kali still reaches .20 on host-only; your scope file lists exact IPs. Purple note: Red showed how one wrong adapter turns a teaching VM into a LAN risk; Blue proved isolation + written scope + snapshots.

Real incident: WannaCry ransomware wave (2017)

In May 2017, the WannaCry ransomware campaign spread widely by exploiting unpatched Windows SMB systems (EternalBlue-class vulnerability). Hospitals and enterprises that had not applied available patches, and that lacked network segmentation, were hit hard – reported disruption included the UK NHS among many others. Weakness: missing patches + flat networks that let worm-like spread move laterally. What would have stopped / reduced it: timely patching, disabling unnecessary SMBv1, network isolation between critical and user segments, offline backups, and least-privilege exposure of file shares. Lab lesson for us: never bridge a deliberately weak practice VM onto a real LAN, keep snapshots, and treat isolation as safety – the same hygiene that stops worm spread. Source: public NCSC / NHS and major vendor post-incident summaries; Microsoft security advisories on the related SMB fixes (verify current docs).

Real incident: Unauthorized access cases and IT Act awareness

Across many jurisdictions, people who accessed or tested systems without authorisation have faced criminal investigation – even when they claimed a research or "student practice" motive. In the US, the Computer Fraud and Abuse Act (CFAA) is frequently cited in such prosecutions; in India, the IT Act, 2000 (sections such as 43 and 66 – always verify the current text) addresses unauthorized access and related acts, with reporting via cybercrime.gov.in, 1930, local cyber cells and CERT-In (s. 70B). Exact case facts differ; the pattern is consistent: permission and scope decide legality. What stops the career-ending mistake: written authorisation, defined IP ranges, isolated labs, and refusing classmate / institute / random internet targets. Source: public DOJ CFAA materials; MeitY / IT Act text; CERT-In and cybercrime.gov.in guidance (verify before quoting section numbers in exams or jobs).

Interview model (clean English): "I only run offensive tools inside an isolated host-only lab I own, against targets listed in a written scope note. I keep snapshots and session logs. Without written permission, the same scan is unauthorized access – I treat that as a hard stop."

Aata pudhe scanning chapter – pan ethics card pocket madhe theva. Chala mitrano!

Thodkyaat sangaycha tar

The one rule: written permission and a defined scope – the same action is a crime without it and a profession with it.
IT Act 2000: s. 43 (civil) lists the acts; s. 66 (criminal) is those acts done dishonestly/fraudulently; know 66B–66F, 65, 70, 72 too, and verify the current text.
Report cyber crime via cybercrime.gov.in, the 1930 helpline, local cyber cell and CERT-In (s. 70B).
Build an isolated lab: Kali + Metasploitable 2 + DVWA + Juice Shop on a host-only network, never bridged.
Kali is just Debian Linux: update it, change the password, unzip rockyou.txt, keep organised notes.
Run the pre-engagement checklist and take clean snapshots before every session.

Samjla ka? Kayda aani lab tayar aahet – aata aapan pahila khara step ghevu: information gathering aani scanning. Chala pudhe, mitrano!