Cloud Penetration Testing: A Complete Guide for AWS, Azure, and GCP

Cloud penetration testing validates that your cloud security controls work as intended. Unlike traditional network penetration testing, cloud assessments focus on misconfigurations, identity weaknesses, and cloud-specific attack paths that automated scanning tools miss.

The cloud shared responsibility model changes the scope—you test what you control (applications, data, configurations) while the provider secures the underlying infrastructure. This guide covers how to plan, execute, and remediate cloud penetration tests across major providers.

Cloud Provider Policies

Each cloud provider has specific policies governing penetration testing. Violating these can result in account suspension.

AWS Penetration Testing Policy

No approval required for most services. AWS allows testing on resources you own without prior notification.

Permitted services (customer responsibility):

• EC2 instances, NAT Gateways, Elastic Load Balancers
• RDS, Aurora
• CloudFront
• API Gateway
• Lambda functions
• Lightsail resources
• Elastic Beanstalk environments
• Amazon EKS

Prohibited activities:

• DNS zone walking via Route 53
• Denial of Service (DoS) or Distributed DoS
• Port/protocol/request flooding
• Testing infrastructure not owned by you

Shared resources testing: Testing resources shared between customers (like AWS-managed services) requires careful scoping to avoid impacting other tenants.

Azure Penetration Testing Rules

No pre-approval required since 2017 for most testing.

Unified Rules of Engagement apply:

• Test only resources you own
• No denial of service attacks
• No testing of Azure infrastructure
• No testing Microsoft Online Services directly

Azure-specific considerations:

• Active Directory testing allowed on your tenant
• Testing Azure DevOps requires care around shared pipelines
• Web app testing allowed but avoid impacting shared App Service infrastructure

Microsoft Bug Bounty: If you find Azure infrastructure vulnerabilities, report through the MSRC program rather than exploiting.

GCP Penetration Testing Policy

No notification required for testing your own resources.

Acceptable testing scope:

• Compute Engine instances
• Cloud Functions
• Cloud Run
• GKE clusters
• Cloud SQL
• Your applications on App Engine

Prohibited:

• DoS/DDoS attacks
• Social engineering of Google employees
• Scanning non-owned resources
• Attempting to access other customers' data

Important: GCP Abuse policy applies—activities that could impact other customers or Google infrastructure may trigger suspension.

Pre-Engagement Planning

Scope Definition

Define clear boundaries before testing:

In-scope resources:

AWS Account: 123456789012
  - Production VPC (vpc-abc123)
  - All EC2 instances tagged Environment=Production
  - RDS instances: prod-db-1, prod-db-2
  - S3 buckets: company-prod-*
  - Lambda functions in production account
  - IAM users and roles (configuration review)

Azure Subscription: {subscription-id}
  - Resource Group: Production-RG
  - All VMs in Production-RG
  - Azure SQL databases
  - Storage accounts: proddata*
  - Azure AD tenant: contoso.onmicrosoft.com

Out-of-scope:

• Third-party integrations
• Development/testing environments (unless specifically included)
• Customer-facing production during business hours

Authorization Documentation

Before testing, obtain:

1. Written authorization from system owner
2. Scope agreement detailing what will be tested
3. Rules of engagement including testing windows
4. Emergency contacts for critical findings
5. Cloud account details for scoping

Testing Environment Setup

Attacker infrastructure:

• Separate AWS/Azure/GCP account for attack tools
• VPN or dedicated IP for testing
• Logging of all testing activities
• Backup communication channels

Credentials received:

• Low-privilege user for authenticated testing
• (Optional) Read-only IAM access for configuration review
• API keys or service accounts as needed

Cloud Testing Methodology

Phase 1: Reconnaissance

External footprint discovery:

• DNS enumeration for cloud resources
• Certificate transparency logs
• Cloud service fingerprinting
• S3/Azure Blob/GCS bucket enumeration

Tools:

• cloud_enum (multi-cloud)
• S3Scanner, GCPBucketBrute
• Shodan, Censys for exposed services
• dnsrecon for subdomain enumeration

Common findings:

• Exposed storage buckets
• Unintended public endpoints
• Leaked credentials in public repositories

Phase 2: Configuration Assessment

IAM review:

• Overprivileged users and roles
• Unused credentials
• Missing MFA
• Cross-account trust relationships
• Inline vs. managed policies

Network configuration:

• Security group analysis
• Network ACL review
• Public IP exposure
• VPC peering risks

Storage security:

• Bucket policies and ACLs
• Encryption at rest status
• Public access settings
• Logging configuration

Tools:

• ScoutSuite (multi-cloud)
• Prowler (AWS)
• Steampipe (multi-cloud SQL)
• CloudMapper (AWS)

Phase 3: Vulnerability Assessment

Application layer:

• Web application vulnerabilities
• API security testing
• Container image scanning
• Serverless function code review

Infrastructure:

• Missing patches on instances
• Vulnerable container base images
• Outdated Lambda runtimes
• Known CVEs in dependencies

Phase 4: Exploitation

Common cloud attack paths:

1. Credential compromise:

• Access key in public repository
• Metadata service exploitation (SSRF → IMDSv1)
• Lambda environment variable exposure

2. Privilege escalation:

# AWS privilege escalation via Lambda
# If user can update Lambda function code and Lambda has broader permissions
aws lambda update-function-code \
  --function-name target-function \
  --zip-file fileb://malicious.zip

3. Lateral movement:

• Instance profile credential extraction
• Service account impersonation
• Cross-account role assumption
• VPC peering exploitation

4. Data exfiltration:

• S3 bucket data access
• Database dumps via compromised credentials
• Secrets Manager/Parameter Store retrieval

Phase 5: Post-Exploitation

Demonstrate impact:

• What data could be accessed?
• What could be modified or deleted?
• How persistent could access be?
• What blast radius exists?

Document findings with:

• Attack chain narrative
• Technical evidence (logs, screenshots)
• Business impact assessment
• Remediation recommendations

Common Cloud Vulnerabilities

Identity and Access

Network Exposure

Data Security

Serverless Security

Reporting

Executive Summary

Provide business-context findings:

• Overall security posture rating
• Critical risks requiring immediate attention
• Comparison to industry benchmarks
• Strategic recommendations

Technical Findings

Each finding should include:

## Finding: Overprivileged Lambda Execution Role

**Severity:** High
**Affected Resources:** arn:aws:lambda:us-east-1:123456789012:function:DataProcessor

### Description
The Lambda function DataProcessor has an execution role with AdministratorAccess policy attached, granting full access to all AWS services and resources.

### Evidence

aws iam list-attached-role-policies --role-name DataProcessor-role { "AttachedPolicies": [ { "PolicyName": "AdministratorAccess", "PolicyArn": "arn:aws:iam::aws:policy/AdministratorAccess" } ] }

### Impact
An attacker exploiting a vulnerability in the Lambda function code could:
- Access and exfiltrate all data in the account
- Create backdoor credentials for persistent access
- Modify or delete any resource
- Pivot to other accounts via cross-account roles

### Remediation
1. Analyze function code to determine actual permissions needed
2. Create custom IAM policy with only required permissions
3. Remove AdministratorAccess policy
4. Enable CloudTrail logging for function activity
5. Consider using Lambda resource-based policies for additional restrictions

### References
- AWS Lambda least privilege: https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html
- CIS AWS Benchmark 1.16

Compliance Considerations

PCI DSS Requirements

• Quarterly external vulnerability scans (ASV)
• Annual penetration testing of cardholder data environment
• Segmentation testing every 6 months
• Application penetration testing for significant changes

SOC 2

• Penetration testing typically included in risk assessment controls
• Results feed into trust services criteria evaluation
• Remediation tracking required

HIPAA

• Risk assessment must include technical evaluation
• Penetration testing demonstrates reasonable safeguards
• Document findings and remediation in security records

FedRAMP

• Annual penetration testing required
• Specific methodology requirements
• Results reported to authorizing officials
• Remediation timelines enforced

Red Team vs. Penetration Test

When to use red team:

• Mature security program wanting to test detection
• Compliance requirements for adversary simulation
• Board/executive request for realistic assessment

Frequently Asked Questions

Do we need to notify our cloud provider before testing?

For AWS, Azure, and GCP, you don't need pre-approval for testing your own resources within their acceptable use policies. However, document your authorization from the resource owner and stay within permitted activities.

Can we test SaaS applications in our cloud environment?

Generally yes for your configurations, but testing the SaaS application itself (like Salesforce, ServiceNow) requires the vendor's permission. Focus on your configuration of those services rather than their application code.

How is cloud penetration testing different from on-premise?

Cloud testing focuses more on misconfigurations, IAM weaknesses, and cloud-specific attack paths rather than network-level exploitation. The attack surface includes APIs, identity federation, and cloud-native services that don't exist on-premise.

What credentials should we provide to testers?

For authenticated testing: provide low-privilege user credentials. For configuration review: read-only IAM access is helpful. For blind/black-box: provide only the scope information and let testers discover access. Always provide break-glass contacts for critical findings.

How often should we penetration test cloud environments?

Annually at minimum, and additionally after significant changes (new applications, architecture changes, major cloud service adoption). Continuous configuration assessment through CSPM complements periodic manual testing.

Building a Testing Program

Year 1: Establish Baseline

• Initial penetration test of production environment
• Configuration review of all cloud accounts
• Remediate critical and high findings
• Implement CSPM for ongoing visibility

Year 2: Expand Coverage

• Test additional environments and applications
• Add red team exercise
• Include supply chain/third-party assessment
• Purple team exercises to improve detection

Ongoing: Continuous Improvement

• Quarterly configuration assessments
• Annual penetration testing
• Bi-annual red team exercises
• Integration with vulnerability management
• Metrics tracking and trend analysis

Conclusion

Cloud penetration testing is essential for validating your security controls actually work. Automated scanning finds some issues, but manual testing by skilled professionals discovers the complex attack chains that lead to significant breaches.

Plan tests carefully with proper authorization and scoping. Focus on cloud-specific risks: misconfigurations, identity weaknesses, and excessive trust relationships. Remediate findings based on actual risk, and track progress over time.

Regular testing builds confidence that your cloud environment can withstand real attacks—not just pass compliance checkboxes.

Part of the 30 Cloud Security Tips for 2026 series.