Cloud Penetration Testing (AWS, Azure and GCP): Guide

A cloud pentest is an offensive audit against the infrastructure, identities and managed services a company has deployed on AWS, Azure or Google Cloud. It is not the same as a traditional server pentest: here the targets are not public IPs and open ports, they are misconfigured IAM policies, internet-reachable buckets, serverless functions with excessive permissions, keys embedded in CI/CD pipelines and cross-account pivots an external attacker can chain to end up reading your production database without ever touching a machine.

This guide covers what a cloud pentest is, what gets audited on each hyperscaler, the mistakes that show up in 80% of audited environments and how it fits NIS2, DORA, ENS, ISO 27001 and CIS benchmarks.

What a cloud pentest is

A cloud pentest is an authorised and scoped offensive exercise that evaluates the security posture of a cloud tenant (AWS Account, Azure Subscription, GCP Project or Organization) from the perspective of three attacker types:

• Unauthenticated external. What anyone can see from the internet: exposed domains, public buckets, unauthenticated API endpoints, leaked credentials on GitHub.
• External with leaked credentials. The most realistic scenario today: someone compromised an IAM user or a key in a public repository and starts from there.
• Internal (assume breach). Starting from a legitimate low-privilege identity, the team tries to escalate to administrator and pivot across accounts or subscriptions.

Scope is defined by configuration, not by IPs. Auditing AWS doesn't mean scanning Amazon's range: it means reviewing IAM policies, S3 configurations, CloudTrail logs, Lambda deployments, VPC networks, KMS keys, secrets in Secrets Manager and, where applicable, managed services the client uses (RDS, EKS, ECS, API Gateway, Step Functions). Each hyperscaler has its catalogue and its pitfalls.

Unlike a web pentest, where the attacker exploits code you maintain, in cloud the attacker exploits the shared responsibility model contract: AWS, Azure or GCP secure the platform, but the configuration of identities, networks and services is on you. 90% of publicly documented cloud incidents come from customer configuration, not from provider flaws.

Why run a cloud pentest: real value

Three reasons any CISO or CTO already knows and that regulatory frameworks are turning into an obligation:

1. The traditional perimeter is gone. The attack surface lives in IAM policies and service permissions, not in perimeter firewalls. A modern network scanner doesn't detect a Lambda role with iam:PassRole *, but an attacker will use it to escalate to administrator.
2. Cloud incidents are fast and devastating. The mean time between the first command run by an attacker with valid credentials and exfiltration of sensitive data in cloud is under 6 hours according to annual incident response reports from the main EDR/MDR vendors. There's no margin to detect after the fact.
3. NIS2, DORA, ENS and the ISO 27001 audit itself already demand evidence. Control A.5.23 (use of cloud services) in ISO 27001:2022 is not met with a PDF of good intentions, it is met with regular technical audits.

Done well, a cloud pentest delivers:

• Real inventory of identities, resources and effective permissions. Most teams discover entities, keys or roles that have been active for years and forgotten.
• Reproducible attack chains from a realistic starting point to the critical asset, with exact commands.
• Prioritised recommendations by impact, not generic "best practices" lists nobody applies.
• Auditable evidence for the compliance body.

Types of cloud pentest

Not every project is the same. Three formats cover 95% of engagements:

1. Configuration pentest (Cloud Security Posture)

Review of the full account or subscription against CIS benchmarks and official vendor guides. Combines tooling (Prowler for AWS, ScoutSuite and Cloudsplaining multi-cloud, PowerZure for Azure, GCP Scanner) with manual review of non-trivial findings. The base of any cloud pentest: catches 60-70% of exploitable problems before any active attack starts.

2. Assume-breach pentest

Starts from a real low-privilege identity (an internal user, a pipeline key) and measures how far an attacker who already has a foot inside can reach. The format that best reflects the real scenario because most incidents start that way, not with a 0day from the outside.

3. Cloud-native application pentest

Audit of applications that lean on cloud services: APIs behind API Gateway with Lambda, containers in ECS/AKS/GKE, Cloud Run functions, integrations with Cognito or Entra ID. Covers both application logic and the cloud infrastructure supporting it. Overlaps with web pentest but goes into the cloud layer in detail.

What gets audited on AWS

AWS is the hyperscaler with the largest surface and where more flaws appear, for the simple reason that it's the most used. The critical points:

• IAM. Inline policies, managed policies, cross-account assumable roles, poorly restricted trust policies, wildcard * in Resource or Action, missing condition keys, unrotated access keys.
• S3. Public buckets via disabled Block Public Access, inherited ACLs, bucket policies with Principal: "*", unrestricted cross-account copy, pre-signed URLs generated with privileged credentials.
• EC2 and VPC. Security Groups with 0.0.0.0/0 on SSH/RDP, instance profiles with broad permissions reachable via Instance Metadata Service v1, AMIs shared across accounts with sensitive data, public EBS snapshots.
• Lambda and Step Functions. Execution roles with iam:PassRole *, secrets in environment variables, source code reachable via API if the function is invokable without auth.
• RDS and Aurora. Public databases, public snapshots, optional encryption, permissive parameter groups.
• CloudTrail and GuardDuty. Is it active in every region? Is it integrated with SIEM? Does it detect the typical IoCs of an AWS attack (access from Tor IPs, GetCallerIdentity in a loop, IAM user creation by unexpected entities)?
• Secrets Manager and SSM Parameter Store. Who can read each secret, rotation, presence of credentials in User Data of EC2 or in CloudFormation templates.
• EKS and ECS. Misconfigured RBAC, containers mounting the Docker socket, service accounts with excessive permissions via IRSA, open network policies.

Classic attack chains on AWS combine two or three of these pieces. For example: an S3 bucket with a .sh script using a hardcoded key, that key belongs to an IAM user with iam:PassRole permissions, and through iam:CreateRole + AssumeRole the attacker jumps to a role with AdministratorAccess. Each link individually looks "minor"; chained, they are full account takeover.

What gets audited on Azure

Azure has a different model from AWS and that changes the flaw repertoire. Critical points:

• Microsoft Entra ID (formerly Azure AD). Misconfigured Privileged Identity Management, incomplete conditional access policies, abusive consent grants on enterprise applications, service principals with secrets exposed in Azure DevOps or GitHub Actions, optional MFA for privileged roles.
• RBAC and management groups. Inherited Owner assignments, scope /, custom roles with Microsoft.Authorization/*/write.
• Storage Accounts. Containers with anonymous access, Shared Access Signatures generated with excessive privileges and infinite expiry, unrotated account keys.
• Azure Key Vault. Access policies vs RBAC, secrets with open listing permissions, soft delete disabled, absence of purge protection.
• Virtual Networks and NSG. Rules with Internet as source, peering between subscriptions without segmentation, absence of Azure Firewall in critical subscriptions.
• AKS. Cluster RBAC, managed identities assigned with broad permissions, integration with Entra ID, disabled pod security standards.
• Logic Apps and Functions. Triggers exposed without auth, embedded keys, managed identities with Owner roles.

Typical lateral movement in Azure almost always passes through Entra ID and service principals: an attacker who controls an account with permissions over Azure DevOps, GitHub Actions or any pipeline can read the secrets stored in Key Vault with the corresponding managed identity.

What gets audited on Google Cloud (GCP)

GCP has less market share in Spain but is growing in ML, big data and serverless architectures. Critical points:

• IAM and Service Accounts. Bindings to allUsers or allAuthenticatedUsers (public), default service accounts with Editor (what happens if nothing is configured), absence of organization policies restricting enabled services.
• Cloud Storage. Public buckets, missing uniform bucket-level access, inherited legacy ACLs.
• Compute Engine. Images and disks shared between projects, service accounts associated with Editor, permissive OAuth scopes.
• GKE. Workload Identity, node pools with privileged accounts, cluster RBAC, integration with Binary Authorization.
• Cloud Functions and Cloud Run. Functions invokable without auth (allUsers on roles/run.invoker), default service accounts.
• VPC Service Controls. Are there perimeters for sensitive data (BigQuery, Cloud Storage) or does everything rely on IAM?
• Cloud Logging and SCC. Coverage of Audit Logs (Admin Activity, Data Access), connection to an external SIEM.

GCP penalises IAM wildcards less because role bindings are more granular by default, but compensates with a larger blast radius when something fails in a Shared VPC host project.

Methodology: how a serious cloud pentest gets executed

The process we follow in any cloud audit always follows the same six blocks:

1. Scope and authorisations. Written agreement with the list of accounts/subscriptions/projects in scope, time windows, stop criteria and, on AWS, the Customer Support Policy for Penetration Testing (self-tests allowed without prior notice since 2019, with exceptions for DDoS and attacks against shared resources).
2. Reconnaissance. Identification of identities, resources, public domains, leaked repositories, secrets on GitHub/Pastebin with targeted searches (gitleaks, trufflehog, client-specific dorks).
3. Configuration. Execution of automated audit (Prowler, ScoutSuite, Cloudsplaining, PowerZure) and manual review of non-trivial findings. Posture mapped against CIS Benchmarks and CCM (Cloud Controls Matrix) from the Cloud Security Alliance.
4. Exploitation with judgement. Chaining of relevant flaws to demonstrate real impact (data access, escalation to admin, cross-account pivot). No data destruction or service interruption.
5. Reporting. Reproducible attack chains with commands, CVSS severity justified by business impact (not generic category), recommendations prioritised by effort/benefit.
6. Hand-off. Review session with the technical teams, support during remediation and, in clients with recurring audits, retest after changes.

Recurring mistakes that show up in 80% of audited environments

Three systemic failures we see in almost any organisation, regardless of size:

• IAM with historic wildcards. Roles created years ago with * in Action or Resource that nobody dares to touch because "we'd break something". The middle path is to review usage logs (CloudTrail Lake or Access Analyzer in AWS, Activity Logs in Azure) and adjust permissions to what's actually being used.
• Accounts and subscriptions without clear segmentation. Production, staging and innovation environments live in the same account, with the same trust boundary. A compromise in any sandbox compromises production.
• Logs active but nobody is watching. CloudTrail, Azure Monitor or Cloud Logging active but without SIEM, without alerts and without a team to attend them. The forensic capacity exists; the detection capacity does not.

Cloud pentest and compliance: NIS2, DORA, ENS, ISO 27001

The cloud pentest is the technical piece that evidences several mandatory controls:

• NIS2 (article 21). Risk management measures require regular effectiveness testing of technical measures. For cloud environments, that's a specific offensive audit. More in NIS2 in Spain: a compliance guide for 2026.
• DORA (article 25). The TIBER-EU/TLPT regime presupposes threat-led testing on any infrastructure critical to operations, including cloud. More in DORA compliance guide for financial entities 2026.
• ENS (Spanish Royal Decree 311/2022). Measures op.cont.4 (alternative means) and mp.s.2 (cloud service protection) presume regular evaluation of posture.
• ISO 27001:2022 (control A.5.23 Information security for use of cloud services). The certifier demands technical evidence of control over the cloud provider.
• PCI DSS v4.0. Requires annual segmentation testing when cloud is used to process card data.

How to choose a cloud pentest provider

Five criteria that make the difference between a PDF full of Prowler screenshots and a useful pentest:

1. Specialisation by hyperscaler. AWS, Azure and GCP are not interchangeable. The team that signs the report must demonstrate experience exploiting real environments on each one, not just running a checklist.
2. Ability to chain flaws. A good report doesn't list "57 isolated critical findings", it lists "3 attack chains that take an unprivileged user to account takeover". This is where you see whether there are real pentesters behind it or just tooling.
3. Report that serves development. Exact commands, screenshots, minimum viable scripts. Without that, developers cannot remediate and the report ends up filed.
4. Willingness to retest after remediation. An audit without closure verification has half the value.
5. Operational discretion. Cloud findings include secrets, keys and sometimes personal data. The provider must operate with end-to-end encryption, internal repository and contractual deletion at closure.

Frequently asked questions about cloud pentesting

Do you need to ask AWS, Azure or GCP for permission to pentest?

Today not in most cases. AWS published in 2019 the Customer Support Policy for Penetration Testing that allows self-tests on your own account without prior notice over a broad list of services. Azure has had an equivalent policy since 2017 and GCP doesn't require notification if the scope is your own. The exceptions are DDoS, attacks against provider shared resources and techniques that could affect other tenants. Any serious cloud pentest starts by reviewing the current policy of the hyperscaler before touching anything.

How long does a cloud pentest take?

Depends on the estate size. A single account with 30-50 enabled services gets covered in 5-7 working days. A multi-account organisation with landing zone, multiple environments and hundreds of resources typically takes 10-20 days, split across configuration pentest + assume-breach + critical application review.

What's the difference between cloud pentest and CSPM?

A CSPM (Cloud Security Posture Management) like Wiz, Prisma Cloud or Microsoft Defender for Cloud is a continuous tool that detects configuration drift. A cloud pentest is a point-in-time exercise with human judgement that chains flaws to demonstrate real impact. They are complementary: CSPM gives broad permanent coverage; pentest gives depth and prioritises what an attacker would actually exploit.

Does the cloud pentest replace the application pentest?

No. If your application runs in cloud (Lambda + API Gateway, containers on EKS, Cloud Run) you need both: the cloud pentest audits infrastructure and identity; the web pentest audits the code and application logic. The overlap is real but partial. For API surfaces specifically see API penetration testing: REST and GraphQL.

What about hybrid and multicloud environments?

The most common scenario in European mid-sized and large companies: part in AWS, part in Azure for Microsoft 365, GCP for data analytics. The pentest has to cover each one with its own methodology and, above all, the connection points: identity federation, network peering, key synchronisation. Multicloud pivots are the most under-examined vector and the one that surprises most when evaluated.

What about Kubernetes in cloud?

EKS, AKS and GKE deserve their own pentest block because they combine the cluster's specifics (RBAC, pod security, service accounts, admission controllers) with cloud integration (IRSA on AWS, Workload Identity on GCP, managed identities on Azure). A complete cloud audit includes Kubernetes; an audit that ignores the cluster leaves out the asset where the critical application of most modern clients runs.

Related resources

• What is a penetration test: the pillar guide to understand the full discipline.
• Web application penetration testing: how the application layer running on cloud gets audited.
• API penetration testing (REST and GraphQL): the API layer that often sits on top of serverless cloud architectures.
• Cloud misconfiguration errors in AWS and Azure: the catalogue of patterns that show up in 80% of audits.
• Penetration testing pricing in Spain: how cloud pentest engagements get scoped and priced.

Cloud pentesting at Secra

At Secra we run cloud pentests on AWS, Azure and GCP combining configuration auditing (Prowler, ScoutSuite, internal tooling), assume-breach pentesting and cloud-native application review. Every finding ships with a reproducible attack chain, severity justified by business impact and a prioritised remediation plan. If you want a concrete proposal for your landing zone or your subscriptions, get in touch through contact and we'll come back with a first assessment.