Cloud Attack Surface

The cloud attack surface is the total set of points where an attacker could try to enter or extract data from a cloud environment. Unlike on-prem networks, the cloud surface is defined mostly by configuration and identity, not physical perimeter.

• Public-facing APIs and management consoles
• Identity and access management (IAM)
• Storage buckets, databases, and serverless functions
• Network exposure (security groups, load balancers)

A single misconfigured setting can expose an entire account.

Most cloud pentests target one of the three major providers. Each has its own identity model and terminology, but the attack patterns rhyme.

• AWS — IAM users/roles, S3, EC2, Lambda
• Azure — Entra ID (Azure AD), Blob Storage, VMs, Functions
• GCP — IAM service accounts, Cloud Storage, Compute Engine

Learning one deeply makes the others easier, because the core concepts (identity, compute, storage, network) map across all of them.

Cloud providers secure the infrastructure; the customer secures what they put in it. This is the shared responsibility model, and almost every cloud breach happens on the customer side.

• Provider: physical data centers, hypervisor, managed service patching
• Customer: IAM policies, data, OS patching (IaaS), network config

As a pentester, you focus on the customer's responsibilities, because that is where the exploitable mistakes live.

The first job in a cloud assessment is figuring out who you are and what you can do with the credentials you have. The AWS CLI exposes the caller identity instantly.

If a key is over-permissive, this single identity can pivot across the whole account.

Cloud resources can be reachable from the public internet or only from inside a virtual network. Misconfigured exposure is one of the most common findings.

• Security groups / NSGs open to 0.0.0.0/0
• Storage buckets set to public read
• Databases with public endpoints enabled
• Management ports (22, 3389, 5432) exposed

Mapping which resources are public is the foundation of cloud recon.

Even without credentials, attackers enumerate a target's cloud footprint. Predictable naming and DNS leak a surprising amount.

Tools brute-force bucket and storage names based on the company name and common patterns.

Two distinct attack layers exist in every cloud account:

• Management/control plane — the APIs that create, modify, and delete resources (e.g. iam:CreateUser, ec2:RunInstances)
• Data plane — access to the data inside resources (reading an S3 object, querying a DB)

Compromising the management plane is usually game over, because the attacker can grant themselves any data-plane access they want.

Cloud actions are logged centrally. As a pentester you must know these exist because defenders watch them, and finding them disabled is itself a finding.

• AWS CloudTrail — records all API calls
• Azure Activity Log / Monitor
• GCP Cloud Audit Logs

An account with logging disabled or not monitored is a high-risk finding even before any exploitation.

Most cloud compromises start from one of a handful of footholds:

• Leaked access keys in Git repos, CI logs, or mobile apps
• Over-permissive IAM roles attached to compromised servers
• SSRF reaching the instance metadata service
• Public storage buckets exposing secrets or backups

Recognizing these patterns lets you prioritize where to look first.

A structured approach keeps a cloud assessment thorough. Automated tools enumerate the entire account once you have credentials.

Tools like ScoutSuite and Prowler audit configuration across services and flag risks automatically.

Cloud testing must stay inside the engagement's authorization. Providers also have rules of engagement.

• Confirm the exact accounts, subscriptions, or projects in scope
• Avoid actions that affect other tenants or shared infrastructure
• Never run denial-of-service style tests without explicit written approval

Unauthorized cloud testing can violate provider terms and local law.

Under the shared responsibility model, which side is responsible for IAM policies and data configuration?

You learned what defines the cloud attack surface and how it differs from traditional networks.

• The surface is shaped by identity and configuration, not a physical perimeter
• AWS, Azure, and GCP share the same core concepts: identity, compute, storage, network
• The shared responsibility model puts config and data on the customer
• Distinguish the management plane from the data plane
• Always confirm scope and authorization before testing

Next, we drill into IAM misconfigurations, the heart of cloud attacks.