Links

AWS - STS Enum

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
Other ways to support HackTricks:

STS

AWS Security Token Service (STS) is primarily designed to issue temporary, limited-privilege credentials. These credentials can be requested for AWS Identity and Access Management (IAM) users or for authenticated users (federated users).
Given that STS's purpose is to issue credentials for identity impersonation, the service is immensely valuable for escalating privileges and maintaining persistence, even though it might not have a wide array of options.

Assume Role Impersonation

The action AssumeRole provided by AWS STS is crucial as it permits a principal to acquire credentials for another principal, essentially impersonating them. Upon invocation, it responds with an access key ID, a secret key, and a session token corresponding to the specified ARN.
For Penetration Testers or Red Team members, this technique is instrumental for privilege escalation (as elaborated here). However, it's worth noting that this technique is quite conspicuous and may not catch an attacker off guard.

Assume Role Logic

In order to assume a role in the same account if the role to assume is allowing specifically a role ARN like in:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<acc_id>:role/priv-role"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
The role priv-role in this case, doesn't need to be specifically allowed to assume that role (with that allowance is enough).
However, if a role is allowing an account to assume it, like in:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<acc_id>:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
The role trying to assume it will need a specific sts:AssumeRole permission over that role to assume it.
If you try to assume a role from a different account, the assumed role must allow it (indicating the role ARN or the external account), and the role trying to assume the other one MUST to have permissions to assume it (in this case this isn't optional even if the assumed role is specifying an ARN).

Enumeration

# Get basic info of the creds
aws sts get-caller-identity
aws sts get-access-key-info --access-key-id <AccessKeyID>
# Get CLI a session token with current creds
## Using CLI creds
## You cannot get session creds using session creds
aws sts get-session-token
## MFA
aws sts get-session-token --serial-number <arn_device> --token-code <otp_code>

Privesc

In the following page you can check how to abuse STS permissions to escalate privileges:

Post Exploitation

Persistence

References

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
Other ways to support HackTricks: