Cloud Penetration Testing Basics

Most systems now run in the cloud (AWS, Azure, GCP), which changes both what you test and what you are allowed to test. The cloud provider owns the infrastructure; you (or your client) own the configuration on top. That split — the shared-responsibility model — determines the boundary of a cloud pentest, and crossing it can breach the provider's terms or the law. This lesson covers the model, the provider rules, the characteristic cloud weaknesses, and the hard constraint: test only your own (or explicitly authorized) cloud account, within the provider's rules.

The cloud boundary is both legal and contractual

You may test the resources your client controls (their VMs, their app, their IAM config). You may not test the provider's underlying infrastructure, other tenants, or anything outside the account — and some activities (like load/stress testing) require prior provider notification or approval. This course describes cloud testing; it does not run it against any account, because doing so needs a real account and provider authorization.

The shared-responsibility model

The provider secures the cloud; the customer secures what they put in it. The exact line depends on the service model:

Layer	IaaS (VMs)	PaaS (managed app)	SaaS (finished app)
Physical / hardware	Provider	Provider	Provider
Hypervisor / host OS	Provider	Provider	Provider
Guest OS / runtime	Customer	Provider	Provider
App / code	Customer	Customer	Provider
Configuration & IAM	Customer	Customer	Customer
Data	Customer	Customer	Customer

Notice configuration, identity and data are always the customer's responsibility — and that's exactly where most cloud breaches happen. A pentest of a cloud environment is overwhelmingly a test of the customer's configuration, not the provider's infrastructure (which is out of scope and off-limits).

Provider testing rules

Each major provider publishes a penetration-testing policy. Historically much testing of your own resources is permitted without prior approval, but there are important exclusions — notably denial-of-service / stress testing, which generally requires prior arrangement — and you must stay within your own account. Always read the current policy for the specific provider before testing, because these rules change; this course won't quote a policy that may be out of date.

Characteristic cloud weaknesses

Cloud pentesting focuses on the customer-responsibility layers:

Identity & Access Management (IAM) — the new perimeter

• Over-permissioned identities — users, roles or service accounts with far more rights than they need; a compromise of one grants sweeping access.
• Privilege escalation via IAM — a role allowed to modify policies or assume other roles can bootstrap itself to admin. (Tools like Pacu for AWS enumerate these paths.)
• Long-lived access keys committed to code or left in images.
• Missing MFA on privileged accounts.

Storage misconfiguration

• Publicly readable/writable object storage (S3 buckets, Azure blobs, GCS) — the classic cloud data breach. Test whether your buckets are public and whether listing/reading is possible.
• Over-shared snapshots, images, or databases.

Network & exposure

• Over-permissive security groups / firewall rules (0.0.0.0/0 to sensitive ports).
• The instance metadata service (Level 2 lesson 7's SSRF target) handing out credentials — a cloud VM's SSRF often becomes credential theft. IMDSv2 (session-token metadata) mitigates it.
• Exposed management interfaces and secrets in environment variables.

Serverless, containers & secrets

• Function permissions and event-source trust.
• Container image vulnerabilities and registry exposure.
• Secrets in environment variables, build logs, or source instead of a secrets manager.

Tooling

• Posture scanners — ScoutSuite, Prowler (AWS/Azure/GCP) assess your account's configuration against best practice. Run them on your own account.
• Exploitation frameworks — Pacu (AWS) for IAM/privilege-escalation path testing.
• Provider-native — the cloud's own security tooling (e.g. access analyzers) often surfaces over-sharing.

A worked example (reasoning)

Testing your own lab AWS account: you run a posture scanner (Prowler/ScoutSuite), which flags a public S3 bucket, an IAM role with a wildcard policy, and a security group open to the world on a database port. You validate: confirm the bucket lists and reads anonymously (proof: a redacted object name), confirm the role's policy permits privilege escalation, confirm the DB port is reachable. You write each as a finding with the specific fix (bucket policy + Block Public Access, least-privilege IAM, restrict the security group), noting you tested only your own account and did not touch provider infrastructure or other tenants. You did not run any DoS/stress test (needs provider approval).

How It Actually Works

Why does moving to the cloud shift breaches so decisively toward configuration and identity rather than the kinds of memory-corruption or patch-level exploits that dominate on-prem? Because the provider takes over exactly the layers that used to be the customer's hardest security problems — the physical security, the hypervisor, the host OS patching, the network fabric — and operates them at a scale and competence most organisations can't match. That's genuinely more secure for those layers. But it doesn't reduce total risk; it relocates it. Everything the customer still controls — who-can-do-what (IAM), what's-exposed (network config), what's-public (storage), where-secrets-live — becomes the entire attack surface, and these are configuration decisions, made quickly, by many people, through APIs, often without the review that code gets. A single checkbox makes a bucket public; a single over-broad policy makes a role omnipotent. The cloud made the hard infrastructure problems disappear and made the easy-to-get-wrong configuration problems the whole game. This is why cloud pentesting is mostly posture assessment and IAM analysis, not exploitation in the classic sense: you're testing decisions, not code.

IAM being "the new perimeter" follows directly. On-prem, the network was the perimeter — get inside the firewall and you were "in." In the cloud there is no inside; every resource is an API endpoint reachable over the internet, and what gates access is identity and policy, not network position. So the question "what can an attacker do?" becomes "what can the identity they compromised do, and what can that identity become?" — which is why IAM privilege-escalation paths (a role that can rewrite policies or assume other roles) are the cloud equivalent of Level 3's local privesc, and why over-permissioning is catastrophic: identity is the access, so excess identity is excess blast radius. The shared-responsibility model isn't just a legal boundary for scoping; it's the map of where the risk moved. Read it and you know where to test: the customer's columns, every time.

Common mistakes and pitfalls

• Testing provider infrastructure or other tenants. Off-limits, and likely illegal. Stay inside the account you own/are authorized for.
• Running DoS/stress tests without provider approval. These are specifically restricted; arrange them in advance or don't.
• Not reading the current provider policy. The rules change; check before every engagement.
• Focusing on the provider's layers instead of configuration/IAM. The breaches are in the customer's columns — storage, IAM, network config, secrets.
• Treating a scanner's output as the finding. Validate (bucket actually public and readable, role actually escalatable) as in Level 3 lesson 1.
• Ignoring the metadata service. A cloud VM's SSRF often becomes credential theft via metadata; check for IMDSv2.
• Exfiltrating real data from a public bucket to "prove" it. A redacted object name and the fact it's listable prove it; don't copy the data.

Exercise

1. Describe the shared-responsibility split for IaaS vs SaaS, and name the three layers that are always the customer's responsibility.
2. Find and summarise the current penetration-testing policy for one major provider (AWS, Azure or GCP). Note one activity that requires prior approval.
3. On your own lab cloud account (or a free tier), run a posture scanner (Prowler/ScoutSuite). Pick one finding and validate it, then write the specific remediation.
4. Explain why IAM is "the new perimeter" in the cloud, contrasting it with the network perimeter on-prem.
5. In your own words, explain why cloud adoption relocates rather than reduces risk, and how the shared-responsibility model tells you where to test.