DEV Community: Bennet Sharwin

Penetration Testing on AWS Goat

Bennet Sharwin — Wed, 10 Dec 2025 13:04:46 +0000

Previously we have set up AWSGoat using terraform and AWS cli. Now its ready to receive requests.

What is The AWSGoat?

AWSGoat is a Vulnerable AWS Infrastructure for teaching people to AWS cloud vulnerabilities and pentesting. It has some vulnerabilities like;

· XSS
· SQL Injection
· Insecure Direct Object Reference
· Server Side Request Forgery on Lambda Environment
· Sensitive Data Exposure and Password Reset
· S3 Misconfigurations
· IAM Privilege Escalations
· ECS Container Breakout

The terraform apply command after finishing gave us this link:

app_url = "https://lboeqh1eq7.execute-api.us-east-1.amazonaws.com/prod/react"

visiting the URL:

Cross Site Scripting (XSS)

In the search bar if I search something that will give me search results:

This is a possible XSS, So I tried a simple XSS Injection and it worked

This proves the site is vulnerable to Reflex XSS attacks.

Clicking on the profile icon at the top - right there is a login page and when we visit it there is a Register page too, lets create a fake account and see what it holds.

lets create a fake account.
After registering it took us to the home page

Insecure Direct Object Reference (IDOR)

Surfing through all the pages there is a profile page where I can change my profile. The possibility of IDOR existing here is high.

I opened burp and started intercepting the requests that's going to the server to understand which API call is used and how it is being used.

Looks like its just changing the password based on an id . That means if we manipulate it we can change the password of another user.

And it worked I successfully changed the password of another user. This confirms the existence of IDOR vulnerability.

SQL injection

Going to the user tab there is a search box, and upon tinkering with it, I found that each time you type something it sends a request to the backend, There is a possible SQL Injection here.

Lets type something and inspect the request

That gives is this an SQL Injection is possible here, lets send it to the repeater.

Now lets go to the repeater tab in burp, and try the SQL Injection

And it works, it gives us all the details about the users present.
Now if we want we can change any users password and impersonate him. But that is not going to get us anywhere.

Server Side Request Forgery SSRF

Now we can check for SSRF vulnerabilities in the webpage, when I went to the newpost tab, I saw that we can upload an image or enter a URL for the image.

What if we put a file URL instead? so I tried to get the contents of /etc/password .

Click upload and submit. Now to view the post go to the Posts tab, and click on all posts.

Click on the post we have created. Go to inspect and refresh the page.

We know that in AWS most of the time, images are stored in S3 buckets, so most probably the file we uploaded in place of the image will also be uploaded to the S3.

Looking at the request there is a png that failed, and it is being loaded from a bucket. Lets see what's inside of it by downloading it. Right click and copy its URL and use wget to download.

This gave us the contents of /etc/passwd

Now we can understand that SSRF is completely possible here.

Lets check other files like environment variables. Lets create a new post and instead of file:///etc/passwd we will look for /proc/self/environ

Now click Upload and go to Burp Suite to intercept the request, turn on response intercept.

We have a bucket link, lets download it and check the contents.

That's the entire dump of the environment variables that has been set in the instance. With a few commands we get a clear view:

Now this has all the credentials and endpoint URL's we need.

lets load this credentials to a separate aws profile by editing the ~/.aws/credentials file.

lets run a identity check command to see if the creds worked:

Okay, that worked. We have the user ID, Account No, and the AWS Resource Name

Gaining access to the EC2 Instance

After surfing around using the credentials and seeing what we have access to, we can finally find s3 buckets, lambda function and two dynamodb tables blog_posts and blog_users.
Use this command to find the functions:

aws dynamodb list-tables --region us-east-1

lets take a look inside those tables

firstly blog-users:

aws dynamodb scan --table-name blog-users --region us-east-1

This contains a list of all the users and their details including security questions and password hashes.

Now lets look at the S3 buckets

This looks odd, a development bucket is also present with the production one. Sometimes this contains important information

lets go through all those files to find something

In this folder: /shared/files/.ssh/ there are multiple keys that was supposed to stay hidden. And in the same folder there is file called config.txt, this file contains information such as IP, hostname, port, user, and the location to the key. Lets download it:

And this is the config.txt:

since we have the IP addresses lets see if they are actually open to receive SSH connections, we will use nmap to scan those ports

Looks like the second IP is ready to accept connections, lets try logging in with its SSH key

We have successfully logged into the EC2 instance.

IAM Enumeration

In the newly exploited EC2 instance lets check the roles we have.

Lets see what all policies does AWS_GOAT_ROLE role have:

The role AWS_GOAT_ROLE has full access to AWS S3.
The other role is in development. lets take a closer look at it:

IAM policies can have up to 5 versions but this only has one.

This looks like we can perform multiple IAM action with this policy. one that stands out is iam:CreatePolicy . This could allow us to create a policy that will escalate our privileges to Admin.

So In order to create a admin account that has privileges to everything like a root account we need to create a policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

Now lets create the policy with the name adminesc:

aws iam create-policy --policy-name adminesc --policy-document file://policy.json

Now that we have created a policy that has access to anything like a root user we need to attach it to a user, group or role:
Before we logged into this ec2 machine we had a different role we got from the SSRF attack, its name was blog-application-data .

This role by default this didn't have any high level access like to create a new user or something

as the AWS_GOAT_ROLE we have access to create and attach policies, so we can attach the high privilege policy to blog-application-data

Lets try creating a user again

lets give him maximum administrative access by attaching a administrative policy

We successfully created a Administrative user with maximum privileges.

Roadmap

Setting up AWS Goat

Bennet Sharwin — Wed, 10 Dec 2025 12:38:56 +0000

Objective

Run AWS Goat on a real AWS account → practice discovery & remediation on actual AWS infrastructure with real IAM policies, real networking, and real cloud attack paths.

Goals & constraints

Goal: Deploy AWS Goat on a real AWS account to understand how vulnerable services behave in an actual cloud environment.
Constraint: Minimize charges - destroy resources when done. Monitor billing → Free Tier covers most AWS Goat labs.

Required tools

AWS Account (Free Tier works)
AWS CLI
Terraform
Kali/Parrot VM (attacker environment)
IDE for editing Terraform files (VSCode recommended)

High-level architecture

Real AWS Account - all resources deployed into AWS cloud.
Terraform - provisions vulnerable AWS Goat modules.
Attacker VM - uses AWS CLI/SDKs to enumerate & exploit.
Control machine - where Terraform & AWS CLI run.

Isolation: use a separate AWS account or AWS Organizations sub-account to avoid contaminating production environments.

AWS Goat Pentesting Lab

1. Configure AWS CLI for real AWS

Create an AWS profile:

aws configure --profile awsgoat

Use your real AWS credentials:

AWS Access Key ID: <YOUR_KEY>
AWS Secret Access Key: <YOUR_SECRET>
Default region name: us-east-1
Default output format: json

You can find the keys or create a new one by going to AWS console go Your account > Security Credentials > Create Access Key

Environment variable are needed because terraform uses it to find the Access Keys:

export AWS_PROFILE=awsgoat
export AWS_DEFAULT_REGION=us-east-1
export AWS_ACCESS_KEY_ID=xxxxxxxxxxxxxx
export AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxx

add this in your .bashrc or run them in the current terminal session (recommended).
The profile name should be same as the one that you have configured aws command with.

2. Clone AWS Goat repository

git clone https://github.com/ine-labs/AWSGoat
cd AWSGoat/modules/module-1

3. Use the default Terraform provider

Your provider should look like this in the main.tf file:

provider "aws" {
  region = "us-east-1"
}

Terraform will now connect directly to AWS.

4. Initialize Terraform

terraform init

5. Deploy AWS Goat to real AWS

terraform apply -auto-approve

Terraform will start provisioning vulnerable infrastructure: S3 buckets, Lambda, IAM roles, EC2, API Gateway, etc.

Grab a coffee, this will take a few minutes.

6. Verify AWS Goat resources in AWS

List S3 buckets:

aws s3 ls --profile awsgoat

List Lambda functions:

aws lambda list-functions --profile awsgoat

List EC2 instances:

aws ec2 describe-instances --profile awsgoat

Now the instances have been created and a public URL has been generated, after the pentesting you can destroy everything you have created using terraform itself.

Cleanup (important)

Always destroy resources when finished:

terraform destroy -auto-approve

This prevents unnecessary AWS charges.

Disclaimer

This setup is designed to run within the AWS Free Tier by default. However, staying within the Free Tier is not guaranteed. Usage beyond the intended scope, leaving resources running longer than necessary, or modifying the deployment may result in charges. Always monitor your AWS billing dashboard and ensure all provisioned resources are properly destroyed when no longer needed.