Cloud Pentest: What We Test in AWS, Azure, and GCP

Cloud penetration testing is a security assessment of your cloud infrastructure on AWS, Azure, or GCP. It tests IAM policies and privilege escalation paths, storage bucket and blob permissions, network segmentation and security groups, container configurations and escape vectors, secrets management, and shared-responsibility boundaries between provider-managed and customer-managed components. Unlike a web application pentest which targets your code, cloud pentest targets the infrastructure your application runs on. Both are separate scopes. At Cyber Secify, cloud is one scope: Startup plan covers 1 scope at INR 74,999 (7 days), Growth plan covers 2 scopes at INR 1,79,999 (10 days).

Your application code might be solid. Your web app pentest came back clean. But the S3 bucket your app writes logs to is publicly readable. The IAM role attached to your EC2 instance has admin privileges. Your security groups allow SSH from 0.0.0.0/0.

None of that shows up in an application pentest. That is what cloud penetration testing is for.

Cloud Pentest vs Traditional Pentest

A web application pentest tests your code. Authentication flows, authorization checks, injection vulnerabilities, business logic flaws. It treats your app as a black box or grey box and attacks the application layer.

A cloud pentest tests the infrastructure your application runs on. The questions are different:

• Can an attacker with compromised credentials escalate to admin?
• Are your storage buckets or blobs accessible without authentication?
• Can a compromised container escape to the host or reach other services?
• Do your network rules actually isolate production from staging?
• Are your secrets stored in environment variables instead of a secrets manager?

These are infrastructure-level findings. Your application scanner will never flag them. Your cloud provider’s built-in tools (AWS Security Hub, Azure Defender, GCP Security Command Center) catch some of it, but they run rule-based checks. They operate within the shared responsibility model where your provider secures the infrastructure and you secure everything you build on top of it. They do not simulate what an attacker would actually do after gaining initial access.

What Gets Tested

The specific checks vary by provider, but every cloud pentest covers these areas.

IAM and Access Controls

This is where most critical findings live. We test:

• Overprivileged roles. An EC2 instance role with s3:* or iam:* when it only needs read access to one bucket.
• Cross-account trust misconfigurations. Roles that can be assumed by any AWS account, not just yours.
• Unused credentials. API keys and access keys that haven’t been rotated in months (or years).
• Missing MFA. Console access without multi-factor authentication on privileged accounts.
• Service account sprawl. GCP service accounts or Azure service principals with permissions nobody remembers granting.

IAM misconfigurations are consistently among the most common findings in cloud penetration tests. Most startups set permissions during initial setup and never revisit them as the team and infrastructure grow.

Storage and Data Exposure

• Public buckets/blobs. S3 buckets, Azure Blob containers, or GCS buckets with public read or list permissions.
• Bucket policy conflicts. A bucket with ACLs set to private but a bucket policy that allows public access.
• Unencrypted storage. Data at rest without encryption, especially backups and logs.
• Overshared snapshots. EBS snapshots or RDS snapshots shared publicly or with unintended accounts.

We have seen production database backups sitting in publicly listable buckets. The bucket name was not guessable, so the team assumed it was safe. An attacker with any foothold in the AWS account could enumerate it in seconds.

Network Segmentation and Security Groups

• Overly permissive ingress rules. Security groups allowing 0.0.0.0/0 on SSH (22), RDP (3389), or database ports.
• Missing egress controls. No restriction on outbound traffic, which lets an attacker exfiltrate data freely after compromise.
• VPC peering misconfigurations. Production VPC peered with development VPC without route restrictions.
• Publicly exposed management interfaces. Kubernetes dashboards, Jenkins, Grafana, or admin panels accessible from the internet.

Privilege Escalation Paths

This is what separates a pentest from a configuration review. We start with limited credentials (simulating a compromised developer laptop or leaked API key) and map every path to higher privileges:

• Can this IAM user create a new admin user?
• Can this role attach a more permissive policy to itself?
• Can this Lambda function’s role access secrets it should not?
• Can we move from a staging environment to production through shared resources?

We document the full attack chain, not just the individual misconfiguration.

Container and Serverless Security

If you run EKS, AKS, GKE, Lambda, or Cloud Functions, we test:

• Container image vulnerabilities. Base images with known CVEs.
• Pod security. Containers running as root, privileged mode enabled, host network access.
• Secrets in environment variables. API keys and database passwords passed as plaintext env vars instead of using Secrets Manager or Vault.
• Lambda/function permissions. Execution roles with broader access than the function needs.

When You Need a Cloud Pentest

Three common triggers for SaaS startups:

An enterprise buyer asks for it. Their security questionnaire specifically asks about infrastructure testing, not just application testing. A web app pentest report will not satisfy this. They want to know your cloud environment has been independently assessed.

You are preparing for SOC 2 or ISO 27001. Both standards expect you to test your infrastructure controls, not just your application. Your auditor will ask for evidence that cloud-specific risks have been assessed.

You just migrated or re-architected. You moved from a monolith on a single VM to microservices on Kubernetes. You adopted multi-account strategy. You introduced a CI/CD pipeline that deploys to production. Each change creates new attack surface that your previous pentest did not cover.

Post-incident. You found an exposed key, a public bucket, or unauthorized access. You need to know what else is wrong before it becomes a second incident.

What the Report Looks Like

Our cloud pentest report includes:

1. Executive summary. What we found, the overall risk level, and what to fix first. Written for founders and CTOs, not security engineers.
2. Finding details. Each finding includes severity, the affected resource (specific ARN, resource ID, or service), proof of exploitation, and step-by-step remediation.
3. Attack chain documentation. If we chained multiple findings to escalate privileges or access sensitive data, we document the full path.
4. Evidence. Screenshots, API responses, and configuration snippets that prove each finding.
5. Remediation priorities. Findings ranked by business impact, not just CVSS score. A publicly readable bucket with PII is more urgent than a missing tag policy.
6. Compliance mapping. Findings mapped to SOC 2 trust service criteria or ISO 27001 Annex A controls, depending on what you need.

You can see how we approach security testing overall on our methodology page.

Cloud Counts as One Pentest Scope

At Cyber Secify, cloud infrastructure testing is a pentest scope. If your cloud environment is your only concern, the Startup Pentest Plan at INR 74,999 covers it in 7 days. If you need both a web app pentest and a cloud pentest, the Growth Pentest Plan at INR 1,79,999 covers 2 scopes in 10 days and includes SOC 2 + ISO 27001 audit prep evidence.

Both plans are founder-led. Rathnakara (OSCP, CompTIA PenTest+) personally leads every engagement.

Need to assess your cloud environment? Talk to us or run a free external attack surface scan to see what is already exposed.