Common Cloud Misconfigurations
Almost no cloud breach is a clever exploit. It is a checkbox left wrong.
What you will learn
- -Name the handful of misconfigurations behind most cloud incidents
- -Spot an over-broad security group or IAM grant on sight
- -Understand why the instance metadata endpoint turns SSRF into a full compromise
Nobody is defeating AWS's cryptography. The breaches that matter almost all come from the same short list of settings someone got wrong and nobody caught. If you learn to find these, you find most of what an attacker would, and most of what a real flags.
The security group open to the world
A is a stateful wrapped around an instance or a service. The classic mistake is a rule allowing 0.0.0.0/0 on a that should never see the public internet: 22 (), 3389 (RDP), 3306 (MySQL), 5432 (Postgres), 6379 (Redis), 27017 (MongoDB). Redis and Mongo are especially brutal because their defaults historically had no at all. Open the port to the world and you have opened the database to the world.
$aws ec2 describe-security-groups --query "SecurityGroups[?IpPermissions[?ToPort==\`22\` && contains(IpRanges[].CidrIp, '0.0.0.0/0')]].GroupId"$aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values=0.0.0.0/0Run that against your own account and you will usually find at least one group someone opened "just to test" and never closed.
Public storage
Public their own lesson next because there is a lot to say. The short version: default-private storage that got flipped public by an ACL, a bucket , or a lazy --acl public-read on upload is behind a long list of data leaks. Azure Blob and GCS buckets have the exact same failure mode.
IAM grants that are too generous
The wildcard policy from the lesson lives here too. Beyond raw "Action": "*", watch for managed policies like AdministratorAccess attached to a , or a role a public-facing can assume that carries far more than it needs. The principle is , and the reality is that most tenants grant far more than the workload ever calls.
The metadata endpoint, and why SSRF is worse in cloud
This one is the difference between a medium bug and a company-ending one. Every EC2 instance can reach a magic address, 169.254.169.254, that hands back the instance's own metadata, including the temporary for whatever role it assumed. That is convenient for the app. It is a gift for an attacker who finds a server-side request forgery bug.
If a web app will fetch a you give it, you point it at the metadata and read the role's keys straight out of the response.
$curl http://169.254.169.254/latest/meta-data/iam/security-credentials/The fix is , which requires a session obtained by a PUT request first, so a naive that can only issue GETs cannot reach it. Capital One was IMDSv1 plus an over-privileged role plus an SSRF. Kill any one of the three and the breach does not happen.
Reading the metadata endpoint, probing security groups, and enumerating IAM all leave records in the target's account. Do this on your own free-tier resources, flAWS.cloud, or CloudGoat, or under a signed engagement. Hitting someone else's 169.254.169.254 through their app without is a computer-crime charge, not a gray area.
Logging turned off
The quietest misconfiguration: CloudTrail disabled, or on but never read. It does not open a door, it just means nobody sees the attacker walk through the ones already open. The next lesson on logging is where that gets fixed, and it is the that turns a silent breach into a caught one.
An attacker finds an SSRF vulnerability in a web app running on an EC2 instance. Why is this often catastrophic in AWS specifically?