If you were notified of suspicious user behavior and believe that an Amazon Web Services (AWS) account has been compromised, consider the following steps:
- Change your AWS root account password or the passwords of IAM users.
- Delete or rotate AWS access keys of the affected account.
- Delete any resources created by the compromised account, especially running EC2 instances, EC2 spot bids, or IAM users.
- Review/confirm recent user activities.
- Review user permissions in the AWS console.
Read on for additional information about each solution.
Step #1 – Change Passwords
If the root AWS account was compromised, change your AWS root account password and the passwords of any IAM users for whom the root account reset the password, using CloudTrail to review for password resets. If another IAM user's account was compromised, change that account password.
To change your root AWS password, refer to AWS documentation on How do I change the password associated with my AWS account? For information on changing the password of an IAM user, refer to AWS documentation on Managing Passwords for IAM Users.
It is strongly recommended to protect your root account with multi-factor authentication using a hardware key. It’s a best practice to change your passwords on a regular basis to avoid unauthorized use of your account. For information on AWS security best practices, refer to the whitepaper at AWS Security Best Practices.
Step #2 – Disable, Delete, or Rotate Access Keys
If your application access key has been compromised, replace the compromised key with a new one. Create a new key, modify your application, and disable (but do not delete) the first key. If there are any problems with your application using the new key, reactivate the first key temporarily. When your application is fully functional with the first key in the ‘disabled’ state, delete the first key.
Treat AWS access keys the same way you would treat an account password—do not provide access keys to anyone you do not know and trust, do not publish access keys to public websites or code repositories, and consider best practices when using or managing AWS access keys. You might also consider using IAM roles for EC2 instances, or using STS to generate temporary credentials.
If you find AWS access keys that you no longer need or did not create, consider deleting them.
Solution #3 – Delete Unrecognized or Unauthorized Resources
Sign in to your AWS account and check that all resources currently running on your account are resources you launched. Make sure to check all AWS regions, even regions in which you have never launched AWS resources. Pay special attention to running EC2 instances, EC2 spot bids, or IAM users. If you are not sure how to delete a resource associated with a particular AWS service, find the documentation related to that service at AWS Documentation.
Solution #4 – Review User Activities
Review CloudTrail logs for other activities by the potentially compromised user. You can review seven days of CloudTrail messages in the AWS console or Log Manager customers have access to a year (by default) of CloudTrail messages in the Alert Logic Log Manager console.
Solution #5 – Review Permissions
Limit future impact from compromised user accounts by auditing user, group, and role permissions for opportunities to restrict the permissions. For instance, only authorized users should be able to change password policy requirements. Allowing any user to change this could cause your business to fail a compliance audit.
You may also want to check your remediations in Cloud Insight for users that have overly permissive IAM policies. To check remediations for users, navigate to Remediations > List and use the Refine By section to filter the list to a specific user. Review the list of remediations for the user and address remediations for that user as needed.
Still have questions? Check out other customers’ posts or add your own in the Cloud Insight Essentials community.