7 Cloud Misconfigurations That Caused Real Data Breaches

The cloud does not come secure by default. Misconfigured S3 buckets, overpermissive IAM roles, public database snapshots, and default credentials have caused some of the largest data breaches in history. This guide examines real incidents and shows you exactly what went wrong and how to prevent it.

The Scale of Cloud Misconfiguration

According to Gartner, through 2025, 99% of cloud security failures will be the customer's fault. Not the cloud provider's. The shared responsibility model means AWS, Azure, and GCP secure the infrastructure, but you are responsible for configuring it correctly. Most organizations do not.

The 2025 Verizon DBIR found that misconfiguration was the most common error category in breaches, involved in 12% of all incidents. Cloud-specific misconfigurations are growing faster than any other vulnerability category because cloud environments are complex, change rapidly, and are often managed by developers without security training.

Case Study: The Capital One Breach (2019)

The Capital One breach remains the textbook example of cloud misconfiguration. An attacker exploited a misconfigured WAF (Web Application Firewall) to perform a Server-Side Request Forgery (SSRF) attack against the EC2 instance metadata service. This gave them temporary credentials from an IAM role that had excessive permissions, including access to an S3 bucket containing 106 million customer records.

What went wrong:

• Overpermissive IAM role: The EC2 instance role had access to S3 buckets it did not need
• No IMDSv2 enforcement: IMDSv1 allowed unauthenticated access to instance metadata (including IAM credentials) via SSRF
• Missing detection: The exfiltration of 700+ GB of data was not detected for over four months
• No data loss prevention: No alerts on unusual S3 data access patterns

Prevention: Enforce IMDSv2 on all EC2 instances, apply least privilege IAM policies, enable CloudTrail with S3 data events, set up GuardDuty for anomaly detection. See our AWS Security Checklist for complete controls.

Misconfiguration 1: Public S3 Buckets

Despite years of warnings, public S3 buckets continue to expose sensitive data. In 2024, researchers found over 18,000 S3 buckets with public read access containing databases, backups, log files, and customer records.

# Check if your bucket is public
aws s3api get-bucket-acl --bucket your-bucket
aws s3api get-public-access-block --bucket your-bucket

# Block public access (bucket level)
aws s3api put-public-access-block --bucket your-bucket   --public-access-block-configuration     BlockPublicAcls=true,IgnorePublicAcls=true,    BlockPublicPolicy=true,RestrictPublicBuckets=true

# Block public access (account level - recommended)
aws s3control put-public-access-block --account-id YOUR_ACCOUNT_ID   --public-access-block-configuration     BlockPublicAcls=true,IgnorePublicAcls=true,    BlockPublicPolicy=true,RestrictPublicBuckets=true

Misconfiguration 2: Overpermissive IAM Policies

Using "Action": "*" and "Resource": "*" in IAM policies is the cloud equivalent of giving everyone the master key. In a 2024 breach, an attacker compromised a single developer's laptop and used their overpermissive IAM credentials to access production databases, S3 buckets, and Secrets Manager, exfiltrating data from multiple services.

Prevention: Apply least privilege. Use IAM Access Analyzer to identify unused permissions. Implement permission boundaries. Use aws iam generate-service-last-accessed-details to find and remove unnecessary permissions.

Misconfiguration 3: Public Database Snapshots

RDS snapshots and EBS snapshots can be shared publicly with a single API call. Attackers scan for public snapshots, restore them, and extract the data. A 2023 study found 2,058 public RDS snapshots containing production data including PII, financial records, and credentials.

# Check for public RDS snapshots in your account
aws rds describe-db-snapshots --snapshot-type manual   --query 'DBSnapshots[?contains(DBSnapshotAttributes[].AttributeName, `restore`) && contains(DBSnapshotAttributes[].AttributeValues[], `all`)]'

# Check for public EBS snapshots
aws ec2 describe-snapshots --owner-ids self   --query 'Snapshots[?contains(to_string(CreateVolumePermissions), `all`)]'

Misconfiguration 4: Exposed Kubernetes Dashboards

Kubernetes dashboards exposed to the internet without authentication give attackers full control over your cluster. Tesla's Kubernetes cluster was compromised in 2018 through an exposed dashboard, which was used for cryptocurrency mining. In 2024, researchers found over 900 exposed Kubernetes dashboards on the public internet.

Misconfiguration 5: Default Credentials

Cloud-deployed databases, message queues, and management interfaces often ship with default credentials or no authentication. MongoDB, Redis, Elasticsearch, and RabbitMQ have all been mass-exploited through default configurations. In 2024, a single ransomware campaign encrypted 35,000 MongoDB databases that had no authentication enabled.

Misconfiguration 6: Security Groups as Firewalls That Never Get Updated

Security groups accumulate rules over time. Temporary rules for debugging (0.0.0.0/0 on port 22) become permanent. Old rules for decommissioned services remain active. A 2024 analysis found that 41% of security groups in production AWS environments contained at least one overly permissive rule.

Misconfiguration 7: Missing Encryption

S3 buckets without default encryption, RDS instances without encryption at rest, EBS volumes storing sensitive data in plaintext. AWS now enables default encryption for new S3 buckets and EBS volumes, but existing resources may still lack encryption. This is especially critical for compliance with PCI DSS, HIPAA, and SOC 2.

Frequently Asked Questions

What is the most common cloud misconfiguration?

Overpermissive IAM policies are the most common and most dangerous misconfiguration. According to Palo Alto's Unit 42 Cloud Threat Report, 99% of cloud users, roles, services, and resources have excessive permissions. This means that when any single credential is compromised, the blast radius extends far beyond what that user actually needs. Apply least privilege systematically and use automated tools like IAM Access Analyzer to detect overpermissive policies.

How do I audit my cloud configuration?

Use AWS Config Rules, Azure Policy, or GCP Organization Policies for automated compliance checking. Run Prowler (AWS), ScoutSuite (multi-cloud), or CloudSploit for one-time audits. Enable GuardDuty (AWS), Microsoft Defender for Cloud (Azure), or Security Command Center (GCP) for continuous monitoring. For web-facing resources, run the SecureBin Exposure Checker to catch exposed files and misconfigurations.

Does moving to the cloud make us more or less secure?

It depends entirely on your implementation. Cloud providers invest billions in infrastructure security that most organizations could never match. The physical security, network security, and hypervisor security of AWS, Azure, and GCP are world-class. However, you are responsible for everything above the infrastructure layer: IAM, network configuration, encryption, application security, and data protection. Organizations that invest in proper cloud security posture management are more secure in the cloud. Those that "lift and shift" without adapting their security practices are often less secure because the cloud's automation capabilities work equally well for attackers.

The Bottom Line

Cloud misconfigurations are preventable. Every breach described in this article could have been avoided with proper IAM policies, encryption, access controls, and monitoring. The cloud shared responsibility model means security is your job. Use automated tools to continuously check your configuration, apply least privilege everywhere, encrypt everything, and monitor for anomalies. The cost of prevention is a fraction of the cost of a breach.

Related reading: AWS Security Checklist for Production, Data Breach Cost for Small Business, Secure Environment Variables in Production, How to Check if API Key is Exposed.