# AWS - STS Enum

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

## STS

**AWS Security Token Service (STS)** est principalement conçu pour émettre des **identifiants temporaires à privilèges limités**. Ces identifiants peuvent être demandés pour des utilisateurs **AWS Identity and Access Management (IAM)** ou pour des utilisateurs authentifiés (utilisateurs fédérés).

Étant donné que le but de STS est d'**émettre des identifiants pour l'usurpation d'identité**, le service est extrêmement précieux pour **l'escalade de privilèges et le maintien de la persistance**, même s'il peut ne pas avoir une large gamme d'options.

### Usurpation de Rôle

L'action [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) fournie par AWS STS est cruciale car elle permet à un principal d'acquérir des identifiants pour un autre principal, l'usurpant essentiellement. Lors de l'invocation, elle répond avec un ID de clé d'accès, une clé secrète et un jeton de session correspondant à l'ARN spécifié.

Pour les testeurs de pénétration ou les membres de l'équipe rouge, cette technique est essentielle pour l'escalade de privilèges (comme expliqué [**ici**](../aws-privilege-escalation/aws-sts-privesc.md#sts-assumerole)). Cependant, il convient de noter que cette technique est assez évidente et peut ne pas surprendre un attaquant.

#### Logique d'Usurpation de Rôle

Pour assumer un rôle dans le même compte si le **rôle à assumer permet spécifiquement un ARN de rôle** comme dans :
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<acc_id>:role/priv-role"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
```
Le rôle **`priv-role`** dans ce cas, **n'a pas besoin d'être spécifiquement autorisé** à assumer ce rôle (avec cette autorisation, c'est suffisant).

Cependant, si un rôle permet à un compte de l'assumer, comme dans :
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<acc_id>:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
```
Le rôle essayant de l'assumer aura besoin d'une **permission `sts:AssumeRole` spécifique** sur ce rôle **pour l'assumer**.

Si vous essayez d'assumer un **rôle** **d'un compte différent**, le **rôle assumé doit le permettre** (indiquant le **ARN** du rôle ou le **compte externe**), et le **rôle essayant d'assumer** l'autre **DOIT** avoir des permissions pour l'assumer (dans ce cas, ce n'est pas optionnel même si le rôle assumé spécifie un ARN).

### Énumération
```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

Dans la page suivante, vous pouvez vérifier comment **abuser des permissions STS pour escalader les privilèges** :

{{#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}}

## Références

- [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}}
