Setting up security in the cloud is of utmost importance. A security breach is a nightmare for any organization and a proactive security approach is the best possible way to prevent security breaches from happening. But, response methods in case of security breach also carries an equal weightage.
I will demonstrate the 2 scenarios of handling the User Access compromise in this article.
You are giving a live presentation or uploaded a video on a public portal and by mistake exposes your programmatic access credentials.
In this scenario, you are aware of your mistake and know that action needs to be taken before any damage to your AWS environment is done.
Steps to be followed:
- Go to your IAM user and make the access keys Inactive. This will stop anyone using your access credentials. This is the most important step and has to be followed ASAP.
2. There could be chances that the intruder has used this access key ID to issue temporary credentials(Session token) to different AWS services. These temporary credentials can be used between 15 mins to 36 hours. Add an Explicit Deny policy to the IAM user will stop the usage of any temporary credentials generated by the IAM user.
These 2 steps will stop the unauthorized use of your Access Key ID. Create your new access key IDs and always prefer IAM roles over access IDs.
You are reviewing your code in public repository and shocked to find that you forgot to remove the programmatic access from the code which was uploaded 3 days ago.
In this scenario, you are not aware of whether your AWS environment is already breached or not.
Steps to be followed:
- Follow both the steps which are mentioned in Scenario 1. These steps will at least stop the unauthorized access by using your programmatic access ID.
- Generate credentials report in IAM using the below-mentioned command. CSV file will be generated and find out the attribute values of access_key_last_used_date and access_key_last_rotated. This will provide you with some information on the access key usage.
aws iam get-credential-report
3. Go through the CloudTrail logs and find the events created for your user. This will help in scoping the damage done by the user. Take appropriate action for all the services which seem to be accessed by assuming the role from your access IDs. Below are the screenshots of the Cloudtrail events created.
4. Validate the CloudTrail logs using the digest files. This will help in confirming whether intruders tried to cover the tracks after making the changes.
Each digest file contains the names of the log files that were delivered to your Amazon S3 bucket during the last hour, the hash values for those log files, and the digital signature of the previous digest file. If the logs or digest files are deleted then the log validation will fail.
Run the following AWS CLI command to validate the logs:
If there is no modification or deletion of the CloudTrail events then the validation will pass with the following message.
However, if the Trails or digest are modified or deleted following output will be provided by the validation command.
Both these cases present that your AWS environment is breached and you need to do the forensics on all the services whose roles can be assumed by your user.
A proactive approach to prevent Scenario 2 is to provide the least-privileges to IAM users. Users with Admin access should have MFA enabled. Multiple preventive guardrails can help in reducing the blast radius.
Stay Alert and Stay Safe.