October 24, 2024

Comprehensive AWS Pentesting Guide

Amazon Web Services (AWS) and other cloud service providers (CSPs) like Microsoft Azure and Google Cloud Platform (GCP) have become ubiquitous for hosting and deploying applications, especially over the past decade.

With that said, it’s not surprising that IBM recently reported that when breached data was stored in public clouds, it incurred the highest average breach cost at USD 5.17 million. Furthermore, 40% of data breaches involved data stored across multiple environments.

Offering a plethora of configurable services that apply a complex array of use cases across every sector, AWS environments require a unique set of security controls and policies. To ensure that the AWS environment is configured properly, and the correct controls are in place, AWS pentesting is not only essential but must be comprehensive and consider all aspects of an organization’s infrastructure and services being consumed.

In this AWS Pentesting Guide, we will delve into the different stages of Pentesting AWS environments, how to approach these assessments, how to identify potential vulnerabilities and security misconfigurations, and the tools and technologies that should be used to do so.

In this AWS pentesting guide, we will cover the process of pentesting AWS environments in the following six steps:

1. Enumerate AWS Organizational Units and Accounts (Reconnaissance)
2. Initiate Automated Scans Using Offensive Security Tools (Discovery)
3. Review Access Management through IAM and Policies (Vulnerability Analysis)
4. Simulate Attack on S3 and Storage Gateway (Exploitation)
5. Analyze AWS Compute with EC2 and Related Network Configurations (VPC) (Exploitation)
6. Compile Findings, Observations, and Remediation in a Report

1. Enumerate AWS Organizational Units and Accounts (Reconnaissance)

AWS pentesting should begin with the enumeration of the AWS Organization Unit (OU) or account, which can be done in a few different ways:

1. By making use of any Cloud Security Posture Management (CSPM) tool, like Wiz or InsightCloudSec, which can help gather an inventory of AWS resources.
2. By using an internal AWS service like AWS Config or Workload Discovery (formerly known as AWS Perspective), to inventory the current set of resources and their state.
3. Ideally and most comprehensively, by leveraging a dedicated OPEN-SOURCE tool for this like aws-inventory or aws-auto-inventory.

Another open-source tool worth making a note of is Cloud Security Suite (cs-suite), which is a combination of different cloud security assessment tools like Scout2 and Prowler, which also includes scanning and config audit from internal AWS services.

Once the tool finishes scanning the AWS account within the scope, it creates an HTML report which is stored in the /reports directory. The report appears as shown below:

Pentesters can always make use of Prowler for this purpose by running the command:
prowler aws –scan-unused-services

*Note: Prowler by default only scans the services in use which is indicated in the tool results by a declaration: * You only those services that contain resources here.

The intent here is to enumerate and uncover the following:

• AWS services in use
• Publicly exposed infrastructure
• Applications that are hosted or application-level components
• AWS internal network-level components

The next portion of this AWS Pentesting Guide will explain how to initiate automated scans using offensive tools for discovery.

2. Initiate Automated Scans Using Offensive Tools (Discovery)

After enumeration is complete, then comes the next essential step of pentesting AWS services, specifically those that are enabled and in use. This is where automated scanning comes in.

Penetration testers should leverage a tool like Prowler, Pacu, Scout2, or CS-Suite to begin. These tools not only scan and detect anomalies, identify misconfigurations, and flag warnings, but also provide a strategic starting point that tells pentesters where to dig deeper with details into all services in use and their configurations.

At this point, pentesters can then leverage the generated list of services that are in use and create a mind map or an attack surface target to reference. In doing so, it’s helpful to carefully consider which areas look vulnerable and determine what to test for within each service or category. This is also a good time to make note of how different services are interacting with one another.

Before beginning to perform the analysis, be sure to check for the following:

• CloudWatch
• CloudTrail
• Billing alerts

In the next portion of this AWS Pentesting Guide, we’ll explain how to review access management through IAM and policies.

3. Review Access Management through IAM and Policies (Vulnerability Analysis)

When pentesters start analyzing identity and access management (IAM) and user setup for the account being tested, they should aim to first answer the following questions:

• How are AWS accounts being managed? How are team members & IAM Accounts provisioned?
• Are there any Root and individual user accounts? Is MFA enabled for high privilege accounts?
• How are IAM user rights being managed? Is there a role-based user and group creation (DevOps, Executive/Business user, Dev user, Security or SecOps user, etc.)?
• Are the environment and users segregated based on the stage of development?
• Are different Roles being used for inter-service access provisioning? Are different access keys provisioned for different applications or are access keys being shared?

Once these questions are answered, it’s time to drill deeper into testing particular services. Test cases differ for each service category and the possible configurations within each one.

For example, if an IAM user, group, or role is flagged, the tool will also highlight if IAM permissions are overtly permissive. A list of these users should be compiled so that pentesters can then attempt to not only assume their role but also attempt to escalate their privileges.

On the other hand, if a user or group with outdated credentials or lacking multi-factor authentication (MFA) is identified, the AWS account should be tested further to identify how it could be exploited. In particular, pentesters should look for any access keys embedded directly into the code or access keys being used in AWS-CLI.

In the next portion of the AWS pentesting guide, we’ll walk through how to assess the security of AWS S3 and AWS Storage Gateway.

4. Simulate Attack on S3 and Storage Gateway (Exploitation)

The storage category in AWS consists of different services, including S3, relational database service (RDS), and other services.

Penetration testers can begin simulating attacks on and exploiting these services through configuration review, which involves obtaining all available information about a particular service and interpreting the results. For example, to test AWS S3, a pentester would need to collect all available information for a particular S3 bucket. The following settings are available for buckets:

• Object Access (object in this case refers to files stored in the bucket)
• List Objects
• Write Objects
• ACL Access
• Read Permissions
• Write Permissions

To manage access to AWS S3, permissions are applied to the following groups:

1. Authenticated Users
2. Public Users (without AWS credentials set)

*Note both bucket-level and object-level access controls can also be applied to specific users for access management in AWS S3.

What this Means

While pentesting the defined access control lists (ACLs) on an S3 bucket and object, a pentester would observe that testing the bucket returns an “AccessDenied” response. Essentially, this means that they can’t read/write to the S3 bucket being tested. Interestingly, there is still a possibility that a pentester could list ACLs, but not read/write to the bucket.

To attack AWS S3 buckets, penetration testers can always use Prowler or AWS-CLI, but there are open-source tools available that specifically test buckets, such as S3Scanner, as shown below.

This tool can scan AWS S3 and other CSPs for storage-related misconfigurations, including multi-thread scanning and scanning bucket permissions, and can even store results in a database.

The next portion of this AWS pentesting guide will explain how to analyze AWS Compute with EC2 and related network configurations.

5. Analyze AWS Compute with EC2 and Related Network Configurations (VPC) (Exploitation)

When analyzing EC2, pentesters should check if any ports are open, with inbound HTTP/HTTPS ports being the only exception, examine traffic management, and ensure minimal outbound connections.

The EC2 instances found in the account should also be checked to see if IMDSv1 is enabled, which can further be analyzed for the server-side request forgery (SSRF) vulnerability.

Insufficient Verification

The primary security vulnerability of Instance Metadata Service version 1 (IMDSv1) is the absence of any kind of authentication mechanism. Programs and users that can send an HTTP request to the Metadata service IP (169.254.169.254) are able to view the metadata of the instance, including private data. This means that an attacker could simply access all the EC2’s metadata if they were able to run code on the EC2 instance.

Even when an application doesn’t require access to metadata, vulnerabilities in the program may be used to obtain it.

Attacks exploiting SSRF, a popular web application vulnerability, enable attackers to force the server to submit requests to a given URL. When it comes to IMDSv1, SSRF can cause major security problems.

Attack Scenario

An online application feature that lets users submit a URL (such as URL preview, webpage screenshot, etc.) is discovered by the attacker.

The IMDS URL, http://169.254.169.254/latest/meta-data/, is supplied as input by the attacker.

The application will submit a request to this URL in order to access the instance’s metadata if it is not properly protected.
It is possible for the attacker to access basic data like the instance ID and network configuration. More dangerously, the attacker might manage to get their hands on the instance’s temporary IAM role credentials.

In the next section of this AWS pentesting guide, we will explain how AWS pentest findings should be compiled into a report after an exercise is complete.

6. Compile Findings, Observations, and Remediation in a Report

Once the pentesting exercise is concluded, it becomes even more critical to collect all artifacts like the report from Prowler, etc. for complete account assessment and service-specific scans. Pentesters should also include the enumeration results for all services being consumed and continue add detailed assessment notes on what exactly was tested and interesting findings, even if they do not qualify as vulnerabilities.

Maintaining a categorized approach to assessment notes is ideal. Reports should be specific to each individual assessment, as generic findings and descriptions are not sufficient. Pentesters should carefully explain all the vulnerabilities identified, including the attack scenario, impact, and likelihood of exploitation, and include proof of concept and steps that can be taken to reproduce it.

AWS Pentesting Guidelines

It’s important to note that like most other CSPs, AWS has a set of specific rules and guidelines that users must follow when it comes to penetration testing on their platforms and services to ensure the security and stability of their infrastructure. It’s comprehensive penetration testing policy specifies specific conditions that AWS customers must follow when performing penetration testing exercises on AWS-hosted applications and infrastructure.

Here are a few of the rules that AWS outlines in their pentesting guidelines:

• Customers must submit a request through the AWS Support Center to notify AWS when they intend to conduct a penetration test.
• AWS customers can only conduct penetration testing on their own resources. Customers are not permitted to perform pentesting on AWS-owned infrastructure or third-party applications hosted on AWS.
• Certain activities are prohibited by AWS, including but not limited to DNS hijacking via Route 53, request flooding, and protocol flooding.

AWS Shared Responsibility Model

AWS maintains that security is a shared responsibility between itself and its customers. Simply put by Amazon itself, AWS customers are responsible for the security for the security “in” the cloud, while AWS itself is responsible for the security “of” the cloud.

More specifically, here is a list of what AWS and its customers are responsible for:

AWS Security Responsibilities

• Software, including compute, storage, database, and networking services
• Hardware/AWS Global Infrastructure, including different regions, availability zones, and edge locations

AWS Customer Security Responsibilities

• Customer Data
• Their own platforms, applications, and IAM
• Operating system, network & firewall configuration
• Client-side data encryption & data integrity authentication
• Server-side encryption
• Networking traffic protection

The AWS Shared Responsibility Model is publicly available on Amazon’s website, which includes more granular details.

Secure Your AWS Environment with BreachLock Cloud Pentesting

BreachLock offers AWS penetration testing services that assess the security of AWS-hosted environments, services, and applications to close the gaps to improve your AWS security posture. BreachLock adheres to the clear policies that AWS has in place for penetration testing, as discussed in this AWS pentesting guide, to identify vulnerabilities specific to your AWS environment for validation, prioritization, and remediation. Common vulnerabilities that we identify in AWS environments include, but are not limited to:

• S3 Bucket Misconfigurations
• IAM Misconfigurations
• Security Group and Network ACL Issues
• Insecure EC2 Instances
• Serverless Function Vulnerabilities
• Database Security
• Identify Federation

To speak to an expert about improving your security posture in your AWS environment, contact BreachLock today!

About BreachLock

BreachLock is a global leader in Continuous Attack Surface Discovery and Penetration Testing. Continuously discover, prioritize, and mitigate exposures with evidence-backed Attack Surface Management, Penetration Testing Services, and Red Teaming.

Elevate your defense strategy with an attacker’s view that goes beyond common vulnerabilities and exposures. Each risk we uncover is backed by validated evidence. We test your entire attack surface and help you mitigate your next cyber breach before it occurs.

Know your risk. Contact BreachLock today!