24.6 Red vs Blue, Project and Real Incidents

By Ravindra Bagale Last updated: 27 September 2026

Chala mitrano, tcpdump, Wireshark, Follow TCP Stream, HTTP leak, ARP spoof concept – aata Purple Team loop. Red lab madhe host-only HTTP login cha password stream madhe dakhavto; Blue HTTPS/TLS, HSTS, cleartext services band, DAI/port security, arpwatch/IDS ani VPN lavto. Tumhi Sahyadri Traders style OWN lab madhe build → hack → fix karun Purple report liha. Capture awareness; fix + prove = career. Samjla ka?

Red Team vs Blue Team – sniffing and MITM awareness

Red team (attacker) does	Blue team (defender) detects / stops
`sudo tcpdump -i eth0 -n -A port 80` or Wireshark capture on host-only	Force HTTPS/TLS end to end; redirect HTTP→HTTPS; HSTS where the app supports it
Display filter `http.request.method == "POST"` + Follow TCP Stream to read lab password	Disable cleartext login services; never send secrets over plain HTTP
`arpspoof` / MITM concept so traffic passes through attacker on same L2	Dynamic ARP Inspection + port security on switches; static ARP for critical hosts
Sniffs cafe / shared Wi-Fi cleartext sessions	VPN on untrusted nets; user training: lock chinh / HTTPS only for logins
Leaves long promiscuous captures on shared adapters	Written scope; host-only lab only; IT Act 43/66 reminder; delete captures after lab
Relies on old HTTP apps years after TLS became default	Continuous inventory: find `:80` logins, Certbot/TLS, reverse-proxy terminate TLS

Defender chi simple checklist: HTTPS everywhere → kill cleartext logins → arpwatch/DAI → VPN on untrusted nets → prove HTTP password no longer visible. Capture tools Kali/Wireshark var; bachav TLS ani switch controls Blue var. Interview madhe "I saw the password in Follow TCP Stream" peksha "I forced HTTPS and re-captured to prove the secret stayed encrypted" jast strong.

# OWN host-only only – Kali 192.168.56.10 → Metasploitable/DVWA 192.168.56.20
mkdir -p ~/labs/sahyadri-sniff
# Capture HTTP login (lab target already taught – DVWA or Metasploitable web):
sudo tcpdump -i eth0 -n -s 0 -w ~/labs/sahyadri-sniff/http-login.pcap \
  'host 192.168.56.20 and tcp port 80'
# In another terminal: browse http://192.168.56.20/ (or DVWA) and submit a lab login
# Then Wireshark: open pcap → filter http.request.method == "POST" → Follow TCP Stream
# Defender prove (after you enable HTTPS on a helper you control, e.g. .50 or Certbot path from Ch.13):
#   sudo tcpdump -i eth0 -n -w ~/labs/sahyadri-sniff/https-login.pcap 'host <https-host> and tcp port 443'
#   Wireshark shows Encrypted Application Data – password NOT readable
# Optional Blue notes on lab notes page:
#   - arpwatch / IDS alert on sudden MAC-IP change
#   - DAI + port security on real switches (document – may not run in VirtualBox host-only)
#   - VPN when on untrusted Wi-Fi

Ravindra Bagale's Tip

Students sagla interface capture kartat (GB bhar pcap) ani mag password shodhat basatat – filter visartrat. Dusri mothi chuk: cafe/college Wi-Fi var "practice" sniffing. Rule: host-only only → filter host/port 80 → Follow TCP Stream once → write HTTPS fix → delete or lock the pcap. Capture tool shikne = TLS ani scope shikne. Ghabru naka, practice ne yetay.

Lab

Kali 192.168.56.10 var tcpdump/Wireshark ne Metasploitable or DVWA 192.168.56.20 cha HTTP login POST capture kara. Follow TCP Stream madhe lab username/password plain text dakhavla – screenshot/notes ~/labs/sahyadri-sniff/. Mag kontya hi HTTPS site (lab Certbot helper kiwa known https://) var login attempt compare kara – fakt Encrypted Application Data. 5 lines liha: HTTPS, HSTS idea, cleartext off, arpwatch/DAI, VPN. Public/cafe network var nahi.

Project: Build it, hack it, fix it

Build: For fictional Sahyadri Traders (Pune) sniffing lab on host-only:

Keep Metasploitable / DVWA-style HTTP login reachable at 192.168.56.20 (already in earlier chapters)
Optional: simple cleartext PHP login on helper .50 if you already run a lab web stack there
Ethics card + host-only only (no bridged sniffing of other people)

Hack (lab awareness only): From Kali 192.168.56.10:

sudo tcpdump -i eth0 -n -w http-login.pcap 'host 192.168.56.20 and port 80' while you POST a lab login
Open in Wireshark → http.request.method == "POST" → Follow TCP Stream → note password visible
ARP spoof: concept only as already shown in 24.5 – if you demo arpspoof, only between your own lab VMs, then stop forwarding and restore ARP

Do not sniff cafe/neighbour traffic, do not keep pcaps with real personal passwords, do not ARP-spoof production switches.

Fix:

Force HTTPS/TLS on any web app you control (Certbot / reverse proxy – Chapter 13 path); redirect HTTP to HTTPS
HSTS where the stack supports it; disable plain HTTP login listeners
Document Blue controls: DAI + port security on real switches; arpwatch/IDS for MAC-IP flaps; VPN on untrusted nets
On Amazon Linux helpers you own: sudo yum update, stop unused cleartext daemons with sudo service <svc> stop when appropriate

Re-verify: Re-capture during HTTPS login – password not readable in Follow TCP Stream (only encrypted application data). 1-page Purple report for owner Shraddha: finding → risk → HTTPS/arpwatch/VPN fix → before/after evidence. Peer-review with Amir / Ravina. No internet targets, no captures leaving the lab folder without redaction.

Real incident: Superfish adware on Lenovo laptops (2015)

In 2015, public reporting (including coverage tied to Lenovo and security researchers) showed that some consumer Lenovo laptops had shipped with Superfish VisualDiscovery adware. That software installed an extra trusted root certificate and could intercept HTTPS connections (a local man-in-the-middle style risk), weakening the usual browser trust model. Weakness: a vendor-preinstalled component that broke TLS trust so ads/injection could inspect or modify encrypted sessions. What would have reduced it: no extra roots from adware, certificate pinning/transparency habits for high-risk apps, endpoint inventory that flags unexpected roots, and rapid vendor removal/uninstall guidance. Lab lesson: if TLS is undermined (fake root, cleartext fallback), Wireshark-style inspection becomes trivial again – Blue answer is intact trust + HTTPS everywhere. Source: Lenovo Superfish customer advisories and major tech-security news (2015); verify current vendor summaries.

Real incident: Heartbleed OpenSSL (2014)

In 2014, the Heartbleed bug in OpenSSL's heartbeat extension was publicly disclosed. Affected servers could leak chunks of process memory to a remote reader – reported contents included credentials, session material and private key material in worst cases. Weakness: a memory-disclosure flaw in a widely deployed TLS library, so "we use HTTPS" was not enough until OpenSSL was patched and secrets rotated. What would have reduced it: rapid OpenSSL/patch SLAs, reissue/revoke certificates after exposure windows, secret rotation (passwords, session keys), and inventory of every internet-facing TLS terminator. Lab lesson: sniffing shows why cleartext is fatal; Heartbleed shows defenders must also patch the crypto stack and rotate secrets – HTTPS is necessary, not automatic forever. Source: heartbleed.com / OpenSSL security advisories and CERT/major news coverage (2014); verify current summaries.

Interview model (clean English): "I capture HTTP only on my host-only lab to show why passwords leak in Follow TCP Stream. I then enable HTTPS, re-capture, prove the secret is no longer readable, and document ARP-spoofing defences like DAI, arpwatch and VPN for untrusted networks."

Thodkyaat: sniffing shika, pan HTTPS + arpwatch/DAI + VPN shika. Aata pudhe wireless – WPA2/WPA3. Chala pudhe, mitrano!

Thodkyaat sangaycha tar

Sniffing captures network packets; switches limit what you see, ARP spoofing and Wi-Fi change that.
tcpdump captures from the command line (use -n, filter by host/port, save with -w); Wireshark reads it in a GUI.
Learn display filters (http, ip.addr==, POST) and Follow TCP Stream to read a whole conversation.
HTTP shows passwords in plain text; HTTPS encrypts everything – the reason for Chapter 13's Certbot setup.
ARP spoofing enables man-in-the-middle on a switch; defend with HTTPS, DAI/port security, arpwatch and VPNs.

Samjla ka? Aata network cha aatla khel disla. Pudhchya chapter madhe wireless security – Wi-Fi cha suraksha, fakt swatahchya network var. Chala pudhe, mitrano!