Cloud Penetration Testing: What Changes in AWS, Azure, and GCP Environments

Moving workloads to a cloud provider does not move your security responsibility with them. The shared-responsibility model defines what the provider secures, which is the physical infrastructure and the managed services layer, and what the customer secures, which is everything built on top of it. Most cloud security incidents exploit the customer side. A penetration test that treats a cloud-hosted system the same way it would treat an on-premises system will miss the categories of risk that actually cause cloud breaches.

Cloud environments introduce attack paths that do not exist in traditional infrastructure. Identity and access management configurations, service account permissions, metadata service access, and cross-service trust relationships create vulnerabilities that are invisible to a tester running standard network-layer tools. Testing a cloud environment properly requires understanding how the provider's control plane works and where misconfigurations in it create exploitable conditions.

The Identity Layer Is the Perimeter

In a cloud environment, the identity and access management layer is effectively the perimeter. Poorly scoped permissions, overly permissive service account roles, and credentials exposed in environment variables or code repositories are the most common initial access vectors in cloud breaches. A cloud penetration test needs to examine the permission model across all relevant identities: human users, service accounts, and the roles that cloud resources assume when interacting with each other.

Privilege escalation in cloud environments frequently looks nothing like privilege escalation in traditional infrastructure. An attacker who starts with a low-privileged identity may find a service account with broader permissions, a misconfigured role that allows the attacker to attach policies to their own identity, or a storage bucket containing credentials for a higher-privileged account. Chaining these steps together can produce administrator-level access without exploiting a single software vulnerability. This class of finding requires a tester who understands the provider's permission model, not just network-layer enumeration.

Misconfigurations Are the Dominant Finding Category

The most impactful findings in cloud pen tests are typically configuration issues rather than traditional software vulnerabilities. Public-facing storage buckets, overly permissive network security groups, unencrypted snapshots accessible across accounts, logging disabled on sensitive services, and unauthenticated metadata service access are all configuration states that create immediate, exploitable risk. These are not hypothetical edge cases; they appear in production environments at organisations with mature security programmes.

The metadata service available within cloud compute instances is a particularly important testing target. This service provides instance-specific configuration information and, in many environments, temporary credentials for the role the instance is running as. If an attacker achieves server-side request forgery against an application running on a cloud instance, the metadata service is often the first pivot point. Testing whether the metadata service is accessible from application-layer vulnerabilities and whether the credentials it returns have excessive permissions is a fundamental part of cloud pen testing that standard web application assessments skip.

Cross-Account and Cross-Service Trust Relationships

Cloud deployments frequently involve resources spread across multiple accounts, with trust relationships allowing one account or service to access resources in another. These relationships are often configured early in a cloud deployment and reviewed infrequently. A trust relationship that made sense when a project was a proof of concept may persist into production with permissions that were never intended for that context.

Cross-service trust is similarly overlooked. When a cloud function has permissions to read from a storage bucket, write to a database, and call an external API, the function itself becomes a high-value target. Compromising the function, or finding a way to invoke it with unexpected inputs, may provide indirect access to all those connected resources. Mapping these trust relationships and testing the paths they create is work that requires specific cloud knowledge and cannot be replicated by running network-layer tooling against IP addresses.

Rules of Engagement Differ by Provider

Each major cloud provider has specific rules governing what penetration testing activities are permitted without prior notification or approval. These rules change over time and differ in their details. Some categories of testing, particularly anything that could affect the availability of shared infrastructure or that involves the provider's own management interfaces, require advance notification or are prohibited entirely. A testing firm that is not familiar with the current rules of each provider creates compliance risk for the client organisation, not just testing risk.

The scope definition process for a cloud pen test must account for provider rules, test account isolation (to avoid impacting production workloads or neighbouring accounts), and what cloud-specific tooling the tester will use. Testers who do not bring cloud-specific methodology and experience to these engagements typically produce findings that could have been generated by a configuration scanner, which is a different and cheaper product from a penetration test.

• Confirm that the tester has specific experience with the cloud provider your workloads run on.
• Require that the engagement includes IAM review and privilege escalation path analysis.
• Include cross-account and cross-service trust relationships explicitly in scope.
• Ensure the tester understands and complies with the provider's rules of engagement.
• Treat misconfiguration findings with the same severity as software vulnerabilities.

To discuss cloud penetration testing for your environment, contact Cyberlinx at info@cyberlinx.com.au.