About this playbook¶
My AWS access keys were exposed and are being exploited by a threat actor. What do I do?!?! Step 1: Don’t panic! There are playbooks that can help you in this situation.
Cheat Sheet¶
The playbook for IAM credentials exposure and exploitation¶
AWS has multiple Incident Response playbooks you can access for free and has one exactly for this scenario. These can be helpful in an emergency situation, but also in taking pre-emptive action and in helping you develop your own playbooks.
At a high level, you want to figure out:
- 💥 Vulnerabilities exploited
- 💥 Exploits and tools observed
- 💥 Actor’s intent
- 💥 Actor’s attribution
- 💥 Damage inflicted to the environment and business
To ultimately achieve your recovery point: returning to the original plus hardened configuration.
You can get there by following response steps from NIST:
- ✅ Analysis
- ✅ Containment
- ✅ Eradication
- ✅ Recovery
- ✅ Post-incident activity
This isn’t always a linear process. For example, once you’ve performed basic analysis and identified it’s not a false positive, you may want to contain by disabling exposed credentials before moving on to further analysis.
In this playbook, AWS recommends using Amazon Athena for most of the analysis. Athena can perform advanced querying across multiple AWS sources like:
- ALB
- CloudFront
- CloudTrail
- GuardDuty
- and more
Directly from Amazon S3 by using SQL. It basically kind of turns your S3 data into an SQL database without directly modifying the S3 data.
Of course, you can use other tools. Maybe you've only got CloudTrail Lake up and running, in which case you may have limited visibility since you may not be pulling the same type of data. Or, maybe you've got a third party SIEM running.
Common causes of compromised access keys¶
100% of compromised access keys happen because you're using access keys. This might seem obvious, but you should really be moving away from using access key.
- Phishing (social engineering in general)
- Leaked environment variables
- Hardcoded credentials in code
- Malware
Other possibilities include:
- SSRF (Server-Side Request Forgery)
- Breached 3rd party
- Internal threat actors
Steps¶
- [ANALYSIS] Validation - Validate alert by checking ownership of exposed credential
- [ANALYSIS] Scope - Gather info about what's happened, inventory resources involved, determine it's not a false positive
- [ANALYSIS] Impact - What's the business impact?
- [CONTAINMENT] How you contain here depends on a lot of factors, highlighted in the cheat sheet above
- [ERADICATION] ie: delete affected IAM Users, resources, etc... then apply security updates and hardening
- [RECOVERY] If needed / as needed. ie: re-create destroyed resources, restore data, etc...
- [POST-INCIDENT ACTIVITY] Recommendations include automating containment and eradication steps, saving queries used to investigate for future use, eliminating long-term credentials, and enabling additional alerts