You Moved to the Cloud. Hackers Moved with You.

In 2019, Capital One discovered that 106 million customer records had been exposed through a single misconfigured AWS firewall rule.

Cloud providers like AWS and Azure are excellent at securing the infrastructure they operate. This includes the physical data centers, the hardware, and the underlying software that makes the cloud run. That part is their job, and they do it well.

What they don’t do is secure your account, configurations, data, access controls, or your applications. This is called the shared responsibility model, and it’s the source of most cloud security problems we see.

According to Gartner, an estimated 99% of cloud breaches through 2025 resulted from customer misconfigurations, not provider vulnerabilities.

What “Shared Responsibility” Means

Think of it this way: The cloud provider builds and secures the building. You’re responsible for locking your own doors and windows inside it.

Amazon and Microsoft aren’t going to audit your account for vulnerabilities. They won’t notice that your storage bucket is publicly accessible or that an IAM role has more permissions than it should. Neither provider audits or tests your environment for vulnerabilities. That’s what an independent cloud penetration test is for.

What falls on the customer includes things like how access is configured, who can reach what, how data is stored, how applications are built and deployed, and how everything connects to each other. Every one of those areas can be misconfigured.

What Attackers Are Finding in Cloud Environments

The most common cloud vulnerabilities aren’t sophisticated. The most frequent findings in cloud penetration testing cluster around a few specific areas:

Misconfigured storage

Many breaches happen because an S3 bucket or Azure Blob storage container is set to public when it should be private. Another issue is when an IAM policy grants far more access than the user or service needs. Both vulnerabilities can be easy to miss, especially in environments that have grown quickly or where multiple people have been making configuration changes over time.

Hard-coded credentials

Developers sometimes embed access keys or passwords directly into application code or configuration files. When that code lives in a repository, especially a public one, those credentials are effectively exposed. Attackers scan for them specifically.

Overly permissive identity and access management

IAM in AWS and Azure is powerful and flexible, which can also be a vulnerability. A service account with admin-level access when it only needs read access to one bucket is a privilege escalation path waiting to be exploited. A user account that was provisioned for a project and never deprovisioned is an open door.

APIs that aren’t properly secured

Cloud environments are heavily API-driven. Misconfigured APIs, missing authorization checks, and improper access controls on API endpoints are some of the top findings across cloud security assessments.

Cloud environments change quickly, and new services, permissions, integrations, or deployments can introduce security gaps that weren’t present in a previous assessment. This is part of what makes cloud security harder than traditional network security. The configuration that was fine last quarter may not be fine today because something changed.

The Capital One breach is probably the most cited example of what this looks like. A single misconfigured AWS firewall rule exposed 106 million customer records, cost millions in fines, legal fees, and lost trust.

Wondering what a cloud pen test would find in your environment? It’s usually different than what you’d expect. Talk to MainNerve about what that conversation looks like.

How Cloud Pen Testing Is Different from a Regular Network Test

Cloud penetration testing covers the same fundamental goal as any pen test. That is, to find what an attacker could exploit before an attacker does. But the techniques and focus areas are different from a traditional network test, because the environment is a little different.

Unlike traditional network penetration testing, cloud penetration testing addresses the unique architecture, shared responsibility models, and dynamic nature of cloud platforms. Testers aren’t just scanning for open ports and missing patches. They’re testing for privilege escalation paths, checking whether storage is properly secured, looking for hard-coded credentials in code repositories, and verifying that the access controls in place match the access controls that were intended.

The testing also has to work within each provider’s rules. AWS and Azure both allow penetration testing of your own account and resources, but there are specific boundaries. You can’t test infrastructure that affects other customers or the provider’s own systems. A competent testing firm understands those boundaries and works within them. For most common cloud services, AWS no longer requires pre-authorization before testing, though specific services still have restrictions. Azure has its own rules of engagement that govern what’s permitted.

Cloud Security and Compliance

If your organization operates under HIPAA, PCI DSS, SOC 2, or similar frameworks, cloud security isn’t optional. Moving regulated data to AWS or Azure doesn’t transfer your compliance obligations to Amazon or Microsoft. The data is still yours and the controls are still your responsibility.

Cloud misconfigurations, insecure APIs, and overly permissive IAM policies are consistently among the top causes of cloud breaches, and they’re also consistently what compliance auditors and penetration testers find when they dig into cloud environments. A cloud pen test that maps findings to your specific compliance framework gives you something you can use directly in an audit.

What to Do with This Information

If your business runs on AWS, Azure, or any other cloud platform, the starting point is understanding what you’re responsible for versus what the provider handles. Most people who’ve made the move to the cloud have a general sense of this, but there’s often a gap between the general sense and the specific configurations that are actually in place.

A cloud penetration test can help close that gap. It can tell you what an attacker would find in your environment, how far they’d get, and what needs to be addressed before someone finds it the hard way. The findings from a good cloud test are specific, prioritized, and actionable, not a generic list of cloud security best practices.

Basic IT and cyber hygiene still matter in the cloud. Reviewing who has access to what, making sure storage isn’t publicly exposed, rotating credentials, and keeping an eye on configurations that change over time will help prevent the kind of breach that makes the news.

MainNerve provides many kinds of network penetration testing, including cloud penetration testing. If you’d like to talk through what a cloud penetration test would look like for your environment, we can talk through what would be in scope, what the process looks like, and what you’d walk away with. Reach today to schedule your free consultation.