CDRGoat Scenario 2: Web Vuln to Full Account Takeover via SSM & IAM

This blog is part of our CDRGoat Series. To learn more about why we created CDRGoat, click here, and how to get started with CDRGoat, click here.

Let’s dive in to our first attack scenario together: CDRGoat Scenario 2. This scenario demonstrates how a simple but popular web application vulnerability, SSRF, can escalate into complete AWS account compromise. We'll walk through a realistic attack chain that leverages common cloud misconfigurations rather than obvious security flaws.

An SSRF vulnerability allows an attacker to influence a web application's functionality to fetch a remote resource using a user-supplied URL. By exploiting this, attackers can compel the vulnerable server to send requests to internal network endpoints that are normally protected by network controls.

Explore Scenario 2 of CDRGoat!

Phase 1: Initial SSRF Exploitation and IMDS Token Theft

The first step involves exploiting the SSRF vulnerability to steal IAM credentials from the EC2 instance hosting the web application, specifically, the IMDS tokens.

By default, cloud assets have no roles, meaning the stolen token may not have permissions for a next move. Users do this for a number of legitimate purposes: jump boxes, Kubernetes nodes, web application data stored in S3 buckets, and more.

Phase 2: Permission Enumeration and Reconnaissance

Next, the attacker discovers what permissions they've gained access to.

With over 5,000 unique IAM actions possible, full permission enumeration takes significant time, so we focus on the most common ones.

Using GetCallerIdentity, we identify the role name we have access to. The next allowed action lets us get information about EC2 assets, revealing we attacked the public "EC2a" host and there's a private virtual machine "EC2b" in the account.

We also checked for two specific permissions providing direct EC2 shell access: ec2-instance-connect:SendSSHPublicKey and ssm:SendCommand.

One method works! EC2a was likely configured as a jump host or orchestrator, then repurposed as a public web server without reconfiguring permissions - a common real-world scenario. Using AWS Systems Manager (SSM), we can communicate directly with private EC2b, which doesn’t have a public IP address.

Phase 3: Lateral Movement to Private EC2

Rather than stealing EC2b's IMDS token, we deliver tools directly to the instance for internal pivoting, making our attack more stealthy.

We directly query "who am I?" and "what can I do?" instead of manual enumeration. This works because EC2b has these permissions: iam:ListRoles, iam:ListRolePolicies, iam:GetRolePolicy and iam:GetRole.

Phase 4: Privilege Escalation via Lambda

We discover a dangerous permission combination of permissions: lambda:CreateFunction, iam:PassRole and lambda:InvokeFunction. With CreateFunction and PassRole, we can create a Lambda function, attach any role to it, and execute it using InvokeFunction.

The key is finding a role that we can assign our new Lambda Function to for privilege escalation. We selected iam:AttachRolePolicy. Any role with this policy allows our Lambda to add the “FullAdmin” policy AdministratorAccess to a role we control, like the one stolen from EC2a.

Fortunately, from EC2b, we have the permissions needed to perform this quick search.

We discovered three roles configured in the account, and identified that StreamGoat-AttachRolePolicy-Role has the permissions we’re looking for. We create a Lambda that assigns the AdministratorAccess default policy to StreamGoat-JumpHostRole.  

Then, with crossed fingers, we execute the Lambda.

Validation and Impact

Using the same permission enumeration from the beginning, we validate our success.

Now we can access many assets storing sensitive information: RDS, S3, KMS, Secrets Manager, and others. Mission accomplished!

Check your SIEM to validate if you detect anything suspicious.

Behind the Scenes of CDRGoat Scenario 2

Most readers have heard the scary stories about how SSRF vulnerabilities in web applications can instantly lead to full infrastructure compromise in cloud environments. Such a compromise could be considered “simple” if Full Admin roles were assigned to EC2 instances. But that type of configuration isn’t one that I’ve ever encountered in the real world.

This scenario examines a longer, more realistic attack chain starting from SSRF vulnerability.

When attackers identify SSRF on servers, they can use them as proxy servers for web requests, enabling communication with internal resources not meant to be public.

In the public cloud, the Metadata API at 169.254.169.254 is particularly sensitive. Compute resources communicate with it for authorization tokens for further internal communication. The vector becomes interesting (from the attacker’s POV) when EC2 instances have assigned IAM roles rather than running standalone. This is the IAM compromise chain we developed for Scenario 2.

By working through CDRGoat Scenario 2, you’ll see how seemingly small vulnerabilities and permissive role configurations chain into full-account compromise.

Explore Scenario 2 of CDRGoat yourself to walk through the attack chain and validate your team’s defenses.

Disclaimer

This content is provided for educational and informational purposes only. Stream.Security’s CDRGoat is provided as-is without warranties of any kind. By using this project you accept full responsibility for all outcomes. Scenarios are intentionally vulnerable and must only be deployed in isolated, non-production accounts. Stream.Security does not guarantee the accuracy or completeness of the content and assumes no liability for any damages resulting from its use.

Stream.Security does not endorse or condone any illegal activity and disclaims any liability arising from misuse of the material. Stream.Security and project contributors assume no liability for misconfiguration or unintended consequences, including any illegal activity. Ensuring safe and appropriate use is your responsibility.

‍

‍

‍

‍