How to Perform Penetration Testing in the AWS Cloud

How to Perform Penetration Testing in the AWS Cloud

Amazon Web Service (AWS) has the largest user base of any cloud provider, with 1.45 million businesses. They offer 90 different cloud hosting services that generally fall within the categories of Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS), and are commonly used for data storage, networking, code development, and web application services.

By leveraging AWS cloud services, users can scale their web services quickly and effectively while avoiding upfront costs for hardware and maintenance. However, penetration testing with AWS-based services is slightly more limited than with on-premise servers. As a result, it’s crucial to gain a clear understanding of the scope and objectives of penetration testing for your organization’s AWS Cloud services while factoring in the limitations of AWS penetration testing.

What can be pentested in AWS?

The methodologies used to pentest the AWS Cloud differ primarily from traditional systems in the ownership of the systems. The lack of dedicated, on-premise hardware and user ownership of the environment means that SaaS AWS services cannot be tested in the same way as a traditional on-premise environment or IaaS models.

Traditional ‘ethical hacking’ methodology would violate the AWS acceptable use policies, as AWS owns the underlying core infrastructure. AWS pentests must instead focus on user-owned assets and attack strategies specific to AWS Cloud and require specialized knowledge and approaches.

The following CAN NOT be pentested within the AWS cloud:

  • AWS services or applications
  • Physical hardware, underlying infrastructure, or physical facilities owned by AWS
  • EC2 environments owned by partners or vendors
  • Security appliances managed by other vendors without their permission
  • Amazon’s small or micro Relational Database Service (RDS)

The following CAN be pentested within the AWS cloud:

  • Security testing for User-Operated Services, including cloud offerings created and configured by the user (e.g. an organization’s AWS EC2 instance can be fully tested, except for disruption of business continuity tactics like Denial of Service (DOS) attacks).
  • The implementation and configuration of the cloud environment of Vendor Operated Services (cloud offerings that are owned and managed by a third-party vendor) can be pentested. However, the underlying infrastructure can not.
  • Elastic Cloud Computing (EC2) services can be pentested in the following specific areas:
    • Application Programming Interfaces (APIs)
    • Web and mobile applications hosted by your organization
    • The application server and associated stack
    • Virtual machines and operating systems

There are other areas that can be pentested in AWS, but the list above includes areas most commonly included in a test.

How to prepare for your AWS pentest

The first step in determining which pentesting company to select is to clearly define the scope, objectives, and rules for the test. Often, objectives are driven by legal, regulatory, or industry requirements, and will shape the scope and frequency of the tests. Certain industries require annual pentests of specific systems, others require bi-annual pentests of completely different systems. Establishing what your organization specifically requires and why will help guide your pentesting provider’s strategy and approach.

Next, you should determine the type of pentest you would like conducted, outline expectations for stakeholders, and establish a timeline for the testing, reporting, remediation, and follow-up testing. In addition, it is essential to develop a protocol for how to proceed if it is revealed that your organization’s systems have already been breached.

Finally, you must inform AWS of the dates that testing will take place, the IP Address range the scan or penetration testing will come from, and the IP Address range being tested.

Seek out the right pentest provider for your organization

Finding and vetting the right pentest provider should be a carefully considered and thorough selection process. This is not the time to “cut corners.”You must find a provider with extensive knowledge of AWS and demonstrable expertise within the industry that can adapt their services to your organization’s specific requirements.

Citadelo has over a decade of experience in AWS pentesting for a wide range of industries and can employ the following testing methods:

What should I do after the penetration test?

Once the penetration testing is complete, the provider will hand over a report of the findings, including a list of found threats and their level of criticality. Higher-level threats should obviously be dealt with immediately. Depending on the industry, applicable laws, and regulations certain “Critical” and “High” level risks could require a retest.

If you are distributing your penetration testing results to any third-party, partner, client, or auditor, you must take special precautions to do so securely, as the results contain sensitive insights into how to attack your organization’s systems. The reports you distribute should also include details about how each vulnerability revealed was remediated.

Need some help?

Citadelo has extensive experience with pentesting AWS services and is well-equipped to handle a broad range of specific and intensive requirements for any imaginable use case. Our testers hold AWS Certified Solutions Architect - Associate and WS Certified Security - Specialty certifications and all have first-hand experience with developing customized testing procedures for the most demanding clients. For a consultation with one of our technicians, please feel free to get in touch directly with the Citadelo team.

About the author

Citadelo
Citadelo
Citadelo is a firm of ethical hackers on your side. We think like hackers, but we don't abuse it. On the contrary, our main goal is to reveal vulnerabilities without causing damage. We have been conducting simulated attacks for our clients since 2006
Show more from author

Related blogs