30.7 Red vs Blue, Project and Real Incidents

By Ravindra Bagale Last updated: 27 September 2026

Chala mitrano, Shared Responsibility, IAM, security groups, S3 Block Public Access, CloudTrail, GuardDuty, IMDSv2 – aata Purple Team loop. Red OWN AWS Free Tier account madhe ek weak setting dakhavto (public-leaning test bucket, open SSH SG for lab IP, IMDSv1, missing trail); Blue BPA + least-privilege policy, tight SG / Session Manager, IMDSv2, org CloudTrail + GuardDuty ne band karto. Tumhi Sahyadri Traders style OWN cloud madhe build → hack → fix karun Purple report liha. Awareness + fix; dusryacha AWS account – kadhi nahi. Samjla ka? Billing alarm on theva.

Red Team vs Blue Team – cloud / AWS security

Red team (attacker) does	Blue team (defender) detects / stops
Leave a test S3 bucket with Block Public Access off / overly open policy	Account-level Block Public Access; least-privilege bucket policy; S3 access logging / CloudTrail data events
Commit long-lived IAM access keys into Git (OWN throwaway key only)	Prefer IAM roles on EC2; MFA on humans; no root access keys; rotate/delete unused keys; credential report
Security group SSH `0.0.0.0/0` on admin port (lab mistake pattern)	Least-privilege SG (office/lab IP only); prefer SSM Session Manager; private subnet + bastion pattern
SSRF awareness toward EC2 metadata (`169.254.169.254`) on OWN weak app	IMDSv2 (`--http-tokens required`); hop limit; no public metadata abuse path; role least privilege
Skip CloudTrail / GuardDuty so nobody notices API abuse	Multi-region / org trail; GuardDuty; Config rules; Security Hub; billing alarm
Use over-broad IAM (`Action: *` on role) after stealing temp creds	Least-privilege roles; Access Analyzer; review unusual `GetCallerIdentity` / S3 `ListBuckets` in CloudTrail

Defender chi simple checklist: BPA on → IAM roles + MFA + no root keys → SG least privilege / Session Manager → IMDSv2 required → CloudTrail + GuardDuty + Config → billing alarm → re-prove the weak path is closed. Red = lab misconfig awareness; Blue = console/CLI hardening. Interview madhe "I opened S3 to the world" peksha "I demonstrated one cloud misconfig on my Free Tier account, fixed BPA/IMDSv2/SG/Trail, and re-proved the check failed" jast strong.

# OWN AWS Free Tier only – fictional Sahyadri Traders (Pune) lab notes
# Ethics: your account only; billing alarm ON; turn off paid trials after lab
mkdir -p ~/labs/sahyadri-aws-harden
aws sts get-caller-identity | tee ~/labs/sahyadri-aws-harden/whoami.json
# 1) Baseline weak checks (detect – do NOT leave these on overnight):
#    aws s3api get-public-access-block --bucket YOUR-TEST-BUCKET-NAME
#    aws ec2 describe-security-groups --query 'SecurityGroups[].[GroupId,GroupName,IpPermissions]'
#    aws ec2 describe-instances --query 'Reservations[].Instances[].[InstanceId,MetadataOptions]'
#    aws cloudtrail describe-trails
# 2) FIX examples (Blue – run on resources YOU own):
#    aws s3control put-public-access-block --account-id YOUR_ACCOUNT_ID \
#      --public-access-block-configuration \
#      BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
#    aws ec2 modify-instance-metadata-options --instance-id i-YOURID \
#      --http-tokens required --http-endpoint enabled
#    # tighten SG: remove 0.0.0.0/0 on port 22; allow only your lab/office IP
#    # enable multi-region trail + (optional) GuardDuty free trial – then disable if not keeping
# 3) Re-verify:
#    aws s3api get-public-access-block --bucket YOUR-TEST-BUCKET-NAME
#    curl -s http://169.254.169.254/latest/meta-data/   # on EC2: should 401 without IMDSv2 token
# Amazon Linux EC2 you own:
#   sudo yum update
#   sudo service amazon-ssm-agent status   # if using Session Manager
echo 'Scope: OWN AWS account – Sahyadri Traders Free Tier lab' \
  > ~/labs/sahyadri-aws-harden/scope.txt
echo 'Fix: BPA | SG tighten | IMDSv2 | CloudTrail | GuardDuty-as-needed' \
  >> ~/labs/sahyadri-aws-harden/scope.txt

Ravindra Bagale's Tip

Students take a CloudTrail screenshot and stop there – but they don't apply S3 BPA and IMDSv2. The second mistake: touching someone else's bucket/account "for practice". Rule: OWN Free Tier only → ek weak setting deliberately (short time) → CLI/console detect → FIX same day → re-prove → Purple report → paid trials off. The cloud chapter is really a shared-responsibility chapter. Don't worry, the checklist gets you there.

Lab

Tumchya OWN AWS account madhe ekach weak item choose kara – test bucket with Block Public Access briefly off (empty/non-sensitive only) OR security group SSH open to your lab IP only (not the whole internet if you can avoid it), OR an EC2 still on IMDSv1. Notes + CLI output ~/labs/sahyadri-aws-harden/. Mag matching fix (BPA / SG tighten / --http-tokens required / enable trail) apply karun punha check – weak path closed pahije. Dusryacha account/bucket nahi. Billing alarm confirm kara.

Project: Build it, hack it, fix it

Build: For fictional Sahyadri Traders (Pune wholesale shop cloud lab) in your own AWS Free Tier account:

Create a short-lived lab: empty test bucket or one EC2 in a lab VPC with a deliberately weak control (BPA off on that bucket, SSH SG limited to your IP as the "noisy" lesson, or IMDSv1)
Confirm scope file: account ID (last 4 digits ok), region, resource names; written note that this is Sahyadri's OWN practice account
Ethics card: IT Act – no other people's buckets/accounts; billing alarm on; delete lab resources and disable paid GuardDuty/Config trials after the project

Hack (lab awareness – OWN account only):

Use AWS CLI/console checks from this chapter to detect the weak setting (public-access-block status, SG ingress, metadata options, missing trail)
Screenshot/CLI proof of the finding; name the risk (public S3 exposure path, SSH blast radius, SSRF→IMDS credential theft awareness, blind API abuse)
Do not paste weaponized SSRF payloads against anything you do not own; do not scan random public buckets

Fix:

Enable account-level S3 Block Public Access; lock bucket policy to least privilege
Replace long-lived keys with an instance/role pattern; MFA on IAM users; no root keys
Tighten SG; prefer SSM Session Manager; keep RDS/admin paths private
Force IMDSv2 on lab EC2; shrink role permissions
Enable multi-region CloudTrail; optional GuardDuty sample findings then decide keep/off
Confirm billing alarm still on

Re-verify: Same CLI checks now show BPA on, SG closed, IMDSv2 required, trail present. 1-page Purple report for owners Raja and Rani (Sahyadri ops): finding → AWS control → fix → evidence. Peer-review with Zoya / Salman. IT Act: only cloud you own or are authorised to test.

Real incident: Capital One – SSRF to EC2 metadata (2019)

In July 2019, Capital One disclosed a breach in which a former AWS engineer exploited SSRF against a misconfigured WAF/proxy on EC2, reached the instance metadata service, and obtained temporary IAM role credentials that could list and read data from S3. Capital One reported personal information related to roughly 100 million-plus credit-card applicants and customers in the U.S. and Canada (treat published figures as reported). Public technical write-ups and court materials described an over-privileged role path and IMDSv1-style metadata access that a simple SSRF chain could abuse. Weakness: SSRF on a cloud-facing component + IAM over-privilege + metadata reachable without IMDSv2. What would have reduced it: IMDSv2 (token + hop controls), least-privilege roles (no broad S3 list/read on a WAF role), tighter WAF/proxy config, and monitoring for unusual metadata/API use from roles. Lab lesson: your Sahyadri IMDSv2 + least-privilege fix is the same Blue answer AWS later pushed industry-wide. Source: Capital One July 2019 disclosure, U.S. DOJ charging materials, and major technical analyses of the SSRF→IMDS→S3 path; verify current summaries.

Real incident: Code Spaces – AWS console takeover (2014)

In June 2014, code-hosting provider Code Spaces reported that a DDoS/extortion incident coincided with an attacker gaining access to its AWS EC2 control panel. When staff tried to regain control by changing passwords, the intruder – who had reportedly prepared backup logins – deleted EBS snapshots, S3 buckets, AMIs and machine instances over roughly a 12-hour window. Most customer repositories and recovery copies that lived under the same panel were destroyed; the company publicly stated it could not restore service and ceased trading. Weakness: cloud console takeover + recovery and backups reachable from the same compromised identity plane (and weak account hygiene around console access). What would have reduced it: MFA on all console users, no shared root, separate break-glass / backup accounts with MFA, immutable/off-account backups the attacker cannot delete with the same credentials, CloudTrail alerts on IAM user creation and mass deletes. Lab lesson: "we have backups" is useless if one stolen console session can delete the backups too. Source: Code Spaces public incident advisory (June 2014) and contemporary reporting (e.g. Ars Technica / ESET summaries); verify current summaries.

Interview model (clean English): "I pick one AWS misconfiguration on my own Free Tier account, prove it with CLI checks, fix Block Public Access or IMDSv2 or the security group, enable CloudTrail, and re-prove the weak path is closed."

Thodkyaat: cloud misconfig olakha, pan BPA + IAM + IMDSv2 + Trail ne fix + re-prove shika. Aata pudhe SOC, SIEM ani incident response – alert pasun contain paryant. Chala pudhe, mitrano!

Thodkyaat sangaycha tar

AWS secures the cloud; you secure what you put in it – most breaches are your misconfiguration.
Lock root with MFA, give least privilege, and use roles instead of long-lived keys.
Keep admin and database ports closed to the internet; RDS in private subnets.
Block public S3 at the account level, encrypt data and keep secrets in SSM or Secrets Manager.
CloudTrail, GuardDuty, Config and Security Hub let you see and respond to attacks.
Require IMDSv2 to stop SSRF credential theft; if a key leaks, deactivate it first.

Samjla ka? Tumcha AWS account aata khup surakshit zala. Pudhchya chapter madhe SOC, SIEM ani incident response – attack zala tar company kashi shodhte ani uttar dete. Chala pudhe, mitrano!