Cloud Penetration Testing
Cloud penetration testing evaluates the security of workloads, configurations, and identities deployed on cloud platforms. It applies offensive techniques to find misconfigurations, overprivileged roles, exposed services, and lateral movement paths specific to cloud environments.
itOffensive security and application security | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Cloud Penetration Testing
Cloud penetration testing is the disciplined effort to show how an attacker could reach a valuable cloud resource, while having permission to be there. That last part is not a footnote. It is the wall that keeps a useful security test from becoming an expensive conversation with several lawyers.
The old mental picture of a penetration test is a person staring at ports and web pages. Keep the ports and pages, but add the cloud's favorite furniture: provider APIs, managed services, temporary sessions, roles, policies, and data-sharing features. A machine can have no open door at all while an identity still has a very interesting set of keys.
The useful map has four surfaces. The public workload surface is what strangers can reach. The cloud control plane, meaning the provider consoles and APIs that create or alter resources, is where configuration becomes action. The identity plane, meaning accounts, workload identities, roles, credentials, and policies, decides who gets to ask. The data plane is where stored information gets read, copied, shared, or removed. A test follows the joins between them.
This is why a permission that looks harmless in isolation can be the beginning of a longer story. An application flaw might reveal a workload identity. That identity might assume a role. The role might change a policy. The policy might expose data. None of those steps needs a dramatic network exploit, which is rude of the cloud but entirely on brand.
The safety trick is minimum proof: collect the smallest evidence that answers the question. Listing approved secret metadata can prove discovery without reading a secret. Demonstrating that a role is assumable can prove escalation without changing a production resource. The evidence is still evidence; it merely arrives with fewer broken things attached.
Start with the Intro for the full map and the reason provider rules matter. Use Slides when the four surfaces and attack path need a quick redraw. Keep the Cheatsheet nearby for scope records, identity questions, and stop conditions. The Reference tab leads from NIST's testing structure to the current policies and cloud behaviors. The Quiz is where the terms stop politely nodding and start asking whether they have connected.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://csrc.nist.gov/pubs/sp/800/115/final
Supports
- Planning and conducting technical security tests and examinations
- Analysis of findings and development of mitigation strategies
- Examination, target-identification, and vulnerability-validation techniques
- Technique selection according to benefits, limitations, and assessment goals
- https://aws.amazon.com/security/penetration-testing/
Supports
- AWS services permitted for customer penetration testing without prior approval
- Activities and services that are prohibited or require coordination
- Separation between testing customer infrastructure and testing AWS infrastructure or services
- Requirement for prior approval when testing includes command and control activity
- https://learn.microsoft.com/en-us/azure/security/fundamentals/pen-testing
Supports
- Testing Azure resources owned by the tester or covered by explicit owner authorization
- No Microsoft pre-approval for covered Azure resource testing
- Requirement to follow the Microsoft Cloud Unified Penetration Testing Rules of Engagement
- Examples of permitted testing and prohibition of denial-of-service testing
- https://support.google.com/cloud/answer/6262505?hl=en
Supports
- No Google notification requirement for penetration testing a customer's project
- Requirement that testing affect only the customer's projects and not other customers
- Requirement to follow Google Cloud terms and the Acceptable Use Policy
- Direction to report discovered Google Cloud vulnerabilities through Google's program
- https://cloud.google.com/terms/aup
Supports
- Restrictions against unauthorized access, disruption, impairment, and interference
- Restrictions on testing or reverse engineering services except where expressly permitted
- Consequences of failing to comply with the policy
- https://attack.mitre.org/techniques/T1078/004/
Supports
- Cloud accounts as paths for initial access, persistence, privilege escalation, and defense evasion
- Long-lived additional credentials as a persistence path
- Overprivileged identities and role-assumption misconfigurations
- Workload-attached identities as paths to access tokens and other resources
- https://attack.mitre.org/techniques/T1098/
Supports
- Account, credential, and role changes as persistence or privilege paths
- Permission changes that preserve or expand access
- https://attack.mitre.org/techniques/T1537/
Supports
- Data transfer through cloud-account sharing and provider APIs
- Snapshot, backup, object-policy, and signed-link paths
- Transfers that may not use traditional external network egress
- https://github.com/RhinoSecurityLabs/cloudgoat
Supports
- Intentionally vulnerable AWS scenarios for cloud security practice
- Warning to avoid production environments and sensitive resources
- Scenario cleanup and the limitation that manually created resources require manual removal
- https://github.com/BishopFox/cloudfox
Supports
- Read-oriented cloud enumeration for situational awareness during authorized penetration tests
- Identity, endpoint, and permission-path discovery capabilities across supported cloud providers
- https://github.com/nccgroup/ScoutSuite
Supports
- Point-in-time, multi-cloud security posture assessment
- Offline analysis after account configuration data is gathered
- https://github.com/RhinoSecurityLabs/pacu
Supports
- AWS-focused cloud security assessment framework maintained by Rhino Security Labs
- https://github.com/prowler-cloud/prowler
Supports
- Open-source cloud security assessment project and supporting documentation
- https://github.com/lyft/cartography
Supports
- Cloud asset and relationship mapping project maintained by Lyft
