After this lesson, you will be able to: Explain cloud attack techniques: SSRF to the instance metadata service to steal credentials (the Capital One mechanism), IAM privilege escalation, and lateral movement between cloud services.
This lesson covers how attackers turn misconfigurations into compromise: the metadata-service SSRF attack that stole credentials in the Capital One breach, IAM privilege escalation paths, and lateral movement between cloud services.
Cloud instances expose a metadata service at a link-local address (169.254.169.254 on AWS) that returns instance information and, critically, the temporary IAM credentials of the instance's role. If an application has a server-side request forgery (SSRF) flaw that lets an attacker make the server fetch an attacker-chosen URL, the attacker points it at the metadata endpoint and reads the role's credentials. This is exactly how the 2019 Capital One breach worked: an SSRF reached the metadata service, stole the role's credentials, and used them to read S3 data. The defense is IMDSv2 (which requires a session token and blocks naive SSRF) plus fixing the SSRF and least-privileging the role.
Even a limited identity can sometimes escalate if its permissions allow it to grant itself more: attaching a more powerful policy, creating a new access key for a privileged user, passing a powerful role to a service it can invoke (iam:PassRole misuse), or updating a Lambda's execution role. Tools like Pacu and the research from Rhino Security Labs catalog dozens of these escalation paths. The lesson: a 'small' permission like iam:PutUserPolicy can be a path to admin.
Once an attacker has some credentials, they pivot. Stolen instance credentials might read secrets from Parameter Store, which unlock a database, whose contents reveal more keys. A compromised Lambda role might access an S3 bucket that holds deploy credentials. Cloud lateral movement follows the IAM graph: each over-broad permission is an edge an attacker can traverse. This is why least privilege and segmentation matter so much.
Deploy a vulnerable-by-design AWS scenario into your own account.
1. In your own AWS account (free tier), install CloudGoat and deploy a scenario (for example, an IAM privilege-escalation or SSRF scenario).
2. Start from the low-privilege credentials CloudGoat gives you.
3. Enumerate your permissions and the environment.
4. Find and exploit the misconfiguration (e.g. SSRF to metadata, or an IAM escalation path) to reach the goal.
5. Destroy the CloudGoat resources when done (cloudgoat destroy) to avoid charges, and write up the path plus the remediation (IMDSv2, least privilege, fixing the SSRF).
Pick one.
Leaving IMDSv1 enabled, so any SSRF becomes credential theft. Over-privileging instance and Lambda roles. Ignoring iam:PassRole and policy-modification permissions as 'minor.' Storing secrets where a pivoted role can read them. Not destroying lab resources (surprise bill). Treating SSRF as a low-severity web bug when in cloud it can mean full account compromise.
Sign in and purchase access to unlock this lesson.