AWS Cloud Penetration Testing

AWS Cloud Penetration Testing

AWS Cloud Penetration Testing is the practice of simulating cyber attacks against an AWS environment where security experts attempt to find and exploit vulnerabilities. It is a proactive approach to identify, analyse, and address cyber-security vulnerabilities within an AWS cloud environment. This form of testing is essential due to the unique characteristics and inherent complexities of AWS cloud environments, that include shared resources, dynamic provisioning, and third-party control of the infrastructure.

Why Choose ProCheckUp for Your AWS Penetration Testing?

Choosing ProCheckUp means partnering with a proven leader with over 25 years experience. Our CREST approval and NCSC endorsements reflect our commitment to delivering top-tier cyber services across various sectors. We offer flexible, cost-effective solutions tailored to meet the diverse needs and budgets of our clients, ensuring continuous improvement..

Legal and Preparatory Requirements for AWS Cloud Penetration Testing

Before initiating any penetration testing activities in an AWS environment, it is crucial to ensure all legal and preparatory steps are thoroughly addressed. This not only guarantees compliance with laws and AWS policies but also sets the stage for a successful and ethical penetration testing process. We outline below, the essential legal and preparatory requirements..

Legal Compliance and Permissions

• Client Authorisation: We obtain written authorisation from the entity that owns the AWS environment. This documentation should clearly outline the scope of the penetration test, the systems that will be tested, and the methods that will be used.
• Service Agreements: We ensure that there is a formal agreement, such as a Statement of Work (SOW) in a Job Schedule Form or a more formal Professional Services Agreement (PSA) for larger clients, that details the engagement's goals, scope, limitations, and responsibilities of each party.
• Legal Restrictions: Both client stakeholders and ProCheckUp should be aware of and comply with all applicable local, national, and international laws regarding cyber-security and data protection. This may involve consulting with legal counsel to ensure the penetration test does not violate any regulations.

AWS Policies and Notifications

• AWS Penetration Testing Policy: AWS has specific guidelines and processes that must be followed when conducting penetration tests against its services. Review the AWS Acceptable Use Policy and the AWS Penetration Testing guidelines to understand what is permitted and what actions need prior approval.
• Notification: For certain types of tests, AWS requires customers to request permission through the AWS Management Console before proceeding. This ensures AWS is aware of the test and does not mistakenly identify it as a real attack, which could lead to unnecessary incident response measures.
• Scope of Testing: Working with the customer we clearly define what AWS resources are included in the testing scope. AWS policy may limit testing to specific resource types or configurations, so it’s crucial to align the testing scope with these guidelines.

Pre-Test Preparation

Technical Preparation

• Access Requirements: We determine the types of access required for the test, such as IAM roles, user accounts with specific permissions or accounts using MFA.
• Tool Configuration: We configure penetration testing tools to respect the boundaries of the testing scope and AWS’s testing policies. Tools are configured to minimise disruption to any production environments, though it is best to use cloned non production environments.

Stakeholder Engagement

• Communication Plan: We establish a communication plan with all stakeholders, including security teams, IT management, and any operational personnel who may be affected by the test.
• Incident Response Coordination: We coordinate with the client’s incident response team to prepare for any potential discoveries of active security incidents during the test.

Customer Safety Processes

• Backup Systems: When testing production systems customers should ensure that backups are available for all critical data and configurations in case the test inadvertently affects system stability or data integrity.
• Impact Analysis: Customers should conduct a risk assessment to identify potential impacts of the test on the system and operations, preparing mitigation strategies for identified risks.

Documentation and Record-Keeping

• Test Plan Documentation: We maintain detailed documentation of the test plan, methodologies, tools, and customer procedures used during the penetration test. This should include the rationale for choosing specific testing methods and the expected test outcomes.

Stages of AWS Cloud Penetration Testing

Planning and Reconnaissance

The "Planning and Reconnaissance" phase is the foundation of our successful AWS Cloud Penetration Testing methodology. This initial stage is critical as it sets the scope and objectives for the penetration test and gathers essential information that will guide all subsequent activities. Below we list the key steps involved in this phase.

Define The Test Objectives And Scope

• Objective Setting
• Working with customer stakeholders we clearly define what the penetration test aims to achieve. Common objectives include identifying exploitable vulnerabilities, evaluating the effectiveness of existing security measures, and testing the response capabilities of the security team.
• Scope
  In-scope Resources: Working with the stakeholders we then determine which AWS resources (e.g., EC2 instances, S3 buckets, RDS databases) are included in the test. Consider both the technical and business context of these resources.
  Limitations: Clear boundaries are set to avoid any impact on production systems or data. This includes time frames for testing to minimise disruption to normal business operations.
• Compliance and Regulations
• We ensure that the testing activities align with relevant legal, regulatory, and AWS compliance requirements.

Pre-Flight Checks

• Stakeholder Briefing (optional dependent on the customer): We hold a meeting with all relevant stakeholders to review the test plan, confirm scope, and discuss any potential concerns or limitations.
• Logistical Arrangements: We ensure all necessary tools, access credentials, and resources are in place before the testing begins. This includes setting up secure channels for data collection and reporting.
• Legal and Ethical Compliance: As part of the pre-flight checks we re-confirm that all testing activities are authorised and documented, with special attention to ethical considerations and data protection laws.

Information Gathering

• Public Data Collection
• We use publicly available information to gather data about the target organisation. This includes DNS records, websites, and publicly posted documents which might reveal useful information about the AWS architecture.
• Network Mapping
  External Exposure: We identify external-facing endpoints such as APIs, web services, and other internet-accessible assets.
  Service Discovery: We enumerate AWS services being used, such as API Gateway, Lambda functions, or managed database services. Utilising tools like AWS CLI (if accessible) and AWS SDK  for automated querying and mapping of services.

Scanning and Enumeration

The "Scanning and Enumeration" phase of our AWS Cloud Penetration Testing methodology involves actively probing the defined targets to identify live systems, discover open ports, uncover services, and gather as much information as possible about the technical environment. This step is crucial for mapping the attack surface of an AWS environment and forms the basis for any further exploitation.

Detailed Steps for Scanning and Enumeration

IP/URL identification  and Asset Discovery

• IP and URL Identification: We use the collected public data and AWS account information to determine the applicable IP addresses and URL's for the penetration test.
• Asset Inventory: We utilise AWS-specific tools like AWS Config or third-party tools to list all assets within the scope, categorizing them by type (e.g., EC2 instances, Lambda functions).

Port and Service Scanning

• Network Scanning: We use network scanning tools to identify open ports and services. Tools like Nmap or Masscan can be used to scan IP addresses and URL's associated with the AWS environment to find entry points and detect open ports that could indicate running services.
• Service Detection: For each open port, determine the service type (e.g., HTTP, SSH, RDP) and version to identify potential vulnerabilities.
• Encryption in Transit: We ensure that data transmitted over the Internet is adequately encrypted, preventing data interception during transmission.

Vulnerability Scanning

• Automated Scanning: Once open ports are identified, we further enumerate the types of services running on those ports using tools like Nessus Professional, Qualys that are configured to recognize AWS environments and can detect common misconfigurations and known security flaws.
• Custom Scripts and Tools:  We deploy scripts that can interact with AWS APIs to test for improper permissions, misconfigurations in IAM roles, S3 bucket permissions, and more.
• Simulate Network Attacks: Use tools like Metasploit to test the effectiveness of network controls against simulated attacks.
• Application Scanning: We then use web application scanners like Burp Suite professional and Qualys Web Application scanning to discover and catalog web applications, APIs, and their endpoints that are hosted within the AWS environment.

Risk Identification

• Threat Modeling (optional CSTAR approach) : If within the scope of the engagement, based on gathered data, we develop threat models that describe potential attack vectors specific to the organisation's AWS environment. Considering both external and insider threats.(Learn More)

Security Group and Network ACL Analysis

• Security Policies and Configurations review (optional configuration review): If within the scope of the engagement, we examine the policies attached to roles, groups, and users for vulnerabilities like overly permissive access, which could be exploited during later phases.(Learn More)

• Review AWS Firewall Settings (optional firewall review): If within the scope of the engagement, we analyse firewall rules that control inbound and outbound traffic to AWS resources to identify overly permissive settings or configuration errors.(Learn More)

Gaining Access

The "Gaining Access" phase of our AWS Cloud Penetration Testing methodology focuses on leveraging the identified vulnerabilities to achieve unauthorised and later authorised access to systems, services, or data within the AWS environment to gain access to restricted areas or information. This stage is critical as it demonstrates the practical impact of vulnerabilities and helps assess the real-world threats that an organisation may face.

Techniques

• Exploitation of Known Vulnerabilities: We utilise known exploits or develop custom exploits based on the vulnerabilities identified during the scanning phase.
• Social Engineering (optional): If within the scope of the engagement, we use techniques like phishing to gain credentials or other sensitive information from legitimate users.
• Misconfiguration Exploitation: We take advantage of misconfigured permissions, security groups, or IAM roles to escalate privileges or access sensitive information.

Detailed Steps for Gaining Access

Credential Exploitation

• Password Attacks: We utilise brute force, dictionary attacks, or credential stuffing on known user accounts to gain access.
• Access Key Misuse: Identify and exploit improperly secured AWS access keys found in code repositories, configuration files, or logs.

Service Exploitation

• Exploiting Vulnerable Services: We use identified vulnerabilities in services like EC2, RDS, or custom applications to gain unauthorised access or execute arbitrary code.
• API Exploitation: We attack vulnerable API endpoints to manipulate back-end services or extract data.

Privilege Escalation

• IAM Role Misconfigurations: Exploit excessive permissions associated with IAM roles to access other AWS services or escalate privileges within the environment.
• Instance Profile Hijacking: If an EC2 instance has an overly permissive role, we use that instance to escalate access within the AWS infrastructure.

Using Misconfigured Network Services

• Security Group Bypass: If a security group is misconfigured to allow traffic from the internet to sensitive ports, we exploit this to gain access to databases or application interfaces.
• Network ACL Exploits: We take advantage of weak network ACLs that fail to properly segment network traffic within the VPC.

Lateral Movement

• Session Hijacking: After gaining initial access, if possible we hijack existing user sessions to move laterally across the network.
• Cross-Service Exploitation/Chained exploits: We use access gained in one service (e.g., an S3 bucket) to compromise other interconnected services or applications.

Data Encryption Verification

• Encryption at Rest: We verify that sensitive data stored in services like S3 buckets and RDS databases is encrypted at rest, ensuring data protection against unauthorized access.
• Encryption in Transit: Ensure that data transmitted between services (e.g., from EC2 to RDS) is adequately encrypted, preventing data interception during transmission.

Serverless Architecture Security

• AWS Lambda Security: We examine the security configurations of any serverless architectures found, such as AWS Lambda, to ensure that they are free from vulnerabilities that could be exploited by attackers.

Maintaining Access and Lateral Movement (optional)

If within the scope of the engagement the "Maintaining Access and Lateral Movement" phase of our AWS Cloud Penetration Testing methodology involves establishing persistent access to the environment and explores ways to expand control over additional resources and data. By mimicking the behavior of Advanced Persistent Threats (APT), we assess the depth of any potential breach and understand how an attacker could embed themselves into the system. The lateral movement part of this phase uses techniques to navigate through the AWS environment, expanding access from the initial foothold to other systems and resources.

Techniques

Establishing Persistence

• Backdoors: We install back-doors on compromised systems, such as EC2 instances, to ensure continued access.
• Scheduled Tasks: We set up cron jobs or AWS Lambda functions to periodically execute and maintain access or gather data.
• Database Triggers: We create database triggers on services like RDS to execute commands when certain conditions are met, helping maintain presence covertly.

Credential Harvesting and Reuse

• Extract Credentials: We use tools to extract credentials stored on compromised instances or intercepted during communication. The use software like hashcat using powerful GPU's to recover weak passwords.
• Role Switching: Utilise stolen IAM role credentials to assume roles with broader access across the AWS environment.

Exploiting Trust Relationships

• Cross-Account Access: We exploit trust policies between AWS accounts to access additional resources.
• Service to Service Exploitation: We use permissions granted to one service (like Lambda) to access or manipulate other services (like S3 or DynamoDB).

Lateral Movement Techniques

• Pass the Role/Policy: Similar to "pass the hash" in traditional IT environments, we use an assumed IAM role’s permissions to access further resources within or across AWS accounts.
• Network Pivoting: We utilise a compromised EC2 instance as a pivot point to access internal networks or other VPCs linked through peering connections.

Command and Control Channels

• Data Exfiltration Routes: We establish secure channels for data exfiltration to external servers or through DNS queries.
• Covert Channels: We set up covert channels using AWS services like SNS or SQS to communicate between compromised assets without raising alarms.

Monitoring and Evasion Techniques

• Log Manipulation: We modify or delete logs to erase traces of activity and evade detection by security monitoring tools.
• Security Group Manipulation: We adjust security group rules to facilitate movement while attempting to remain under the radar.

ProCheckUp's Reporting Transparent, Tangible 

Every engagement culminates in a detailed report, featuring both high-level overviews for management and detailed technical findings for IT professionals. 

Our reports include

• Executive Summary: Provides a high-level overview of the test objectives, methodology, key findings, and overall security posture.
• Detailed Findings: Each finding is detailed with evidence, impact analysis, and clear, actionable remediation steps.
• Technical Appendices: Includes raw data, logs, tool outputs, and detailed technical descriptions for deeper analysis by the IT team.

Reporting formats

• Delivery Formats: We can supply the report in multiple formats, such as PDF for executives or spreadsheets for technical teams.
• Review Meeting: A wash up meeting with all stakeholders to go through the findings, discussing the implications, and answer any questions.

Conclusion

AWS Cloud Penetration Testing is an essential component of a organisations comprehensive cloud security strategy. Through a systematic process of planning, scanning, gaining access, maintaining access, and then detailed analysis and reporting by ProCheckUp, customer organisations can uncover and better understand vulnerabilities within their AWS environments. AWS Cloud Penetration Testing not only identifies security weaknesses but also provides actionable insights and recommendations for strengthening their security posture.