Cloud Misconfigurations That Lead to Data Breaches (Multi-Cloud Analysis)

Introduction: The Silent Threat of Cloud Misconfigurations

Cloud infrastructure now underpins the majority of enterprise workloads. AWS, Microsoft Azure, and Google Cloud Platform collectively host everything from public marketing sites to regulated financial data, and most organizations run across more than one of them. That sprawl creates a governance problem: every storage bucket, IAM role, security group, API gateway, and managed database is a configuration decision, and each one can be set incorrectly.

Cloud misconfiguration is any setting, permission, or exposure that deviates from a secure baseline, whether through human error, insecure defaults, infrastructure-as-code drift, or incomplete hardening. It is not a software vulnerability in the traditional sense. There is no patch to apply. The flaw lives in how the environment was built and how it is maintained.

That distinction matters because misconfiguration has become the dominant root cause of cloud data breaches. Gartner has repeatedly estimated that through 2025, 99% of cloud security failures will be the customer’s fault, not the provider’s. IBM’s Cost of a Data Breach Report has consistently identified misconfigured cloud environments and compromised credentials as the two most common initial attack vectors, with breaches traced to misconfiguration carrying above-average detection and containment costs because the exposure often goes unnoticed for months.

The reason is structural. Under the shared responsibility model, AWS, Azure, and GCP secure the cloud itself - the physical facilities, hypervisors, and managed service internals. The customer secures what they put in the cloud: identity policies, network exposure, encryption settings, logging, and data classification. Providers ship permissive defaults because flexibility sells, and a storage bucket that blocks all public access by default still requires someone to configure access correctly for legitimate use. One checkbox left unchecked, one overly broad s3:GetObject policy, one security group rule opened to 0.0.0.0/0 for “testing,” and sensitive data is reachable from anywhere.

Multi-cloud adoption compounds the problem. Each provider uses different terminology, different policy languages, and different default behaviors. A team fluent in AWS IAM may misjudge Azure role assignments or GCP IAM bindings, and centralized visibility across all three is rare. Attackers exploit exactly this gap, using automated scanners that enumerate exposed storage, misconfigured APIs, and leaked keys across every major provider simultaneously.

This article examines how misconfigurations actually lead to breaches across AWS, Azure, and GCP. It covers real-world incidents, a side-by-side comparison of the misconfiguration classes most common in each platform, and a concrete remediation playbook covering preventive controls, continuous detection, and response when exposure is discovered.

Anatomy of a Misconfiguration Breach

Cloud misconfiguration breaches rarely begin with sophisticated exploitation. They begin with discovery. Attackers systematically enumerate cloud infrastructure for exposed resources, harvest credentials, escalate privileges within the environment, and exfiltrate data. Each phase maps directly to techniques in the MITRE ATT&CK Cloud Matrix, which catalogues adversary behavior specific to AWS, Azure, GCP, and SaaS platforms.

Phase 1: Exposed Resource Discovery

The initial reconnaissance phase targets publicly accessible cloud assets. Attackers use tools like Shodan, Censys, and CloudEnum to identify exposed storage buckets, misconfigured APIs, and open management interfaces.

# CloudEnum - enumerate public S3 buckets for a target organization
cloud_enum -k targetcompany -k target-company-backup

# Shodan query for exposed Kubernetes API servers
shodan search "k8s version" port:6443 country:US

# Shodan query for exposed Elasticsearch instances
shodan search "product:Elastic" port:9200

Common discovery targets include:

Resource Type	Misconfiguration	Discovery Method
S3/GCS/Azure Blob	Public read/write ACL	CloudEnum, Grayhat Warfare
Kubernetes API	Anonymous auth enabled	Shodan, masscan
Elasticsearch	No authentication	Shodan, ZoomEye
Docker API	Exposed on TCP 2375	Shodan, Nmap
CI/CD pipelines	Leaked secrets in logs	TruffleHog, GitLeaks
Metadata endpoints	SSRF-accessible IMDS	Manual probing

This maps to ATT&CK T1526 (Cloud Service Discovery) and T1530 (Data from Cloud Storage). A single publicly readable S3 bucket containing .env files or Terraform state can hand attackers everything they need for lateral movement.

Phase 2: Credential Theft

Once an exposed resource is identified, attackers pivot to credential extraction. Cloud environments leak credentials through multiple vectors:

• Instance Metadata Service (IMDS): SSRF vulnerabilities that reach 169.254.169.254 allow attackers to steal IAM role credentials. The 2019 Capital One breach exploited exactly this chain, where a misconfigured WAF allowed SSRF against EC2 metadata, yielding credentials with access to over 100 million customer records.
• Exposed environment files: .env, docker-compose.yml, and appsettings.json files committed to public repositories or left in web-accessible directories.
• CI/CD logs: Build pipelines that echo secrets, tokens, or connection strings into publicly visible logs.
• Terraform state files: Often stored in S3 buckets with overly permissive access, containing plaintext credentials for databases, APIs, and service accounts.

This phase corresponds to ATT&CK T1552.005 (Cloud Instance Metadata API) and T1552.001 (Credentials in Files).

Phase 3: Privilege Escalation

Stolen credentials rarely have the exact permissions an attacker needs. The next step is escalation within the cloud control plane. Common paths include:

• Overly permissive IAM roles: A role with iam:PassRole and lambda:CreateFunction allows an attacker to create a Lambda function that assumes a more privileged role.
• Service account key abuse (GCP): Default compute service accounts with Editor-level permissions across the project.
• Managed identity exploitation (Azure): Assigning a managed identity to a compromised VM or automation account.
• Cross-account trust abuse: Misconfigured trust relationships that allow assumption of roles in other accounts.

# AWS - enumerate current permissions after credential theft
aws sts get-caller-identity
aws iam list-attached-user-policies --user-name compromised-user
aws iam list-roles | jq '.Roles[] | select(.AssumeRolePolicyDocument)'

This maps to ATT&CK T1078.004 (Valid Accounts: Cloud Accounts) and T1548 (Abuse Elevation Control Mechanism).

Phase 4: Data Exfiltration

With elevated privileges, attackers exfiltrate data using native cloud APIs, which blend into normal traffic patterns. Techniques include:

• Snapshot and share: Creating EBS snapshots or RDS snapshots and sharing them with an attacker-controlled account.
• Storage sync: Using aws s3 sync or gsutil rsync to copy entire buckets.
• Database dumps: Connecting directly to exposed RDS or Cosmos DB instances and extracting records.
• DNS exfiltration: Encoding data in DNS queries when direct egress is blocked.

This phase corresponds to ATT&CK T1537 (Transfer Data to Cloud Account) and T1567 (Exfiltration Over Web Service).

The throughline across all four phases is that a single misconfigured setting - a public bucket ACL, an unauthenticated API, an overprivileged role - provides the initial foothold. From there, the attack chain unfolds using legitimate cloud APIs that generate minimal anomalous telemetry. Detection requires correlating identity, network, and audit log data across the entire multi-cloud estate.

Case Studies: Real-World Breaches from Cloud Misconfigurations

The following breaches share a common thread: each began with a configuration decision that appeared harmless at deployment time. The exploitation paths differ, but the root causes cluster around a small set of recurring mistakes - public storage ACLs, over-permissive IAM roles, and credentials committed to code repositories.

Capital One (2019): SSRF, an Over-Privileged IAM Role, and S3

The Capital One breach remains the canonical example of how multiple small misconfigurations chain into a catastrophic exposure.

What was misconfigured:

• A WAF (ModSecurity on AWS) was left with a configuration vulnerable to SSRF vulnerabilities, allowing an attacker to make the WAF issue requests to the EC2 instance metadata service (IMDSv1).
• The IAM role attached to that EC2 instance carried s3:ListBucket and s3:GetObject permissions across a broad set of S3 buckets, far beyond what the WAF needed.
• IMDSv1 was enabled, meaning no session token was required to retrieve temporary credentials.

How it was exploited:

# Attacker sends a crafted request to the WAF, which fetches:
http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

# Response returns temporary AWS credentials:
{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "2019-07-17T..."
}

With those credentials, the attacker enumerated S3 buckets using the AWS CLI, identified writable and readable targets, and exfiltrated approximately 100 million credit applications. The data included names, addresses, credit scores, and in some cases Social Security numbers.

Timeline: The intrusion occurred in March 2019. Capital One detected anomalous activity in July 2019 after a tip from a responsible disclosure, and the FBI arrested the suspect shortly after.

Root cause: Excessive IAM permissions combined with an SSRF-vulnerable component and IMDSv1. Any one of these controls would have broken the chain.

Lessons learned:

• Enforce IMDSv2 (HttpTokens: required) to defeat credential theft via SSRF.
• Apply least privilege to instance roles. A WAF has no business reading customer data buckets.
• Monitor for GetObject calls originating from unexpected source roles.

Accenture (2017): Four Publicly Writable S3 Buckets

What was misconfigured: Four S3 buckets containing internal Accenture data were configured with public read and, in some cases, public write access. The buckets held credentials, API keys, internal authentication tokens, and customer configuration data.

How it was exploited: UpGuard researchers discovered the buckets through routine internet scanning and demonstrated that they could both read and overwrite contents. No sophisticated exploitation was required - the buckets were simply world-accessible.

Impact: Accenture remediated the exposure before any confirmed malicious access, but the data included secrets that would have enabled lateral movement into production systems.

Root cause: Bucket ACLs set to public-read or public-read-write, likely inherited from a misconfigured deployment script or a manual change that was never audited.

Lessons learned:

• Block Public Access at the account level, not per bucket.
• Rotate any credentials that were ever stored in a publicly accessible bucket, regardless of whether exfiltration is confirmed.

Verizon (2017): Third-Party S3 Exposure

What was misconfigured: A Verizon partner, Nice Systems, stored customer data on an S3 bucket configured for public access. The bucket was managed by the vendor, not Verizon directly.

How it was exploited: UpGuard discovered the bucket via scanning and found approximately 14 million Verizon customer records, including account PINs and partial phone numbers. The data was used by Nice Systems to support Verizon’s customer service operations.

Impact: Exposure of PII and authentication-adjacent data (PINs) at scale. Verizon publicly downplayed the severity, but the PINs alone could facilitate SIM-swap attacks.

Root cause: Vendor-managed storage with no contractual security controls and no visibility from the data owner.

Lessons learned:

• Third-party data processors inherit your risk. Contractual security requirements must include storage configuration standards.
• Maintain an inventory of where your data physically resides, including vendor infrastructure.

Pegasus Airlines (2022): Azure Blob Storage Without Authentication

What was misconfigured: An Azure Blob Storage container holding flight crew and operational data was configured to allow anonymous public access. The container held approximately 6.5 TB of data, including sensitive flight documents, crew PII, and in some cases source code for onboard systems.

How it was exploited: Security researchers identified the container through internet-wide scanning for publicly accessible Azure Blob endpoints. Anonymous access required no credentials.

Impact: Exposure of crew personal data, internal documents, and potentially aircraft software artifacts. The breach illustrated that Azure’s default container access model is not inherently safe - the misconfiguration was explicitly set.

Root cause: Container access level set to Container (anonymous read) rather than Private, likely to simplify an internal workflow.

Lessons learned:

• Audit Azure storage accounts for AllowBlobPublicAccess: true at the account level.
• Use Azure Policy to deny public blob access across subscriptions.
• Treat storage account keys as root credentials; scope access through SAS tokens or managed identities.

Facebook (2019): Public S3 Buckets with User Data

What was misconfigured: Facebook’s third-party app integration infrastructure stored user data in S3 buckets that were publicly readable. The buckets contained hundreds of millions of user records, including names, phone numbers, and Facebook IDs.

How it was exploited: Researchers at UpGuard identified the buckets through scanning and confirmed public read access. Facebook’s response characterized the data as already available through other means, but the exposure was real.

Impact: Hundreds of millions of records exposed. Facebook faced regulatory scrutiny and reputational damage, though the company argued the data was not sensitive in the traditional sense.

Root cause: Bucket ACLs set to public, likely as a side effect of an integration pipeline that assumed internal-only access.

Lessons learned:

• The scale of exposure from a single misconfigured bucket can dwarf traditional breach vectors.
• Automated scanning for public buckets is trivial; assume any public bucket will be found within hours.

Uber (2016): AWS Keys in a Public GitHub Repository

What was misconfigured: Uber engineers committed AWS access keys to a private GitHub repository. The repository was later made public, or the keys were otherwise exposed, allowing attackers to access Uber’s AWS infrastructure.

How it was exploited: Attackers used the exposed keys to access an S3 bucket containing driver and rider data. The breach affected approximately 57 million users and 600,000 drivers.

Impact: Uber paid a $148 million settlement across all 50 US states and faced criminal charges against its former CSO for attempting to conceal the breach.

Root cause: Long-lived AWS access keys stored in source code, combined with a repository that was not scanned for secrets.

Lessons learned:

• Never commit credentials to source control. Use IAM roles, instance profiles, or short-lived tokens.
• Enable secret scanning on all repositories, including private ones.
• Rotate any key that has ever been committed, even if the repository was later deleted.

Pattern Summary

Breach	Cloud	Misconfiguration	Attack Vector	Approx. Impact
Capital One	AWS	SSRF + over-permissive IAM + IMDSv1	Credential theft via metadata service	100M records
Accenture	AWS	Public read/write S3 buckets	Internet scanning	Internal credentials
Verizon (via Nice)	AWS	Public S3 bucket (vendor-managed)	Internet scanning	14M records
Pegasus Airlines	Azure	Anonymous Blob container access	Internet scanning	6.5 TB
Facebook	AWS	Public S3 buckets	Internet scanning	Hundreds of millions
Uber	AWS	AWS keys in GitHub	Credential reuse	57M users, 600K drivers

The recurring lesson across all six cases: the breach did not require zero-days or sophisticated tradecraft. It required only that a configuration default was left in place, a permission was granted too broadly, or a credential was stored where it should not have been. For organizations tracking similar incidents, latest breach reports and threat intelligence provide ongoing visibility into how these patterns continue to appear in the wild.

AWS: Common Misconfigurations and Default Settings

AWS operates on a shared responsibility model: AWS secures the cloud itself, while customers secure everything they put in it. Most AWS breaches trace back to customer-side configuration errors, and the platform’s defaults often favor flexibility over safety.

S3 Bucket ACLs and Policies

Amazon S3 remains the single most exploited AWS service in public breach reporting. The dangerous pattern is a bucket policy containing a wildcard principal with no condition constraints:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::example-bucket/*"
  }]
}

This grants anonymous read access to every object. Older buckets may also carry legacy ACLs like public-read set at the object level, which persist even after the bucket-level policy is tightened. S3 Block Public Access (BPA) exists precisely to override these settings, but it is enabled by default only on buckets created after April 2023. Buckets created earlier require manual activation, and many organizations never audited them. A related issue is the s3:ListBucket permission left open, which allows attackers to enumerate object names before downloading them, turning a single leaked filename into a full data dump.

IAM Roles and Over-Permissive Policies

IAM misconfigurations typically fall into three buckets: wildcard actions, wildcard resources, and overly broad trust relationships.

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

This policy, attached to a service role or an EC2 instance profile, grants full account access. Attackers who compromise the instance via SSRF or a vulnerable application inherit every permission. Trust policies are equally dangerous: a role that trusts arn:aws:iam::*:root allows any AWS account to assume it if the attacker knows the role ARN. Cross-account confused deputy issues, missing ExternalId conditions, and long-lived access keys that never rotate compound the problem. AWS now defaults new IAM users to no permissions, but the console’s policy generator and managed policies like AdministratorAccess make it trivial to over-provision.

Security Groups and Network Exposure

A security group rule with 0.0.0.0/0 on port 22 or 3389 exposes SSH or RDP to the entire internet. The same applies to database ports (3306, 5432, 1433, 27017), management interfaces, and internal APIs that were never meant to be public. AWS creates a default security group per VPC that allows all inbound traffic from other members of the group and all outbound traffic. When users launch instances without specifying a security group, they often land in this default, which can inadvertently permit lateral movement between unrelated workloads.

RDS Public Accessibility and EBS Snapshots

RDS instances have a PubliclyAccessible flag that defaults to false for instances launched in a VPC, but the console wizard has historically made it easy to flip. A publicly accessible RDS instance with a weak or reused password is a direct path to data exfiltration. Separately, EBS snapshots can be shared with all AWS accounts by setting group=all on the snapshot’s createVolumePermission. Attackers and researchers routinely scan for these snapshots, mount them, and read whatever filesystem data remains, including credentials, database files, and application secrets.

Lambda Environment Variables and CloudTrail Gaps

Lambda environment variables are stored in plaintext by default. Anyone with lambda:GetFunctionConfiguration can read them, which means API keys, database passwords, and tokens end up exposed to any principal with read access to the function. The fix is KMS encryption with a customer-managed key, but it is opt-in.

CloudTrail is enabled by default for management events in each region, but only for the first copy in an account, and only for 90 days of event history. Organizations that need multi-region trails, data event logging for S3 and Lambda, or log file integrity validation must configure these explicitly. Attackers who gain credentials frequently disable or delete trails before exfiltrating data, so CloudTrail log file validation and a separate log archive account are essential.

Defaults vs. Misconfigurations

Resource	AWS Default	Common Misconfiguration
S3 bucket	Private, BPA on (new buckets)	Public ACL or wildcard policy
IAM user	No permissions	AdministratorAccess attached
Security group	Deny inbound, allow outbound	0.0.0.0/0 on 22/3389/DB ports
RDS	Not publicly accessible	PubliclyAccessible=true
EBS snapshot	Private	Shared with group=all
Lambda env vars	Plaintext	Secrets stored unencrypted
CloudTrail	Single-region, management events	Disabled or deleted by attacker

Tooling for Detection

Prowler runs hundreds of CIS, HIPAA, and PCI checks against an AWS account and flags public buckets, open security groups, and IAM wildcards. ScoutSuite performs multi-cloud posture assessment and produces an HTML report mapping findings to risk. AWS Config provides continuous compliance evaluation through managed and custom rules, with auto-remediation via SSM Automation. Running Prowler or ScoutSuite on a schedule, paired with AWS Config rules for the highest-risk controls, catches most of the misconfigurations described above before an attacker does. For related exposure patterns across providers, see Privilege Escalation vulnerabilities and SSRF vulnerabilities, both of which are common pivots from a misconfigured AWS workload.

Azure: Common Misconfigurations and Default Settings

Azure’s defaults are, in most cases, secure. The breaches come from operators who flip the wrong switch or inherit permissive settings from legacy deployments. The following covers the misconfigurations that recur most often in Azure incident response.

Blob Storage Public Access

Azure Storage accounts have a hierarchical access model: the account-level Allow Blob Public Access setting, the container-level Public Access Level, and the blob-level ACL. All three must permit anonymous access for a blob to be publicly reachable, but operators frequently enable all three without realizing the combined effect.

Container access levels:

Level	Behavior
Private (default)	No anonymous access; requires auth
Blob	Anonymous read of individual blobs if URL known
Container	Anonymous list and read of all blobs in container

A container set to Container access means the entire listing is enumerable. Attackers brute-force storage account names (<orgname>storage, <orgname>prod, <orgname>backups) and then list containers. Common exposures include database backups, Terraform state files, customer exports, and application logs containing credentials.

The allowBlobPublicAccess property at the account level is true by default on storage accounts created before 2023. Microsoft changed the default to false for new accounts, but existing accounts retain the permissive setting. Audit with:

az storage account list --query "[?allowBlobPublicAccess==\`true\`].{Name:name,RG:resourceGroup}" -o table

MicroBurst’s Invoke-EnumerateAzureBlobs and Azucar automate discovery of publicly accessible storage across a tenant or subscription.

Network Security Group Rules

NSGs default to allowing outbound traffic and denying inbound from the internet, except for the implicit AllowVnetInBound and AllowAzureLoadBalancerInBound rules. Misconfigurations arise when operators add broad inbound rules for troubleshooting and never remove them.

High-risk patterns:

• 0.0.0.0/0 on port 22 (SSH) or 3389 (RDP), often with a name like temp-allow-rdp or dev-access
• Any protocol with Any port on Internet source
• NSG attached to subnet instead of NIC, applying to all workloads in the subnet
• Priority conflicts where a permissive rule (priority 100) shadows a restrictive one (priority 200)

Azure Security Center (now Microsoft Defender for Cloud) flags these as “Management ports should be closed” and “Internet-facing virtual machines should be protected with network security groups.” Teams that disable the recommendations or ignore them accumulate exposed management planes. RDP exposure remains a top ransomware entry vector, with groups scanning Azure IP ranges for port 3389 within minutes of allocation.

Azure AD Misconfigurations

Azure AD (now Microsoft Entra ID) ships with sensible defaults that operators routinely weaken:

• Guest user permissions: The default Guest invite restrictions allow any member to invite guests. Combined with Guest user access set to “Same as member users,” guests can enumerate the directory, read group memberships, and access applications. The tighter default restricts guests to their own directory objects.
• Overly permissive roles: Assigning Global Administrator for routine tasks, or Application Administrator to service principals that only need directory read. Privileged Identity Management (PIM) is available but often not enforced.
• Consent framework: When Users can consent to apps is enabled (the legacy default), any user can grant an OAuth application access to their mailbox, files, and directory profile. Malicious consent grants are a common persistence technique.
• Conditional Access gaps: No policy enforcing MFA for administrative roles, or exclusions for “break glass” accounts that accumulate over time.

MicroBurst and ROADtools enumerate these weaknesses from an authenticated context, and tools like AADInternals demonstrate consent abuse and token manipulation.

Key Vault Access Policies vs. RBAC

Key Vault historically used access policies - per-principal grants on the vault itself. The default policy grants nothing, but operators often add Get, List, and Backup to broad groups or service principals to “make things work.” A service principal with Get on secrets can read every secret in the vault, not just the one the application needs.

The RBAC model (Azure role-based access control) is finer-grained: Key Vault Secrets User grants read, Key Vault Secrets Officer grants write, and scopes can be limited to individual secrets. Vaults still on access policies frequently have over-broad grants that predate the RBAC model.

Also check soft delete and purge protection. Without purge protection, an attacker with delete rights can destroy secrets permanently. Without soft delete, recovery is impossible.

App Service Authentication

App Service can enforce authentication at the platform layer via Easy Auth (App Service Authentication). When disabled, authentication is the application’s responsibility - and often absent on internal APIs, admin endpoints, or staging slots.

Common findings:

• Staging slots with *.azurewebsites.net hostnames that bypass the production WAF and front door
• clientCertMode set to Ignore when mutual TLS is expected
• Managed identity disabled in favor of connection strings or service principal secrets stored in app settings - which are visible to anyone with Website Contributor or Reader on the resource
• CORS set to * on APIs that return authenticated data

Managed Identities

Managed identities eliminate stored credentials by giving Azure resources an identity in Entra ID. The misconfiguration is not the identity itself but its role assignments: a VM’s system-assigned identity granted Contributor at the subscription scope, or a function app’s identity with Storage Blob Data Owner on every storage account in the tenant. Any code execution on that resource inherits the full role.

Audit with:

az role assignment list --assignee <principal-id> --all -o table

Look for Contributor, Owner, and User Access Administrator at subscription or management group scope, and for identities attached to internet-facing compute.

Tooling Summary

Tool	Purpose
Microsoft Defender for Cloud	Native posture management, misconfiguration findings
Azucar	Azure security audit, storage and NSG enumeration
MicroBurst	Blob enumeration, Azure AD recon, credential hunting
ROADtools	Entra ID enumeration and token analysis
ScoutSuite	Multi-cloud posture scanning including Azure

The pattern across all of these is consistent: Azure defaults are reasonable, exposure comes from operator convenience - temporary rules, broad role assignments, and public access enabled for a one-time transfer that was never reverted.

GCP: Common Misconfigurations and Default Settings

Google Cloud’s project-based resource hierarchy creates a distinct misconfiguration profile from AWS and Azure. Where AWS centers on account-level IAM and S3 policies, and Azure on subscription-scoped RBAC and storage account settings, GCP’s most damaging exposures cluster around IAM bindings at the project level, Cloud Storage bucket ACLs, and firewall rules that default to permissive ingress within a VPC.

Cloud Storage Bucket Permissions

GCS buckets are private by default. The exposure almost always comes from someone adding allUsers or allAuthenticatedUsers to the bucket’s IAM policy. allUsers grants access to anyone on the internet, including unauthenticated requests. allAuthenticatedUsers grants access to anyone with a Google account, which in practice is the same as public for any non-sensitive data.

# Find publicly accessible buckets across all projects
gsutil ls -p PROJECT_ID | while read bucket; do
  gsutil iam get "$bucket" 2>/dev/null | grep -E "allUsers|allAuthenticatedUsers" && echo "PUBLIC: $bucket"
done

The most common causes are developers running gsutil iam ch allUsers:objectViewer gs://bucket to unblock a demo, or Terraform templates that set uniform_bucket_level_access incorrectly. The Bucket Policy Only (now Uniform Bucket-Level Access) setting, when enabled, disables object ACLs entirely and forces all access decisions through IAM. Buckets without it enabled can have per-object ACLs that grant public read on a single file even when the bucket-level policy looks clean.

Firewall Rules

GCP’s default network includes permissive firewall rules that catch teams off guard. The default VPC network ships with default-allow-internal (allows all traffic between instances on the network), default-allow-ssh (port 22 from 0.0.0.0/0), default-allow-rdp (port 3389 from 0.0.0.0/0), and default-allow-icmp. These rules apply to instances tagged default, which the default network assigns automatically.

Rule	Default Source	Default Ports	Risk
default-allow-internal	10.128.0.0/9	all	Lateral movement
default-allow-ssh	0.0.0.0/0	22	Brute force, key theft
default-allow-rdp	0.0.0.0/0	3389	RDP exploitation
default-allow-icmp	0.0.0.0/0	ICMP	Reconnaissance

Custom VPCs have no default rules, but teams frequently recreate the same permissive patterns when adding rules manually. Ingress rules with source 0.0.0.0/0 on management ports are the leading cause of GCP instance compromise. GCP’s Firewall Rules Logging is off by default and must be enabled per-rule.

Primitive IAM Roles

GCP’s primitive roles - Owner, Editor, Viewer - predate the granular predefined and custom roles. They are project-wide and grant sweeping permissions. Editor in particular grants write access to nearly every service in the project, including the ability to modify IAM policies on many resources, deploy Cloud Functions, and read most data.

The dangerous pattern is granting Editor to service accounts for convenience. A compromised VM running with an Editor service account gives an attacker project-wide write access. Predefined roles like roles/storage.objectViewer or roles/bigquery.dataViewer should replace primitive roles in almost every case. The roles/iam.serviceAccountTokenCreator role is a separate escalation vector: a principal with it can mint tokens for any service account it can access, effectively impersonating that account.

Service Account Key Management

Service account keys are long-lived credentials in JSON format. GCP allows up to 10 keys per service account, and keys never expire unless an administrator sets an expiration. Leaked keys in Git repositories, CI logs, or container images are a recurring breach vector. Google’s own guidance discourages key creation in favor of Workload Identity Federation, Workload Identity for GKE, and short-lived tokens via gcloud auth print-access-token.

# List all user-managed keys with age
gcloud iam service-accounts keys list \
  --iam-account=SA_EMAIL \
  --managed-by=user \
  --format="table(name,validAfterTime,validBeforeTime)"

Keys older than 90 days with no rotation policy warrant investigation. The iam.disableServiceAccountKeyCreation organization policy constraint blocks new key creation entirely.

Cloud SQL Public IP and VPC Peering

Cloud SQL instances default to no public IP when created via the console with the “Private IP” option, but the CLI and API default to public IP unless --no-assign-ip is specified. Public IP instances are reachable from the internet if authorized networks include 0.0.0.0/0, and the database is exposed to credential-stuffing attacks. Authorized networks should be scoped to specific CIDRs or replaced with the Cloud SQL Auth Proxy and private IP.

VPC Network Peering connects two VPCs and exchanges routes. Misconfigurations arise when peering is established with projects outside the organization, or when export custom routes and import custom routes are enabled without intent, leaking internal subnet ranges to a peered network. Peered VPCs also bypass firewall rules in some configurations, so a permissive peered network can reach services the local firewall was meant to protect.

Tooling

• Forseti Security (now largely superseded by SCC) provided scanner, inventory, and policy enforcement modules for GCP.
• GCP Scanner by Google enumerates resources and IAM bindings across a project.
• ScoutSuite produces a multi-cloud report with GCP-specific findings on buckets, firewall rules, and IAM.
• Security Command Center (SCC) Premium and Enterprise tiers include built-in detectors for public buckets, open firewalls, and primitive role grants.

For related exposure patterns, see Authentication Bypass vulnerabilities and Privilege Escalation vulnerabilities.

Multi-Cloud Comparison: Default Settings vs. Common Misconfigurations

The three major providers ship with different baseline postures. AWS tends toward permissive service defaults with guardrails bolted on later, Azure inherits much of its identity model from Active Directory and defaults to tenant-wide consent flows, and GCP defaults to a flat project hierarchy where IAM inheritance is the primary control. Understanding where each provider’s defaults diverge is what separates a hardened deployment from a breach waiting to happen.

Cross-Provider Misconfiguration Matrix

Service	Default Setting	Common Misconfiguration	Risk Level
Object Storage (S3 / Blob / GCS)	Private since AWS 2023 Block Public Access default; Azure Blob public access disabled by default at account level; GCS uniform bucket-level access off by default	Legacy buckets created pre-2023 remain public; ACLs granted at object level bypass account-level blocks; allUsers binding on GCS	Critical
IAM (IAM / Entra ID / Cloud IAM)	AWS root has full access; Azure Global Admin separate from subscription Owner; GCP primitive roles (Owner, Editor) available	Wildcard Action: "*" policies; over-scoped service principals; GCP Editor on service accounts; long-lived access keys	Critical
Network (VPC / VNet / VPC)	Default VPC auto-created with permissive routes; Azure NSG default allows intra-VNet; GCP default firewall allows SSH/RDP from 0.0.0.0/0	Open security groups on 0.0.0.0/0; unrestricted egress; peering without segmentation	High
Logging (CloudTrail / Activity Log / Cloud Audit Logs)	CloudTrail off by default; Azure Activity Log on but 90-day retention; GCP Admin Activity logs on, Data Access logs off	S3 data events disabled; Azure diagnostic settings not forwarded to Log Analytics; GCP Data Access logs never enabled	High
Databases (RDS / Azure SQL / Cloud SQL)	Public access disabled, but encryption-at-rest uses provider-managed keys; snapshots inherit source config	Publicly accessible endpoints enabled “temporarily”; unencrypted snapshots shared cross-account; default sa/postgres credentials	Critical
Secrets (Secrets Manager / Key Vault / Secret Manager)	Encryption on, but no automatic rotation; Key Vault soft-delete on, purge protection off	Hardcoded credentials in Lambda env vars or App Service settings; no rotation policy; secrets in Terraform state	High
Serverless (Lambda / Functions / Cloud Functions)	Execution role required; function URLs disabled; HTTP triggers require explicit config	Over-privileged execution roles; unauthenticated function URLs; env vars holding DB credentials	High

Why Defaults Are Not Synonymous With Secure

A default is a starting point, not a control. AWS S3 buckets created after April 2023 ship with Block Public Access enabled and ACLs disabled, but the hundreds of thousands of buckets created before that date retain their original ACL posture. Security teams auditing only newly provisioned infrastructure will miss the legacy estate entirely. The same pattern applies to GCP’s default firewall rules, which permit SSH and RDP from any source until explicitly removed, and to Azure’s default AllowVNetInBound NSG rule, which trusts everything inside the virtual network.

Why Misconfigurations Are Easy to Make

Three structural factors drive cross-cloud misconfiguration:

1. Console defaults favor usability over least privilege. The path of least resistance when provisioning a resource is to accept the wizard’s defaults, which are tuned for “it works” rather than “it is locked down.”
2. Inheritance is invisible. GCP IAM bindings at the organization or folder level cascade silently into every project. Azure management group assignments propagate to subscriptions. Engineers troubleshooting a permission error rarely trace the entire inheritance chain.
3. IaC drift. Terraform and CloudFormation templates capture the intended state, but console changes, emergency hotfixes, and third-party integrations mutate live resources. Without continuous drift detection, the deployed posture diverges from the reviewed code.

Cross-provider tooling such as ScoutSuite, Prowler, and Steampipe maps these defaults against CIS benchmarks and surfaces the gaps, but the underlying lesson is consistent: assume every default is permissive until a control proves otherwise.

Step-by-Step Remediation Guide

Remediation follows a consistent three-phase loop regardless of cloud provider: detect the misconfigured resource, remediate it with the narrowest change that resolves exposure, then verify the fix and confirm nothing dependent broke. The commands below assume authenticated CLI sessions with sufficient privileges (s3:PutBucketPublicAccessBlock, Microsoft.Storage/storageAccounts/write, storage.buckets.setIamPolicy, and equivalents).

Storage Remediation

AWS S3

Detect publicly accessible buckets using the account-level public access block status and per-bucket ACLs:

aws s3control get-public-access-block --account-id 123456789012

aws s3api list-buckets --query "Buckets[].Name" --output text | \
  xargs -I{} sh -c 'echo "{}"; aws s3api get-public-access-block --bucket {} 2>/dev/null || echo "NO PAB"'

For a faster account-wide sweep, use aws s3api get-bucket-policy-status to identify buckets with public policies:

aws s3api get-bucket-policy-status --bucket my-bucket
# Look for "IsPublic": true

Remediate by applying the account-level public access block, which overrides bucket-level settings and blocks future public ACLs and policies:

aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
  "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

For individual buckets with legitimate public hosting needs (static sites), scope the exception instead of disabling the block. Enable server-side encryption by default and enforce TLS-only access via bucket policy:

aws s3api put-bucket-encryption --bucket my-bucket \
  --server-side-encryption-configuration \
  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"},"BucketKeyEnabled":true}]}'

Verify with AWS Config rule s3-bucket-public-read-prohibited or by re-running get-public-access-block and confirming all four flags are true. Attempt an unauthenticated curl against a known object URL and confirm a 403.

Azure Blob Storage

Detect containers with anonymous access:

az storage account list --query "[].{Name:name,RG:resourceGroup}" -o table

az storage container list \
  --account-name mystorageacct \
  --auth-mode login \
  --query "[?properties.publicAccess!='None'].{Name:name,Access:properties.publicAccess}" -o table

Remediate by setting public access to None and disabling anonymous access at the account level, which prevents future containers from being made public:

az storage container set-permission \
  --name mycontainer \
  --account-name mystorageacct \
  --public-access off \
  --auth-mode login

az storage account update \
  --name mystorageacct \
  --resource-group myRG \
  --allow-blob-public-access false

Enforce minimum TLS 1.2 and require secure transfer:

az storage account update \
  --name mystorageacct \
  --resource-group myRG \
  --min-tls-version TLS1_2 \
  --https-only true

Verify by re-listing containers and confirming publicAccess is None, then testing anonymous read against a blob URL. Azure Policy definition Storage accounts should prevent anonymous container access provides continuous enforcement.

GCP Cloud Storage

Detect buckets granting allUsers or allAuthenticatedUsers:

gcloud storage buckets list --format="value(name)" | while read b; do
  gcloud storage buckets get-iam-policy "gs://$b" \
    --format=json | grep -E "allUsers|allAuthenticatedUsers" && echo "PUBLIC: $b"
done

Remediate by removing the public binding and enabling uniform bucket-level access, which disables legacy object ACLs that often reintroduce exposure:

gcloud storage buckets remove-iam-policy-binding gs://my-bucket \
  --member=allUsers --role=roles/storage.objectViewer

gcloud storage buckets update gs://my-bucket --uniform-bucket-level-access

Enable default encryption with a customer-managed key where compliance requires it:

gcloud storage buckets update gs://my-bucket \
  --default-encryption-key=projects/my-project/locations/global/keyRings/kr/cryptoKeys/key

Verify with gcloud storage buckets get-iam-policy and confirm no allUsers binding remains. Org Policy constraint storage.publicAccessPrevention blocks future public grants at the project or folder level.

IAM Remediation

AWS

Detect overly permissive policies and unused credentials using IAM Access Analyzer and the credential report:

aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/my-analyzer

aws iam generate-credential-report && \
  aws iam get-credential-report --query Content --output text | base64 -d > creds.csv

Remediate wildcard actions by scoping to specific resources. Replace "Action": "*", "Resource": "*" with least-privilege statements, and enforce MFA on privileged roles via trust policy conditions:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
  "Action": "sts:AssumeRole",
  "Condition": {
    "Bool": {"aws:MultiFactorAuthPresent": "true"},
    "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"}
  }
}

Verify by re-running Access Analyzer and confirming no isPublic or hasWildcard findings remain for the updated policies.

Azure

Detect role assignments with Owner or Contributor at subscription scope:

az role assignment list --scope /subscriptions/<sub-id> \
  --query "[?roleDefinitionName=='Owner' || roleDefinitionName=='Contributor'].{Principal:principalName,Role:roleDefinitionName,Scope:scope}" -o table

Remediate by replacing broad assignments with scoped roles and enabling PIM (Privileged Identity Management) for just-in-time elevation. Remove standing assignments:

az role assignment delete --assignee [email protected] \
  --role "Contributor" --scope /subscriptions/<sub-id>

Verify with az role assignment list and confirm only intended principals hold elevated roles, ideally as eligible rather than active PIM assignments.

GCP

Detect primitive roles (roles/owner, roles/editor) and public bindings:

gcloud projects get-iam-policy my-project \
  --flatten="bindings[].members" \
  --format="table(bindings.role,bindings.members)" \
  --filter="bindings.role:roles/owner OR bindings.role:roles/editor"

Remediate by replacing primitive roles with predefined or custom roles:

gcloud projects remove-iam-policy-binding my-project \
  --member=user:[email protected] --role=roles/editor

gcloud projects add-iam-policy-binding my-project \
  --member=user:[email protected] --role=roles/storage.objectViewer

Verify by re-running the policy query. Service account keys should be rotated or eliminated in favor of Workload Identity Federation.

Network Remediation

AWS

Detect security groups allowing 0.0.0.0/0 on sensitive ports:

aws ec2 describe-security-groups \
  --filters Name=ip-permission.cidr,Values='0.0.0.0/0' \
  --query "SecurityGroups[?IpPermissions[?FromPort<='22' && ToPort>='22']].{ID:GroupId,Name:GroupName}" -o table

Remediate by revoking the offending rule and replacing it with a scoped CIDR or security group reference:

aws ec2 revoke-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 22 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 22 --cidr 203.0.113.0/24

Verify by re-running the describe command and confirming zero matches. AWS Config rule restricted-ssh provides continuous detection.

Azure

Detect NSG rules with Internet source on management ports:

az network nsg list --query "[].{Name:name,RG:resourceGroup}" -o table
az network nsg rule list --nsg-name myNSG --resource-group myRG \
  --query "[?sourceAddressPrefix=='Internet' || sourceAddressPrefix=='*'].{Name:name,Port:destinationPortRange}" -o table

Remediate by narrowing source prefixes to specific IP ranges and using service tags like VirtualNetwork or AzureBastion:

az network nsg rule update \
  --nsg-name myNSG --resource-group myRG \
  --name AllowSSH --source-address-prefixes 203.0.113.0/24

Verify with az network nsg rule show and confirm the source prefix is no longer Internet or *.

GCP

Detect firewall rules open to 0.0.0.0/0:

gcloud compute firewall-rules list \
  --filter="sourceRanges:0.0.0.0/0" \
  --format="table(name,allowed[].map().firewall_rule().list(),network)"

Remediate by updating source ranges or disabling the rule:

gcloud compute firewall-rules update allow-ssh \
  --source-ranges=203.0.113.0/24

Verify by re-running the filtered list. For bastion-free access, replace open SSH with Identity-Aware Proxy:

gcloud compute firewall-rules create allow-iap-ssh \
  --direction=INGRESS --action=ALLOW --rules=tcp:22 \
  --source-ranges=35.235.240.0/20 --target-tags=iap-ssh

Logging Remediation

Logging gaps are the quietest failure mode: breaches go undetected for months because the audit trail was never enabled or was silently deleted.

AWS

Detect buckets without access logging and trails that are not multi-region:

aws cloudtrail describe-trails --query "trailList[].{Name:Name,MultiRegion:IsMultiRegionTrail,Logging:HasCustomEventSelectors}"
aws s3api get-bucket-logging --bucket my-bucket

Remediate by enabling CloudTrail with log file validation and Object Lock on the destination bucket:

aws cloudtrail create-trail --name org-trail \
  --s3-bucket-name audit-logs-bucket --is-multi-region-trail \
  --enable-log-file-validation
aws cloudtrail start-logging --name org-trail

Verify with aws cloudtrail get-trail-status --name org-trail and confirm IsLogging: true.

Azure

Detect storage accounts and key vaults without diagnostic settings:

az monitor diagnostic-settings list \
  --resource /subscriptions/<sub>/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorageacct

Remediate by routing logs to a Log Analytics workspace or immutable storage:

az monitor diagnostic-settings create \
  --name audit-logs \
  --resource /subscriptions/<sub>/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorageacct \
  --workspace /subscriptions/<sub>/resourceGroups/myRG/providers/Microsoft.OperationalInsights/workspaces/myWorkspace \
  --logs '[{"category":"StorageRead","enabled":true},{"category":"StorageWrite","enabled":true}]'

Verify with az monitor diagnostic-settings list and confirm the settings are present and enabled: true.

GCP

Detect projects without a log sink or with default retention:

gcloud logging sinks list
gcloud logging buckets list --location=global

Remediate by creating a sink to a locked bucket with extended retention:

gcloud logging buckets update _Default --location=global --retention-days=365
gcloud logging sinks create audit-sink \
  storage.googleapis.com/audit-logs-bucket \
  --log-filter='logName:"cloudaudit.googleapis.com"'

Verify with gcloud logging sinks describe audit-sink and confirm the destination and writer identity are correct.

Preventative Controls

Manual remediation does not scale. Enforce these guardrails:

Control	Tool	Purpose
IaC scanning	Checkov, tfsec, KICS	Block misconfigured resources before `

Prevention Best Practices for Multi-Cloud Security

Remediation fixes today’s exposure. Prevention stops tomorrow’s. The following practices apply across AWS, Azure, and GCP, and they compound: each one reduces the blast radius of the others.

Continuous Monitoring with CSPM and CIEM

Cloud Security Posture Management (CSPM) tools continuously scan configurations against benchmarks like CIS, SOC 2, and PCI DSS, flagging drift the moment it occurs. Cloud Infrastructure Entitlement Management (CIEM) complements CSPM by analyzing identity permissions and surfacing excessive or unused access. Together they answer two questions: “Is my infrastructure configured safely?” and “Who can reach it?”

Native options cover most needs:

Provider	Posture Tool	Entitlement Analysis
AWS	AWS Security Hub (with Config and GuardDuty)	IAM Access Analyzer
Azure	Microsoft Defender for Cloud	Entra ID Permissions Management
GCP	Security Command Center (Premium)	IAM Recommender

Aggregate findings from all three into a single SIEM or ticketing pipeline. A misconfiguration that only appears in one console is a misconfiguration nobody owns.

Least Privilege as an Operating Discipline

Least privilege is not a one-time configuration. Enforce it with:

• Just-in-time (JIT) access for privileged roles, granting elevation for defined windows
• Permission boundaries (AWS) and Azure Policy to cap what identities can ever be granted
• Service account scoping with workload identity federation instead of long-lived keys
• Quarterly access reviews driven by CIEM reports, revoking anything unused for 90 days

Wildcard actions ("Action": "*") and wildcard resources ("Resource": "*") should fail policy checks in CI before they reach production.

Infrastructure as Code Security

Shift-left means catching misconfigurations in the pull request, not in production. Treat IaC as the source of truth:

# Example: scan Terraform before merge
checkov -d ./terraform --framework terraform
tfsec ./terraform
trivy config ./terraform

Integrate these scanners into CI so a public S3 bucket or an open security group blocks the merge. Pair them with policy-as-code engines like OPA/Conftest or Sentinel to encode organization-specific rules, such as “no storage bucket may be public without an approved tag.”

Automated Remediation

Manual fixes do not scale across three clouds. Build remediation into your detection pipeline:

• Event-driven auto-remediation: an EventBridge, Azure Monitor, or Cloud Logging rule triggers a Lambda, Function, or Cloud Run job that reverts the change (for example, re-enabling S3 Block Public Access)
• Guardrails over gates: use AWS SCPs, Azure Policy Deny effects, and GCP Organization Policies to make dangerous states impossible rather than merely detectable
• Immutable logging: ship CloudTrail, Activity Log, and Audit Logs to a separate, write-once account so attackers cannot cover their tracks

Auto-remediation should log every action and notify the owning team. Silent fixes hide the underlying process failure.

Training and DevSecOps Culture

Tools fail when teams route around them. Embed security into the developer workflow:

• Security champions in each engineering team
• Cloud-specific secure configuration training tied to real incidents, not generic slides
• Blameless postmortems when drift causes an incident, feeding findings back into policy-as-code
• Onboarding that treats IaC scanning and least privilege as defaults, not optional steps

Use the Provider Security Hubs

Each vendor publishes curated guidance and automated assessment tooling. AWS Security Hub aggregates findings across accounts with automated security checks. Microsoft Defender for Cloud provides secure score tracking and regulatory compliance dashboards. GCP Security Command Center surfaces misconfigurations, threats, and vulnerabilities in one view. Enable these hubs in every account and project, then route their output into your central monitoring rather than treating each console as a silo.

Prevention succeeds when misconfiguration becomes harder than compliance. That requires monitoring that never sleeps, permissions that expire, pipelines that reject bad infrastructure, and remediation that runs itself.

Conclusion: Key Takeaways and Actionable Steps

Cloud misconfigurations remain the single most exploited weakness in modern cloud estates. Across AWS, Azure, and GCP, the same failure patterns recur: public storage buckets, over-permissive IAM roles, disabled logging, and exposed management interfaces. Multi-cloud adoption multiplies these risks because each provider uses different terminology, defaults, and policy models, making consistent enforcement significantly harder. The result is a widened attack surface where a single overlooked setting can expose terabytes of sensitive data, as seen in repeated breach reports involving misconfigured S3 buckets and Azure Blob containers.

The encouraging reality is that misconfigurations are preventable. They stem from process gaps, not unsolvable technical problems. Organizations that treat cloud security as continuous rather than point-in-time consistently reduce exposure.

Immediate Action Checklist

Priority	Action	Target
1	Audit all storage buckets and containers for public access	Within 48 hours
2	Review IAM roles, policies, and service accounts for excessive permissions	Within 1 week
3	Enable audit logging (CloudTrail, Azure Activity Log, GCP Audit Logs) across all accounts	Within 1 week
4	Deploy a CSPM tool with multi-cloud coverage	Within 30 days
5	Establish a recurring misconfiguration review cadence	Ongoing

Start with storage and IAM because they account for the majority of real-world exposure. Logging provides the visibility needed to detect exploitation attempts, and CSPM tooling automates detection at scale across providers.

The strategic shift is cultural: move from reactive incident response to proactive posture management. Treat every new cloud resource as untrusted until validated, encode security requirements as policy-as-code, and monitor threat intelligence feeds for adversary techniques targeting cloud infrastructure. Misconfiguration is not a one-time fix but a continuous discipline. Organizations that institutionalize that discipline close the gap attackers rely on most.