Cloud Penetration Testing for AWS, Azure, and GCP
Your cloud provider secures the physical infrastructure. You’re responsible for everything running on top of it, IAM configuration, storage access policies, secrets handling, workload isolation, and logging coverage. Most cloud breaches don’t exploit zero-days. They exploit misconfigured roles, over-permissive buckets, hardcoded credentials, and trust relationships that nobody audited.
We test those gaps, manually, across AWS, Azure, and GCP, and show you exactly where an attacker would go and what they’d reach.
Engagements from $6,500. Fixed-price quote within 24 hours.
What We Test: Cloud Attack Surface by Layer
Every engagement is scoped to your actual environment, not a generic checklist. Core test areas:
Identity and Access Management (IAM)
Overly permissive roles, unused access keys, cross-account trust misconfiguration, and privilege escalation paths via iam:PassRole and sts:AssumeRole abuse. On AWS we review both IAM policies and Service Control Policies. On Azure, we test RBAC assignments, managed identity exposure, and Entra ID configuration. On GCP, we validate service account key hygiene and Workload Identity Federation setup.
Storage and Data Exposure
Public S3 buckets, Azure Blob containers with anonymous read access, GCS objects with allUsers permissions, misconfigured pre-signed URLs, and missing or disabled access logging. We verify encryption enforcement at rest and in transit across all tested data stores.
Secrets and Credentials Management
Hardcoded credentials in Lambda environment variables, EC2 IMDSv1 exploitation, Kubernetes secrets stored in plaintext, secrets leaking through CI/CD pipeline logs, and insecure configuration of AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager.
Publicly Exposed Services
Internet-facing EC2 instances and RDS endpoints that shouldn’t be public, storage management consoles accessible externally, development environments promoted to production without access controls, and security group or firewall rules with unrestricted inbound access (0.0.0.0/0).
Container and Serverless Attack Surfaces
Container escape in EKS, AKS, and GKE clusters; privileged pod configurations; Kubernetes RBAC misconfigurations; insecure admission controllers; and function abuse via event injection or permission boundary violations in Lambda, Azure Functions, and Cloud Run.
Shared-Responsibility Model Gaps
Configuration drift from baseline hardening, disabled or misconfigured audit logging (CloudTrail, Azure Monitor, Cloud Audit Logs), and detection blind spots where an attacker could operate undetected for days without triggering an alert.
Real-World Attack Scenarios We Simulate
These are representative attack chains we find and validate, not theoretical threats.
IAM Role Chain to Full Account Takeover
A developer role has iam:PassRole with no condition keys. An attacker with access to that role creates an EC2 instance, passes a more privileged role to it, and uses the instance metadata endpoint to retrieve temporary credentials. They then enumerate S3, access RDS snapshots, and exfiltrate data, without touching the primary account owner’s credentials at any point.
Public S3 Bucket to Internal Credential Exposure
A misconfigured bucket containing deployment configuration files is publicly readable. Those files include database connection strings and a hardcoded AWS access key for a service account with ec2:DescribeInstances and ssm:StartSession rights, enough to pivot directly into internal systems.
Kubernetes Workload Breakout to Cloud Control Plane
A pod running with hostPID: true and a mounted host filesystem allows container escape to the underlying node. The node’s instance metadata endpoint exposes an IAM role with broad EC2 and S3 permissions. From inside the cluster, the attacker reaches the cloud control plane with no external network exposure required.
Lambda Credential Theft via Dependency Exploitation
A serverless function stores a third-party API key and internal database credential as plaintext environment variables. The function’s execution role is over-permissioned. A known vulnerability in a runtime dependency is exploited to read the process environment, exposing both secrets in a single step.
Methodology
We work manually from an attacker’s perspective, not from scanner output. After agreeing on scope and establishing a testing account with scoped credentials, we begin with cloud-native reconnaissance, enumerating services, roles, trust boundaries, and exposed endpoints across your account(s). We map privilege escalation paths before attempting exploitation, validate realistic impact for every finding we report, and document all activity throughout. A typical engagement completes in 5–10 business days depending on the number of accounts and services in scope.
Compliance Relevance
Cloud infrastructure is in scope for every major security framework. Our reports are structured to provide the evidence your auditors actually need.
- SOC 2 (CC6, CC7): Logical access controls, encryption, monitoring, and incident detection all require demonstrable evidence from your cloud environment. Findings map to Trust Services Criteria. → [SOC 2 Readiness] [LINK: /soc-2-risk-assessment-services/]
- PCI DSS v4.0 (Req. 11.4): Penetration testing of cloud environments hosting cardholder data is explicitly required. Remediation evidence from our retest supports QSA documentation. → PCI DSS Readiness
- ISO 27001 (A.8, A.12): Asset management and operations security controls require validated cloud configuration review. → ISO 27001 Assessment
- HIPAA: Cloud environments processing ePHI require demonstrated access controls and audit logging — both directly tested in our engagement.
- Shared-responsibility is not a compliance defense. Auditors want evidence that the configuration layer is actually hardened, and they want it in writing.
Read more on how cloud misconfigurations create real business exposure: 7 SaaS Security Vulnerabilities We Found in Real Engagements.
What You Receive
Technical Report Every finding includes: cloud provider reference or CVE where applicable, full attack path narrative, proof-of-concept evidence (screenshots, API responses, command output), CVSS score, exploitability rating under your specific configuration, and step-by-step remediation guidance.
Executive Summary Business-readable risk overview prioritized by exploitability and business impact — suitable for board reporting, investor due diligence, or compliance documentation.
Compliance Evidence Pack Findings mapped to the relevant framework controls for SOC 2, PCI DSS, or ISO 27001, formatted for direct use in audit submissions.
→ Download our sample penetration test report to see the exact format your team and auditors will receive.
Retest Included
Once you’ve remediated findings, we retest every critical and high-severity item at no additional charge within the agreed engagement window. You receive a remediation-confirmed addendum suitable for sharing with auditors, procurement reviewers, or your board.
🔐 Frequently Asked Questions (FAQs)
Find answers to commonly asked questions about our products and services.
Ready to Test Your Cloud Environment?
Tell us which cloud provider(s) you’re running, the key services in scope (IAM, storage, Kubernetes, CI/CD), and the number of accounts or subscriptions — we’ll confirm scope and send a fixed-price quote within 24 hours.