Skip to content

Latest commit

 

History

History
68 lines (51 loc) · 3.52 KB

File metadata and controls

68 lines (51 loc) · 3.52 KB

AWS - SQS Persistence

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

SQS

For more information check:

{% content-ref url="../aws-services/aws-sqs-and-sns-enum.md" %} aws-sqs-and-sns-enum.md {% endcontent-ref %}

Using resource policy

In SQS you need to indicate with an IAM policy who has access to read and write. It's possible to indicate external accounts, ARN of roles, or even "*".
The following policy gives everyone in AWS access to everything in the queue called MyTestQueue:

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

{% hint style="info" %} You could even trigger a Lambda in the attackers account every-time a new message is put in the queue (you would need to re-put it) somehow. For this follow these instructinos: https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %} {% endhint %}