- Overly permissive IAM policies grant more access than users or services need.
- Public S3 buckets are a leading cause of cloud data exposure incidents.
- Security groups with open inbound rules expose services to the internet.
- CloudTrail misconfigurations leave gaps in audit and forensic evidence.
- Infrastructure-as-code drift can silently reintroduce risky configurations.
What is it and why it matters
AWS misconfigurations are the root cause of most cloud security incidents because the shared responsibility model puts configuration control in the customer’s hands, and the default settings aren’t always the most secure. A single misconfigured IAM policy, S3 bucket ACL, or security group can expose sensitive data to the entire internet within minutes. Cloud environments change rapidly — new services are deployed, permissions evolve, and resources are shared across teams — making continuous configuration monitoring essential. For security analysts, understanding common cloud misconfiguration patterns is critical because traditional network and endpoint detection tools often lack visibility into cloud control planes.
Real world examples
- Capital One breach (2019) — A misconfigured web application firewall allowed a server-side request forgery attack that accessed S3 buckets containing over 100 million customer records, resulting in a $190 million settlement.
- Uber breach by Lapsus$ (2022) — The Lapsus$ group gained access through MFA fatigue and an exposed PowerShell script containing hardcoded admin credentials in a network share, then pivoted to Uber’s AWS environment.
- Pegasus Airlines S3 leak (2022) — A misconfigured S3 bucket exposed 23 million files including crew passports, flight logs, and sensitive aviation compliance documents.