Cloud Security Misconfigurations: AWS, Azure, and GCP Testing Guide

Cloud misconfigurations remain the leading cause of data breaches in cloud-native environments. The pattern is consistent across incident reports: not a sophisticated zero-day, not a supply chain attack — just an S3 bucket with public read access, or an IAM role with * on all resources, or a VM with no authentication on port 8080.

Cloud providers give you enormous configurability. They also give you enormous rope to hang yourself with. This guide covers the most critical cloud security misconfigurations in AWS, Azure, and GCP, and how to test for them systematically.

The Most Common Cloud Misconfigurations by Category

1. Publicly Exposed Storage

Public cloud object storage (S3, Azure Blob, GCS) is configured private by default — but not always kept that way. This is the single most commonly exploited cloud misconfiguration.

AWS S3

Three distinct controls can expose an S3 bucket:

• Block Public Access settings: AWS added account-level and bucket-level public access blocks. If these are disabled, bucket and object ACLs can grant public access
• Bucket ACL: A bucket ACL can grant READ or FULL_CONTROL to the AllUsers or AuthenticatedUsers principal
• Bucket policy: A bucket policy with Principal: "*" and Action: s3:GetObject grants public access regardless of ACL settings

Testing exposure:

# Attempt anonymous list on a known bucket name
aws s3 ls s3://target-bucket-name --no-sign-request

# Check bucket policy from outside
curl -s https://target-bucket-name.s3.amazonaws.com/?policy

# Nuclei template for S3 exposure detection covers known bucket naming patterns
nuclei -u https://target.com -t cloud/aws/s3/

Azure Blob Storage

Azure storage containers have an "access level" setting: Private, Blob (anonymous read for blobs only), or Container (anonymous list and read). Any setting above Private exposes data.

# Test for anonymous access to Azure blob container
curl -s "https://accountname.blob.core.windows.net/container-name?restype=container&comp=list"

# If this returns XML with blob names, the container is publicly listed

GCS Buckets

# Test anonymous GCS access
curl -s "https://storage.googleapis.com/bucket-name/"

# If this returns bucket contents without authentication, it's publicly accessible

2. Cloud Instance Metadata SSRF

Every cloud provider runs a metadata service on a link-local IP address that instances use to retrieve their configuration, credentials, and role information:

• AWS: http://169.254.169.254/latest/meta-data/
• Azure: http://169.254.169.254/metadata/instance?api-version=2021-02-01
• GCP: http://metadata.google.internal/computeMetadata/v1/

When an application on a cloud instance accepts user-controlled URLs and fetches them server-side (SSRF), the metadata service is the highest-priority target. From AWS instance metadata, an attacker can retrieve:

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Returns the role name, then:
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]

# Returns:
{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "2026-06-19T14:00:00Z"
}

These temporary credentials have the permissions of the instance's IAM role. In the common case where the role has overly broad permissions, this is full AWS account compromise via SSRF.

IMDSv2 and its limits: AWS introduced IMDSv2 (Instance Metadata Service v2), which requires a PUT request with a session token before GET requests are processed. This blocks simple SSRF-based metadata retrieval. However, IMDSv2 doesn't protect against blind SSRF that can probe internal network topology, and some environments still run IMDSv1.

Test for metadata SSRF via web application:

• Find any URL-accepting input (webhook, avatar upload, link preview, PDF generation)
• Submit the metadata service URL
• Check whether the response contains cloud metadata
• For blind SSRF, use a time-based or DNS-based technique to confirm the request is being made

3. Over-Permissive IAM Policies

IAM misconfigurations don't show up in web application scans — they require cloud account access to assess. But they create the conditions that turn a low-severity finding into a critical one.

The wildcard problem:

# This policy is effectively full admin access:
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

Any principal with this policy can do anything in the AWS account. It's surprisingly common in environments that started with permissive policies "temporarily" and never restricted them.

Privilege escalation paths: A user with limited permissions can escalate to admin through indirect paths that bypass obvious permission checks:

• iam:PassRole + ec2:RunInstances: Can launch an EC2 instance with a high-privilege role attached, then retrieve credentials from that instance's metadata service
• lambda:CreateFunction + iam:PassRole + lambda:InvokeFunction: Create a Lambda with an admin role, invoke it to execute arbitrary actions
• iam:CreatePolicyVersion: Can create a new version of an existing policy with *:* permissions and set it as the default
• iam:AttachUserPolicy: Can attach any existing policy to any user, including AdministratorAccess

Tools like Pacu (AWS exploitation framework) and PMapper (privilege escalation path finder) map these automatically. CNAPP (Cloud Native Application Protection Platform) tools scan for these configurations continuously.

4. Exposed Management Interfaces

Development environments and instances launched without a final security review often have management interfaces exposed to the internet:

The Shodan search engine indexes millions of exposed instances of every service in this table. Automated scanners find them within hours of exposure.

Testing approach: Run a port scan against all public IP ranges allocated to your organization. Compare open ports against your known service inventory. Anything unexpected is either shadow IT or a misconfiguration.

# nmap scan for common management ports against your IP range
nmap -Pn -p 22,2375,2376,2379,3389,6443,8080,8443,9200,27017 \
  --open your-ip-range/24

# nuclei templates cover specific service detection
nuclei -l targets.txt -t network/

5. Public EBS/Azure Disk Snapshots

Cloud disk snapshots can be shared publicly — and sometimes are, accidentally. A public EBS snapshot of a production volume contains everything on that volume at the time of the snapshot: database files, application code, secrets, credentials.

Finding public EBS snapshots owned by a target:

aws ec2 describe-snapshots \
  --owner-id [target-account-id] \
  --filters Name=snapshot-id,Values=snap-* \
  --query 'Snapshots[?State==`completed`]' \
  --no-sign-request

Public snapshots are searchable by anyone. This is how researchers have found database backups containing millions of user records.

Remediation: Enable AWS Organizations SCPs (Service Control Policies) that deny ec2:ModifySnapshotAttribute with Public access. Run AWS Config rules to detect and alert on public snapshots. For Azure, use Azure Policy to deny public disk access settings.

6. CloudTrail and Logging Gaps

Security testing isn't just about active vulnerabilities — it also covers whether you can detect attacks when they happen. Cloud security assessments include logging review:

• AWS CloudTrail: Is it enabled across all regions? Are management events (IAM, console logins) logged? Is log file integrity validation enabled? Are logs stored in a separate account with restricted write access?
• Azure Monitor: Are diagnostic logs enabled for critical services (Key Vault, storage, Azure AD sign-ins)? Is log retention configured?
• GCP Cloud Audit Logs: Are admin activity logs, data access logs, and system event logs enabled for sensitive projects?

Log gaps are a critical finding in any cloud security assessment — not because they create attack surface, but because they mean you're flying blind when an incident occurs.

7. Secrets in Environment Variables and Config

A consistent finding in cloud security reviews is secrets hardcoded into Lambda environment variables, ECS task definitions, or Kubernetes ConfigMaps — where they're visible to anyone with describe permissions on those resources.

# List Lambda environment variables
aws lambda get-function-configuration --function-name production-api \
  --query 'Environment.Variables'

# This often returns:
{
  "DATABASE_URL": "postgresql://admin:ACTUAL_PASSWORD@db.internal:5432/prod",
  "JWT_SECRET": "s3cr3t_key_here",
  "AWS_SECRET_ACCESS_KEY": "..."
}

What pentesters check:

• Lambda environment variables for database credentials, API keys, encryption keys
• ECS task definition environment variables
• Kubernetes Secrets — are they base64-encoded (not encrypted) at rest? Are they accessible via RBAC from a compromised pod?
• EC2 user-data scripts — are credentials passed in startup scripts?
• Public GitHub repositories linked to the organization — git history can contain secrets even after removal

Remediation: Use secrets management services: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager. IAM policies should grant applications access to retrieve their secrets at runtime rather than having secrets stored in configuration.

A Cloud Security Testing Workflow

For a web application hosted in the cloud, the testing scope has two distinct layers:

Layer 1: Web application security testing (Ironimo's domain)

• OWASP Top 10 vulnerabilities in the application itself
• SSRF checks — including attempts to reach cloud metadata services
• HTTP headers and TLS configuration
• Exposed administrative interfaces at the application layer

Layer 2: Cloud infrastructure security (requires cloud account access)

• IAM policy review and privilege escalation path analysis
• Storage bucket access controls
• Security group / network ACL rules
• Public snapshot inventory
• Logging configuration
• Secrets management practices

Most automated web scanners cover Layer 1. Cloud Security Posture Management (CSPM) tools — AWS Security Hub, Microsoft Defender for Cloud, GCP Security Command Center, third-party tools like Wiz, Orca, or Lacework — cover Layer 2. An effective security program runs both.

Testing Tools by Cloud Provider

What to Prioritize

If you're building or improving a cloud security program and need to prioritize:

1. Block public access on all storage — enable account-level S3 Block Public Access, Azure Storage account public access restrictions, and GCS uniform bucket-level access. One setting, massive risk reduction.
2. Enforce IMDSv2 — require IMDSv2 on all EC2 instances. Blocks the most common SSRF-to-credential-theft path in AWS.
3. Rotate access keys, move to roles — long-lived IAM access keys are a persistent credential exposure risk. Replace with IAM roles for services, short-lived OIDC-based tokens for CI/CD.
4. Audit and remove overly permissive policies — run IAM Access Analyzer, identify and remove unused permissions, eliminate wildcard policies.
5. Enable logging everywhere — CloudTrail in all regions, VPC Flow Logs, S3 access logs for sensitive buckets. You can't investigate what you can't see.
6. Move secrets to secrets management — migrate credentials from environment variables and config files to Secrets Manager / Key Vault / Secret Manager. Rotate everything that was previously exposed.