5 AWS misconfigurations that commonly show up on a first scan

Why the same five keep showing up

Cloud teams move fast, and defaults rarely favor the defender. Five misconfigurations come up again and again in AWS security reviews — often in accounts operated by teams that consider themselves mature. Each one is easy to introduce, easy to miss, and each one can quietly widen the blast radius of a routine credential leak into a full compromise.

1. S3 buckets exposed via bucket policies (not ACLs)

Everyone knows to block public ACLs. Fewer teams audit bucket policies that grant s3:GetObject to Principal: "*". The AWS console labels these buckets "Public" only when the policy resource is the bucket itself — not when it's arn:aws:s3:::acme-corp-uploads/public/*.

• Enable Block Public Access at the account level.
• Alert on any new bucket policy statement whose principal is * or whose condition allows broad IPs.
• Treat any s3:* grant to arn:aws:iam::****4821:root from another account as a finding until proven intentional.

2. Over-privileged IAM roles attached to EC2

It is common to find AdministratorAccess on instance profiles that only need to read from one S3 prefix. Combined with an SSRF bug or an exposed metadata endpoint (IMDSv1), that role becomes an admin foothold.

• Enforce IMDSv2 across the fleet.
• Replace * policies on instance profiles with least-privilege equivalents generated from IAM Access Analyzer.
• In Onam, a public-facing workload that can reach such a role shows up as a step on an attack path.

3. Public RDS snapshots

RDS snapshot sharing is a per-snapshot ACL — flipping it to "public" makes the entire database available to any AWS account. Teams do this to move data between environments and forget to revert.

4. Security groups with 0.0.0.0/0 on non-web ports

SSH (22), RDP (3389), database ports, and ANY-protocol rules facing the internet remain a classic initial-access route. Many are legacy — a rule opened for a demo years ago on an account no one owns anymore.

5. CloudTrail gaps

CloudTrail is either not enabled in every region, not covering S3 data events, or writing to a bucket in the same account with no MFA delete. Any attacker with account-level access rewinds the tape.

What "fix it fast" actually looks like

Prioritization matters more than volume. Onam raises findings that sit on an attack path from an internet-exposed resource to a crown jewel such as a data store or key — so the SSH-open bastion in front of an admin IAM role comes before the internal-only bucket policy.

If you're onboarding a new AWS org, check for all five on the first scan. Finding some of them is not a failure of your team — it's the shape of AWS defaults.