Cloud Security: AWS, Azure and GCP Misconfigurations That Lead to Breaches

Cloud misconfigurations are the leading cause of data breaches in 2026, responsible for exposing billions of records across AWS, Azure, and Google Cloud deployments. The irony is that most of these breaches are not the result of sophisticated attacks — they are caused by a forgotten permission, a default setting left unchanged, or a developer testing something “temporarily.” This guide covers the most dangerous cloud misconfigurations with exact detection commands and remediation steps for all three major providers.

AWS Misconfigurations

Exposed S3 Buckets

S3 bucket exposure is the classic cloud security failure. Public buckets have leaked customer databases, source code, SSL certificates, and internal documents for companies ranging from startups to Fortune 500 enterprises.

# Check if a bucket is publicly accessible (no credentials):
aws s3 ls s3://company-backup-bucket --no-sign-request

# List bucket contents without auth:
aws s3 ls s3://company-bucket/  --no-sign-request --recursive

# Find S3 buckets related to a company via brute force:
# Common patterns: company-name, company-backup, company-dev, company-prod, company-assets
s3scanner scan --buckets-file bucket_names.txt

# FIX — Block all public access at account level (do this first):
aws s3api put-public-access-block   --account-id 123456789012   --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Exposed AWS Metadata Service (SSRF → Credential Theft)

# From a vulnerable EC2 instance (or via SSRF vulnerability in a web app):
curl http://169.254.169.254/latest/meta-data/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Returns the IAM role name attached to the instance
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME
# Returns temporary AWS credentials:
# {
#   "AccessKeyId": "ASIA...",
#   "SecretAccessKey": "...",
#   "Token": "..."
# }

# FIX — Enable IMDSv2 (requires tokens, prevents simple SSRF):
aws ec2 modify-instance-metadata-options   --instance-id i-1234567890abcdef0   --http-tokens required   --http-put-response-hop-limit 1

Overly Permissive IAM Policies

# The most dangerous IAM mistake:
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}
# This gives full admin access to everything — avoid wildcard permissions

# Audit all users with admin access:
aws iam list-users --query 'Users[*].UserName' | xargs -I {} aws iam list-attached-user-policies --user-name {}

# Check for users with inline policies:
aws iam list-users --query 'Users[*].UserName' | xargs -I {} aws iam list-user-policies --user-name {}

# Use Prowler for comprehensive AWS security assessment:
pip install prowler
prowler aws -M csv html json-ocsf

Azure Misconfigurations

Azure Blob Storage Exposure

# Check Azure blob storage for public access:
az storage container list --account-name storageaccountname --public-access

# Test anonymous access:
curl "https://storageaccountname.blob.core.windows.net/containername?restype=container&comp=list"

# Find Azure storage accounts via DNS brute force:
# Common pattern: companyname.blob.core.windows.net

# FIX — Disable public blob access at account level:
az storage account update   --name storageaccountname   --resource-group myRG   --allow-blob-public-access false

Azure AD Misconfigurations

# Password spray against Azure AD (Office 365):
# MFASweep — check if MFA is enforced on all auth flows
git clone https://github.com/dafthack/MFASweep
Import-Module MFASweep.ps1
Invoke-MFASweep -Username user@company.com -Password P@ssw0rd

# Check for legacy authentication enabled (bypasses MFA):
# Go to Azure AD → Sign-in logs → filter for "Legacy Authentication"
# OR use AzureAD module:
Get-AzureADPolicy | Where-Object {$_.Type -eq "HomeRealmDiscoveryPolicy"}

# Check service principals for excessive permissions:
az ad sp list --all --query '[].{name:displayName, appId:appId}' | head -30

Google Cloud (GCP) Misconfigurations

# Check GCS (Google Cloud Storage) buckets:
gsutil ls -la gs://company-bucket  # No auth — if it works, bucket is public
# Or just navigate to: https://storage.googleapis.com/BUCKET_NAME/

# Check for public GCS buckets matching company name:
gsutil ls gs://companyname-dev/ --no-user-project

# Check GCP service account key exposure:
# Service account JSON keys committed to GitHub are extremely common
site:github.com "type: service_account" "project_id" "private_key"

# Use ScoutSuite for full GCP security assessment:
pip install scoutsuite
scout gcp --report-dir ./gcp-report/

Universal Cloud Security Checklist

• Enable MFA on all accounts — especially root/administrator accounts which should use hardware keys
• Apply least privilege to IAM/RBAC — users and services get only the permissions they need to function, nothing more
• Enable CloudTrail/Activity Log/Cloud Audit Logs — every API call should be logged, with 90-day minimum retention
• Enable GuardDuty / Microsoft Defender for Cloud / Security Command Center — let the cloud provider’s own threat detection run
• No hardcoded credentials — use IAM roles for EC2, Managed Identities for Azure, Workload Identity for GCP
• Encrypt everything at rest and in transit — use provider-managed or customer-managed keys, enforce TLS 1.2+
• Regular access reviews — audit IAM users and roles quarterly, remove stale accounts and old API keys