Traditional network pentesting is infrastructure-centric. You enumerate IP ranges, scan open ports, fingerprint services, identify outdated software, and attempt exploitation. The workflow is familiar:

  1. Discovery
  2. Service enumeration
  3. Exploit
  4. Privilege escalation
  5. Lateral movement

Cloud pentesting disrupts that model almost immediately. In many AWS environments, for example, there may be no exposed services at all. No open SSH. No public database. Security groups may be tightly restricted. Yet the account may still be vulnerable. Because the attack surface is not just network-facing compute. It is the control plane.

The Attack Surface Is API-Driven

In the cloud, everything is managed via APIs. Compute instances. Storage buckets. IAM roles. Even firewall rules. Pentesting therefore shifts from "Which ports are open?" to "Which identities can call which APIs?" A cloud pentest often begins not with nmap, but with credential validation:

aws sts get-caller-identity

From there, enumeration focuses on:

aws iam list-roles
aws iam list-attached-user-policies
aws ec2 describe-instances
aws s3 ls

The objective is to map the permission graph. You are not scanning hosts. You are mapping trust relationships.

Identity Is the Primary Pivot Point

In network pentesting, lateral movement often involves credential dumping, SMB pivoting, or exploiting internal services. In cloud environments, lateral movement frequently involves sts:AssumeRole. If a compromised principal can assume a more privileged role, escalation is immediate:

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/AdminRole \
  --role-session-name test

Temporary credentials are returned. No internal pivot required. No shell access needed. Cloud lateral movement is often a single API call.

Infrastructure Is Ephemeral

On-prem networks are relatively stable. Servers remain where they are. IP addresses persist. Cloud environments are dynamic. Instances auto-scale. Containers spin up and terminate. Serverless functions execute briefly and disappear. From a pentesting perspective, this creates two complications:

  1. The attack surface changes during the engagement.
  2. Capturing evidence requires deeper logging access.

For example, a misconfigured Lambda function may only exist during runtime invocation. Without reviewing IAM roles and deployment templates, exposure may be missed. Cloud pentesting, therefore, often requires the following:

  • Reviewing Infrastructure as Code (Terraform, CloudFormation)
  • Auditing CI/CD pipelines
  • Evaluating role trust relationships

You are testing design decisions, not just live endpoints.

Metadata Exploitation Replaces Traditional Privilege Escalation

In a traditional environment, privilege escalation often targets local kernel exploits or misconfigured sudo rules. In AWS, escalation frequently targets the instance metadata service. If you compromise an application via SSRF and IMDSv1 is enabled:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

Temporary credentials are exposed. The escalation path is architectural, not exploit-based. Pentesting cloud workloads requires evaluating:

  • IMDS configuration (v1 vs v2)
  • Instance role privileges
  • Container role permissions
  • Service account tokens in Kubernetes

Privilege escalation becomes permission analysis.

Logging and Detection Are Part of the Assessment

In traditional pentesting, detection capability is often secondary. In cloud assessments, visibility is critical. If an organization lacks the following:

  • Organization-wide CloudTrail
  • Logging for global services
  • Alerts on AssumeRole activity

Then compromise may go unnoticed. A cloud pentest frequently evaluates the following:

  • Can CloudTrail be disabled?
  • Are sensitive API calls monitored?
  • Are IAM changes logged centrally?

Testing defensive posture becomes part of the engagement.

Blast Radius Is Larger

In a traditional network, compromising a single server often impacts a limited segment. In cloud environments, a single IAM misconfiguration may expose the entire account. For example:

If an attacker can modify IAM policies:

aws iam create-policy-version --set-as-default

They may escalate to full administrative access.

That one logical error can affect:

  • All compute resources
  • All storage buckets
  • All encryption keys

Cloud pentesting therefore focuses heavily on privilege chaining analysis.

Scope Is More Complex

Cloud environments often span multiple accounts under AWS Organizations. Cross-account trust relationships introduce additional complexity. Assessments must consider:

  • Service Control Policies (SCPs)
  • Cross-account role assumptions
  • Federated identity providers
  • CI/CD pipelines with deployment roles

The attack surface is distributed and interconnected.

The Mindset Shift

Network pentesting is exploit-centric. Cloud pentesting is permission-centric. It requires:

  • Deep understanding of IAM
  • API familiarity
  • Infrastructure as Code analysis
  • Knowledge of provider-specific misconfigurations

The question is no longer "What service is vulnerable?" It becomes:

"What is this identity allowed to do, and what combinations of permissions allow escalation?"

That shift is subtle but decisive.