Cloud Misconfigurations That Pentesters Love to Exploit

Cloud security assessments are where I see the most surprising findings, because the attack surface is invisible to the naked eye. As Petre Radu Cătălin, an offensive security professional based in Brașov, Romania, I have spent the last two years testing AWS, Azure, and GCP environments for enterprise clients. In that time I have noticed the same misconfigurations appearing again and again. This post lists the ones I actually exploit on engagements - not the theoretical ones from compliance checklists - along with the exact techniques that find them.

Why Cloud Misconfigurations Keep Happening

The cloud's promise is speed. The same velocity that lets a team provision a thousand resources in an afternoon also lets a misconfiguration ship with every release. Cloud providers secure the platform; they do not secure your build. In every environment I test, the same three dynamics create the worst findings:

1. Default-permissive settings that are never reviewed for production.
2. Shared development accounts where permissions accumulate across teams.
3. Skill gaps in IAM, the hardest and most consequential cloud primitive.

My job on an engagement is to compress months of an organization's drift into a two-week window and surface what a threat actor would find.

The Top Misconfigurations I Exploit

1. Over-Permissive S3 Buckets (And Storage, Generally)

Publicly readable buckets remain the number-one finding in cloud assessments. What makes them dangerous is not the bucket itself - it is what the bucket contains. On one engagement, a publicly readable bucket exposed a backup file with database connection strings and API keys. That single finding neutralized every other piece of infrastructure the client considered "well defended."

The technique: enumerate bucket names from the client's web properties, scan for predictable naming patterns, and test s3:ListBucket and s3:GetObject permissions anonymously. With the AWS CLI, aws s3 ls s3://bucket-name completes the test in one command. The same logic applies to Azure Blob containers and GCP storage buckets.

The fix: default to private, apply bucket policies that deny anonymous access, enable encryption, and test the policy from an unauthenticated identity.

2. IAM Roles That Violate Least Privilege

IAM is the control plane for everything in the cloud. An over-permissive role is not a vulnerability; it is a vault key. The most common variants are:

• Roles with AdministratorAccess attached to EC2 instances or Lambda functions.
• Cross-account roles with weak trust relationships that allow any principal in a foreign account to assume them.
• Service-linked roles that have accumulated policies during development.

The technique: if I compromise any resource that can make AWS API calls, I immediately inspect its role. sts get-caller-identity, iam list-attached-role-policies, and a check of which actions are actually permitted tells me whether one foothold is really a foothold into the whole account. In Azure, the equivalent is a Managed Identity attached to a VM or app service; in GCP, a service account attached to a Compute Engine instance.

The fix: role least privilege, enforced with IaC, plus anomaly detection on API call patterns.

3. Leaked Credentials In Code And Public Repositories

Developers commit secrets. It is not a character flaw; it is a workflow failure. I have found production AWS keys in public GitHub repositories, hardcoded connection strings in CI/CD configuration files, and API tokens pasted into support tickets. Cloud logs are the best reliable source: CloudTrail in AWS, and a simple grep for compromised key IDs will confirm whether the key is active.

The technique: rotate suspected keys immediately, then search the usage of the leaked key to understand blast radius. A key uploaded to a public repo two years ago may have been copied by scanners within minutes of the commit.

4. Public Snapshots and Publicly Attached Data Disks

Virtual machine images, database snapshots, and data disks silently drift toward public. Azure makes it easy to mark a snapshot public for a test and forget to revert it. The snapshot is a perfect offline copy of a production database - if I can download it, I win without ever touching a running system.

The technique: enumerate snapshot permissions with the provider's API. aws ec2 describe-snapshots --restorable-by-user-ids all lists every snapshot the account can restore - including other accounts' snapshots in the same region.

5. Unrestricted Security Group Rules

An inbound rule of 0.0.0.0/0 on port 22 or 3389 in production is a standing invitation. On one engagement I found a database allowed to the whole internet because an engineer "needed to test from home." The combination of an unfiltered rule and weak credentials is usually all I need.

6. A Broken Shared Responsibility Understanding

The subtlest misconfiguration is cultural. Teams that believe "the provider secures it" ship databases with default ports, weak authentication, and unencrypted traffic. My role in these engagements is as much educator as operator.

Tools I Use To Find Misconfigurations

My standard cloud assessment toolkit is small and purpose-built:

• CloudTrail / audit logs to reconstruct what an attacker could have done.
• aws-cli, az CLI, gcloud for policy and permission inspection.
• Scout Suite / Prowler, which automate the boring ninety percent of checks.
• BloodHound for cloud: the AWS and Azure collectors now map privilege paths the way the original maps Active Directory. If you are serious about cloud security, learn this tool first.

Detection Gaps That Make It Worse

The painful truth is that most organizations do not log cloud API calls at all - or they log them and never read them. Attacking an environment without audit logging is trivially quiet. Where logging does exist, the gaps I exploit are the events nobody alerts on: role assumption from a new principal, first-time access from a foreign IP, and an unexpected storage download.

My Remediation Template

Every cloud assessment I deliver ends with a prioritized remediation sheet. The items that consistently matter most are:

1. Assume every identity is compromised and design permissions to fail closed.
2. Automate permission reviews on a quarterly cadence.
3. Encrypt everything at rest and in transit, with key rotation.
4. Alert on the top ten high-risk events - role assumption, privilege change, public-region exports.
5. Test your own environment with the same tooling and same patience I use.

Conclusion

Cloud misconfigurations are not a niche problem; they are the dominant finding of modern assessments. The good news is that nearly all of them are fixable from the console in a single day if someone with the right understanding drives the change. The bad news is that attackers do not wait for a convenient Tuesday. Test your own environment with the techniques above, fix what you find, and treat the cloud the way you treat the perimeter - as something hostile that must be earned, not assumed.