AWS Cloud Penetration Testing (Basic Test cases and Tools)

AWS customers are welcome to carry out security assessments or penetration tests of their AWS infrastructure without prior approval for the services listed in the below section under “Permitted Services.”

Permitted Services

• Amazon EC2 instances, WAF, NAT Gateways, and Elastic Load Balancers
• Amazon RDS
• Amazon CloudFront
• Amazon Aurora
• Amazon API Gateways
• AWS AppSync
• AWS Lambda and Lambda Edge functions
• Amazon Lightsail resources
• Amazon Elastic Beanstalk environments
• Amazon Elastic Container Service
• AWS Fargate
• Amazon Elasticsearch
• Amazon FSx
• Amazon Transit Gateway
• S3 hosted applications (targeting S3 buckets is strictly prohibited)

Prohibited Activities

• DNS zone walking via Amazon Route 53 Hosted Zones
• DNS hijacking via Route 53
• DNS Pharming via Route 53
• Denial of Service (DoS), Distributed Denial of Service (DDoS), Simulated DoS, Simulated DDoS (These are subject to the DDoS Simulation Testing policy
  Port flooding
• Protocol flooding
• Request flooding (login request flooding, API request flooding)

Suggested tools for performing AWS penetration testing

Attacking cloud environments requires a deep logical understanding of used components and how they interact with each other. Unfortunately, there is no tool that solves all problems in a cloud assessment as the tools mostly depend on specific access rights to execute properly.

In some cases, the tools brute force access rights by observing responses to commands. Especially in AWS, a brute force may take a lot of effort due to the required parameters in an AWS command such as the region. The following is a list of some proven references and tools:

1. AWS CLI: Provides a unified command line interface to Amazon Web Services.
2. AWS CLI reference: Command reference of AWS CLI and useful information about resources
3. Prowler: Prowler is an Open Source security tool to perform AWS and Azure security best practices assessments, audits, incident response, continuous monitoring, hardening and forensics readiness.
4. AWS Consoler: A utility to convert your AWS CLI credentials into AWS console access.
5. awsenum: awsenum is a tool to identify what permissions your account has in AWS by brute-forcing the different operations and check what can you perform. It is only limited to read operations.
6. Enumerate IAM: Tool to enumerate IAM permissions.
7. Scout Suite: Scout Suite is an open source multi-cloud security-auditing tool, which enables security posture assessment of cloud environments.
8. WeirdAAL: AWS Attack Library.
9. Hacktricks Cloud AWS Pentesting: Collection of AWS attack vectors and methodologies.

It should be noted that some of the tools are no longer maintained or do not implement the latest available commands and resources of AWS. However, they still provide useful information during a penetration test. Additionally, linked tools should be reviewed and executed with care.

Identify the attack surface

In a cloud penetration test we first need to determine (even though this was also included during the scoping process) which services are:

• Used by the application (e.g., EC2 vs Lambda)
• Externally exposed (e.g., S3 bucket with static CSS files vs DynamoDB)
• Managed by AWS or by the customer

This also involves enumerating and fingerprinting the cloud infrastructure for used components and further third-party software.

Common AWS penetration testing techniques within an attack path

In this section we assume that we are already performing a cloud penetration test against a vulnerable application that uses various AWS services. The described techniques are not fully presented, nor is it a complete list of all testing techniques usually performed in a cloud penetration test. However, they still give some insights and ideas on how a cloud penetration test is performed in general.

1. External reconnaissance

Reconnaissance is a time-consuming but also non-neglectable part of every security assessment, as actions performed are usually based on discovered information. An attacker needs to understand the environment, have situational awareness, and be able to use his creative mind to connect the dots to create an attack path.

From a black box perspective, standard penetration testing tools such as Burp Suite Professional support detecting common misconfigurations, out-of-date software, and application vulnerabilities.

In addition, some AWS-specific reconnaissance steps should be performed such as:

• Searching the AWS Marketplace for the target organization as the accountid may be disclosed.
• Bute-Forcing the account ID via the AWS Sign-In URL: https://<acountid>.signin.aws.amazon.com.
• Searching through public Snapshots (e.g., EBS Snapshots) or AMI Images.

2. Local Filesystem

In some cases, it is possible to gain interactive access to a service, such as an EC2 instance. The steps after initially compromising an EC2 instance do not differ much from compromising a server in a penetration test or attack simulation, but additional checks should be performed as the environment may disclose sensitive information that could be used in further attacks.

Common tasks of Local Filesystem checks include:

• Discovery of Sensitive information (Passwords, Application Files, Documentation, Home Directories, Environment Configuration)
• Privilege Escalation (Misconfiguration, Kernel Exploit, Permissive Privileges)
• Pivoting to other Services in the same network (Port Scan)

In addition to the above common tasks, special care should be given to the below as they are AWS Cloud Environment specific:

• Discovery of AWS Access Credentials in Home Directories and Application Files
• Verifying access to the AWS metadata endpoint at http://169.254.169.254/ or http://[fd00:ec2::254]

3. AWS Security Token

AWS Security Tokens are used to provide temporary, limited-privilege access for AWS Identity and Access Management (IAM) users. Those tokens can be used directly by users (e.g., to use them in development processes such as terraform or within AWS services).

For example, EC2 instances can be configured with additional privileges via IAM roles. Applications and services running on the system are then able to request credentials to access further services to which access was granted by the IAM role. This provides an easy way for a developer to distribute credentials across services, but also poses the risk that an attacker could re-use the credentials in further attacks.

The credentials can be requested via the AWS metadata service, which is reachable via http://169.254.169.254/ or http://[fd00:ec2::254]. The metadata service holds different kinds of information which are split into categories. The most interesting categories for an attacker regarding credentials are:

• iam/info: Contains information about associated IAM roles.
• iam/security-credentials/role-name: Contains temporary security credentials associated with the role.

To access the metadata service, a token needs to be crafted — which however doesn’t require authentication details. AWS introduced the token in their Instance Metadata Service Version 2 (IMDSv2) as part of a session-oriented method and to prevent SSRF abuse in applications.

4. AWS Security Token Permission enumeration

The command aws sts get-caller-identity can be used to verify if AWS credentials are valid and to output details about the IAM user and role (ServerManager)

5. Privilege escalation

With the captured authentication credentials and information about assigned permission (ec2:CreateSnapshot and ec2:DescribeVolumes) we can work out an attack path that could be used to escalate privileges to root or gain access to sensitive data stored on the system. Escalating privileges by abusing access permissions is a common scenario in a penetration test or even Red team assessment.