Written for the AWS Security Digest Newsletter by Lizzie Moratti
Disclaimer: We are talking about pentesting the customer’s side of the shared responsibility model. My thoughts and hot takes are my own and do not reflect the views of any past, current, or future employers of mine. Never conduct a pentest without proper authorization and legal agreements.
Introduction
I am often asked, “how do I get into cloud pentesting” or “how do I become an AWS pentester”. Especially since I gave my talk on AWS Pentest methodology at fwd:cloudsec NA 2024.
For the first question, I will always say, “Pick a cloud provider first. My specialty is AWS.”
The people asking me about AWS pentesting vary widely in their experience level and prior to my talk I was deferring them to existing resources, such as The Extended AWS Security Ramp-Up Guide by Rami McCarthy while he was at NCC Group (2020). The extended guide built off of the “official” ramp up guide from AWS (updated 2023).
Why write my own ramp up guide?
Rami and AWS themselves focused on a more broad perspective on AWS security rather than AWS pentesting. I also have a different background than most pentesters I know, and I believe it acted as a catalyst for learning AWS pentesting.
My cheat code for accelerated growth was being a project manager at several pentest consultancies. I oversaw many cloud pentests and other types of pentests (hardware, web app, API, network, physical, etc.) My job perks included: reading reports that were under NDA, access to smart people, and answers to all my dumb questions.
Much like learning a language, immersing yourself in cloud and cloud accessories is the fastest way to learn.
Who would benefit from following my guide?
I’m not going to pretend that my approach will work for everyone. It’s rare that I meet people who are willing to brute force information into their brains. Please take the useful parts and build your own roadmap if it doesn’t work for you. You’ll find your own way if you’re motivated enough.
Instead, I wrote what I would do if I had to start over from scratch in 2024 mixed with some strong opinions I hold that shape my approach.
This is who my guide is really for:
- Someone who is already a pentester or security professional
- Someone who understands networking basics, how web apps work, and APIs
- No, seriously, the cloud builds off all these things.
- Someone who is a self-motivated information sponge and who just needs to be pointed in a direction
- Someone who is willing to engage with the cloud security community when they’re stuck
- Anyone who has the mental tenacity to jump in regardless of who I intended this for
I wrote the guide with these goals in mind:
- Avoid the “try harder” mentality, that I find inefficient for learning
- Free or low cost enough to keep it accessible
- Leverage learning platforms that have good content
- Use repetition to strengthen information retention
- Avoid reliance on tools
Dark patterns in cloud pentesting
I debated whether to include this section. I ultimately decided that it’s important for aspiring or future cloud pentesters to know, especially those who will be consultants or are considering it.
To me, cloud pentesting is a unique specialization that I love and enjoy. However, like any other seasoned infosec professional, I also have some gripes about the industry and in some cases how the sausage is made at most pentest consultancies.
Hot Take 1: Cloud pentesting rewards generalized high-level knowledge before it rewards deep cloud knowledge development. This leads to a low skill floor and a giant skill ceiling.
Hot Take 2: Do not pay for AWS pentest certifications. The field is too new to offer definitive advice for certifications, despite all the paid ones that are starting to pop up. I wouldn’t personally recommend any specific certifications at the time of writing.
Hot Take 3: A cloud pentest is not the same as an internal network assessment. I have spoken to amazing network pentest consultants who fell flat on their face on a cloud pentest they assumed would be trivial. Despite this, you will likely continue to hear phrases like “cloud is just someone else's computer, it's the same as X” throughout your career. You will also have people telling you to learn the 3 major clouds. Don’t. It is effectively 3 jobs.
Hot Take 4: Related to #3, the scoping and scheduling processes at pentest consultancies can suck. It frequently happens that a pentester who is in over their head is scheduled for this work. Due to the low skill floor, they might be able to get away with a subpar job without being caught. Another common pattern you might see is a consultant is given insufficient time to deliver high-quality work, and the “pentest” becomes an account configuration review.
Hot Take 5: There are not many pentest sales drivers for AWS Pentesting. A cloud pentest is usually not a requirement for a company to meet compliance goals. It gets treated as a luxury service, and is often the first thing cut for customers who need to save money.
Hot Take 6: AWS develops features at a breakneck pace. Unless you can consistently practice or can be put on AWS pentests, your skills will probably atrophy faster compared to “traditional” pentesting like networking/web apps. Luckily, new services are rarely used broadly.
Hot Take 7: Shady pentest vendors will scan-and-rebrand while mislabeling their work as a pentest. Meaning, they will run automated scans then rebrand the scan’s findings into their own company report templates. Due to #5, some companies would rather pay less to check their required boxes or to avoid identifying more issues for their giant JIRA backlogs.
Hot Take 8: At the moment, I would advise most pentesters not to specialize in cloud unless they are at a consultancy that can support them with consistent actual cloud work. Cloud pentesting is kind of the “niche in a niche inside a niche” at the moment. Ignore this if you are passionate about cloud security or chasing your personal curiosity.
Hot Take 9: A consultancy, if you work for one, will eventually be asking you to, “pretty please write a methodology so that anyone can do what you do and then hide it away in our internal wiki so we can build up a competitive edge”. This artificially hampers the growth & maturity of the cloud pentesting discipline.
Hot Take 10: Checklist methodologies are for experts who already know how to perform the work. They should be living documents and something to refer to, not a replacement for the learning process. Management has an incentive to seek “quick wins” so more people can be billable or “perceived as productive”. Instead, these documents will likely become authoritative because it’s hard to create documentation that will yield a critical thinker.
Stage 1: All the training wheels
In this stage of learning, it is your job to sponge up a ton of information. I want you to be looking for design patterns and common tasks you perform throughout your learning process.
You are also going to be starting your own personal glossary.
- Write down every term you do not know
- Attempt to define the terms in a way that makes sense to you
- If you can’t find what a term means, that’s when you research or ask the dumb questions in an appropriate place
- It will also serve as a reminder for how much you’ve learned when the day comes that everything seems easy to you
The good news is the human brain is a pattern recognition machine, and this automatically happens with exposure to more experiences. We are purposefully trying to take advantage of my Hot Take #1 - broad knowledge is rewarded first. In my opinion, having some practical hands-on experience before being in formalized learning environments means you will retain information better.
To gain this broad practical experience, we are going to commit a sin to those who play CTF or have a “try harder” mentality.
We are going to “cheat” with CTF write-ups.
My favorite place for this, at the moment, is pwnedlabs.io. The reason for this is my subjective opinion and if you have a stronger opinion then you can adapt this approach to nearly any platform or CTF write up.
In my opinion, they have the highest quality learning labs that are red team based. I say this as someone who worked at Rhino during CloudGoat’s release and who is friends with Seth Art who wrote CloudFox and CloudFoxable. I have no sponsorships or affiliations with any learning platforms.
On pwnedlabs, you do not need to learn how to use terraform or pull out your own credit card to spin up an AWS account. They remove a lot of the initial barriers that won’t seem like barriers to those of us who have been around for a while.
There are free labs and then premium labs which will cost $20/month subscription (at the time of writing). You can substitute the premium labs with CTFs that have known write-ups if $20/month is too expensive.
More importantly, they have solutions to every lab and label which labs are good for a blind CTF, which we’ll be doing later. Their discord is also a great and an appropriate place to ask questions and make friends who are into cloud.
I want you to solve every single AWS red team lab.
You can do this over days, weeks, midnight binges or whatever works best for you. I also want you to do it the exact way that they show you how to do it.
Along the way asking yourself the question “why do they solve it this way? Could I solve it differently?” If you don’t have an answer, that’s okay. We are rewiring your brain to be critical of their approach because that’s 90% of the hacker mindset, baby. It also helps make your brain struggle in a way that will remember the content instead of passively consuming it.
I also want you to update your glossary with those terms we mentioned. This will also give you an appropriate amount of struggle to make your brain remember more.
Now that you’ve gone through all the labs, you’re going to do some of them again with a different perspective.
Instead of the intended pwnedlabs.io solution, you are going to learn from my friend Tyler Ramsbey who has a YouTube playlist for pwnedlabs.io or another actual pentester whose content you enjoy.
Copy everything they do and solve the ones they have content for. They will likely have their own opinions and expose you to concepts or tools that you never considered before. Learning from multiple sources is a powerful catalyst for learning.
I have a twist to keep this interesting though, every time the pentester uses a tool that is not the AWS CLI, you are going to copy them but proxy the request it makes to inspect it.
Here’s my guide on how you can proxy AWS HTTP requests using BurpSuite. You are going to note down all the API calls it’s making to AWS and what it’s using for parameters. This might seem heavy-handed or tedious, but what I want you to know is that these tools are not magic.
You can do everything this tool is doing by using CLI calls, the SDK, or the console. This is our way of seeing underneath the hood without needing to understand or dig into the code. If you are coming from a coding background, then you’re also welcome to dive into the code for the open source tools too.
Update your glossary one final time, and then it’s time to move on from having people tell you how to solve the problems.
High level of stage 1:
- Start a glossary, update it as you go
- Solve labs/CTFs using the intended write-ups
- Solve those same labs/CTFs using a write-up from a professional pentester
- See there is no magic in tools, just the AWS APIs
Stage 2: Removing the training wheels
By now, you’re familiar with and have solved some labs twice. You should be seeing patterns and have a glossary you can refer back to see how much you’ve learned and how far you have come.
You might also be realizing there’s a lot of stuff you do not know. This is normal and healthy. Be scared of the people who do not have this reaction.
We’re going to do some reading before going back to solving these labs without help.
Read through these and update your personal glossary:
- https://hackingthe.cloud/
- https://expeditedsecurity.com/aws-in-plain-english/
- https://github.com/open-guides/og-aws (basic guides)
- https://cloudonaut.io/aws-security-primer/
You are going to now solve all the CTF friendly labs blind. For the pwnedlabs.io labs, they should all be marked as CTF friendly or not after some feedback I gave in their support channel on Discord.
Go through and solve the labs without any walkthroughs or solution guides. Again, keeping your glossary up to date. This level of struggle is intended to be a leap forward for you. The good news is that you have solved all of them before, and it will point out the areas you need more work in. From your reading, you might even want to try some new techniques.
Once you are done with your run through of the labs, we’re going to take a brief detour to something else.
We are going to exercise your ability to look at IAM policies and spot misconfigurations. This CTF has write-ups available, but you are going to get as far as you can before using them. I recommend not using the write-ups for this for a particular reason: they are pretty obvious once they’ve been pointed out. Similar to hearing the same joke twice.
You’re now ready to fill in some knowledge gaps, and we’re going to use the roadmap from AWS to do that. Use the updated roadmap from AWS and complete their courses through skill builder, which is free.
The following is my personal opinion: I intensely dislike the AWS courses, and I will often skip entire sections because they are basically designed to sell you on their services or are too introductory. Treat them as a biased source and take all best practices with a grain of salt. They still have valuable content, especially for beginners. If something feels too tedious, this is the place where I’d tell you to skip it.
High level of stage 2:
- Read through community resources to understand attacker techniques, cloud services, and other areas that exist and you should know about
- Solve an IAM challenge from Wiz to build up the ability to spot bad IAM policies
- Use the AWS provided ramp up guide for security to fill gaps
- Most people will stop at this stage
Stage 3: Going from manual to automatic
Pick a few of your favorite labs or CTFs.
We’re going to be solving these manually without automated tools. That’s right, you are going to solve them by only using the AWS CLI / Web Console. Use whatever resources or write-ups you want. Treat this stage as a palette cleanse from the AWS training.
Once you’ve completed a lab manually, take your crafted CLI / Web Requests you made and convert them into code that uses the boto3 SDK. This may be a learning curve for those who don’t have a coding background. Avoid using ChatGPT/ AI to write it for you for now. Take as long as you need to and get the code to a state that you’re 80% happy with it. Then send it to someone you trust and have them give you a code review.
The goal with this exercise is practicing the ability to quickly script common tasks instead of relying on automated tooling. At some point, you will encounter the issue of scale and will need to be able to write scripts that do exactly what you need them to. Once you are confident in your personal coding abilities, you might be able to leverage AI to save some time.
Some notes about good cloud pentest hygiene:
- You should never run code that you haven’t personally vetted in a test account on a clients' environment.
- This includes ChatGPT or open source tools
- Keep your testing environment clean.
- Close terminals, clear environment variables, delete AWS CLI profiles, remove client information, etc
- Consider rolling back a VM to a state when you are done with a project to ensure you’re always working from a known good state.
- You should always do a whoami (sts get-caller-identity) prior to running code or making state changing requests. This has always been a standard operating procedure for me, and you should incorporate this habit as well.
- I once knew someone who wiped out a prod database when they forgot to specify a CLI profile name. The AWS CLI command defaults to the environment variables when no profile is provided. Therefore, because they reused a terminal that had environment variables, they ran the command in the wrong account instead of their personal account.
You should also toss your code someplace like GitHub so you can point to it on a resume or to reflect on in the future. If you have a study group or mentor, this is an excellent peer review opportunity and feedback opportunity.
Also, at this point, you should be able to tell if you love this type of work or not. Personally, I love it, which probably tells you a lot about my psyche.
Optionally, if you can continue to manually solve / script additional labs until you feel comfortable enough to move forward. You’re also welcome to create a manual speed run category for pwnedlabs, if you can’t get enough.
High level of stage 3:
- Solve your favorite labs/ CTFs manually
- Write code to automate the labs with boto3
- Store it on GitHub and get a code review from someone you trust
Stage 4: Building is half the fun
Now that you understand how to break things, and you have some ideas about what’s going on in AWS, we’re going to build some stuff. Our job is to ultimately help blue teamers build better and more secure products. We should know their struggles. Don’t be “that” hacker who only learns the red team side of the profession.
Rich Mogull has an excellent and free series that I’m going to have you do. He calls it Cloud Security Lab a Week. He basically builds (with sane best practices) a security lab and each should take 15-30m. You will do this in your own AWS account(s) with the AWS free tier. Go through all of them at your leisure and have fun with it.
Lastly, once you are done with that. It’s time to do the cloud resume challenge that will stretch your ability to build and your hands-on experience even further. If you explain you’ve done all of this in interviews as a pentester, it looks quite impressive. There are some write-ups but try not to rely on them too heavily.
High level of stage 4:
- Do all of Rich Mogull’s SLAW
- Complete the cloud resume challenge for AWS
Stage 5: The maturity model for AWS
In 2019, Scott Piper published what I consider a foundational white paper called the AWS Security Maturity Roadmap. I want you to be familiar with it. You should be considering the SCP best practices when you’re making recommendations for how to fix things or suggesting guardrails. If you are insatiable in your reading like me, go through all of Scott’s work.
There’s also an extended AWS Security Maturity roadmap talk by Rami which is related to Scott’s that you should watch too. It goes into when to build or buy solutions. It’s also opinionated, and I appreciate that very much about Rami.
My first reaction to this paper and talk was that I hadn’t even scratched the surface of cloud. Now, I actively seek to learn from our blue team builders.
High level of stage 5:
- Read Scott Piper’s AWS Security Maturity Roadmap
- Watch Rami’s extended AWS Security Maturity Roadmap talk
Stage 6: Translating this into holistic pentests
You have learned a lot. Now it’s time to tie all of these disparate pieces of information you have floating around into a practical pentest.
Luckily, I can link to my own work on AWS Pentest Methodology. Before you read through it, I would encourage you to watch my fwd:cloudsec talk which covers some of the material in a high-level way and offers some mental models I personally use.
Take this methodology and apply it to your pentests. If you are not at a consultancy that can provide pentests to you or cannot find someone willing to let you pentest their accounts. Then you will need to instead apply it to CTFs and apply for jobs that will allow you to hone your skills better. There’s not really a shortcut for this process, and there’s not a ready surplus of jobs hiring for this skill set at the moment either. Hopefully that changes in the future.
Stage 7: Continuous learning
You thought you could ever stop learning? Unfortunately, that’s not in the cards for us. AWS will build more things, people will find fundamental flaws in technology, blogs will be posted, and talks will be given.
This is what I do now to keep myself up to speed:
- Subscribe to email mailing lists for AWS security news
- Watch the #blogs-and-feeds channel in the Cloud Security Forum Slack
- Go to fwd:cloudsec and watch all the talks
- Make friends and publish blog posts about the things I want to write about
- Do CTFs to keep the skill atrophy at bay
- Build as much as I can
I hope this post was helpful, or at the very least, interesting.
For more AWS pentesting related content, you can follow me on Medium, Mastodon, X, or connect with me on LinkedIn.
Top comments (0)