How to test a multi-cloud setup during a penetration test

Testing a multi-cloud environment is one of the more technically demanding forms of penetration testing you can undertake. When an organization spreads workloads across AWS, Azure, Google Cloud, or other providers simultaneously, the attack surface multiplies and the interdependencies between platforms create blind spots that single-cloud assessments simply do not expose. This guide walks you through a structured approach to multi-cloud penetration testing, from preparation through consolidated reporting, so you can produce findings that actually reflect the full scope of risk.

What you need before testing a multi-cloud environment

Before any active testing begins, establish a clear scope and gather the access credentials, documentation, and tooling required for each cloud provider in scope. Rushing into testing without this groundwork leads to incomplete coverage and findings that miss entire segments of the environment.

Confirm the following with the client before you start:

• Written authorization covering all cloud accounts, regions, and services in scope
• Read-only or scoped IAM credentials for each provider (AWS, Azure, GCP, etc.) for reconnaissance phases
• Architecture diagrams or infrastructure-as-code repositories, if available
• A list of out-of-scope resources, such as shared services or third-party SaaS integrations
• Emergency contact details and a pause protocol in case testing causes unintended disruption

On the tooling side, install and configure cloud-native enumeration tools such as ScoutSuite, Prowler, or CloudMapper before the engagement begins. Having these ready means you spend the testing window on analysis rather than setup. Verify that your credentials authenticate successfully against each provider and that you can reach the relevant APIs from your testing environment.

Map the attack surface across all cloud providers

With prerequisites confirmed, the first active step is building a complete picture of what exists across every cloud platform. Enumeration is the foundation of effective penetration testing, and in a multi-cloud context it requires running discovery separately for each provider before combining the results.

1. Run automated enumeration tools against each cloud account to list compute instances, storage buckets, databases, serverless functions, container clusters, and networking components.
2. Identify all publicly exposed endpoints, including load balancers, API gateways, and storage objects with public access policies.
3. Document which services communicate across cloud boundaries, such as data pipelines that move between AWS S3 and Azure Blob Storage.
4. Note all regions in use, since misconfigurations frequently appear in secondary regions that receive less operational attention.

After enumeration, consolidate your findings into a single asset inventory before moving forward. Flag any resources that were not mentioned in the client-provided documentation, as undocumented assets are a common source of critical vulnerabilities. At this stage, you should have a clear map of every cloud footprint and the connections between them.

Test identity and access controls in each cloud

Identity is the most frequently exploited layer in cloud environments. Each provider implements identity and access management differently, so you need to evaluate IAM policies, role assignments, and authentication configurations independently for AWS, Azure, and GCP before looking at how they interact.

Review IAM policies and privilege assignments

Examine every IAM role, service account, and managed identity for overly permissive policies. Look specifically for wildcard permissions, roles with administrative access attached to non-administrative workloads, and policies that grant cross-account or cross-subscription access without justification.

1. Export all IAM policies and run them through a policy analysis tool or review them manually against the principle of least privilege.
2. Identify service accounts or managed identities that have permissions beyond what their associated workload requires.
3. Check for long-lived access keys or credentials that are not rotated, particularly in AWS IAM users and GCP service account keys.

Test authentication mechanisms

Verify that multi-factor authentication is enforced for human users across all providers and that federated identity configurations do not introduce trust relationships that can be exploited. In Azure, pay particular attention to Conditional Access policies and whether they apply consistently to all user types, including guest accounts.

After completing IAM testing, you should have a list of specific privilege escalation paths and authentication gaps for each provider. These findings often carry high severity ratings and should be documented with clear reproduction steps.

Probe cross-cloud connectivity and data flows

The most distinctive risk in a multi-cloud setup is how the platforms connect to each other. A misconfiguration in a cross-cloud data pipeline or an overly permissive network peering arrangement can allow an attacker to pivot from a lower-security environment into a more sensitive one. This step focuses specifically on those inter-cloud boundaries.

1. Identify all VPN tunnels, VPC peering connections, private endpoints, and API integrations that span cloud providers.
2. Test whether network security groups, firewall rules, and access control lists on cross-cloud connections restrict traffic to only the required ports and protocols.
3. Attempt to access resources in one cloud provider using credentials or tokens obtained from another, simulating lateral movement across the environment.
4. Review data transfer configurations for encryption in transit, particularly for pipelines that move sensitive data between providers.
5. Check whether logging is consistent across cross-cloud connections, since gaps in log coverage are frequently exploited to avoid detection.

After probing these connections, verify which of your attempted cross-cloud pivots succeeded and which were blocked. Successful pivots that were not logged are particularly significant findings, as they indicate both a security gap and a detection gap simultaneously.

Validate findings and consolidate results across providers

Once active testing is complete across all providers, the final step is validating each finding and producing a unified report that represents the full multi-cloud risk picture rather than a collection of separate single-cloud assessments.

1. Reproduce each finding at least once to confirm it is not a false positive before including it in the report.
2. Assess the chained risk of findings that span providers; for example, an IAM misconfiguration in AWS that enables access to a connected Azure data store carries higher combined severity than either issue in isolation.
3. Prioritize findings by exploitability and business impact, not just by the severity rating assigned by automated tools.
4. Map each finding to the relevant cloud provider, affected resource, and the specific misconfiguration or vulnerability that enabled it.
5. Include remediation guidance that accounts for each provider’s specific controls, since the fix for an overly permissive policy differs between AWS, Azure, and GCP.

A well-consolidated report gives the client a single, coherent view of their multi-cloud risk rather than three separate documents they have to interpret themselves. Cross-provider findings should be highlighted explicitly, as these are often the most actionable and the most overlooked. If you want support structuring or conducting a multi-cloud assessment, reach out to us and we can discuss how we approach these engagements.