Cloud Penetration Testing: AWS, Azure & GCP Attack Strategies 2026 Edition (Penetration Testing Mastery Book 2)

Not sure yet? Here is the full table of contents and the first chapter, exactly as it appears in the book.

Contents

• Chapter 1: Cloud Security’s New Attack Surface
• Chapter 2: Lab Setup and Safe Testing Environments
• Chapter 3: Reconnaissance: Mapping Cloud Footprints
• Chapter 4: AWS IAM: Identity Exploitation Fundamentals
• Chapter 5: Azure AD and Entra ID Attack Paths
• Chapter 6: GCP IAM and Service Account Exploitation
• Chapter 7: Storage Attacks: Buckets, Blobs, and Data Exfiltration
• Chapter 8: Compute Instance Takeover Techniques
• Chapter 9: Serverless and Function-as-a-Service Attacks
• Chapter 10: Kubernetes and Container Orchestration Exploitation
• Chapter 11: Database and Managed Service Targeting
• Chapter 12: Network Segmentation and VPC Exploitation
• Chapter 13: API Gateway and Serverless API Attacks
• Chapter 14: Secrets Management and Credential Harvesting
• Chapter 15: Privilege Escalation: Cross-Service Attack Chains
• Chapter 16: Persistence and Backdoor Mechanisms
• Chapter 17: Detection Evasion and OpSec in Cloud
• Chapter 18: Comprehensive Platform Assessment Framework

18 chapters in the complete book.

Chapter 1: Cloud Security’s New Attack Surface

When I conducted my first cloud penetration test back in 2014, I approached it exactly like I would any traditional network assessment. I fired up Nmap, started port scanning, and waited for results that made sense in the mental model I had developed over years of on-premises testing. What I got instead was confusion, blocked connections, and a rather uncomfortable call from the cloud provider’s abuse team. That experience taught me something fundamental: cloud environments are not simply someone else’s data center. They represent an entirely new paradigm that demands we rethink everything we thought we knew about attack surfaces, security boundaries, and testing methodologies.

The cloud has fundamentally transformed how organizations build, deploy, and secure their infrastructure. But this transformation has also introduced attack surfaces that simply did not exist in traditional environments. When you walk into a physical data center to test security, you deal with tangible network boundaries, physical access controls, and infrastructure that changes at a measured pace. Cloud environments demolish these familiar constructs. Infrastructure becomes code. Networks become software-defined overlays. Identity becomes the new perimeter. Everything exists in a state of constant flux where resources spin up and down in seconds.

This is not merely a technical shift. It represents a complete reimagining of what an attack surface looks like. Traditional penetration testing focused heavily on network exploitation, privilege escalation through operating system vulnerabilities, and lateral movement across relatively static infrastructure. Cloud penetration testing requires us to think in layers of abstraction, API interactions, identity federation chains, and ephemeral compute resources that may not exist long enough to exploit using conventional methods.

Consider the fundamental architecture of cloud platforms. AWS, Azure, and GCP all operate on a model where nearly every action occurs through API calls. When you launch a virtual machine in the AWS console, you’re actually making an API request to the EC2 service. Configure a storage bucket, and you interact with S3 or Azure Blob Storage through their respective APIs. This API-first design creates an attack surface that extends far beyond traditional network protocols. Instead of looking for open ports and vulnerable services, cloud attackers hunt for misconfigured API permissions, exposed credentials, and identity relationships that grant unintended access.

The shared responsibility model complicates this picture further. Cloud providers secure the underlying infrastructure: the physical data centers, hypervisors, network fabric, and foundational services. You remain responsible for everything you build on top of that foundation. This division sounds clear in principle but becomes maddeningly ambiguous in practice. When a misconfigured S3 bucket exposes sensitive data, is that a failure of AWS security or your configuration practices? When an Azure AD misconfiguration allows unauthorized access, where does Microsoft’s responsibility end and yours begin?

AWS articulates this through their shared responsibility model where they handle security of the cloud while customers manage security in the cloud. Amazon secures the infrastructure running their services. You control identity and access management, network configuration, encryption settings, and application-level security. Microsoft Azure draws similar boundaries, with additional complexity around hybrid scenarios where on-premises Active Directory integrates with Azure AD. Google Cloud Platform follows this same pattern, though their terminology and specific boundaries vary slightly.

Understanding these boundaries is critical for penetration testing because they define what you can and should test. You cannot and should not attempt to compromise the underlying hypervisor or physical network infrastructure, those belong to the provider and are explicitly out of scope for any legitimate penetration test. Your testing focuses on the configurations, permissions, and resources you control. IAM policies, network security groups, API configurations, application code, container configurations, and the complex identity relationships that tie everything together.

The API attack surface deserves particular attention because it introduces vulnerabilities that traditional network security tools often miss entirely. Every cloud service exposes management APIs that control resources, retrieve data, and modify configurations. These APIs authenticate requests using access keys, tokens, or federated identity assertions. When credentials leak or permissions are misconfigured, attackers gain powerful capabilities without ever touching a traditional network. The 2019 Capital One breach demonstrated this perfectly: an attacker exploited a misconfigured web application firewall to access AWS metadata services, retrieved temporary credentials, and then used those credentials to call S3 APIs directly and exfiltrate data from hundreds of buckets. No network exploitation occurred. No malware was deployed. The entire attack chain operated through legitimate API calls with stolen credentials.

Identity federation introduces another dimension of complexity that fundamentally changes how we approach authentication and authorization testing. In traditional environments, identity typically lived in Active Directory or LDAP directories with relatively straightforward trust relationships. Cloud environments blend multiple identity providers through federation protocols like SAML, OAuth, and OpenID Connect. An organization might authenticate users through on-premises Active Directory, federate those identities to Azure AD, use Azure AD to provide single sign-on to AWS through SAML assertions, and then map those federated identities to IAM roles that grant access to specific resources. Each step in this chain introduces potential attack vectors, from compromising the on-premises identity provider to exploiting misconfigurations in federation trust relationships to privilege escalation through overly permissive role mappings.

The 2021 SolarWinds supply chain attack illustrated how identity federation can amplify compromise. Attackers who gained access to on-premises environments leveraged that foothold to compromise Azure AD, then used federated access to move into cloud environments where they could access email, documents, and other sensitive resources. The traditional network perimeter had become irrelevant. Identity was the perimeter, and once attackers controlled identity systems, geographic boundaries and network segmentation provided no protection.

Serverless architectures completely upend traditional notions of attack surfaces. When you deploy a function to AWS Lambda, Azure Functions, or Google Cloud Functions, you’re not managing servers, networks, or operating systems in any conventional sense. The platform handles all that infrastructure. Your responsibility focuses entirely on the function code, its permissions, and how it integrates with other services. From a penetration testing perspective, this means traditional tools and techniques often don’t apply. You cannot SSH into a Lambda function. You cannot install a persistent backdoor in a container that exists for milliseconds. Instead, you look for vulnerabilities in function code, excessive IAM permissions that grant unintended access, event injection attacks that trigger functions with malicious payloads, and data exposure through function outputs or logs.

Consider a typical serverless application: an API Gateway triggers a Lambda function that processes user input and writes results to DynamoDB. Traditional penetration testing might focus on the web server hosting the API, looking for operating system vulnerabilities or web application flaws. In the serverless model, there is no web server to compromise. Instead, you examine whether the API Gateway properly validates input, whether the Lambda function handles untrusted data safely, whether the IAM role attached to it has more permissions than necessary, and whether the DynamoDB table’s access controls prevent unauthorized queries. The attack surface has shifted entirely from infrastructure to logic, permissions, and service integration points.

Multi-tenancy represents perhaps the most fundamental difference between cloud and traditional environments. When you deploy infrastructure in your own data center, you control the entire stack. Your servers run your workloads, isolated from other organizations by physical and network separation. Cloud environments deliberately collapse those boundaries. Your virtual machines run on the same physical hardware as other customers’ workloads, separated only by hypervisor isolation. Your data sits in the same storage systems as competitors’ data, separated only by logical access controls. Your network traffic flows through the same physical infrastructure as thousands of other tenants, separated only by software-defined networking.

This multi-tenancy introduces risks that don’t exist in single-tenant environments. Researchers have demonstrated side-channel attacks that leak information across virtual machine boundaries by exploiting shared CPU caches. Though cloud providers implement extensive mitigations, the fundamental concern remains: your security depends partly on the provider’s ability to maintain isolation between tenants. From a penetration testing perspective, this means you must consider not just direct attacks against your resources but also the possibility that insufficient isolation could allow information leakage or cross-tenant attacks.

The legal and ethical framework for cloud penetration testing requires careful navigation because you’re testing infrastructure you don’t own. Traditional penetration testing operated under relatively straightforward authorization: get written permission from the asset owner, define scope, and proceed. Cloud testing adds another layer: the cloud provider’s terms of service and acceptable use policies. Each major provider has specific rules about security testing that you must follow to avoid having your account suspended or facing legal consequences.

AWS maintains a policy that allows certain types of penetration testing without prior approval, including testing of EC2 instances, RDS instances, and other specific services. However, they prohibit several activities including DNS zone walking, port flooding, and DDoS attacks. You must still obtain authorization from your organization, but you don’t need to notify AWS before testing approved services. For prohibited activities or services not on the approved list, you must submit a request through their penetration testing request form and wait for explicit approval.

Microsoft Azure has evolved their policy over the years to become more permissive. As of 2026, Azure generally allows penetration testing of your own resources under their Acceptable Use Policy, provided you comply with their engagement rules. These rules prohibit testing other customers’ resources, conducting denial of service attacks, and exploiting any vulnerabilities you discover in the Azure platform itself. If you discover a platform vulnerability during your testing, Azure expects you to report it through their responsible disclosure process rather than exploiting it further.

Google Cloud Platform similarly allows penetration testing of your own resources without prior approval, subject to their terms of service and acceptable use policy. Like AWS and Azure, GCP prohibits attacks that could impact other customers, platform-level exploitation, and activities that violate laws or regulations. They also expect responsible disclosure if you discover GCP platform vulnerabilities during your testing.

These policies share common themes: you can test your own resources, you cannot attack the platform or other customers, and you must conduct testing ethically and legally. But the specific boundaries and approval processes differ enough that you must review each provider’s current policy before beginning any engagement. Policies also change over time, so the guidance that was accurate six months ago may not reflect current rules.

Beyond provider policies, you must consider broader legal frameworks including the Computer Fraud and Abuse Act in the United States, the Computer Misuse Act in the United Kingdom, and similar legislation in other jurisdictions. These laws generally prohibit unauthorized access to computer systems, and their interpretation in cloud contexts continues to evolve through case law. Your authorization must be crystal clear, documented in writing, and explicitly cover all systems and activities within scope. Assumptions and verbal agreements provide no legal protection if something goes wrong.

Scope definition in cloud environments requires precision that exceeds traditional penetration testing. You cannot simply say you’re testing the production environment when that environment might consist of hundreds of accounts, thousands of resources, and complex service integrations that span multiple regions. Instead, you must identify specific accounts, resource identifiers, IP address ranges (if applicable), and services within scope. You should also explicitly document what is out of scope: production databases, customer data, or critical services that cannot tolerate testing-related disruptions.

The ephemeral nature of cloud resources adds another complication to scope definition. Infrastructure that exists today might be gone tomorrow, replaced by different resources with different identifiers. Scope must be defined more abstractly than traditional penetration tests where you could list specific IP addresses and hostnames. You might define scope in terms of account IDs, resource tags, or architectural components rather than specific resource instances.

Developing the right mindset for cloud penetration testing requires unlearning some habits from traditional testing and embracing new patterns of thinking. In traditional environments, persistence matters. You want to maintain access to compromised systems, install backdoors, and ensure you can return even if some access is discovered and removed. Cloud environments reward different thinking. Resources are ephemeral and easily replaced. Network boundaries are fluid and constantly changing. Instead of fighting for persistent access to specific resources, effective cloud attackers focus on identity compromise, credential theft, and permission escalation that grants lasting access through legitimate authentication mechanisms.

Think about how an attacker approaches an AWS environment. Rather than trying to exploit an EC2 instance and maintain access to that specific compute resource, they hunt for IAM credentials. Once they obtain credentials (through misconfigured S3 buckets, exposed access keys in GitHub repositories, or credentials in EC2 metadata services) they can authenticate directly to AWS APIs as a legitimate user. The specific compute resources become irrelevant because the attacker now operates at the control plane level, calling APIs to enumerate resources, exfiltrate data, launch additional infrastructure, or modify configurations.

This shift from infrastructure-focused thinking to identity-focused thinking represents the core mindset change required for effective cloud penetration testing. You must think in terms of permission boundaries rather than network boundaries, API access rather than network protocols, and identity relationships rather than host-based exploitation. The traditional kill chain of reconnaissance, exploitation, persistence, and lateral movement still applies conceptually, but each phase manifests differently in cloud environments.

Reconnaissance in the cloud means enumerating cloud resources, discovering API endpoints, mapping identity relationships, and understanding service configurations. Exploitation often involves taking advantage of misconfigured permissions rather than exploiting software vulnerabilities. Persistence comes through maintaining valid credentials or creating backdoor access through IAM policies rather than installing malware. Lateral movement happens through assuming roles, pivoting between services using identity relationships, or exploiting trust relationships between accounts rather than exploiting network services on different hosts.

As you work through this book, you’ll develop practical skills for testing each major cloud platform: AWS, Azure, and GCP. You’ll learn specific tools, techniques, and attack patterns that work against real cloud infrastructure. But underlying all those tactical skills is this fundamental understanding: cloud security testing requires different thinking because cloud infrastructure operates according to different principles. Master these principles, understand why the cloud attack surface differs so dramatically from traditional environments, and you’ll develop the adaptability needed to test effectively as cloud platforms continue to evolve.

The cloud has not made penetration testing obsolete, it has made it more important than ever. But it has also made it more complex, more nuanced, and more dependent on understanding architectural patterns and service-specific configurations. The attackers understand this. They’ve moved beyond traditional network exploitation to focus on identity compromise, API abuse, and cloud-native attack techniques. As penetration testers, we must make the same evolution. This book will guide you through that evolution, building practical skills on top of the conceptual foundation we’ve established in this chapter.

… and that is just the beginning. The complete book continues from here, instant download, DRM-free, yours to keep.