From Exposure to Lockdown: How AWS Neutralizes Compromised IAM Credentials through Managed Policies

MITRE Techniques

• [T1078 ] Valid Accounts – Exposed AWS IAM access keys were used as long-term credentials for command-line access to an IAM user (‘Access keys grant long-term command line interface (CLI) access to an IAM user.’).
• [T1589.001 ] Gather Victim Identity Information: Credentials – Threat actors targeted exposed AWS access keys and secrets in public repositories and environment files (‘access keys and secrets exposed in public GitHub repositories or through other notices’).
• [T1074.001 ] Data Staged: Local Data Staging – Sensitive credentials were staged into a public GitHub repository during the exposure test (‘Access key and secret successfully pushed to public GitHub Repository’).
• [T1110 ] Brute Force – The article describes GitHub validity checks and STS calls used to test whether exposed credentials remain active (‘GitHub also performs GET requests with the exposed credentials to confirm the credential’s validity’).
• [T1098 ] Account Manipulation – The policy directly denies actions such as creating users, roles, and access keys to block account modification after compromise (‘iam:CreateUser’, ‘iam:CreateRole’, ‘iam:CreateAccessKey’).
• [T1496 ] Resource Hijacking – The policy additions were influenced by cryptomining activity and EC2/Lightsail abuse (‘AWS uncovered a cryptomining campaign’).
• [T1485 ] Data Destruction – The policy added S3 deletion restrictions to prevent attackers from deleting data after exfiltration (‘threat actors delete data from S3 buckets after exfiltration’).
• [T1528 ] Steal Application Access Token – The article notes exposed secrets being checked and quarantined through automated service-provider workflows (‘identify exposed credentials’).