So you leaked your AWS credentials onto the world wide web, and you are wondering what to do to minimize the damage. There are multiple steps that should be taken, but I do think that the order of these steps matter.

We first want to prevent anyone from successfully using these credentials by disabling or removing them. Then we check CloudTrail if the credentials have been used and destroy any launched AWS resources as soon as possible.

This blog is a follow-up on What happens when you leak AWS credentials and how AWS minimizes the damage

Steps to take after leaking credentials

Below you will find a short list of the steps you should take to minimize the damage, below that you will find detailed descriptions of each step.

1. Rotate, disable or delete the exposed AWS credentials
2. Check CloudTrail if the access key has been used
3. Review the AWS account for any unwanted resources

Rotate, disable and delete the exposed AWS credentials

By rotating, disabling and deleting the exposed AWS access key you make sure that anyone who got hold of them is not able to use the credentials anymore.

If the access keys are used by an application you probably have to rotate them. Because if you disable the access keys the application stops working. So you first have to create a new access key and update the application, and then disable (not delete) the access key. The reason to not delete the access key is if there is any problem with your application after disabling you can enable them again. When the application is fully working you can delete the exposed access key.

Read more about this here: AWS blog: How to Rotate Access Keys for IAM Users

Check CloudTrail for access key usage

After leaking the credentials, bots are very fast with finding the access key and trying to abuse them. Therefore, you have to make sure the access key has not been used by anyone who should not have. This can be done by looking into CloudTrail and filtering on the access key. We can consider any usage the malicious actor have done as unwanted. But there are something’s to specially look out for. Namely, creating anything in IAM, starting any compute (EC2, Lambda, Lightsail), creating or modifying the organization.

These actions are harmful because the malicious actor can continue to access the AWS environment even when the initial access tokens used to access the environment are disabled.

Review the AWS account for any unwanted resources

This part could be a bit tedious, because you have to check the whole account for any unwanted resources. It can be made easier by looking at the billing dashboard to see any high or unusual costs. But if the malicious actor just launched a cheap t3 instance this won’t be noticed.

You could think that because you looked at the CloudTrail logs you have seen everything that the malicious actor did with the access key. But this is not enough I think, because the malicious actor could have assumed a role and created resources that way. You could off course also see the assume role API calls in CloudTrail. But I would be better safe than sorry :)

Conclusion

When AWS credentials are leaked you should take action immediately to minimize the damage done.

1. Rotate, disable or delete the exposed AWS credentials
2. Check CloudTrail if the access key has been used
3. Review the AWS account for any unwanted resources

By following the steps mentioned here you will minimize the damage that can be done and get more information on what and if the AWS credentials have been used.