Cloud Penetration Testing: What Azure and AWS Scans Miss

‍

A configuration scan of an Azure subscription or an AWS account can produce hundreds of findings before lunch. Many of those findings are real. Few of them tell a board whether an attacker can turn a leftover access key, an overprivileged service principal, or a public storage container into a path to customer data.

That gap is why cloud penetration testing exists. Scanners describe posture. A penetration test answers a harder question: if someone already has a foothold, or if a single public resource is mis-set, what can they actually do next?

In our work across Azure, AWS, and hybrid estates, we keep seeing the same pattern. Organisations have invested in Cloud Security Posture Management, identity tooling, and ticketing workflows. The dashboards look mature. Then a manual test follows a chain that no scanner treated as a single problem: a developer key in a CI log, a role that can pass itself into a more privileged function, a storage account that still allows anonymous listing, and a network path that was never meant to exist after a migration.

This article explains what cloud penetration testing covers, why scans consistently miss the issues that matter to the business, and how to commission a test that produces evidence rather than another findings dump.

What Cloud Penetration Testing Actually Is

Cloud penetration testing is a scoped, rules-of-engagement-bound attempt to exploit the customer-controlled layer of a cloud environment. That layer is large. It includes identity, storage, compute, networking, serverless functions, Kubernetes or container platforms, CI/CD integrations, and the APIs that glue those services together.

It is not a vulnerability scan of virtual machines that happen to live in the cloud. It is not a tick-box review of CIS Benchmarks. And it is not a replacement for the provider’s own platform security. AWS, Microsoft, and Google secure the underlying fabric. You secure how you use it. That shared responsibility model is well understood in principle and routinely misunderstood in practice.

A useful cloud test starts from an agreed attacker position. Typical starting points include:

• Unauthenticated access to anything public (storage, APIs, management endpoints, leaked credentials)
• A low-privilege user or service identity, representing a phished staff account or a compromised workload
• A foothold inside a connected on-premise network or a peered virtual network
• A CI/CD identity with permission to deploy or read secrets

From that position, testers attempt to escalate, move, and reach assets that matter: customer data, source code, financial systems, identity control planes, and the ability to persist.

The output should show attack paths, not isolated misconfigurations. “S3 bucket allows public list” is a scan result. “Public list plus object naming convention plus a backup file containing an IAM access key that can assume a role with access to the production database snapshot” is a penetration testing finding.

Why Configuration Scans Keep Missing the Point

Scanners are good at asking binary questions. Is MFA enabled? Is this security group open to 0.0.0.0/0? Does this storage account allow public blob access? Those questions have value. They do not reconstruct how an adversary thinks.

They score issues in isolation

A medium-severity finding for an unused access key and a low-severity finding for a verbose error page do not look related on a dashboard. In a test they can be the same chain. The error page discloses an internal hostname. That hostname hosts a forgotten admin interface. The unused key still works against it.

Risk only becomes clear when findings are combined.

They do not understand your business

A publicly readable bucket of marketing assets is not the same problem as a publicly readable bucket that holds invoice PDFs or database exports. Scanners rarely know the difference. A tester who has scoped the engagement against your critical functions does.

They cannot exploit identity graphs

Identity is the control plane of modern cloud. In AWS that means IAM users, roles, trust policies, and permission boundaries. In Azure it means Entra ID directory roles, app registrations, service principals, managed identities, and Conditional Access.

Privilege escalation in cloud is often a graph problem, not a missing patch. A role with iam:PassRole and lambda:CreateFunction can become a more privileged role. An Entra application with Application.ReadWrite.All can add credentials to another application that already has directory-wide rights. Tools can hint at these paths. Proving them, and showing the business impact of the resulting access, is still manual work.

They stop at the customer-configured boundary they can see

Hybrid estates are the rule in UK mid-market and enterprise environments, not the exception. An Azure landing zone peered to an on-premise Active Directory domain, or an AWS account reachable from a site-to-site VPN, creates movement paths that cloud-only scanners never walk. We regularly find that the interesting part of a “cloud” compromise is the moment it becomes an internal network problem.

‍

The Attack Surface That Matters in Azure and AWS

The details differ by provider. The categories do not.

Identity and standing privilege

This is where most serious cloud findings begin.

In Azure, we still encounter standing Global Administrator assignments that should live in Privileged Identity Management with approval and a time limit. We find app registrations granted Graph permissions that would let a stolen client secret rewrite directory roles. Guest user settings that allow broad enumeration remain common, as do tenants that still permit user consent for applications.

In AWS, wildcard actions and resource statements persist because they made a prototype work. Long-lived access keys sit on developer laptops and in forgotten automation users. Trust policies sometimes allow assumption from accounts the organisation no longer controls.

The business meaning is simple. If one identity is compromised, how much of the estate goes with it? If the answer is “enough to copy the customer database or freeze billing and logging,” the identity model is the risk, not the missing patch on a jump box.

Storage and data that was never meant to be public

Public S3 buckets and Azure blob containers are an old story. They still appear, often on accounts created before default-deny settings became standard, or on resources spun up for a short-lived project and never retired.

The more interesting cases are subtler:

• Shared Access Signatures in Azure that never expire and grant write as well as read
• Storage account keys committed to repositories or baked into container images
• Buckets that are private to the internet but readable by any authenticated principal in the organisation
• Backup archives that include secrets, connection strings, or copies of IAM credentials

Data exposure is rarely a single toggle. It is a combination of listing permissions, predictable object names, and weak monitoring of unusual download volume.

Compute, metadata, and workload identity

Virtual machines, App Services, Lambda functions, and AKS or EKS nodes all run with an identity. If an application on that compute can be coerced into talking to the instance metadata service, the attacker may retrieve temporary credentials for whatever role the workload holds.

AWS IMDSv2 reduces this class of issue when it is enforced. Many estates still allow IMDSv1 on older instances. Azure Instance Metadata Service and managed identities create a similar prize: compromise the app, inherit the identity, reach Key Vault or a storage account the developers never expected an attacker to touch.

Serverless functions deserve the same scrutiny. A Lambda role with broad S3 and Secrets Manager access is a high-value target if the function accepts attacker-controlled input.

Network paths that survived the migration

Lift-and-shift programmes leave fossils. Management ports open “temporarily.” Peering that was required for a cutover and never removed. Security groups copied from a development VPC into production. NSGs that allow RDP or SSH from any address in a partner range that is larger than anyone remembers.

A scan will flag 0.0.0.0/0. It will not always tell you that a more restricted rule still reaches the same jump host from a compromised contractor VPN, or that a Kubernetes service of type LoadBalancer published an internal dashboard to the internet.

CI/CD as the new privileged network

Build pipelines often hold more privilege than any human administrator. They can read secrets, push images, apply Terraform, and assume deployment roles. A pipeline that accepts unreviewed pull requests from forks, or that prints environment variables into logs, is an attack path.

We treat CI/CD as part of the cloud attack surface, not as a separate “DevOps” concern. If the pipeline can deploy to production, the pipeline is production.

‍

What a Competent Cloud Test Looks Like

Scope determines quality. A two-day unauthenticated look at a single public website is not a cloud penetration test, even if the site is hosted on AWS.

Start with the business question

Decide what you need to know. Typical questions we help clients frame:

• Can an external attacker reach data in this account or subscription without phishing anyone?
• If a standard user account is phished, how far can they go before a control stops them?
• Does segmentation between production, development, and shared services actually hold?
• Can a compromised workload identity reach the control plane?
• If we lost a CI deploy key, what is the blast radius?

Those questions drive the rules of engagement, the identities supplied, and the systems declared out of bounds.

Combine unauthenticated, authenticated, and configuration review

The strongest engagements use all three.

Unauthenticated testing finds what the internet can see. Authenticated testing, using agreed low-privilege and role-representative accounts, finds authorisation failures and privilege escalation. A configuration review of IAM, Entra ID, storage policies, and logging fills in the paths that exploitation time would not reach in a short window.

None of those three on their own is sufficient. Together they produce a defensible picture.

Follow paths, then stop at the agreed limit

Testers should prove impact without becoming an incident. That means copying a small, agreed sample of data rather than an entire database. It means demonstrating that a role can be assumed, then stopping. It means not modifying production configurations unless the rules of engagement explicitly allow a controlled change and a rollback plan exists.

This is where experience matters. Cloud estates are easy to damage with a careless API call.

Map findings to ATT&CK and to the business

Technical teams need the technique. Boards need the consequence.

We map relevant activity to MITRE ATT&CK for Cloud (initial access, privilege escalation, credential access, collection, exfiltration, persistence). We then translate each confirmed path into operational language: regulatory exposure, customer notification duty, recovery time, and whether logging would have caught the activity.

If the test cannot say whether CloudTrail, Defender, or equivalent telemetry would have alerted, the test is incomplete.

‍

Anonymised Paths We Keep Seeing

The details below are composite. They reflect patterns from real engagements without identifying clients.

The leftover key and the “private” bucket

A mid-size professional services firm had Block Public Access enabled on new S3 buckets. An older bucket used for “temporary” database dumps predated that control. Object listing was possible without authentication. One object was a SQL dump whose header comments included an access key ID. The matching secret was still valid. The user attached to that key could read a second bucket that held customer exports.

The scanner had marked the old bucket as a medium finding and the access key as unused. Neither ticket conveyed that the two items formed a complete path to client data.

The service principal that outranked the humans

A UK SaaS company used an Entra app registration for an internal automation job. The application had been granted Graph permissions during a rushed integration and never reviewed. From a low-privilege user who could read the application’s configuration in a poorly locked-down repository, testers recovered a client secret. That secret allowed addition of credentials to a second application that held Privileged Role Administrator equivalent rights.

No virtual machine was exploited. No CVE was involved. Identity design was the vulnerability.

The hybrid hop

A manufacturer treated its Azure estate as separate from its factory network. ExpressRoute and a set of shared jump hosts said otherwise. From a Contributor-level managed identity on a misconfigured App Service, testers reached a storage account containing VPN profiles, then authenticated into a network segment that still used local administrator passwords stored in the same account.

The cloud finding was only the first step. The business risk sat on the factory side.

‍

How to Commission a Test That Is Worth the Money

Ask a provider to explain their method before you ask for a price.

Useful scoping questions:

1. What attacker starting points will you use, and why those?
2. Will you test Entra ID or IAM as a control plane, or only the applications sitting on compute?
3. How will you handle production data and rate limits on management APIs?
4. What does a critical finding look like in your reports, in business language?
5. Will you re-test after remediation, and within what window?
6. How do you avoid the test itself becoming a source of outage?

Treat “we will run Prowler, ScoutSuite, and Pacu and send the output” as a scan with extra steps. Those tools are legitimate parts of a tester’s kit. They are not the engagement.

Also be honest about what you will give the testers. A black-box test of a well-locked perimeter can burn days confirming that public exposure is limited, while missing the identity path that a stolen laptop would use. Grey-box testing with representative accounts is usually the better use of budget for cloud.

Align timing with change. A test just after a landing-zone rebuild, a tenant migration, or a major IaC rewrite will find more than an annual ritual performed against an estate that has not moved.

‍

What This Means for the Business

Cloud risk is not abstract infrastructure risk. It is customer data, invoice integrity, uptime of the services you sell, and the cost of investigating an event that logging only half-recorded.

A scan programme can demonstrate that you are looking. A penetration test demonstrates whether looking is enough. For organisations that need to show ISO 27001 Annex A.8.8 evidence, PCI-DSS testing of the cardholder environment in the cloud, or contractual assurance to enterprise customers, that distinction matters. Auditors and customers increasingly ask whether testing was manual, scoped to real attack paths, and performed by people who understand the provider’s identity model.

None of that requires catastrophising. Most of the issues we find are fixable with identity hygiene, storage policy, pipeline controls, and better retirement of old resources. The work is unglamorous. It is also where incidents actually start.

‍

Practical Insights and Key Takeaways

1. Treat identity as the primary cloud attack surface. If you only patch compute, you are defending the wrong layer.
2. Demand attack paths in the report, not a list of CIS deviations. A finding that cannot be explained as “from here, an attacker can do this to that asset” is incomplete.
3. Include Entra ID or IAM, storage, CI/CD, and hybrid connectivity in scope. An application-only test of a site hosted in the cloud is not cloud penetration testing.
4. Give testers representative low-privilege identities. Pure black-box testing often wastes time on a perimeter you already understand.
5. Ask whether detection would have fired. Resilience includes knowing if you would have seen the activity.
6. Retire standing privilege. Privileged Identity Management in Azure and short-lived, tightly scoped roles in AWS remove entire classes of findings.
7. Inventory old storage and old keys. The highest-impact issues we see are frequently resources created before the current security standard existed.
8. Retest. A cloud estate changes weekly. A report that is never verified against the fix becomes historical commentary.

‍

‍

Conclusion

Cloud platforms did not remove the need for penetration testing. They moved the important work into identity, storage policy, automation pipelines, and the seams between cloud and everything you still run yourselves.

Scans will continue to be useful. They catch drift. They feed ticketing. They are a poor substitute for a human who can chain a public object, a leftover key, and a trust policy into a story a CISO can take to the board.

If your current assurance is a monthly posture score and an annual infrastructure test that never touched Entra ID or IAM, you have a blind spot. Close it with a scoped cloud penetration test that starts from a real attacker position and ends with paths you can actually fix.

Ready to see which findings in your Azure or AWS estate are genuinely exploitable? Contact Mongoose Cyber Security for a no-obligation scoping call. We will map the test to your critical functions, agree clear rules of engagement, and deliver a report that technical teams and decision makers can both use.

‍