Exploiting Cloud Misconfigurations: How Attackers Find Cloud Attack Paths (Part 1 - The Basics)

How to Attack cloud environments

When it comes to attacking cloud environments, there’s still a lot of confusion. Many people think of the cloud as simply a managed version of on-prem infrastructure. So when asked how they would attack a cloud environment, they often fall back on the traditional playbook: scan for open ports, discover exposed servers, look for known vulnerabilities, gain an initial foothold, and perform lateral movement.

That approach definitely works, but it only covers one side of the attack surface.

The other side is cloud-native. Instead of targeting servers, attackers target cloud settings. This distinction - targeting identities and configurations rather than hosts and networks - is what separates cloud-native security from traditional infrastructure security.For example discovering an S3 bucket that is accessible to all AWS users via a wildcard (*) in a resource-based policy or finding Azure SQL using weak passwords and having public network access.

In this series, we’ll look at cloud environments from an attacker’s perspective. We’ll break down the different attack paths, and explore the obstacles attackers need to overcome in order to execute an attack. Let’s start from the basics.

The Holy Trinity

Usually, three things determine whether a misconfiguration can be exploited for serverless resources:

1. Resource Discovery
2. Network Accessibility
3. Identity Based Access

When an attacker has all three it is a game over. In some cases, like discussed in ShutterGap, all three appear to an attacker at once, and the exploitation is immediate. But most of the times each of the three obtained to an attacker differently.

Guessing Resource Names

Many teams do not treat resource names or identifiers as sensitive. But in practice, attackers often need to know what to target before they can access it. That makes resource discovery a critical part of cloud exploitation.

Resource discovery is a broad topic in offensive security. The two most common examples are:

1. Public IPv4 addresses
2. Cloud resource names

Some cloud resources are primarily identified by their public IPv4 address, such as public RDS instances. Others are primarily identified by a globally unique resource name, such as AWS S3 buckets or Azure SQL servers.

So how can attackers guess resource identifiers?

For public IPv4 addresses, the common approach is CIDR-based enumeration.

For cloud resource names, there are two common approaches.

The first is brute-force or dictionary-based name enumeration. This method focuses on guessing predictable names using common naming patterns, company names, environments, regions, project names, and wordlists.

The second is public hostname discovery. Instead of guessing names directly, this method looks for resource names that are already stored, referenced, or reachable publicly. These names may appear in DNS records, certificates, public repositories, documentation, logs or third-party indexes.

But this raises an important question:

Even if you can guess an identifier, can you verify that the resource actually exists? What if the resource is supposed to be private?

This is one of the most common misconceptions about cloud security. In cloud environments, “private” means privately accessible, not invisible for identification. A resource may block direct access, but its identifier can still exist in a global namespace.

In other words, private access is not the same as private existence. Given a guess, attackers can often find a way to test whether a resource exists even if it is “Private”. Once they can do that at scale, resource discovery becomes less of a guessing game and more of an enumeration problem.

Network: The Forgotten Perimeter

Cloud security often repeats the phrase: “Identity is the new perimeter.”

There is truth in that. But over time, it has also become an excuse to ignore network exposure.

In many cloud services, resources are reachable from everywhere by default unless defenders explicitly restrict access. If a resource is discoverable and reachable from the internet, the attacker can often skip the network problem and move directly to the last step - identity and access.

It does not have to work this way. In practice, network restrictions function as cloud security guardrails closing off an attack path before identity is ever tested, in practice network restrictions can eliminate a large portion of practical exploitability. Even when identity is misconfigured, limiting from where a resource can be reached can prevent the attack path from being usable.

This is especially important for PaaS resources. In Azure, it is usually straightforward to configure network restrictions for services such as Storage Accounts, Web App, and Key Vaults through the resource’s networking settings. This makes it relatively easy to use network controls as an additional defensive layer alongside identity.

In AWS, similar outcomes are often possible, but the implementation is usually more policy-driven. This policy-driven approach is part of what makes AWS misconfiguration prevention a distinct challenge compared to Azure's more direct networking controls. Defenders may need to rely on resource-based policies or Resource Control Policies to restrict access based on network context for S3 Buckets, Lambda Functions or KMS Secrets.

As a result, we often see stronger network restrictions applied more consistently in Azure PaaS environments than in comparable AWS services. Not because AWS cannot enforce them, but because the path to doing so is often more complex.

Identity - The Holy Grail of Cloud Security

Identity is one of the most important factors in cloud exploitation. But it is often misunderstood. Many times, identity is treated as the only “real” reason an attack succeeds. Sometimes identity issues are placed in a separate category entirely, as if they are not misconfigurations.

But in cloud environments, identity is configuration. Put another way, identity choices are cloud security policy decisions. And in many cases, choosing the right policy could have prevented a breach.

What Next in This Series

We’ll take a deep dive into each of the steps  required to carry out an attack in a cloud environment. For each step, we’ll cover the relevant attack techniques, defensive measures, and how the different cloud providers compare.

Throughout the series, we’ll use storage and database resources as representative examples.