On April 5, 2023, AWS changed the default behavior of every new S3 bucket: S3 Block Public Access and ACL-disabled now ship turned on by default across every region, for buckets created via the console, CLI, SDK, or CloudFormation. That single default-flip closed off one of the most common paths to a public data leak — but only for buckets created after that date. Every bucket provisioned before April 2023, and every bucket where someone deliberately disabled Block Public Access for static site hosting or cross-account sharing, is still exposed exactly as before. Three years on, the same three misconfiguration classes keep showing up in AWS Trusted Advisor scans, AWS Config rule violations, and CIS AWS Foundations Benchmark audits: public S3 buckets, overly permissive IAM policies built on wildcard actions and resources, and security groups that leave SSH, RDP, or database ports open to the entire internet. None of these require exotic attack techniques to find — they require someone to run the right AWS CLI command and actually read the output. This post walks through each misconfiguration class with the exact detection commands AWS itself recommends, and why each one keeps recurring even as the platform's defaults get safer.
Why are pre-2023 S3 buckets still a live exposure class?
Pre-2023 S3 buckets are still exposed because AWS's April 2023 default change is not retroactive — it only applies to buckets created after the change shipped, so any bucket provisioned earlier keeps whatever public-access settings it originally had. A bucket configured years ago for static website hosting, log delivery, or a public dataset often has Block Public Access explicitly disabled, and that setting persists indefinitely unless someone goes back and changes it. To check a specific bucket, run aws s3api get-public-access-block --bucket YOUR-BUCKET — if it returns an error saying no configuration exists, the bucket has no BPA protection at all. Follow with aws s3api get-bucket-policy-status --bucket YOUR-BUCKET to see whether AWS itself classifies the bucket policy as "IsPublic": true. For an account-wide sweep, aws s3control get-public-access-block --account-id YOUR-ACCOUNT-ID checks the account-level default, and AWS Config's s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited managed rules flag every non-compliant bucket continuously rather than at a single point in time.
What makes an IAM policy overly permissive, and how do you find one?
An IAM policy is overly permissive when it grants "Action": "*" or "Resource": "*" far beyond what a role actually uses, or when it relies on long-lived static access keys instead of short-lived STS credentials issued through a role. AWS's own Well-Architected Framework and IAM best-practices guidance have warned against both patterns for years, precisely because a single leaked access key attached to an admin-equivalent policy gives an attacker the same reach as a compromised root account. The fastest way to find unused permissions is IAM Access Analyzer, which AWS built specifically to flag resources shared outside an account and policies granting more access than a role's activity justifies. To quantify exactly what a role actually uses, run aws iam generate-service-last-accessed-details --arn ROLE-ARN followed by aws iam get-service-last-accessed-details --job-id JOB-ID — the output lists every AWS service the role's policy permits alongside the last time it was actually called, which is often "never." Combine that with aws iam list-access-keys --user-name USERNAME to find static keys older than 90 days, a standard rotation threshold in most compliance frameworks.
Why do open security groups keep showing up in every audit?
Open security groups keep showing up because a rule allowing ingress from 0.0.0.0/0 on port 22, 3389, or a database port is easy to create during setup or troubleshooting and easy to forget to remove once the immediate need passes. This pattern is common enough that it has its own dedicated AWS Config managed rules — restricted-ssh and restricted-common-ports — and its own line item in the CIS AWS Foundations Benchmark, which explicitly checks for unrestricted ingress on ports 22 and 3389 as a baseline control. To find every offending rule directly, run aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values=0.0.0.0/0 --query "SecurityGroups[].[GroupId,IpPermissions]" and inspect the returned port ranges — anything covering 22, 3389, 3306 (MySQL), 5432 (Postgres), 6379 (Redis), or 27017 (MongoDB) alongside a 0.0.0.0/0 source is a finding. AWS Trusted Advisor's security category surfaces the same class of issue automatically for accounts with Business or Enterprise support, without needing a custom query at all.
What's the actual cost of leaving these misconfigurations unfixed?
The cost shows up less in dramatic one-off incidents and more in how long these gaps sit open once they exist. Verizon's 2026 Data Breach Investigations Report keeps "Miscellaneous Errors" — the category that includes misconfiguration — as a recurring contributor to breaches, and separately notes that permission and access-related misconfigurations discovered at third parties took a median of roughly eight months to remediate. Eight months is long enough for a scan-and-exploit bot, or a curious researcher, to find an exposed bucket or an open database port well before an internal audit ever catches it. That remediation lag is the real argument for continuous, automated checks rather than periodic manual reviews: a misconfiguration that's invisible between audit cycles is functionally the same as a misconfiguration nobody ever looks for.
How should a team turn these commands into an ongoing practice?
Running these commands once tells you today's exposure; running them continuously is what actually closes the gap Verizon's data points to. AWS Config conformance packs for CIS and PCI bundle the relevant managed rules — including the S3, IAM, and security-group checks above — into a single deployable set that evaluates every resource on a recurring schedule rather than on demand. GuardDuty adds a detection layer on top for S3 and IAM specifically, flagging anomalous API calls (like a sudden PutBucketPolicy making a bucket public, or IAM credentials used from an unfamiliar location) that a point-in-time CLI check would miss entirely. Cloud posture and SBOM-aware scanning platforms play a similar role at the infrastructure-as-code stage, catching a public-access-block removal or a 0.0.0.0/0 ingress rule in a Terraform or CloudFormation diff before it ever reaches a running account. The commands in this post are a good starting checklist for a manual review — but the teams that stop finding these issues in incident postmortems are the ones that wire the checks into CI and into AWS Config, not the ones that run them once a quarter.