> For the complete documentation index, see [llms.txt](https://www.webhackingtips.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.webhackingtips.com/week-56-cloud-ssrf-privesc.md).

# Week 56 - Cloud SSRF PrivEsc

Picture this: you discover Cloud SSRF on an [#AppSec](https://www.linkedin.com/feed/hashtag/?keywords=appsec\&highlightedUpdateUrns=urn%3Ali%3Aactivity%3A7039254102492504065) engagement, and you’re staring at a set of access keys. If you’re anything like me, you’ll be thinking: now what?? In this post, I will document how to turn those keys into AWS Admin and RCE!\
 \
Most of the time with Cloud SSRF, you’ll be dealing with an AWS environment. This is because Google Cloud and Azure by default require a custom header to be passed in the SSRF request, which means that unless you can specify a custom header for the server to use, you will be SOL. \*Interestingly to note, metadata SSRF can also be prevented in AWS by switching from IMDSv1 to IMDSv2\
 \
Once you pull those access keys, the first step is to figure out what permissions they have associated with them. This can be done through two amazing tools: enumerate-iam and pacu (linked in comments). I will cover enumerate-iam first since it’s easier and has a lower learning curve. You can run it like this:\
 \
`python3 enumerate-iam[.]py –access-key [access_key_here] –secret-key [secret_key_here] –session-token [session_token_here]`\
 \
It will then go through and enumerate the permissions associated with the access key. Some dangerous permissions that could be used to further the severity are:\
 \
s3:ListBuckets => List out S3 buckets, probably some sensitive info in there\
iam:PassRole and ec2:RunInstances => create ec2 instance and pass an existing role to it. Then you have RCE on an OS in the AWS environment\
iam:PutGroupPolicy or iam:PutUserPolicy => attach policy with higher permissions to your own group/role\
iam:CreatePolicyVersion => create a new version of your policy with higher permissions\
iam:AddUserToGroup or iam:CreateAccessKey => add your user to a group with higher permissions\
 \
If you are lazy like me, you can automate this with aws\_escalate\[.]py (linked in comments).\
 \
Now onto Pacu. I like to call this tool the Metasploit of the cloud. It can have a steeper learning curve, but there is so much you can do with it once you get comfortable. Once setup, you can run the following module:\
 \
`run iam__bruteforce_permissions`\
 \
This will spit out your permissions associated with the access key. Say you don’t have Admin access. Just run the following module in Pacu:\
 \
`run privesc_scan`\
 \
If Pacu finds a PrivEsc route, it will automatically make you an Administrator. Doesn’t get much easier than that!\
 \
If you found this informative, please hit me with a re-post! I’m hoping to get to 10k followers here soon!

![](/files/A3VgO3kCe19MbvLBj706)