Cloud Penetration Testing

A cloud penetration test is an authorized attempt to prove how an attacker could reach valuable cloud resources. It tests more than open ports and web pages. It also tests identities, permissions, provider APIs, managed services, storage, and the paths between them.

Keep one mental model in mind: authorization defines the boundary; identity and provider APIs define the attack paths.

Cloud changes the shape of a penetration test. You still plan, discover, validate, report, and support remediation. You also work inside infrastructure shared with a provider and other customers. A technically possible action may be outside your authorization or the provider's rules.

Start with authorization

Written authorization is the first control in every engagement. It identifies who owns the target and who may test it. It also records the dates, contacts, objectives, permitted techniques, excluded systems, and stop conditions.

Provider permission does not replace customer permission. Microsoft, for example, allows testing against Azure resources you own or have explicit authorization to test. Google requires tests to affect only your projects. AWS distinguishes permitted customer resources from AWS infrastructure and services that customers may not assess.

Provider rules also differ. Azure and Google generally do not require prior notification for covered customer resources, subject to their rules. AWS permits testing of listed services without prior approval, while some services or activities require coordination. Provider policies can change, so verify them for every engagement.

Treat denial-of-service activity as excluded unless a specific, approved process says otherwise. Ordinary vulnerability validation rarely requires it. Establish a stop procedure for unexpected service impact, access to another tenant, sensitive data exposure, or evidence of an unrelated active compromise.

Map the cloud boundary

A useful scope map has four connected surfaces:

Public workload surface — websites, application programming interfaces, load balancers, virtual machines, and exposed service endpoints.
Cloud control plane — consoles and provider APIs that create, configure, and delete resources.
Identity plane — human accounts, workload identities, roles, policies, federation, credentials, and sessions.
Data plane — stored data and the operations that read, write, share, copy, or delete it.

The public workload surface looks familiar to a network or application tester. The other surfaces make cloud testing distinct.

A stolen cloud session may never exploit a listening service. It can call an authorized provider API instead. An overprivileged workload identity can turn one application flaw into access to storage, secrets, or other services. A data-sharing permission can move information between cloud accounts without sending it through a traditional Internet egress path.

Scope resources by stable identifiers where possible. Record account, subscription, tenant, organization, project, resource, and region identifiers. An Internet Protocol address may be temporary or shared behind a managed endpoint. A hostname alone may not identify every backend resource.

Understand shared responsibility

The provider secures some layers and the customer secures others. The split changes with the service model.

With a virtual machine, the customer controls more of the guest operating system and application stack. With a managed database or serverless service, the provider controls more of the underlying platform. The customer still controls identities, configuration, application behavior, and data access within the service.

Your test should target the customer's responsibilities and authorized interfaces. Do not treat a managed service as permission to attack the provider's underlying platform. If testing crosses a shared-service boundary or exposes a provider vulnerability, stop and use the provider's reporting process.

Plan from impact backward

Start with the outcome an attacker would value. Examples include reading sensitive objects, changing production configuration, assuming a privileged role, creating a persistent credential, or sharing a snapshot with another account.

Then form a testable attack path:

entry point → identity or workload foothold → permission discovery
            → privilege or lateral movement → controlled impact proof

This approach prevents a test from becoming an inventory of unrelated findings. It also tells you which evidence will prove risk without causing unnecessary harm.

For each hypothesis, define a minimum proof. Listing a secret's metadata may prove unauthorized discovery without reading its value. Showing that a role can be assumed may prove privilege escalation without changing production. Creating a harmless marker object in an approved test location may prove write access without altering business data.

Test identity before chasing exploits

Identity and access management is often the shortest route through a cloud environment. Examine how users and workloads obtain credentials, which roles they may assume, and which policies determine effective access.

Separate four questions:

Who are you? The authenticated human or workload identity.
What credential proves it? A password, key, certificate, token, or federated session.
What may you do? The effective permissions after all applicable policies and conditions.
Where can that permission lead? Another role, resource, account, tenant, or data store.

Do not equate a denied action with no risk. A tester may lack permission to read an object but retain permission to change its policy. A workload may not administer identity directly but may run with an attached identity that can request broadly authorized tokens. A user may have modest standing access but be allowed to activate temporary elevated access.

MITRE ATT&CK documents cloud accounts as paths for initial access, persistence, privilege escalation, and defense evasion. It also describes long-lived additional credentials and role changes as persistence mechanisms. Use those behaviors to form hypotheses, not as a checklist that every test must execute.

Follow the data

Cloud data can move through more than a download command. Object policies, snapshots, backups, replication, signed links, and cross-account sharing can expose data while using normal provider features.

Test the complete access path:

identity → permission → resource policy → encryption key → data operation

Each link can allow or block access. A resource policy may grant an external identity access even when the account's ordinary identity policy appears narrow. Encryption at rest does not stop an authorized service path from decrypting data. A backup may have weaker sharing controls than the live database.

Prove access with the least sensitive artifact available. Coordinate handling rules before the test. Record where evidence may be stored, who may view it, how it will be encrypted, and when it will be destroyed.

Use two views of discovery

External discovery asks what an unauthenticated observer can reach. Authenticated discovery asks what an approved identity can enumerate through provider APIs.

External discovery covers public names, addresses, certificates, endpoints, and application behavior. Authenticated discovery covers accounts, roles, policies, networks, storage, compute, keys, secrets, logs, and organizational relationships.

Compare both views. An asset missing from the inventory may still be public. A resource with no public endpoint may still be reachable through a compromised workload or control-plane permission.

Validate with restraint

NIST separates examination techniques, target-identification techniques, and vulnerability-validation techniques. Use the least invasive technique that answers the engagement question.

Automated scanners can find broad patterns. They also produce false positives and may not understand effective cloud permissions. Manual analysis connects configuration, identity, and reachable impact. Keep request rates within agreed limits and understand every tool's side effects before running it.

Log each significant action with its time, source identity, target, purpose, and result. This supports the final report and lets defenders compare test activity with cloud audit records. If the engagement includes detection validation, agree on what the defensive team should observe and how test activity will be identified afterward.

Report attack paths, not just defects

A useful finding explains:

the affected resource and identity;
the preconditions and tested path;
the evidence that proves impact;
the business consequence;
the boundary that stopped further testing;
the corrective control;
the evidence needed for retesting.

Separate observed facts from plausible next steps. If you proved that a workload could list secrets but did not read them, say exactly that. Do not present the untested consequence as an accomplished breach.

Prioritize chains. A public application flaw, an attached overprivileged identity, and a permissive storage policy may form one high-impact path. Reporting them as three isolated items can hide the real risk.

Close the engagement safely

Remove test accounts, keys, role assignments, firewall rules, objects, snapshots, and tooling created during the test. Revoke test sessions where the platform supports it. Confirm that logging and monitoring return to the intended state.

Retest the path after remediation. A policy edit can close one action while leaving an equivalent route open. The goal is not to make one command fail. The goal is to remove the unauthorized outcome.

Who this course helps

Penetration testers use this map to adapt familiar testing work to cloud identity and provider APIs. Cloud engineers use it to prepare safe test environments and interpret findings. Security engineers use it to connect attack simulation with audit evidence, detection, and remediation.

This course does not teach exploitation commands or authorize testing. It provides the mental model, scope discipline, and evidence standard you need before provider-specific practice.