Cloud Penetration Testing on AWS, Azure and Google Cloud: What It Covers, What It Doesn't, and How It Differs From a Configuration Review
Cloud penetration testing follows an attacker from one exposed service, through credentials and roles, to the data a configuration review would have listed as separate findings. What a cloud pentest covers on AWS, Azure and Google Cloud, what the providers allow, the attack paths testers follow, and when you need a test rather than a review.
Cloud Security
A configuration review tells you that a storage bucket is public, a role has more permissions than it needs and a server still answers the old metadata service. A penetration test tells you that those three findings, in that order, are a path from an anonymous web request to every customer record you hold. Both are worth doing. They answer different questions, and organisations that have only done the first are often surprised by the second. Here is what cloud penetration testing covers on AWS, Azure and Google Cloud, what the providers allow, the paths testers follow, and when you need a test rather than a review.
In short. Cloud penetration testing starts from an attacker's position, whether outside the account or holding one low-privilege credential, and chains misconfigurations, over-permissioned identities and exposed services into access to data. All three major providers permit it on your own resources without prior approval, within published rules that prohibit denial of service and attacks on other tenants. The common paths are the same on every platform: an exposed application leaks a credential, the credential belongs to an identity with more rights than it needs, and the rights reach storage. A configuration review against the CIS Benchmark finds the individual weaknesses; a penetration test shows which of them combine, and in what order to fix them.
Review versus test: what each one answers
| Cloud configuration review | Cloud penetration test | |
|---|---|---|
| Question | Which settings deviate from the benchmark? | What can an attacker reach, and how? |
| Method | Read-only API access; tools such as Prowler and ScoutSuite compare every setting with CIS and provider guidance | Act as an attacker from an agreed starting point; enumerate, exploit, escalate, pivot, within the rules of engagement |
| Output | A long list of findings, each rated on its own | A smaller number of attack paths, each showing what was reached and which link to break first |
| Covers | The control plane: identity, network, storage, logging settings | The control plane plus what runs on it: applications, containers, functions, and the people and pipelines that deploy them |
| Misses | Whether findings combine; application flaws; anything the benchmark does not cover | Settings that are wrong but not on the path the tester took |
| Best for | Breadth, baselining, and continuous checking after the first pass | Depth, proving impact, and prioritising a long list of review findings |
The right order is usually review first, test second, then continuous posture management to keep the review's findings closed. Our guide to CSPM, CWPP and CNAPP covers the continuous part; a cloud security assessment is the review.
What the providers allow
You own the configuration and the workloads; the provider owns the infrastructure underneath. AWS describes the split as "security of the cloud", which is AWS's responsibility, and "security in the cloud", which is the customer's. Microsoft's version: "for all cloud deployment types, you own your data and identities." Google now talks about "shared fate", an ongoing partnership rather than a line. Testing follows the same split: you may test what you own, under each provider's rules.
| Provider | Approval | Permitted | Prohibited |
|---|---|---|---|
| AWS | No prior approval for the listed services; simulated events such as red teaming, command-and-control hosting and phishing need a Simulated Events form "at least two (2) weeks in advance" | EC2, WAF, NAT gateways and load balancers, RDS, CloudFront, Aurora, API Gateway, AppSync, Lambda, Lightsail, Elastic Beanstalk, ECS, Fargate, OpenSearch, FSx, Transit Gateway, Bedrock AgentCore, Global Accelerator | DNS zone walking, hijacking or pharming through Route 53; denial of service in any form including simulated; port, protocol and request flooding; S3 bucket takeover; subdomain takeover |
| Microsoft | "As of June 15, 2017, Microsoft no longer requires pre-approval to conduct a penetration test against Azure resources"; the unified rules of engagement apply to all Microsoft-managed services | Fuzzing, port scanning and vulnerability assessment of your own virtual machines; testing Conditional Access and app protection policies; container break-out attempts, stopping immediately on success; AI system boundary tests | Denial of service of any kind; phishing or social engineering of Microsoft staff; accessing other tenants' data; using credentials that are not yours, including publicly leaked ones; moving laterally into Microsoft's own services after a compromise |
| Google Cloud | "You are not required to contact us" | Testing of your own projects under the acceptable use policy and terms of service | Anything that affects other customers' applications; vulnerabilities in Google's platform go to the Vulnerability Reward Program |
A tester who proposes a denial-of-service test or a phishing campaign against a provider's own staff has not read the rules. Scope documents should quote them.
The attack paths testers follow
Cloud attacks are catalogued in MITRE ATT&CK, and the techniques below account for most of what a test finds. The names are ATT&CK's; the examples are ours.
Cloud Instance Metadata API (T1552.005)
A server-side request forgery or an open proxy in an application lets the tester ask the metadata service for the credentials of the role attached to the server. AWS introduced IMDSv2 in November 2019 specifically to defend against "misconfigured-open website application firewalls, misconfigured-open reverse proxies" and unpatched SSRF, and Amazon Linux 2023 disables the old version by default; many older instances still answer it.
Valid Accounts: Cloud Accounts (T1078.004)
Access keys in a repository, a build log, a container image or a developer's laptop. Microsoft reports that "more than 99 percent of password spray attacks use legacy authentication protocols", which is why a test checks whether legacy protocols are still enabled in the tenant.
Account Manipulation: Additional Cloud Roles (T1098.003)
A credential with permission to attach policies, create keys for other identities or assume other roles is a path to administrator. Tools such as PMapper and CloudFox exist to find these chains, and attackers use the same ones.
Steal Application Access Token (T1528)
In Entra ID, an attacker "creates a registered application in Microsoft Entra ID that requests access to data such as contact information, email, or documents" and tricks a user into consenting. Microsoft notes that "normal remediation steps (for example, resetting passwords or requiring multifactor authentication (MFA)) aren't effective against this type of attack."
Modify Cloud Compute Infrastructure (T1578)
Snapshot a disk, share it to another account, mount it elsewhere; or start an instance with an administrative role attached. These are quiet and rarely alerted.
Data from Cloud Storage (T1530) and Exfiltration to Cloud Storage (T1567.002)
The destination of almost every path: buckets and blobs reachable with the credentials gathered along the way, and copies made to storage the attacker controls.
Palo Alto Networks' 2026 incident response report says identity weaknesses "played a material role in almost 90%" of its investigations, about 35% of which involved cloud or SaaS assets, and that "99% of cloud users, roles and services had excessive permissions, some unused for 60 days or more." Verizon's 2026 Data Breach Investigations Report found 31% of breaches now start with vulnerability exploitation, ahead of stolen credentials for the first time. A cloud test exercises both.
What differs by provider
| Provider | Findings a test keeps producing | Provider guidance |
|---|---|---|
| AWS | IMDSv1 still enabled; IAM policies with wildcard actions or resources; roles that can pass themselves to new instances; public snapshots and AMIs; long-lived access keys for people; cross-account trust that is wider than intended | Account-level IMDSv2 enforcement exists and can be applied through Organizations; CIS AWS Foundations Benchmark v7.1.0 (November 2026) adds Organizations, IAM and Bedrock sections |
| Azure and Entra ID | Over-permissioned service principals, where "Contributor is the default Azure role-based access control (Azure RBAC) role"; legacy authentication enabled; Conditional Access gaps for service principals, which Microsoft notes cannot be managed by Conditional Access; applications with unused high-privilege API permissions; managed identities attached to functions anyone can trigger | Block legacy authentication; review consent grants; CIS Azure Foundations Benchmark v6.0.0 (May 2026) |
| Google Cloud | The Compute Engine default service account, which "might automatically be granted the Editor role on your project" in older organisations; basic roles in production, against Google's advice that "basic roles include thousands of permissions across all Google Cloud services"; user-managed service account keys in code; buckets without public access prevention | Disable the automatic Editor grant (enforced by default for organisations created after May 2024); "the best way to mitigate these threats is to avoid user-managed service account keys"; CIS Google Cloud Platform Foundation Benchmark v5.0.0 (June 2026) |
Starting points: what kind of test do you need?
The most important scoping decision is where the tester starts. Each starting point answers a different question, and a mature programme uses more than one over time.
| Starting point | Question it answers | Typical scope |
|---|---|---|
| External, unauthenticated | What can anyone on the internet reach? | Exposed applications, APIs, storage, management interfaces, leaked credentials in public sources |
| Assumed breach: one low-privilege identity | If a developer's key or a service account leaks, how far does it go? | Enumeration of everything the identity can see, escalation chains, pivot to data |
| Assumed breach: one compromised workload | If this container or function is exploited, what does its role reach? | Metadata credentials, workload identity, network reach to other services |
| Pipeline | What can someone who can open a pull request do to production? | CI/CD credentials, deployment roles, infrastructure-as-code review; see IaC security |
How a cloud penetration test runs
Step 1 — Scope and rules
Accounts, subscriptions or projects in scope; the starting point; what is out of bounds; the provider's rules quoted in the agreement; and a contact who can pause the test if production is affected.
Step 2 — Enumerate
From the starting point, map everything reachable: identities and their permissions, networks, storage, compute, functions, secrets, logging. Tools such as Prowler, ScoutSuite, ROADtools and AzureHound speed this up; the judgement about what matters is manual.
Step 3 — Exploit and escalate
Follow the paths: application flaws to credentials, credentials to roles, roles to data. Each step is reproduced and recorded, and nothing destructive is done without agreement.
Step 4 — Check detection
Compare what the tester did with what the cloud audit logs and the SOC saw. A path that completed without an alert is two findings, not one.
Step 5 — Report and retest
Attack paths with the link to break first, each setting change spelled out, and a retest to confirm the path is closed rather than just one finding fixed.
This is the shape of our cloud penetration testing engagements. For identity-heavy environments, a cloud identity and access review often runs alongside, because most paths turn out to be identity paths.
What Indian regulators expect
RBI's 2026 cybersecurity directions for NBFCs require vulnerability assessment at least every six months and penetration testing at least every twelve for critical and customer-facing systems, and state that the documented approach "shall also apply to the NBFC's information systems hosted in a cloud environment." The commercial bank directions carry the same cadence. CERT-In's 2022 directions require logs of all ICT systems to be kept for a rolling 180 days within Indian jurisdiction, which for cloud workloads means audit logs, flow logs and application logs retained in an Indian region, and they place registration duties on cloud and virtual server providers. Our articles on the NBFC directions and cloud security for fintechs and NBFCs go further.
Preparing for a cloud penetration test
- An inventory of accounts, subscriptions or projects, and which hold production data.
- Architecture diagrams, including how identities federate and how pipelines deploy.
- The starting point you want tested, and the credentials for it if it is an assumed-breach test.
- Confirmation that logging is on and reaching the SOC, so detection can be measured.
- A recent configuration review, if one exists, so the test can concentrate on proving impact rather than rediscovering settings.
- Named contacts for the test window, and agreement on what happens if a path reaches production data.
Frequently Asked Questions
Click any question to expand the answer.
QWhat is cloud penetration testing?
An authorised test of your cloud accounts, subscriptions or projects from an attacker's position. The tester starts outside or with one low-privilege credential and chains exposed services, misconfigurations and over-permissioned identities into access to data, within the provider's rules of engagement. The output is attack paths with a fix order, not only a list of settings.
QHow is a cloud penetration test different from a cloud security assessment or configuration review?
A configuration review compares every setting with a benchmark such as the CIS Foundations Benchmark and lists the deviations. A penetration test shows which of those deviations combine into a path to data and proves the impact. Most organisations need the review first and the test second, then continuous posture management.
QDo we need permission from AWS, Microsoft or Google to run a penetration test?
Not for testing your own resources within their rules. AWS permits testing of a published list of services without prior approval, but simulated events such as red teaming need a form submitted at least two weeks ahead. Microsoft has not required pre-approval since June 2017. Google Cloud says you are not required to contact it. All three prohibit denial-of-service testing and anything that affects other customers.
QWhat are the most common findings in a cloud penetration test?
Identity findings dominate: credentials in code or build artefacts, roles and service principals with far more permission than they use, and escalation paths through permission to manage other identities. On the workload side, applications that leak metadata credentials through server-side request forgery, instances still answering IMDSv1, and storage reachable with the credentials gathered along the way.
QWhat is the instance metadata attack?
Cloud servers obtain the credentials for their attached role from a metadata service on a link-local address. If an application on the server can be made to request arbitrary URLs, an attacker can read those credentials. AWS introduced IMDSv2 in 2019 to require a session token, which blocks the simple version of the attack, and Amazon Linux 2023 disables the old version by default; many older instances still allow it. MITRE ATT&CK tracks it as T1552.005.
QDoes a cloud penetration test cover Entra ID and Microsoft 365?
It can, and for most organisations it should, because Entra ID is the identity layer for both Azure and Microsoft 365. Typical checks include legacy authentication, Conditional Access coverage, consent grant risks, over-permissioned applications and service principals, and what managed identities can reach.
QWhat is an assumed-breach cloud test?
A test that starts with one credential or one compromised workload, to answer the question of how far a single leak goes. It is usually more revealing than an external test alone, because most cloud incidents begin with a credential rather than an exploit against the provider.
QHow often should cloud environments be penetration tested?
At least annually and after significant changes, which in cloud terms includes new accounts, new identity federation, major architecture changes and migrations. RBI's 2026 directions for banks and middle-layer-and-above NBFCs require vulnerability assessment every six months and penetration testing every twelve for critical systems, explicitly including those hosted in cloud environments.
QCan a cloud penetration test disrupt production?
A well-run test should not. Destructive actions are agreed in advance or excluded, denial-of-service testing is prohibited by every provider, and a named contact can pause the test. The highest-risk steps, such as reading production data to prove a path, are done to the minimum extent needed and recorded.
QWhich tools are used in cloud penetration testing?
Commonly used tools include Prowler and ScoutSuite for configuration enumeration, Pacu and CloudFox for AWS attack paths, PMapper for IAM permission analysis, ROADtools and AzureHound for Entra ID, and Steampipe for querying cloud APIs. Attackers use many of the same tools; the value of a test is the judgement applied to their output.
QWhat should a cloud penetration test report contain?
Each attack path as a narrative from starting point to data, the exact settings, policies or code to change, the link that breaks the most paths if fixed first, what the SOC saw during the test, and a retest confirming the path is closed.
QDoes the shared responsibility model mean the provider tests the cloud for us?
No. The provider secures the infrastructure underneath and tests its own platform. Everything you configure and deploy on top, including identities, networks, storage settings, applications and pipelines, is yours to secure and yours to test.
Related reading
For the settings a review finds, see the most common cloud security misconfigurations and anatomy of an AWS misconfiguration in BFSI. For the tools that keep findings closed, CSPM, CWPP and CNAPP explained. For containers, Kubernetes and container security. For getting the design right before anything moves, cloud migration security.
Sources
- Amazon Web Services, Customer support policy for penetration testing.
- Amazon Web Services, Shared responsibility model.
- Amazon Web Services, Defense in depth: open firewalls, reverse proxies, SSRF vulnerabilities and the EC2 Instance Metadata Service (IMDSv2).
- Microsoft, Penetration testing in Azure.
- Microsoft, Microsoft Cloud Unified Penetration Testing Rules of Engagement.
- Microsoft, Shared responsibility in the cloud.
- Microsoft, Block legacy authentication with Conditional Access.
- Microsoft, Detect and remediate illicit consent grants.
- Microsoft, Securing service principals in Microsoft Entra ID.
- Google Cloud, Cloud security FAQ: penetration testing.
- Google Cloud, Shared responsibility and shared fate.
- Google Cloud, Service accounts in Compute Engine.
- Google Cloud, Using IAM securely.
- Google Cloud, Best practices for managing service account keys.
- MITRE ATT&CK, Unsecured Credentials: Cloud Instance Metadata API (T1552.005).
- Center for Internet Security, CIS Benchmarks November 2026 update.
- Palo Alto Networks Unit 42, 2026 Global Incident Response Report.
- Verizon, 2026 Data Breach Investigations Report.
- Reserve Bank of India, NBFC – Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026.
- CERT-In, Directions under section 70B(6) of the IT Act, 2000 (28 April 2022).
Adayptus Consulting
Cloud Security, Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India, testing AWS, Azure and Google Cloud environments the way an attacker would, within each provider's rules.
On This Page
- Review versus test: what each one answers
- What the providers allow
- The attack paths testers follow
- What differs by provider
- Starting points: what kind of test do you need?
- How a cloud penetration test runs
- What Indian regulators expect
- Preparing for a cloud penetration test
- Frequently Asked Questions
- Related reading
- Sources
