Penetration Testing on AWS: a step-by-step guide
Why is it necessary to conduct a penetration test on a cloud service provider?
We are currently in an era where many companies are moving their workloads to the cloud, for a variety of reasons. One of the main reasons is security. However, in my experience, there are not many resources available that discuss an ideal methodology for conducting a pentest with AWS. Therefore, I have taken it upon myself to create a methodology that will be used by Uproot Security, as well as any internal teams who use AWS as their cloud service provider.
In the industry, there are often misunderstandings about the differences between a cloud security audit and a penetration test. Some pentesting firms suggest their clients undergo a cloud audit instead of a pentest, but as a security engineer, I personally disagree with this approach. While a cloud audit may identify misconfigurations, such as S3 buckets with write access, only a dynamic pentest can uncover actual vulnerabilities associated with your EC2 workloads or instances, like sensitive data leakage. However, it's important to note that for smaller companies with little AWS workloads, a cloud security audit may suffice initially, but as the company grows and its cloud infrastructure expands, the limitations of a mere audit become apparent, necessitating the more comprehensive approach of penetration testing.
Are AWS clients relying too much on the shared responsibility model?
The shared responsibility model laid out by Amazon Web Services (AWS) has been a solid framework for organizations managing their cloud infrastructure. It clearly delineates who's accountable for what in terms of security: AWS handles security "of" the cloud, while customers are in charge of security "in" the cloud. But lately, there's a concerning trend of AWS clients leaning too heavily on this model, possibly overlooking their own share of responsibilities.
It's easy to fall into the trap of assuming that because AWS provides such a robust platform, all security bases are covered. Some clients might think that since AWS ensures the safety of the infrastructure, they're off the hook for a big chunk of security duties. But here's the thing: while AWS takes care of the infrastructure, the security of your data, applications, and everything else you build on top of it is squarely on your shoulders. This misunderstanding often leads to laxity in implementing the necessary security measures to fend off cyber threats effectively.
The minimum requirements to start the Pentest
If you are conducting a white hat assessment in AWS, you will need to ensure that you have the necessary permissions and have signed an agreement to get started and these are the information that you be requesting from the client to start the pentest.
- Requesting the client to create IAM user with console access, with MFA enabled
- Also, you can request them to create an access_id and secret for the user
- And, attach an IAM policy called security audit for the user created.
- An architecture diagram and the data flow diagram of the client
This might not be the case when conducting a red team assessment, an offensive security engineer would capture enough information with open-source intelligence and would be able to come up with his own ideas reaching the internal servers of the client :)
What's next?
Step 1: Gathering Information and Sizing
During this step, you gather all necessary details about the AWS environment you'll be evaluating. This includes understanding the architecture, purpose, permissions, and dependencies related to different resources and services in use.
This process involves reviewing the architecture and data flow diagrams, determining the boundaries for inspection, understanding configurations, etc. Tools like ScoutSuite can provide a quick and readable overview of the resource configurations.
Step 2: Scanning and Finding Issues
During the scanning phase, use automated tools to scan the configurations and find vulnerabilities. ScoutSuite and Prowler excel in this step, identifying possible security vulnerabilities, misconfigurations, and non-compliance with best practices.
Detailed Steps for Inspections:
Single Service Inspection:
-
Choose the service to inspect based on the perceived threat level or as identified by a preliminary scan.
-
Run Prowler with checks specific to selected service. Prowler will attempt to identify risks and potential misconfigurations in the chosen service.
-
Analyze results and trace findings to actual configurations in the AWS console/CLI to confirm. This could involve manual review, documentation analysis and inspecting how the service is being used in various workflows.
Cross Account Inspection:
-
Define the list of accounts to inspect. Getting list of accounts is easier if AWS Organizations is used.
-
Run ScoutSuite specifying all targeted accounts. ScoutSuite will then inspect and document potential issues across the accounts.
-
Review the findings to identify trends or repeated issues that might indicate larger, systemic problems within the organization’s governance/usage of AWS services.
Cross Service Inspection:
-
Identify the services to be included in the cross service inspection. This could be all services or a subset, depending on scope defined.
-
Use Pacu to run simulations and tests that involve multiple services. Pacu’s modules interact with AWS services in a variety of complex ways, emulating an attacker exploring for vulnerabilities.
-
Investigate findings. Some potential vulnerabilities may affect multiple services at once, or a vulnerability in one service may exacerbate a vulnerability in another.
Step 3: Reporting Responsibly
After the previous stages have been executed, it's time to compile a report detailing the findings. Detail each identified issue, provide evidence, and potential impacts, and propose remediation strategies. Highlight high-risk ratings and prioritize them. Finalize the report by summarizing the overall state of AWS security. Ensure all findings are communicated clearly and objectively, focusing on aiding the client in understanding the risks and remediation steps.
Remember, vigilant, thorough, and ongoing inspections and assessments are key to maintaining a secure cloud environment. These steps provide a solid base but should be further customized based on the organization's needs and the AWS environment’s complexity.
Conclusion
Conducting penetration tests and cloud audits are both essential for securing cloud environments. The reason for this is that the issues found in pentesting the internal network of a client application hosted in AWS may not be identified when conducting an audit that checks for misconfigurations. As the company grows and more resources are added to the cloud, these tests need to be conducted frequently.

Robin Joseph
Head of Security testing