Common AWS Security Misconfigurations That Cause Breaches

Most AWS breaches don't start with a zero-day. They start with a misconfiguration: a bucket that was public when it shouldn't have been, a role that could do far more than its job required, or a credential that leaked and was never rotated. The classes of misconfiguration below account for the overwhelming majority of the cloud findings we report in cloud penetration tests.

None of this is exotic. That's the point — attackers automate the search for exactly these issues, so the boring misconfigurations are the dangerous ones.

Public S3 Buckets and Objects

The classic. S3 access control has multiple overlapping layers — bucket policies, ACLs, Block Public Access settings at both bucket and account level — and confusion between them is how data ends up world-readable.

Common variants we see:

• Buckets made public 'temporarily' for a migration or a vendor, then forgotten
• Bucket policies that grant access to any authenticated AWS user — which means any AWS account on the internet, not just yours
• Private buckets serving objects through a misconfigured CloudFront distribution
• Backups, database dumps and log archives in buckets nobody remembers creating

The fix is structural: turn on Block Public Access at the account level, treat any exception as a formally approved risk, and inventory buckets regularly. Public buckets are trivially discoverable — attackers enumerate bucket names from certificate transparency logs, JavaScript source, and plain guessing.

Over-Privileged IAM

IAM is where cloud breaches escalate. A leaked access key or a compromised application is a contained incident when the associated role can do one thing; it's a disaster when the role has AdministratorAccess because someone was debugging in 2022 and never tightened it back up.

The patterns that hurt:

• Wildcard actions and resources ("Action": "*") in policies attached to humans and workloads alike
• Long-lived access keys for IAM users where roles and short-lived credentials would do
• Roles assumable from far more principals than intended — overly broad trust policies are a favourite privilege-escalation path
• Permissions that allow indirect escalation: iam:PassRole plus the ability to launch a service, or iam:CreatePolicyVersion on your own policy, quietly equals admin

Least privilege is tedious, which is why it rarely happens by default. Tools like IAM Access Analyzer and last-accessed data make trimming realistic. And if credentials do leak, speed matters — we've written about what to do when credentials leak.

Exposed EBS Snapshots and AMIs

Snapshots and machine images inherit none of the instance's network protections. A snapshot shared publicly — or shared to the wrong account ID — hands an attacker the entire disk: configuration files, embedded credentials, SSH keys, application source, and whatever data was on the volume.

This happens more than it should because sharing a snapshot is a one-line action often used to move data between accounts, and 'public' sits one dropdown away from 'shared with account X'. Audit ec2 describe-snapshots for anything with public launch permissions, and treat RDS snapshots the same way — a public RDS snapshot can be restored by anyone into their own account.

Metadata Service Abuse

Every EC2 instance can query the instance metadata service (IMDS) for the temporary credentials of its attached role. That's how AWS auth is supposed to work — until an attacker reaches the metadata endpoint through your application.

A server-side request forgery (SSRF) bug in a web app running on EC2 becomes a cloud breach when the attacker points it at the metadata endpoint and reads the role credentials. This is a well-worn path in real-world incidents, and it's why IMDSv2 exists: it requires a session token obtained via a PUT request, which most SSRF primitives can't produce.

Enforce IMDSv2 (HttpTokens: required) across the fleet, set the hop limit to 1 so containers can't reach the host's credentials unless they're meant to, and — critically — keep the roles behind the metadata service minimal, because IMDSv2 mitigates the access path, not the blast radius.

Flat Networks and Wide-Open Security Groups

VPCs default to being one flat network unless you design otherwise. The recurring issues:

• Security groups allowing 0.0.0.0/0 to SSH, RDP, or database ports — often left over from initial setup
• No segmentation between environments, so a compromised dev box can reach production databases
• Internal services (Elasticsearch, Redis, admin panels) with no authentication because 'it's internal' — which stops meaning anything after the first foothold
• VPC peering and Transit Gateway routes that quietly connect everything to everything

Segment by trust boundary, not convenience. Assume one workload will be compromised and ask what it can reach — that question is the core of the lateral-movement phase in any competent cloud or external network penetration test.

Finding These Before an Attacker Does

Configuration scanners (including AWS's own Security Hub and Config) will flag much of the above and are worth running continuously. What they can't do is chain findings the way an attacker does: SSRF to metadata credentials, credentials to snapshot access, snapshot to hardcoded secrets, secrets to admin. That chaining is what a manual cloud penetration test adds — ours run 4–8 days and are priced at AU$6,000–14,000, with a fixed quote after a free scoping call.

FAQ

Isn't AWS responsible for securing my environment?

Only partly. Under the shared responsibility model, AWS secures the underlying infrastructure; everything you configure — IAM, S3 policies, security groups, snapshots — is yours to get right.

How do attackers find AWS misconfigurations?

Mostly automation: enumerating bucket names, scanning exposed services, trawling public snapshots and leaked keys in code repositories. Public misconfigurations are usually found within hours, not weeks.

How often should we review our AWS configuration?

Continuously via automated tooling, plus a manual cloud penetration test annually or after significant architecture changes — new accounts, new workloads, major IAM refactors.

If you'd like a practitioner-led review of your AWS environment — not just a scanner report — get in touch. We'll scope it in a free call and send a fixed quote within one business day, with a free retest of fixed issues within 90 days.