UPDATE: This page is no longer accurate, and is being kept solely for reference. As of early 2019, Amazon no longer requires prior approval of penetration testing. To read more about our AWS pentesting services, visit our page here.

This article aims to provide an explanation and example for each section of the AWS penetration testing request form. This form can be accessed via an AWS root account at https://aws.amazon.com/forms/penetration-testing-request.

A downloadable set of answers for Rhino Security Labs’ customers is available here:  AWS Pentesting Form Submission.

A datasheet of Rhino’s AWS Penetration Testing is available here.

Further details and answers on the AWS penetration test form are below.

This section should contain a list of EC2 instance IDs in your AWS account that are to be attacked/tested during the penetration test (e.g. i-abc123, i-xyz987, …). For an AWS post exploitation assessment by Rhino Security Labs, this section most likely will include all EC2 instances in the account. AWS chooses to exclude EC2 instances of the size t1.micro, m1.small, and t2.nano, so be sure not to include any instances of that size. Due to that rule, it is also important to inform us at Rhino Security Labs if you host any excluded EC2 instance types.

This section should contain a list of Cloudfront Distributions that may be impacted during any of the testing (e.g. asdasdasd.cloudfront.net, qweqweqwe.cloudfront.net, …). This most often would be related to a web application being tested that uses Cloudfront as its CDN.

This section should contain a list of API Gateway REST API IDs and any associated Lambda functions that get used by the API (e.g. 1so2a3abij, 12or1nagip, arn:aws:lambda:us-east-1:123123123123:function:test …). API Gateway and Lambda are often fruitful attack vectors in an AWS post exploitation assessment, so it is important to include these services in the penetration testing form if they are being used in the environment.

This section should contain a list of the different RDS database DBI Resource IDs that may be impacted during the penetration test (e.g. db-B3COT4JG5UC4IACGJ72IGR34RM, db-A39OT1JH5UCZI0CCJ22PGI31RQ, …). These databases are often tied in with web applications that may be targeted during the assessment. Databases often lead to sensitive data and passwords, where an attacker will abuse to escalate further into the environment.

This section should include a list of Elastic Load Balancer names that are in use in the AWS account and will be impacted by the testing (e.g. my-load-balancer, my-2nd-lb, …). These often endure higher-than-usual traffic during an assessment, so it is important to list all active ELBs.

As part of an AWS post exploitation assessment, the DNS Zone Walking section does not need to be filled out. DNS Zone Walking is an enumeration method that can allow attacks to read all the content of DNSSEC signed DNS Zones. This kind of method is something that may be a focus of a network penetration test, but an AWS post exploitation assessment looks at the settings and configuration of AWS accounts and the services inside them, with less of a focus on exploiting network or web application vulnerabilities.

This section should contain the IP address/range of Rhino Security Labs, which will be provided prior to you filling out the penetration testing form (e.g. 1.2.3.4, 100.88.2.1/24, …). This is where all API requests and activity will originate from. This kind of data ensures that you know potentially malicious requests are coming from the correct source, which would be us as the penetration testers. This also allows your security team to review all account logs and compare them to the report we present at the end of the engagement to assess your response and monitoring capabilities to ensure that all malicious activity is being detected and responded to in the future.

No, the associated source IP addresses are not in your (the client) offices.

These source IP addresses are owned by Rhino Security Labs.

(888) 944-8679   (the primary phone number for Rhino Security Labs)

Yes, Rhino Security Labs has an NDA with AWS from previous collaboration between the teams.

For a typical internal network, external network, or web application penetration test, a typical answer for the expected peak bandwidth Is around 1 Gbps. For an AWS post exploitation assessment, a fraction of that, typically around 100 Mbps max will suffice. This is because network and web application penetration tests often include a large amount of scanning and fuzzing to try and discover or exploit vulnerabilities. Post exploitation assessments don’t rely hitting different endpoints with large amounts of data, but more-so inspection and exploitation of misconfigurations in settings and infrastructure.

Similar to the expected peak bandwidth, expected peak requests per second are far higher for internal network, external network, and web application penetration tests. For network and web application tests, 100 requests per second is a typical answer. Post exploitation assessments do not require many requests to exploit the environment, but instead more manual inspection and analysis.