Cloud Penetration Testing: AWS, Azure, and GCP Security Assessments

Cloud penetration testing has become a mandatory component of any comprehensive security program as organizations migrate critical infrastructure and data to AWS, Azure, and Google Cloud Platform. Cloud environments introduce a fundamentally different attack surface from traditional on-premises infrastructure — one defined by IAM misconfigurations, overprivileged service principals, exposed storage buckets, and metadata service exploitation rather than network perimeter vulnerabilities. This guide covers cloud penetration testing methodology, regulatory requirements, and the most common findings across all three major providers.

How Cloud Penetration Testing Differs from Traditional Assessments

Traditional network penetration testing focuses on network-layer vulnerabilities, service exploitation, and credential attacks against a defined IP range. Cloud penetration testing is primarily an identity and configuration assessment. The most critical findings in cloud environments typically involve:

• IAM roles and policies with excessive permissions (the principle of least privilege is consistently violated)
• Publicly accessible storage (S3 buckets, Azure Blob containers, GCS buckets) containing sensitive data
• Instance metadata service (IMDS) exploitation via Server-Side Request Forgery (SSRF)
• Misconfigured security groups and network access control lists allowing unrestricted inbound access
• Secrets stored in environment variables, user data, or cloud-native secret stores without proper access controls
• Privilege escalation paths through IAM policy combinations that individually seem benign

Compliance requirements for cloud penetration testing are explicit. PCI DSS 11.3.1 requires penetration testing of all system components, including cloud-hosted cardholder data environments. CSPs have specific notification requirements: AWS requires pre-authorization for certain test types through their Vulnerability Reporting page; Azure has a notification portal; GCP requires advance notification for certain test activities. Understanding these requirements is essential before beginning any cloud assessment.

AWS Penetration Testing Methodology

IAM Enumeration and Privilege Analysis

AWS assessments begin with IAM enumeration using the current credentials (typically obtained through an assumed breach scenario with a low-privileged IAM user). The aws iam get-account-authorization-details API call — if permitted — returns all IAM users, roles, groups, and attached policies. Even without this permission, tools like Pacu and ScoutSuite enumerate accessible resources and identify misconfigurations:

python3 pacu.py then run iam__enum_permissions

scout --provider aws --profile <profile> --report-dir ./output

Privilege escalation paths in AWS IAM are non-obvious. Common escalation vectors include: iam:PassRole combined with ec2:RunInstances (allows launching EC2 with a more privileged role); lambda:CreateFunction and lambda:InvokeFunction with iam:PassRole (allows creating a Lambda that executes with a privileged role); sts:AssumeRole with overly permissive trust policies.

S3 Bucket Review

Public S3 buckets remain one of the most common critical findings in cloud assessments despite years of AWS security improvements and S3 Block Public Access controls. The assessment enumerates all buckets accessible to the current principal and checks for:

• Buckets with public access enabled (ACL or bucket policy)
• Buckets containing sensitive data (credentials, PII, application secrets, backups)
• Buckets with server-side encryption disabled
• Buckets without versioning enabled (ransomware risk)
• Cross-account access permissions that are broader than required

EC2 Metadata Service SSRF

The AWS Instance Metadata Service (IMDS) at http://169.254.169.254/latest/meta-data/ provides IAM role credentials to EC2 instances. When a web application hosted on EC2 is vulnerable to SSRF, an attacker can retrieve these credentials and use them to access AWS APIs with the instance's IAM role. The critical path is:

SSRF vulnerability → IMDS credential retrieval → IAM role abuse → privilege escalation → data exfiltration

IMDSv2, which requires a session-oriented PUT request with a token, mitigates basic SSRF exploitation. AWS now defaults new instances to IMDSv2, but existing instances in production environments may still use IMDSv1. Ensure all EC2 instances are configured with HttpTokens=required (IMDSv2 only) via instance metadata options.

Azure Penetration Testing Methodology

Azure assessments focus on Azure Active Directory (Entra ID), service principals, managed identities, and Azure Resource Manager (ARM) role assignments. Common critical findings include:

• Overprivileged service principals: Applications registered in Entra ID with Global Administrator or Contributor-level permissions across the entire subscription
• Client secret exposure: Service principal client secrets stored in application configuration, source code, or Azure DevOps pipelines
• Managed identity abuse: VMs or App Services with system-assigned managed identities that have excessive ARM permissions
• Azure Storage Account key exposure: Storage account access keys provide full control over all blobs, queues, and tables in the account
• Conditional Access policy gaps: Authentication from untrusted locations permitted for privileged accounts

ROADtools and AADInternals are the primary enumeration tools for Azure/Entra ID environments. Stormspotter generates visual attack graphs of Azure resource relationships and privilege paths.

GCP Penetration Testing Methodology

GCP assessments center on IAM, service accounts, and GCP-specific services including Cloud Storage, Cloud Functions, and the Compute metadata server. Notable GCP-specific vectors include:

• Service account key file exposure (JSON key files downloaded and stored insecurely)
• Workload Identity configuration errors allowing cross-namespace privilege escalation in GKE
• Default compute service account with Editor role (a common misconfiguration in default GCP project configurations)
• Public Cloud Storage buckets with legacy ACLs granting allUsers or allAuthenticatedUsers access

GCP penetration testing uses gcloud CLI enumeration combined with GCP-specific scripts from the Rhino Security Labs GCP IAM privilege escalation research.

Cloud Security Assessment Tools

The primary toolchain for cloud penetration testing includes:

• ScoutSuite (multi-cloud): Automated security auditing across AWS, Azure, and GCP — generates HTML reports with findings categorized by severity
• Prowler (AWS/Azure/GCP): CIS benchmark checks and custom compliance framework assessments
• Pacu (AWS): Exploitation framework for AWS environments — modules for privilege escalation, persistence, and lateral movement
• Cloudsplaining (AWS IAM): Identifies AWS IAM policies that permit privilege escalation, resource exposure, and data exfiltration
• Trivy: Container and cloud configuration vulnerability scanner

Cloud penetration testing is a specialized discipline that requires deep knowledge of cloud provider APIs, IAM models, and service-specific security controls. Fortress MSSP's penetration testing practice includes cloud security assessments for AWS, Azure, and GCP environments. Contact us to discuss your cloud security assessment requirements.