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 Cybersecify, cloud is one scope: Startup plan covers 1 scope at INR 74,999 (5 business days), Growth plan covers 2 scopes at INR 1,79,999 (10 business 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 our cloud penetration testing services cover.

Cybersecify is a founder-led cloud pentest firm based in Bengaluru, India, serving AI-first and API-first SaaS startups from Seed to Series B on AWS, Azure, and GCP. Rathnakara (OSCP) leads every engagement. For the report deliverable format you receive after a cloud pentest, see our SOC 2 + ISO 27001 ready pentest report sample.

Key findings

• Cloud pentest is different from a cloud configuration audit (CSPM). CSPM tools like Wiz or Prisma Cloud produce a list of misconfigurations. A pentest chains those misconfigurations into actual privilege-escalation paths and verifies exploitability. Both are useful; most SaaS startups need both.
• IAM is where most of the critical and high findings concentrate. One overpermissioned role typically chains to full account compromise. Start with limited credentials, map every escalation path, document the full chain.
• All three hyperscalers are tested with the same six-layer methodology (IAM, storage, network and segmentation, container or serverless, supporting services, privilege escalation), but each provider has its own tools and primitives. AWS pentest uses Pacu; Azure uses PowerZure; GCP uses custom scripts plus Google Cloud’s own asset inventory APIs.
• Cloud counts as one pentest scope at Cybersecify. Startup Pentest plan (INR 74,999, 1 scope, 5 business days) covers a single cloud environment. Growth Pentest plan (INR 1,79,999, 2 scopes, 10 business days) covers cloud plus web app or cloud plus API with SOC 2 + ISO 27001 audit prep included.
• Reports are built so your auditor can use them as evidence for SOC 2 and ISO 27001. Methodology follows PTES and CIS Benchmarks (CIS AWS Foundations, CIS Azure, CIS GCP). Growth plan adds explicit SOC 2 TSC and ISO 27001 Annex A control mapping per finding.

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.

IAM Trust Policies and Role Chaining

Permission policies answer “what can this role do”. Trust policies answer “who is allowed to become this role”, and that second question is where the escalation paths live. A role can have a tightly scoped permission policy and still be a critical finding because anyone in any account can assume it.

We read both sides:

• Trust policy principals. On AWS, a role trust policy naming a wildcard principal, or a third-party account without an sts:ExternalId condition, means the role is assumable by parties you did not intend. On GCP the equivalent question is who holds iam.serviceAccounts.actAs or token-creator on a service account. On Azure it is who owns the app registration and who can add a client secret to the service principal behind it.
• Chain depth. One assume-role hop is rarely the whole story. We follow the chain: the low-privilege role can assume role B, role B can pass role C to a compute service, role C has broad access. Each hop looks defensible in isolation.
• PassRole and self-modification. Can this identity attach a more permissive policy to itself, create access keys for a higher-privileged identity, or pass a privileged role to a service it controls (Lambda, ECS task, Cloud Function, Automation Account)?
• Hierarchy inheritance. GCP bindings at the organization or folder level flow down to every project underneath. Azure role assignments at a management group flow down to every subscription. Escalation often comes from a grant made two levels above the resource, by someone who no longer works there.

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.

Metadata Services and SSRF to Credentials

Every cloud VM and most managed compute services expose an internal metadata endpoint at 169.254.169.254 that hands out short-lived credentials for the attached identity. If any application in the environment can be made to issue a request on the attacker’s behalf, that endpoint is the fastest route from a web-layer bug to cloud credentials.

We test every server-side request path we can reach: URL parameters that fetch remote content, webhook targets, PDF and image renderers that follow links, SSO metadata importers, and anything that resolves a hostname supplied by a user. The mechanics differ by provider and the difference is what decides exploitability:

• AWS. IMDSv1 answers a plain GET with no headers, so a basic SSRF returns credentials directly. IMDSv2 requires a PUT to obtain a session token first and applies a response hop limit, which blocks most naive SSRF. We check whether IMDSv2 is merely available or actually enforced as required on each instance, and whether the hop limit permits a containerised workload to reach it.
• Azure. Azure Instance Metadata Service requires the Metadata: true request header, so exploitation needs an SSRF primitive that controls headers rather than just a URL. The managed identity token endpoint is the target.
• GCP. The metadata server requires Metadata-Flavor: Google, the same shape of constraint as Azure. Where it gets interesting is what the token is scoped to, which brings us back to the default Compute Engine service account.

Findings here include the exact request, the credential returned (redacted), and what we could then do with it.

Secrets in Build Pipelines and Environment Configuration

Secrets rarely sit in one place. They sit in the four or five places the team forgot about after moving them to the one right place.

• CI/CD. Build logs that echo environment variables, pipeline definitions with inline credentials, and over-scoped OIDC trust between the CI provider and the cloud account. A GitHub Actions or GitLab OIDC trust policy that matches on the repository owner but not the specific repository, branch, or environment lets any repo under that owner mint cloud credentials.
• Environment configuration. Function and container environment variables, task definitions, and Kubernetes ConfigMaps holding database passwords and API keys in plaintext, where anyone with read access to the resource definition can see them.
• Artifacts and state. Container image layers with credentials baked in from an earlier build step, Terraform state files in storage buckets (state records secret values in cleartext by default), and infrastructure repositories with .tfvars committed.
• Rotation reality. A secret that appears in a git history or a build log is compromised whether or not it was later moved to a secrets manager. We check whether the current live value is the same one that leaked.

Logging and Detection Gaps

A cloud pentest tells you what an attacker could do. Reviewing your logs afterwards tells you whether you would have known. We record the timestamps of our own actions and compare them against what your pipeline captured.

Common gaps: CloudTrail configured in one region while workloads run in three, data events disabled so object-level reads of a sensitive bucket are invisible, Azure diagnostic settings enabled per-resource with new resources silently missing them, GCP Data Access audit logs off by default for most services, and alert rules that fire into a channel nobody reads. Detection findings map cleanly to the MITRE ATT&CK cloud matrices, which is a useful shared vocabulary when your team already runs a SIEM.

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.

Where AWS, Azure, and GCP Actually Differ

The six-layer method is the same on all three. The primitives underneath are not, and pretending otherwise produces a report full of generic advice. The differences that change how we test:

Identity model. AWS separates users and roles, and escalation is usually an sts:AssumeRole chain plus iam:PassRole. Azure has no direct assume-role equivalent; identity lives in Entra ID, so the escalation surface is app registrations, client secrets on service principals, and role assignments made at management-group scope. GCP centres on service accounts that are both identities and resources, so a principal can hold permissions on a service account (impersonate it, create a key for it) separately from holding the account’s permissions.

Default grants. GCP penetration testing engagements repeatedly surface the same starting point: the default Compute Engine service account carries the legacy Editor role, and any workload on the instance inherits it. AWS has no equivalent default at that blast radius. Azure’s analogue is broad Contributor or Owner assignments inherited from a management group.

Hierarchy. GCP has organization, folder, and project. Azure has management group, subscription, and resource group. AWS uses accounts under Organizations with service control policies. Segmentation testing has to follow whichever shape you use, because “production is a separate account” and “production is a separate resource group in the same subscription” are very different isolation stories.

Storage semantics. S3 has both bucket policies and ACLs, and the conflict between them is a recurring finding. Azure Blob adds SAS tokens, which are bearer credentials with their own expiry and revocation problem. GCS has uniform bucket-level access, which removes per-object ACLs when enabled and is worth verifying is actually on.

Metadata endpoint. Covered above: header-free on AWS IMDSv1, header-gated on Azure and GCP. This single difference decides whether a given SSRF is a critical finding or a medium one.

Where a Cloud Pentest Ends and a Configuration Review Begins

Buyers confuse these two constantly, and the confusion usually surfaces after a proposal rather than before. It is worth being direct about it.

A configuration review (which is what CSPM platforms automate) reads your cloud state and compares it against a rule set such as the CIS Benchmarks for your provider. It is broad, fast, repeatable, and complete in the sense that it checks every resource. It answers: does this setting match the recommended value.

A cloud pentest starts from a credential and behaves like an attacker. It is narrow, slower, and deliberately incomplete: we go where the paths lead rather than checking every box. It answers: given this foothold, what can actually be reached.

Practically:

• If a control is misconfigured but nothing exploitable follows from it, a pentest may note it and move on. A configuration review will always flag it. That is the review doing its job, not the pentest missing something.
• If exploitation requires chaining three settings that each look acceptable alone, a configuration review will not flag it and a pentest will. That is the pentest doing its job.
• Coverage claims differ. A configuration review can honestly say “every S3 bucket in the account was checked”. A pentest cannot, and any vendor claiming otherwise is describing a scan.
• Most SaaS teams need both, at different frequencies. Continuous configuration monitoring is a running control. Adversarial testing is a periodic validation, typically annual or triggered by a re-architecture, an enterprise buyer, or an audit.

Our cloud engagements are pentests. We reference CIS Benchmarks in findings because auditors and engineers both recognise them, but we are not selling you a benchmark scan with a report cover on it.

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 Cybersecify, 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 5 business 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 business days and includes SOC 2 + ISO 27001 audit prep evidence.

Both plans are founder-led. Rathnakara (OSCP) 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.

Corrections

• 2026-08-15: Corrected three cloud provider testing-policy references. The GCP answer previously linked to Google’s Cloud Data Loss Prevention product page, which says nothing about penetration testing; it now cites Google’s Cloud Security FAQ, which states you are not required to contact Google to test your own Cloud Platform infrastructure. The Azure answer previously implied Microsoft notification was required for certain testing; Microsoft’s Security Testing Rules of Engagement instead require testing to stay within your own tenant or assets you have explicit authorization for. The AWS answer now names the specific prohibited activities the policy lists. All three provider pages checked 2026-08-15.
• 2026-08-09: Replaced precise percentages describing our own engagement data with qualitative wording. We do not publish a per-engagement findings register, so those figures were not something a reader could verify. The underlying observations are unchanged.