# AWS - STS Enum

{{#include ../../../banners/hacktricks-training.md}}

## 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](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) 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**](../aws-privilege-escalation/aws-sts-privesc.md#sts-assumerole)). 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:

```json
{
  "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:

```json
{
  "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 h**ave permissions to assume it** (in this case this isn't optional even if the assumed role is specifying an ARN).

### Enumeration

```bash
# 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**:

{{#ref}}
../aws-privilege-escalation/aws-sts-privesc.md
{{#endref}}

### Post Exploitation

{{#ref}}
../aws-post-exploitation/aws-sts-post-exploitation.md
{{#endref}}

### Persistence

{{#ref}}
../aws-persistence/aws-sts-persistence.md
{{#endref}}

## References

- [https://blog.christophetd.fr/retrieving-aws-security-credentials-from-the-aws-console/?utm_source=pocket_mylist](https://blog.christophetd.fr/retrieving-aws-security-credentials-from-the-aws-console/?utm_source=pocket_mylist)

{{#include ../../../banners/hacktricks-training.md}}