Cloud Penetration Testing
The misconfigurations that actually cause cloud breaches
Cloud breaches rarely involve a zero-day. They involve an over-permissive role, a storage bucket someone opened for a one-off migration, or a function that can assume more than it should. We audit configuration across identity, network, storage, and logging, then prove which weaknesses actually chain into privilege escalation — under rules of engagement that keep production intact.
What we cover.
- AWS, Azure, and GCP environments
- VPCs/VNets, subnets, IP ranges, and public FQDNs
- Storage services, serverless functions, container clusters, and managed databases
- IAM roles, trust relationships, and privilege escalation paths
- Explicitly excluded: the provider's own infrastructure, other tenants, and any denial-of-service testing
How the engagement runs.
Introduction
Cloud penetration testing is a systematic, authorized assessment of cloud infrastructure, platform, or applications. Unlike on-premise testing it targets the vulnerabilities and misconfigurations specific to cloud provider environments and to how you have implemented within them.
The objective is to identify and exploit weaknesses under controlled conditions so the real risk is understood, and to hand back remediation you can actually action.
Critical prerequisite
Explicit written authorization from the asset owner, before anything begins.
Provider rules of engagement
Cloud providers have their own testing policies and, in some cases, a mandatory notification. Skipping this risks account suspension and legal exposure — so we handle it as part of scoping.
Test phases
Planning and scoping
- Objectives — for example: assess the production Kubernetes cluster, validate segmentation between development and production networks, or determine whether an unauthenticated user can reach customer data in object storage.
- In-scope assets — enumerated explicitly.
- Virtual networks, subnets, IP ranges, and public hostnames
- Object storage buckets and containers
- Serverless functions and container clusters
- Managed database instances
- IAM roles and policies
- Out of scope — the provider's own infrastructure, any other tenant's assets, production systems during peak hours, and denial-of-service testing.
- The shared responsibility model — testing is scoped strictly to your side of the line.
- You are responsible for security in the cloud — identity, data, network configuration, operating systems, applications
- The provider is responsible for security of the cloud — physical hardware, hypervisors, physical network
- Rules of engagement — signed authorization plus provider approval, an agreed testing window, a dedicated channel for real-time escalation, and a data-handling procedure. The goal is to prove access, never to bulk-extract personal data.
Reconnaissance
- External reconnaissance.
- DNS enumeration — subdomains, hostnames, and records pointing at cloud assets such as load balancers and storage
- Public asset discovery — publicly readable storage buckets and containers
- Code repositories — public repos scanned for leaked keys, tokens, and configuration
- Provider fingerprinting — establishing which cloud and which services are actually in use
- Cloud-specific enumeration.
- Port scanning in-scope public addresses to find exposed services
- Identifying authentication endpoints and identity providers
- Noting the instance metadata endpoint, a primary target for server-side request forgery
- Where credentials are supplied, using cloud enumeration tooling to map and visualise the environment
Vulnerability analysis
Configuration auditing is the core of a cloud engagement — this is where breaches actually originate.
- Identity and access management.
- Overly permissive roles and wildcard policies
- Privilege escalation paths, such as a role able to attach policies or assume a more powerful role
- Missing multi-factor authentication on root and administrative accounts
- Full enumeration of users, roles, and policies to map effective permissions
- Network security — security group and firewall rules opened far too broadly, and peering and routing tables analysed for lateral movement paths.
- Storage security — every bucket and container checked for public read or write, and encryption verified on storage, volumes, and managed databases.
- Logging and monitoring — confirming audit and flow logging is enabled, comprehensive, and protected against tampering.
- Service-specific scanning.
- Authenticated and unauthenticated vulnerability scans against compute instances
- Container image scanning, plus Kubernetes misconfiguration checks such as exposed APIs, anonymous access, and weak role bindings
- Serverless function code reviewed for injection and vulnerable dependencies, and execution roles audited for excessive permission
Exploitation
- Initial access.
- Leaked credentials recovered during reconnaissance, used against the cloud APIs
- Exposed services — default or weak credentials on public management and database ports
- Server-side request forgery in a hosted application, used to query the metadata service and steal temporary role credentials
- Misconfigured storage — reading sensitive objects, or writing to a publicly writable bucket that serves a website
- IAM privilege escalation — from a low-privilege role, identifying and exploiting policy misconfigurations that let the principal grant itself more permission.
- Post-exploitation — run only with explicit documented authorization.
- Lateral movement — using credentials from a compromised instance to reach other services, and crossing subnets or networks where rules are too permissive
- Persistence — creating privileged identities, attaching permissive policies, issuing new API keys, or modifying a serverless function to hold a backdoor
- Data exfiltration is simulated, never performed in full: a single non-sensitive object is copied out as proof the path exists
Reporting
- Executive summary for management, framed around business risk and posture.
- Technical report — per finding: description, a step-by-step attack narrative, evidence, business impact, risk rating, and prioritized remediation.
Remediation and re-testing
- Debrief meeting to present the findings.
- Re-test after fixes to validate each issue is genuinely closed.
What you get at the end.
Who it's for
Organizations running production workloads on AWS, Azure, or GCP — especially after rapid growth or migration.
Need a scope for this engagement?
Tell us what's in your environment and we'll come back with a scoped plan.