← All articles
// cloud · 6 min
Cloud Misconfigurations: The Breaches Nobody Had to Cause
CLOUD
Most cloud breaches are not clever attacks. They are doors left open. No exploit, no malware — just a setting that should have been off.
| Misconfiguration | Consequence |
|---|---|
| Public storage bucket | Customer data exposed to the internet |
| Over-broad IAM role | One compromise = full account access |
| Exposed metadata endpoint | SSRF → stolen cloud credentials |
| Open security group | Database reachable from anywhere |
| Disabled logging | Nothing to investigate after a breach |
The usual suspects
- Public storage buckets — the classic. Customer data in object storage set to public "just to test something", never reverted.
- Over-broad IAM roles — a service given full admin because scoping permissions was fiddly. When it's compromised, so is everything.
- Exposed metadata endpoints — SSRF plus cloud metadata equals stolen credentials. A design flaw that keeps giving.
- Security groups open to the world — a database port on 0.0.0.0/0 because a developer needed access from home once.
- Disabled logging — so when something does happen, there is nothing to investigate.
Finding them before attackers do
A cloud security review checks identity and access policies, network exposure, storage permissions, logging coverage, and key management across your accounts — mapped to the CIS Benchmarks and provider best practice. Cheap to fix when you find them yourself; catastrophic when a researcher (or worse) finds them for you.
Concerned about any of this in your environment?
I help organisations test, find, and fix exactly these issues — with evidence, not scanner output. Start with a no-obligation conversation.
Written by Abdullah Bin Zarshaid, MSc, CEH.
Discuss your security →