Skip to content

IAM Role credential exfiltration

Generate a finding manually

All of the simulated attacks and findings are generated automatically in the CloudFormation template except for one; which requires you to take some manual steps. To produce the final finding, you will need to copy the IAM temporary security credentials from the EC2 instance and manually make API calls from your laptop.

API calls need to come from outside the AWS network or they will not generate findings

Retrieve the IAM temporary security credentials using AWS Systems Manager

To simulate this last and final attack you will need to retrieve the IAM temporary security credentials generated by the IAM Role for EC2. You can either SSH directly to the instance and query the metadata or follow the steps below to use AWS Systems Manager Session Manager (an SSM agent was automatically started on the instance at launch).

  1. Go to Fleet Manager within the AWS Systems Manager console (us-west-2).

    You should see an instance named GuardDuty-Example: Compromised Instance: Scenario 3 with a ping status of Online.

  2. To see the keys currently active on the instance, click on Session Manager on the left navigation and then click Start Session.

  3. To see the credentials currently active on the instance, click on the radio button next to Compromised Instance: Scenario 3 and click Start Session.
  4. Run the following command in the shell:
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/GuardDuty-Example-EC2-Compromised
  1. Make note of the AccessKeyID, SecretAccessKey, and Token.

Create a new AWS CLI profile on your laptop to use the IAM temporary credentials

Now that you have retrieved the IAM temporary security credentials you will need to add them to an AWS CLI profile. There are a number of ways to do this, but below are some commands to help get you started:

From a command prompt, run the following commands (replace the variables with your credentials):

aws configure set profile.badbob.region us-west-2
aws configure set profile.badbob.aws_access_key_id <access_key>
aws configure set profile.badbob.aws_secret_access_key <secret_key>
aws configure set profile.badbob.aws_session_token <session_token>

If you view your local aws credentials file, you should now see an [badbob] profile with the stolen IAM temporary credentials.

Run commands using the IAM temporary credentials

Now that you have your named profile you can use it to make API calls. Use the commands below to query different services to see what you have access to.

Don't be surprised if you see some access denied responses, it is intended

Do you have any IAM permissions:

aws iam get-user --profile badbob

aws iam create-user --user-name Chuck --profile badbob

What about DynamoDB?

aws dynamodb list-tables --profile badbob

aws dynamodb describe-table --table-name GuardDuty-Example-Customer-DB --profile badbob

Can you query the data?

aws dynamodb scan --table-name GuardDuty-Example-Customer-DB --profile badbob

aws dynamodb put-item --table-name GuardDuty-Example-Customer-DB --item '{"name":{"S":"Joshua Tree"},"state":{"S":"Michigan"},"website":{"S":"https://www.nps.gov/yell/index.htm"}}' --profile badbob

aws dynamodb scan --table-name GuardDuty-Example-Customer-DB --profile badbob

aws dynamodb delete-table --table-name GuardDuty-Example-Customer-DB --profile badbob

aws dynamodb list-tables --profile badbob

Do you have access to Systems Manager Parameter Store?

aws ssm describe-parameters --profile badbob

aws ssm get-parameters --names "gd_prod_dbpwd_sample" --profile badbob

aws ssm get-parameters --names "gd_prod_dbpwd_sample" --with-decryption --profile badbob

aws ssm delete-parameter --name "gd_prod_dbpwd_sample" --profile badbob

After manually remediating the previous GuardDuty finding, you have finally finished your first cup of coffee when an email notification comes in alerting you to yet another finding. You finish reading the first email and then a minute or so later you see the relevant remediation email, meaning Alice has already put in place a remediation for this finding. The other findings you looked at dealt with EC2 instances and AWS IAM credentials separately, but this finding appears to be related to an AWS IAM Role associated with an EC2 instance. You decide to take a closer look at the finding and remediation.

None of your personal IAM credentials have actually been compromised or exposed in any way.

Architecture Overview

Attack Scenario 3

  1. The remote host accesses the compromised instance and exfiltrates the IAM role credentials via the metadata.
  2. The remote host sets up a CLI user to make API calls to the AWS account to which the credentials belong.
  3. GuardDuty generates a finding and sends this to the GuardDuty console and CloudWatch Events.
  4. The CloudWatch Event rule triggers an SNS topic and a Lambda function.
  5. SNS sends you an e-mail with the finding information.
  6. A Lambda function attaches a policy to the role revoking all active sessions.

Investigation

Browse to the GuardDuty console to investigate

To view the findings:

  1. Navigate to the GuardDuty console (us-west-2) and then, in the navigation pane on the left, choose Current.

  2. Click the Refresh icon to refresh the GuardDuty console. You should see a finding with the type UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS.

  3. Click on the UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS finding to view the full details.

Looking at the finding details you can see that this is actually a High Severity finding. This finding informs you of attempts to run AWS API operations from a host outside of EC2, using temporary AWS credentials that were created on an EC2 instance in your AWS account. This means your EC2 instance has been compromised, and the temporary credentials from the instance have been exfiltrated to a remote host outside of AWS.

You will notice that each GuardDuty finding has an assigned severity level (low, medium, or high) that can help you determine your response to a potential security issue that is highlighted by the finding. These severity levels are preset by AWS but we have seen customers modify these values in their automation workflows to better align the risk of that finding in the context of their environment and requirements.

View the CloudWatch Event rule

  1. Navigate to the CloudWatch console (us-west-2) and on the left navigation, under the Events section, click Rules.
  2. Click on the rule that Alice configured for this particular finding (GuardDuty-Event-IAMUser-InstanceCredentialExfiltration).

Take a closer look at the Event Pattern. The pattern Alice setup for all the rules specifies particular findings.

Like Alice, you can create CloudWatch Event Rules that are triggered for particular findings but you can also create a rule that is triggered based on any GuardDuty finding in order to have a centralized workflow. Below is an example of an Event Pattern that would trigger for any GuardDuty finding:

{
  "detail-type": [
    "GuardDuty Finding"
  ],
  "source": [
    "aws.guardduty"
  ]
}

View the remediation Lambda function

Alice also set up a remediation for this threat. Look through the Lambda Function code to better understand the remediation.

Go to the Lambda console (us-west-2) and review the function named GuardDuty-Example-Remediation-InstanceCredentialExfiltration.

The Lambda Function retrieves the Role name from the finding details and then attaches an IAM policy that revokes all active sessions for the role.

What permissions does the Lambda Function need to perform the remediation? Is there a risk associated with this level of permissions?

Verify that the remediation was successful

To verify that the InstanceCredentialExfiltration finding was remediated, you can run one of the CLI commands you ran earlier.

aws dynamodb list-tables --profile attacker

You should see a response that states that there is an explicit deny for that action. Go view the Role to evaluate the policy that was attached.

  1. Browse to the AWS IAM console.
  2. Click Roles in the left navigation.
  3. Click on the Role you identified in the GuardDuty finding and email notifications (GuardDuty-Example-EC2-Compromised).
  4. Click the Permissions tab.
  5. Click on the RevokeOldSessions Policy.

Questions

What are the risks involved with this remediation?

What other EC2 instances are using this Role?