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
Intro
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.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
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
