Credentials Compromise
- Let's say an attacker compromises an employee laptop, finds the file
~/.aws/credentials
, and uses them to configure their own AWS CLI - They run
aws sts get-caller-identity
{ "Account": "111111111111", "UserId": "AIDA00EFXQQ53AZ3IY11U", "Arn": "arn:aws:iam::111111111111:user/alice" }
- They run
aws iam get-account-authorization-details
- in the returned data look up the user
alice
- find this user has the
AdministratorAccess
policy attached, which allows theAction *
on theResource *
- in the returned data look up the user
- The attacker then looks at
~/.aws/config
on the laptop they compromised and finds:[default] [profile security] source_profile=default role_arn=arn:aws:iam::222222222222:role/admin
- The attacker can now access two accounts, the original 111111111111 and the new 222222222222
- In order for alice to assume this other role, the 222222222222 account might have a trust policy on the admin role that looks like:
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111111111111:user/alice" } }
- The attacker can then review the IAM privileges in the two accounts, and they might come across another user in the account with an IAM policy like:
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::333333333333:role/admin" } }
- The attacker can then user their admin privileges to become that other user and then assume the role into the third account