Cloud Attack Surface

In the cloud, the provider secures the infrastructure while the customer secures configuration, identity, and data. Most breaches occur on the customer side of this line.

• The provider patches hypervisors and physical security.
• The customer owns IAM policies, storage permissions, and network rules.
• Misconfiguration, not provider compromise, is the dominant risk.

Cloud has no traditional network edge. Access is governed by IAM: users, roles, policies, and keys. A leaked access key can be as damaging as a stolen domain admin password.

• IAM policies grant actions on resources.
• Roles let services and users assume temporary credentials.
• Over-permissioned identities are the primary escalation vector.

Cloud credentials leak constantly. Common sources include:

• Access keys committed to public Git repositories.
• Keys hardcoded in mobile apps, CI logs, or container images.
• Server-Side Request Forgery (SSRF) reaching the metadata service.
• Overly broad sharing of long-lived keys instead of short-lived roles.

Every cloud instance exposes a metadata endpoint that can hand out temporary role credentials. An SSRF or RCE on a VM that reaches it often yields the instance role.

• AWS IMDS lives at 169.254.169.254.
• IMDSv1 is request-only and trivially abused via SSRF.
• IMDSv2 requires a session token (PUT then GET), blunting many SSRF attacks.

Object storage (S3, GCS, Azure Blob) is a recurring source of data exposure.

• Public-read buckets leak sensitive files.
• Public-write buckets allow tampering or malware hosting.
• Overly broad bucket policies or ACLs grant authenticated users access.
• Pre-signed URLs with long expiry leak persistent access.

Cloud network controls (Security Groups, NSGs, firewall rules) are easy to over-open.

• Databases or admin ports exposed to 0.0.0.0/0.
• Management planes (Kubernetes API, RDP, SSH) reachable from the internet.
• Internal services trusting the VPC implicitly with no auth.

Serverless shifts but does not remove risk. Functions, queues, and managed databases each have an execution identity.

• A Lambda's execution role may be over-permissioned.
• Environment variables often hold secrets readable on compromise.
• Event-source misconfig can let untrusted input trigger privileged functions.

Distinguish the two attack surfaces:

• Control plane: the cloud API (create resources, modify IAM, read configs). Compromise here is account-wide.
• Data plane: the workloads themselves (apps, VMs, containers).

A foothold in the data plane that yields control-plane credentials is the classic cloud escalation.

Large organizations split workloads across many accounts/subscriptions/projects.

• Cross-account roles with weak trust policies allow pivoting.
• A confused-deputy in a third-party integration role can be abused.
• Organization-level roles (e.g., OrganizationAccountAccessRole) are high value.

Defenders rely on cloud-native logs. Attackers try to blind them.

• CloudTrail / Activity Log / Audit Logs record control-plane calls.
• Attackers may disable trails or stop log delivery.
• GuardDuty / Security Command Center / Defender flag anomalies.

Disabling logging is itself a high-signal event worth alerting on.

Cloud pentests require provider awareness and authorization. Some actions (denial-of-service, certain scanning) violate provider terms. Always confirm account ownership, agree on blast radius, and prefer read-only enumeration first.

Use a dedicated test account or clearly tagged resources, and never touch resources outside the documented scope.

Confirm your grasp of the cloud attack surface.

You mapped the cloud attack surface.

• Misconfiguration on the customer side dominates cloud risk.
• Identity is the perimeter; leaked keys and roles are key vectors.
• The metadata service bridges data-plane bugs to cloud credentials.
• Storage, network, and logging misconfigs round out the surface.

Next: enumerating cloud resources to find these issues.