The CSA Top 10 cloud threats, the SSRF-to-IMDS credential theft chain, and the critical difference between IMDSv1 and IMDSv2 — the attack patterns that dominate modern cloud breaches.
Sign in to mark this article as read and track your progress.
The Cloud Security Alliance (CSA) publishes an annual list of the most significant cloud threat categories. Understanding these is the starting point for any cloud risk assessment.
| # | Threat | Real Example |
|---|---|---|
| 1 | Insufficient identity, credential, and access management | Capital One breach — overprivileged IAM role |
| 2 | Insecure interfaces and APIs | Exposed management APIs without authentication |
| 3 | Misconfiguration and inadequate change control | Public S3 bucket with sensitive data |
| 4 | Lack of cloud security architecture and strategy | Flat network with no micro-segmentation |
| 5 | Insecure software development | Vulnerable code deployed to Lambda |
| 6 | Unsecured third-party resources | Compromised CI/CD pipeline (SolarWinds pattern) |
| 7 | System vulnerabilities | Unpatched OS on EC2 instance |
| 8 | Accidental cloud data disclosure | Dev copying prod data to unprotected bucket |
| 9 | Serverless and container workload misconfiguration | Over-permissive Lambda execution role |
| 10 | Organised crime / advanced persistent threats | Nation-state cloud environment compromise |
Notice that the top three threats are all configuration and access management failures — not sophisticated zero-days. Most cloud breaches are won, not by attackers, but by defenders losing control of identities and configuration.
The most impactful cloud attack chain of the past five years starts with a deceptively simple web vulnerability.
Step 1 — Find an SSRF vulnerability: The attacker identifies a web application that makes server-side HTTP requests based on user input (e.g., a URL fetch, a webhook, a PDF generator).
Step 2 — Pivot to the Instance Metadata Service: The attacker supplies the internal IMDS address as the target URL:
http://169.254.169.254/latest/meta-data/iam/security-credentials/
This address is only reachable from within the EC2 instance — but the vulnerable application is making the request server-side, so it reaches the metadata service.
Step 3 — List attached IAM roles: The IMDS responds with the name of any IAM role attached to the instance (e.g., ec2-prod-role).
Step 4 — Steal temporary credentials: A second request retrieves live AWS credentials:
http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-prod-role
The response includes AccessKeyId, SecretAccessKey, and Token — valid for hours.
Step 5 — Exfiltrate and pivot: The attacker now has AWS credentials usable from anywhere on the internet. They can enumerate S3 buckets, pivot to other services, escalate privileges, and exfiltrate data.
AWS introduced IMDSv2 specifically to break the SSRF-to-IMDS chain.
| Feature | IMDSv1 | IMDSv2 |
|---|---|---|
| Authentication | None — any HTTP GET works | Requires a PUT to obtain a session token first |
| SSRF exploitability | Directly exploitable | PUT request blocks most SSRF (SSRF cannot follow redirects or send PUT) |
| Token lifetime | N/A | 1 second to 21,600 seconds (configurable) |
| Enforcement | Optional | Can be enforced via HttpTokens: required in instance metadata options |
Critical control: Set
HttpTokens: requiredon every EC2 instance or enforce it via an SCP (Service Control Policy) across your entire AWS organisation. This single control blocks the SSRF-to-IMDS chain at its most critical pivot.
GetCallerIdentity calls from unusual IPs immediately after credential issuance169.254.169.254 from unexpected sourcesUnauthorizedAccess:IAMUser/InstanceCredentialExfiltration findingThe SSRF vulnerability class, combined with the power of cloud IAM credentials, creates a high-severity attack path that has compromised organisations running billions of dollars of cloud workloads. Enforcing IMDSv2, auditing for SSRF in web applications, and monitoring credential usage patterns are the three controls that break this chain.