Cloud Misconfigurations That Caused Real Breaches

by

The cloud has not made organizations more secure — it has made the consequences of misconfiguration dramatically more severe. A single S3 bucket left open to the world has exposed hundreds of millions of records. A default AWS key with admin privileges, committed to GitHub for six minutes, has led to million-dollar ransom demands. This guide examines the most consequential real-world cloud security failures and how to prevent each one.

AWS S3: The Most Commonly Misconfigured Service in History

# Check if a bucket is publicly accessible
aws s3 ls s3://bucket-name --no-sign-request
# If you see file listings without credentials = public bucket

# Check bucket ACL and policy
aws s3api get-bucket-acl --bucket bucket-name
aws s3api get-bucket-policy --bucket bucket-name

# Prevention: Block all public access at account level
aws s3api put-public-access-block \
  --bucket bucket-name \
  --public-access-block-configuration \
  "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

AWS IAM: The Keys to the Kingdom

IAM misconfiguration is responsible for the majority of serious AWS breaches. The pattern is almost always the same: a developer creates an IAM user with AdministratorAccess for “convenience,” commits the access keys to a public GitHub repo, and an automated scanner finds it within minutes.

# If you find or suspect leaked keys: IMMEDIATELY rotate them
aws iam delete-access-key --access-key-id AKIA...
aws iam create-access-key --user-name service-account

# Audit what a key can do
aws iam get-user
aws iam list-attached-user-policies --user-name username
aws sts get-caller-identity

# Enumerate all IAM permissions with enumerate-iam
python enumerate-iam.py --access-key AKIA... --secret-key ...

# Best practices:
# - Never use IAM Users for applications - use IAM Roles instead
# - Apply least privilege - only permissions actually needed
# - Enable MFA for all human users
# - Use AWS Secrets Manager instead of hardcoded credentials
# - Enable CloudTrail logging and alert on unusual API calls

Security Groups: “Open to 0.0.0.0/0” Is the Biggest Mistake

# Find overly permissive security groups
aws ec2 describe-security-groups \
  --query "SecurityGroups[?IpPermissions[?IpRanges[?CidrIp=='0.0.0.0/0']]].{ID:GroupId,Name:GroupName}" \
  --output table

# Common dangerous configurations found in real environments:
# - SSH port 22 open to 0.0.0.0/0 -- anyone can attempt to login
# - RDP port 3389 open to 0.0.0.0/0 -- Windows remote desktop exposed to the world
# - MySQL port 3306 open to 0.0.0.0/0 -- database directly on internet
# - Port 0-65535 open to 0.0.0.0/0 -- everything open

# AWS Scout Suite: automated cloud security auditing
pip install scoutsuite
scout aws --report-dir ./scout_report

Azure Active Directory: The Most Targeted Cloud Identity

# Password spray against Azure AD
# Tool: MSOLSpray
python MSOLSpray.py --userlist users.txt --password "Winter2026!"

# Check if Azure AD allows legacy authentication (bypasses MFA)
Get-MsolUser -All | Where-Object { $_.StrongAuthenticationRequirements.Count -eq 0 }

# Enumerate Azure with ROADtools
pip install roadtools
roadrecon auth -u user@target.com -p password
roadrecon gather
roadrecon gui

Real Breach Case Studies

Capital One (2019): SSRF + Overprivileged IAM Role

The attacker exploited a Server-Side Request Forgery vulnerability in a WAF to reach the AWS metadata endpoint (169.254.169.254), which returned temporary IAM credentials. Those credentials belonged to a role with read access to hundreds of S3 buckets. Result: 100 million customer records exposed. Root cause: SSRF combined with an IAM role that had far broader access than needed.

Toyota (2023): AWS Keys in Public GitHub for 5 Years

Toyota accidentally published AWS access keys in a public GitHub repository. The keys remained active for approximately five years. When discovered, they potentially exposed personal data of 2.15 million customers. Root cause: no automated secret scanning in the CI/CD pipeline.

Essential Cloud Security Tools

  • Prowler — AWS, Azure, GCP security auditing and CIS Benchmark compliance
  • ScoutSuite — Multi-cloud auditing with visual HTML reports
  • Pacu — AWS exploitation framework for authorized red team assessments
  • TruffleHog — Find secrets in Git repositories before they leak
  • GitLeaks — Pre-commit hook to prevent secrets from ever reaching a repository
# Prowler: run all AWS security checks
pip install prowler
prowler aws --region us-east-1

# TruffleHog: scan repo for leaked secrets
trufflehog git https://github.com/target-org/target-repo.git

# GitLeaks: prevent future leaks
gitleaks protect --staged

Cloud security is not a configuration you set once — it is a continuous practice. As organizations add new services, new accounts, and new developers, the attack surface expands. Automated scanning with Prowler combined with alerting on CloudTrail anomalies is the minimum viable security posture for any organization running workloads in the cloud.