31.7 Red vs Blue, Project and Real Incidents

By Ravindra Bagale Last updated: 27 September 2026

Chala mitrano, SOC tiers, logs, SIEM, Wazuh, triage, NIST IR lifecycle – aata Purple Team loop. Red OWN lab madhe noisy SSH fail / web probe / log-clear attempt dakhavto; Blue fail2ban + SIEM alert + immutable/central logs + triage playbook + containment ne band karto. Tumhi Raja-Rani Traders style OWN Kali→.20/.50 madhe build → hack → fix karun Purple (L1 notes + Blue fix) report liha. Alert baghun thambu naka – decide + document + escalate. Samjla ka? Dusryacha production – kadhi nahi.

Red Team vs Blue Team – SOC / SIEM / IR

Red team (attacker) does	Blue team (defender) detects / stops
Noisy SSH password spray / brute force on OWN Metasploitable `.20`	`fail2ban` + SIEM/Wazuh rule on `/var/log/secure` or `auth.log`; block source IP; key-only SSH
Web SQLi/XSS flood noise in access.log on OWN DVWA `.50`	Wazuh/ELK rules on web logs; WAF/mod_security as extra layer; rate limits
Clear or truncate local logs to cover tracks (OWN VM only)	Centralised / immutable log shipping (rsyslog→SIEM); CloudTrail-style central store; alert on log-service stop
Hope L1 closes high-severity as "false positive" without notes	Triage playbook + enrichment + escalation SLA; ticket must say why TP/FP
Lateral movement after foothold (new user, new cron) on OWN lab	IR lifecycle: contain (isolate host/SG) → eradicate → recover; EDR/Wazuh FIM awareness
Alert flood to bury the real event	Severity tuning, suppress known-good scanners, hunt for rare high-impact signals

Defender chi simple checklist: centralise logs → detect (SIEM rule) → triage with notes → contain fast → eradicate root cause → recover from clean backup → lessons learned rule/playbook update. Red lab = generate a controlled signal; Blue = see it, decide, fix. Interview madhe "I ignored the alert" peksha "I triaged a lab SSH brute alert in Wazuh, documented L1 notes, applied fail2ban, and re-proved the next spray was blocked" jast strong.

# OWN lab only – Kali 192.168.56.10 → Metasploitable/DVWA 192.168.56.20 / .50
mkdir -p ~/labs/raja-rani-soc
# 1) Generate a CONTROLLED signal (examples already taught in Ch.20–29 – OWN targets only):
#    From Kali: a few failed SSH tries to .20 (enough for fail2ban/Wazuh – not an internet spray)
#    Or: revisit one known DVWA low action so access.log shows the pattern
# 2) Blue see / create alert:
#    On Wazuh dashboard: find authentication-failed / web-attack related alert
#    If Wazuh is not up yet: file-based triage on the agent host YOU own:
#      sudo grep -i 'Failed password' /var/log/secure | tail -n 20
#      # Ubuntu/Kali agent style: /var/log/auth.log
# 3) L1 triage notes (fill):
cat > ~/labs/raja-rani-soc/l1-triage.txt << 'EOF'
Alert: (SSH brute | web injection noise | new user)
True/False positive: 
Evidence: (log lines / Wazuh id)
Scope: host-only lab IPs only
Action: escalate / close with reason / contain
EOF
# 4) FIX on the OWN target (Amazon Linux / lab VM style):
#    sudo yum install -y fail2ban
#    sudo service fail2ban start
#    sudo service fail2ban status
#    # tighten sshd: PasswordAuthentication no (keys only) – then sudo service sshd restart
# 5) Re-verify: repeat a few failed tries – fail2ban bans; SIEM shows block or fewer alerts
echo 'Scope: Raja-Rani OWN lab 192.168.56.0/24' > ~/labs/raja-rani-soc/scope.txt

Ravindra Bagale's Tip

Students think a SIEM screenshot is a project – but there are no ticket notes and no Blue fix. The second mistake: a "demo spray" against a production IP. Rule: OWN .20/.50 only → controlled lab signal → Wazuh or log triage → L1 notes with WHY → fail2ban/harden → re-prove → Purple report. The SOC chapter is really a decide-and-document chapter. Don't worry, the playbook gets you there.

Lab

Kali 192.168.56.10 pasun Metasploitable 192.168.56.20 var thodya failed SSH attempts (lab only). Wazuh madhe alert shodha – nasel tar agent host var /var/log/secure (kiwa auth.log) grep karun L1-style note ~/labs/raja-rani-soc/l1-triage.txt madhe liha (TP/FP, evidence, next action). Mag Blue fix: fail2ban install/start (sudo yum / sudo service style on Amazon Linux helper) kiwa sshd harden. Punha try – ban/block disla pahije. Internet brute nahi; dusryacha server nahi.

Project: Build it, hack it, fix it

Build: For fictional Raja-Rani Traders (Nashik shop SOC practice) on host-only lab:

Confirm Wazuh manager+agent (Ch.31.4) or prepare a file-based triage folder if SIEM is not running yet
Scope file: Kali .10, target .20 and/or DVWA .50; written note that alerts come only from OWN lab actions
Ethics card: IT Act – no scanning or spraying third-party hosts; no deleting someone else's logs

Hack (lab awareness – OWN systems only): From Kali 192.168.56.10:

Generate one controlled signal: failed SSH cluster toward .20, or one known Ch.20–29 web action against .50
Capture the alert id / log excerpt proving the SIEM (or grep) saw it
Optional Red awareness (OWN VM only): show why clearing local logs is noisy if logs are centralised – do not destroy evidence you need for class

Do not attack production shops, do not run password sprays on the public internet, do not disable logging on shared machines.

Fix:

Install/enable fail2ban (or equivalent) on the SSH target; tighten sshd (keys only) with sudo service sshd restart after config test
Add/confirm a Wazuh rule or dashboard saved search for "many auth failures"
Write a 5-line L1 playbook: enrich IP → check success after fails → contain (SG/firewall ban) → escalate L2 if success+new user
Document IR containment step: isolate host / tighten SG before rebuild (link to Ch.28 evidence habit)

Re-verify: Same lab spray produces ban + alert; L1 ticket sample shows clear TP/FP reasoning. 1-page Purple report for owners Raja and Rani: signal → detection → triage notes → Blue fix → re-proof. Peer-review with Zoya / Salman. IT Act: only systems you own or are authorised to test.

Real incident: Target – SOC alerts without timely action (2013)

In late 2013, U.S. retailer Target suffered a major payment-card and personal-data breach. Reporting and later reviews described attackers entering via credentials tied to an HVAC vendor (Fazio Mechanical) after phishing, then planting malware on point-of-sale systems. Critically for SOC students: Target had invested in advanced malware detection (FireEye); public reporting (including Bloomberg Businessweek and Target's own later comments) said the tools raised alerts around 30 November / early December while exfiltration malware was active, Bangalore monitoring escalated, and Minneapolis responders evaluated the activity but did not treat it as requiring immediate follow-up at that moment – so detection existed without fast containment. Reported impact scale is often cited around 40 million payment cards and 70 million personal records (treat figures as reported). Weakness: vendor access path + POS malware + alert fatigue / weak escalation (tools fired; human playbook/SLA failed). What would have reduced it: least-privilege vendor access + MFA, network segmentation for POS, and an IR playbook that forces timed escalation on high-severity EDR/SIEM alerts. Lab lesson: your Raja-Rani L1 notes + SLA habit matter as much as installing Wazuh. Source: Target breach public disclosures, contemporary Bloomberg/Reuters reporting on FireEye alerts, and Senate Commerce "kill chain" analysis summaries; verify current summaries.

Real incident: SolarWinds Orion – SUNBURST supply chain (2020)

In December 2020, researchers (notably FireEye) and then CISA described a supply-chain compromise of SolarWinds Orion: malicious code (commonly called SUNBURST) was inserted into legitimate updates and used for initial access into multiple government and private networks. CISA Alert AA20-352A and follow-on guidance documented APT follow-on activity, including lateral movement and abuse of identity/federation paths that could bypass some MFA assumptions. Detection and eviction at that scale required long IR campaigns (inventory of Orion versions, hunting for related domains/TTPs, rebuilding trust in identity). Weakness: trusted update channel + deep enterprise privileges for monitoring software + slow widespread detection of anomalous Orion callbacks. What would have reduced blast radius: software supply-chain controls, least privilege for management tools, egress monitoring for odd DNS/C2 patterns, and rehearsed IR/eviction playbooks (CISA later published Category-based remediation guidance). Lab lesson: SIEM rules and IR lifecycle are how organisations notice "trusted" software behaving wrongly – not only noisy SSH brutes. Source: FireEye/Mandiant December 2020 disclosure, CISA AA20-352A and related advisories (2020–2021); verify current summaries.

Interview model (clean English): "I generate a controlled SSH or web signal on my own lab, triage it in Wazuh or raw logs with written L1 notes, apply fail2ban or service hardening, and re-prove the next attempt is blocked."

Thodkyaat: alert olakha, pan triage notes + contain + fail2ban/harden + re-prove shika. Aata pudhe Linux ani network hardening – attack yashasvi hou naye itka majboot. Chala pudhe, mitrano!

Thodkyaat sangaycha tar

A SOC watches, detects and responds; L1 triages, L2 investigates, L3 hunts and engineers detection.
Know where logs live on Linux, web servers, Windows and AWS, and read them with grep and awk.
A SIEM collects, normalises, correlates and alerts; Wazuh is a free SIEM you can run in your lab.
Triage every alert: read, enrich, scope, decide, document – and fear false negatives most.
Follow the incident response lifecycle; preserve evidence before cleaning, and fix the root cause.

Samjla ka? Aata tumhi attacker ani defender dogha baju samajta. Pudhchya chapter madhe Linux ani network hardening – server la itka majboot karayche ki attack yashasvi ch hou naye. Chala pudhe, mitrano!