Tapping a message stream with a policy edit: AWS SQS cross-account siphon

SQS queues carry the data flowing between services, and the queue’s resource policy decides who may read them. Edit that policy and you can quietly tap the stream.

How the attack works

An attacker with permission to edit queue attributes calls SetQueueAttributes to rewrite a queue’s resource policy, adding a cross-account principal as an authorized consumer. That external principal begins calling ReceiveMessage against the queue, reading messages meant for the internal consumer. Because SQS messages are typically delivered once, the rogue consumer can also delete messages it reads, starving the legitimate pipeline and creating an integrity problem on top of the data theft. This is Account Manipulation, T1098, and Data from Cloud Storage, T1530.

Why it works

The tap is implemented purely through the resource policy, so it bypasses any network control. The queue is meant for a single internal consumer, but any role that can set queue attributes can re-add a cross-account allow, and message age, deploys, and throughput look like ordinary operational noise.

How to fix it

Pausing producers leaves the policy open and lets the rogue consumer drain the backlog, and network ACLs do not govern SQS API access. Restore the queue’s original resource policy to remove the cross-account allow, revoke the editing role’s session, and confirm only the intended principal can ReceiveMessage. For the durable fix, inventory queue policies for unexpected cross-account principals, restrict who can call SetQueueAttributes, enforce policy guardrails via a service control policy, and alert on queue-policy changes.

Practice it

We built this as a GraphLattice Range scenario so security teams can rehearse spotting a queue-policy tap, restoring the policy, and scoping both the data read and the messages dropped.