Cloud misconfigurations are behind the majority of cloud breaches, and almost none of them involve a clever exploit. They involve a bucket that was left public, a role that was granted far too much power, or a secret that ended up in a code repository. Across AWS, Azure and GCP the pattern is remarkably consistent: the platform did its job, and a setting on the customer side of the shared responsibility model quietly opened the door.
For Australian organisations moving more workloads to the cloud each year, understanding these misconfigurations is essential. This article walks through the ones that most often lead to breach, and how cloud penetration testing finds them before an attacker does.
The Shared Responsibility Gap
Every major cloud provider operates a shared responsibility model. The provider secures the underlying infrastructure, the physical facilities and the core services. You remain responsible for how you configure those services, who can access them, and the data you place inside them.
Almost every high-profile cloud breach has originated on the customer side of that line. The provider's platform worked exactly as designed, but a configuration choice exposed data or handed over access. Recognising where your responsibility begins is the foundation for everything that follows, because it tells you which risks are yours to manage.
The difficulty is that the boundary shifts between services. A managed database moves more responsibility to the provider than a virtual machine you patch yourself, and a serverless function moves more still. Australian teams running a mix of these across several accounts often lose track of who owns what, and that ambiguity is where misconfigurations breed. The most resilient organisations write their responsibility model down, service by service, so nobody assumes the provider is covering a gap that is actually theirs.
Public Storage: The Breach That Needs No Exploit
Publicly accessible storage remains the single most reliable source of cloud data exposure. It affects S3 buckets on AWS, blob containers on Azure and storage buckets on GCP alike.
The problem is structural rather than technical. Storage is easy to create, easy to make public with one setting, and often holds large volumes of sensitive data. Automated scanners constantly sweep provider address ranges looking for open storage, and once they find it the data can be downloaded silently with no attack required.
The defences are well understood:
- Enable account-level public access blocks so individual buckets cannot be made public by accident.
- Apply least-privilege access policies and default to private.
- Continuously inventory storage so new buckets are caught before they leak.
The challenge in a large environment is not knowing the fix, it is the sheer number of storage resources that any one of them could be misconfigured without regular checking.
Over-Permissive IAM: Too Much Power, Too Widely Held
Identity and access management is the true control plane of the cloud, and it is routinely too generous. Roles and policies are often granted broad permissions during development and never tightened, leaving workloads and users with far more privilege than they need.
Common patterns we find include:
- Wildcard permissions that effectively grant full administrative rights to a workload that needs only to read one bucket.
- Roles that can escalate their own privileges by editing policies or assuming more powerful roles.
- Long-lived access keys shared between services or embedded in scripts.
Over-permissive IAM turns a minor foothold into a major breach. If an attacker compromises one component, the blast radius is defined entirely by what that component was allowed to do. Least privilege is not a nice-to-have, it is the single most effective way to contain an incident.
Exposed Metadata and SSRF
Compute instances in every major cloud expose an internal metadata service that can hand out temporary credentials for the role attached to the instance. That is convenient for legitimate workloads and dangerous when a web application is vulnerable to server-side request forgery.
In an SSRF attack, an attacker tricks the server into making requests on their behalf. If they can point that request at the metadata service, they can retrieve the instance's credentials and then use them to access cloud resources directly. This exact chain has driven some of the largest cloud breaches on record.
Defences work in layers:
- Fix the SSRF vulnerability in the application itself.
- Enforce the hardened version of the metadata service that requires a session token.
- Scope instance roles tightly so stolen credentials grant as little as possible.
Secrets in Code and Insecure Defaults
Two quieter misconfigurations round out the list, and both are extremely common.
Secrets in code. API keys, database passwords and access tokens frequently end up committed to source control or baked into container images and environment variables. Once a secret reaches a repository it is effectively permanent, because it lives in the history even after it is deleted. Attackers actively scan public and private repositories for exactly this. The answer is a dedicated secrets manager, short-lived credentials, and automated scanning to catch secrets before they are committed.
Missing MFA on root and admin accounts. The most powerful accounts in a cloud environment are sometimes protected by nothing more than a password. Without multi-factor authentication on root and administrator identities, a single phished or reused credential can compromise the entire account. Enforcing MFA everywhere, and avoiding day-to-day use of root, is a basic control that still goes missing.
Insecure defaults. Many services ship with settings tuned for ease of adoption rather than security, and those defaults are never revisited. Open security groups, unencrypted data stores, disabled logging and permissive network rules all fall into this category. Disabled logging is especially costly, because it means a breach can happen with no record of how it unfolded, leaving your responders blind exactly when they most need visibility. Turning on the platform's native audit and access logs, and shipping them somewhere tamper-resistant, should be one of the first things configured in any new account.
How Cloud Penetration Testing Finds These Issues
Many cloud weaknesses are permission and policy problems, which means they are best found by inspecting the account, not only attacking it from the outside. Cloud penetration testing combines active testing with configuration review, examining IAM policies, storage permissions, network controls, secrets management and logging across AWS, Azure and GCP.
Expert operators map how services trust one another, then follow the chains an attacker would use: from an exposed application to stolen credentials, from an over-permissive role to sensitive data, from a leaked secret to a foothold. Because they work within the provider's rules of engagement, this can be done safely against real environments.
| Misconfiguration | How testing finds it |
|---|---|
| Public storage | Enumeration and permission review |
| Over-permissive IAM | Policy analysis and privilege-escalation paths |
| SSRF to metadata | Application testing chained to credential theft |
| Secrets in code | Repository and artefact scanning |
| Missing MFA and defaults | Configuration and identity review |
Because cloud environments change constantly, testing works best alongside continuous configuration monitoring. Periodic in-depth engagements catch the deeper attack paths, while ongoing checks flag drift as it appears. For organisations wanting a broader inventory of weaknesses first, vulnerability assessments provide the wider view, and our AI offensive security work models how attackers are using automation to find these misconfigurations faster in 2026.
Closing the Gaps Before They Open
Cloud misconfigurations lead to breach precisely because they are ordinary. A public bucket, a generous role, a forgotten secret: each looks harmless until it is the one an attacker finds. The reassuring part is that every issue in this article has a clear, achievable fix.
If you want to know which misconfigurations exist in your AWS, Azure or GCP environment, and how to close them, our team of expert operators can help. Explore our penetration testing services or get in touch for a scoping conversation. You can also call StrikeCyber on 1300 654 898.
Frequently asked questions
What are the most common cloud misconfigurations?
The most common cloud misconfigurations are publicly accessible storage such as open S3 buckets or blob containers, over-permissive identity and access management that grants far more privilege than any workload needs, secrets and API keys committed to code or left in environment variables, missing multi-factor authentication on root and administrator accounts, exposed instance metadata that can be reached through server-side request forgery, and insecure defaults that were never hardened after deployment. Each of these turns up regularly across AWS, Azure and GCP, and each has caused real breaches.
Why do public storage buckets keep causing breaches?
Public storage buckets keep causing breaches because they are easy to create, easy to make public by accident, and often hold large volumes of sensitive data. A single permissions setting can expose a bucket to the entire internet, and automated scanners constantly sweep cloud provider ranges looking for open storage. Once found, the data can be downloaded silently with no exploit required. The fix is straightforward, using account-level public access blocks and least-privilege policies, but the sheer number of buckets in a large environment means mistakes slip through without regular checking.
What is an SSRF attack on cloud metadata?
Server-side request forgery, or SSRF, is where an attacker tricks a server into making requests on their behalf. In the cloud this is dangerous because compute instances expose an internal metadata service that can hand out temporary credentials for the role attached to the instance. If a web application is vulnerable to SSRF, an attacker can make it fetch those credentials and then use them to access cloud resources directly. Enforcing the hardened version of the metadata service and scoping instance roles tightly are the key defences, alongside fixing the SSRF flaw itself.
How is cloud penetration testing different from a normal pen test?
Cloud penetration testing focuses on the configuration, identity and service relationships that are unique to cloud platforms, rather than only the operating systems and applications running inside them. It examines IAM policies, storage permissions, network controls, secrets management, logging and the specific services each provider offers. Testers work within the provider's rules of engagement and often review configuration alongside active testing, because many cloud weaknesses are permission and policy issues that are best found by inspecting the account, not just attacking it from the outside.
Does the cloud provider secure my configuration for me?
No. Cloud providers operate a shared responsibility model. The provider secures the underlying infrastructure, the physical data centres and the core services, but you remain responsible for how you configure those services, who can access them, and the data you place in them. Almost every well-known cloud breach has stemmed from the customer side of that line, typically a misconfiguration rather than a fault in the provider's platform. Understanding where your responsibility begins is the first step to closing the gaps.
How often should we test our cloud environment?
Cloud environments change constantly, so point-in-time testing alone is rarely enough. A sensible pattern combines periodic in-depth penetration testing, at least annually and after major architectural changes, with continuous configuration monitoring that flags drift as it happens. High-value and internet-facing workloads warrant more frequent attention. The aim is to catch misconfigurations quickly after they are introduced rather than discovering them months later, or worse, after an attacker has already found them.