In 2023, Toyota disclosed that a misconfigured cloud environment had exposed data tied to roughly 2.15 million customers for nearly a decade before anyone caught it. In 2022, Pegasus Airlines left an AWS S3 bucket open to the public internet, exposing 6.5TB of data and 23 million files, including flight crew source code and plaintext credentials. Neither incident involved a zero-day. Both came from default settings, wildcard IAM policies, and open security groups that get created every day in AWS accounts. Unit 42's 2023 Cloud Threat Report found that 99% of cloud identities analyzed were granted permissions they never used, and Orca Security's 2023 State of Public Cloud Security report found 78% of organizations had at least one workload reachable from the internet on a high-risk port. This is a working cheat sheet for the AWS misconfigurations that actually get exploited in the wild, plus the specific IAM policy edits, console settings, and Config rules that close them.
What is the single most exploited AWS misconfiguration?
Overly permissive IAM policies — specifically "Action": "*" and "Resource": "*" statements attached to roles that don't need that scope. This is exactly what turned a web application firewall bug into the 2019 Capital One breach: an SSRF vulnerability let an attacker query EC2 instance metadata, retrieve temporary credentials for an IAM role, and use that role's overly broad S3 permissions to pull records on 106 million people. Capital One paid an $80 million OCC fine on top of remediation costs. The IAM role itself wasn't the initial bug — the SSRF was — but the blast radius was entirely a function of what that role was allowed to do.
The fix is boring but effective: run IAM Access Analyzer against every role and strip unused permissions it flags, replace wildcard resources with explicit ARNs, and attach service control policies (SCPs) at the organization level that cap what any account can grant, even if a developer attaches an over-broad policy by mistake. AWS's own IAM Access Analyzer "unused access" findings, generally available since late 2023, will directly surface roles matching the Unit 42 pattern of granted-but-never-used permissions.
Why do public S3 buckets keep causing breaches?
Because S3 Block Public Access is still frequently disabled at the bucket level, or a bucket policy grants access to Principal: "*" for convenience during setup and never gets locked down. AWS made Block Public Access the account-wide default for new buckets in April 2023, but that default doesn't retroactively fix buckets created earlier, and it can still be explicitly overridden per bucket or per account. That's the exact gap that exposed Pegasus Airlines' bucket and, separately, the gap researchers at UpGuard have repeatedly found across dozens of unrelated companies since 2017 using nothing more than automated bucket-name enumeration.
Fix it by enabling Block Public Access at the organization level via an SCP so member accounts can't opt out, adding an AWS Config rule (s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited) that auto-remediates, and running IAM Access Analyzer for S3 to get a continuous diff of which buckets are reachable from outside your account, not just which ones you remember creating.
How do open security groups expose workloads to the internet?
By allowing inbound traffic from 0.0.0.0/0 on ports that should never be internet-facing — SSH (22), RDP (3389), and database ports like 3306 and 5432 are the recurring offenders. A widely cited Comparitech honeypot study found unsecured databases exposed to the internet were discovered and attacked by automated scanners in under 9 hours on average. Shodan and similar internet-wide scanners index open AWS security groups continuously, so "we'll lock it down later" routinely becomes "it was already found." Orca's 2023 data on 78% of organizations having at least one internet-reachable high-risk port lines up with what shows up in incident response engagements: lateral movement almost always starts from a port that had no business being open.
The fix: replace SSH/RDP security group rules with AWS Systems Manager Session Manager, which needs no inbound ports at all; scope database security groups to specific application-tier security groups instead of CIDR ranges; and run AWS Config's restricted-ssh and restricted-common-ports managed rules across every account, not just production.
What gets missed when CloudTrail and GuardDuty aren't configured correctly?
Attacker activity in regions or accounts you're not logging. A single-region CloudTrail trail, or a trail without log file validation and multi-region enabled, creates a blind spot the moment an attacker pivots to a region your team doesn't operate in day-to-day — a known technique precisely because it works. AWS itself recommends an organization-wide, multi-region trail with log file validation as the baseline, not an option, yet it's routinely one of the first things missing in accounts that were spun up quickly for a proof of concept and never revisited.
GuardDuty has the same failure mode: it's a per-region service, and enabling it in us-east-1 while your workloads also run in eu-west-1 and ap-southeast-1 leaves two-thirds of your footprint unmonitored. Fix both with AWS Organizations: enable an org-wide multi-region CloudTrail trail delivering to a centralized, access-restricted logging account, and enable GuardDuty organization-wide so every new account inherits detection automatically instead of depending on someone remembering to turn it on.
Are unencrypted EBS volumes and public snapshots really a risk?
Yes — a public EBS snapshot is a full, byte-for-byte copy of a disk, including any credentials, config files, or database contents that were on it, and anyone with the snapshot ID can restore it into their own account. Security researchers at firms like Rhino Security Labs have repeatedly demonstrated finding live credentials and internal source code inside snapshots that were shared "temporarily" for a migration or support ticket and never made private again. AWS added an account-level "Block public access for snapshots" setting in January 2022, but like S3's Block Public Access, it has to be explicitly enabled per region — it isn't retroactive for existing shares.
Fix it by turning on EBS encryption by default in every region you operate (aws ec2 enable-ebs-encryption-by-default), enabling the account-level block on public snapshot sharing, and adding the Config rule ebs-snapshot-public-restorable-check so any snapshot that gets shared publicly — intentionally or by accident — triggers an alert instead of sitting exposed indefinitely.
How Safeguard Helps
Safeguard treats AWS misconfigurations the same way it treats vulnerable dependencies: by asking whether the exposure is actually reachable before flagging it as urgent. Reachability analysis correlates IAM permissions, security group rules, and network paths with what your workloads actually run and expose, so a wildcard IAM policy on an idle role doesn't get the same alert priority as one attached to an internet-facing Lambda. Griffin AI triages each finding against your environment's context and drafts the remediation — a scoped-down IAM policy, a corrected security group rule, a Config rule enablement — as an auto-fix pull request your team reviews instead of writes from scratch. Safeguard also generates and ingests SBOMs across your cloud accounts and CI/CD pipelines, giving security teams one place to see both the software supply chain and the cloud configuration risks that expose it, instead of stitching together CSPM and SCA tooling separately.