Key Takeaways
- Public storage buckets (S3, Azure Blob, GCS) remain the dominant exposure. Even with Block Public Access defaults, accidental and exception-based exposure is common.
- Public disk snapshots and AMI images are an under-appreciated risk. A public EBS snapshot or shared AMI can leak entire production filesystems.
- Overpermissive IAM (wildcard actions, * resources, broad role trust policies) is the #1 finding in cloud pentest. Lateral movement through IAM is faster than network movement.
- Open security groups on management ports (22, 3389, 1433, 3306) are still found on every engagement. Often labelled 'temporary' from 2019.
- Disabled logging (no CloudTrail, no Activity Log, no Audit Log) leaves the customer blind to attack and unable to satisfy compliance evidence requests.
Why Misconfiguration, Not Zero-Day, Drives Cloud Breaches
Cloud security is not failing because of unpatched zero-day vulnerabilities. It is failing because of misconfiguration. Verizon's annual Data Breach Investigations Report, Mandiant's M-Trends, Microsoft's Digital Defense Report and IBM's Cost of a Data Breach all converge on the same conclusion: misconfiguration is the leading or second-leading cause of cloud-related breach incidents every year since 2019.
The reasons are structural. Cloud APIs make it easy to provision resources at scale; the same scale applies to mistakes. Developers and engineers self-serve infrastructure faster than security teams can review. Defaults vary by service. Integrations between services create permissions that are individually reasonable and collectively dangerous. The result is that even well-resourced teams accumulate misconfiguration debt continuously.
The fix is structural too. Manual review cannot keep up. Continuous configuration monitoring (CSPM), policy-as-code enforcement (Azure Policy, AWS Config Rules, GCP Organisation Policy), and regular external testing close the loop. The patterns below are what to look for first.
Public Storage Buckets
S3 buckets, Azure Blob containers and GCS buckets remain the most-cited cloud data exposure. The vendor defaults have tightened (AWS Block Public Access at account level, Azure storage account public network access disabled by default for new accounts, GCS uniform bucket-level access), but exception cases persist: legitimate static-site hosting buckets, marketing asset libraries, data lake landing zones temporarily public during a transfer, third-party integrations that require object public-read.
Real-world breach examples cluster around: misnamed buckets where 'public' was intended for one file and applied to the bucket, bucket policy edits that disabled Block Public Access for one operation and were not re-enabled, Cross-Origin Resource Sharing (CORS) settings that allowed scripted enumeration from the open web, and bucket inventory dumps where the dump itself was published.
Detection: AWS S3 Access Analyzer, Azure Defender for Storage public access alerts, GCS Cloud Asset Inventory queries. Fix: re-enable Block Public Access at account level, treat public buckets as exceptions requiring named approval, scheduled scan of all bucket policies, and automated alerting on any policy that grants public access.
Need a Cloud Security Assessment?
Codesecure runs ISO/IEC 27001:2022 certified cloud security assessments and pentest across AWS, Azure and GCP for Indian enterprises. Named OSCP consultants, CIS and CSA mapping, fixed-price proposals, free retest within 90 days.
See Cloud Services →Public Disk Snapshots and Shared Images
Less obvious than public buckets, public EBS snapshots and shared AMIs leak entire disk contents. The mechanism: an engineer shares a snapshot or AMI with a partner account, then sets the visibility to 'all' for convenience, or accidentally selects 'public' in the console. Once public, anyone with the snapshot ID can create a volume from it. AMI search engines crawl public AMIs continuously.
What typically leaks: production database dumps, configuration files with embedded credentials, SSH host keys, application source code, customer data exports. Several public breach reports in 2023 and 2024 trace back to public snapshots that were never intended to leave the account.
Detection: AWS Config rule ebs-snapshot-public-restorable-check, ec2-imdsv2-check (related, prevents the credential capture that often precedes snapshot creation), and Trusted Advisor public snapshot check. Azure and GCP equivalents exist. Fix: revoke public sharing, rotate any credentials that were in the snapshot, and add a Config rule that flags or blocks creation of new public snapshots.
Overpermissive IAM Roles and Policies
IAM is the single largest source of cloud misconfiguration findings. The recurring patterns: wildcard actions (Action: '*'), wildcard resources (Resource: '*'), wildcard principals (Principal: '*' in resource-based policies), trust policies that allow any principal in the same account to assume the role, and roles attached to services with permissions far beyond the service's actual need.
Privilege Escalation Paths
Tools like Pacu (AWS), AzureHound (Azure) and CloudPEASS find escalation paths from a low-privilege foothold to administrative control. A user with iam:CreateAccessKey on another user becomes that user. A role with iam:PassRole and lambda:UpdateFunctionCode on a higher-privileged function inherits the function's permissions. A service account with create-pod permission in Kubernetes becomes node-root via a privileged pod. These paths are routine in mid-size cloud estates.
Open Security Groups and Network ACLs
Security Groups with 0.0.0.0/0 (or ::/0) on TCP 22, 3389, 1433, 3306, 27017, 9200, 6379 and other database or management ports are still found on every cloud engagement we run. The pattern is consistent: a temporary rule opened for debugging, an external vendor needed access for an installation, a misconfigured CI/CD pipeline opened the rule and never closed it.
The detection is trivial (CSPM tools, scout suite, prowler, AWS Config managed rules, Azure Policy). The fix is operational: move all SSH and RDP access through Session Manager, Bastion, or VPN; database access through PrivateLink or Private Endpoint; and ensure no production security group has internet ingress on a management or database port. Where a temporary exception is needed, it must be ticketed and time-bound.
CSPM, IAM Cleanup or Audit Pressure?
Whether you need a CSPM deployment, an IAM rationalisation, a SOC 2 or ISO 27001 cloud control evidence pack, or a quick second-opinion on a finding, our cloud security lead is available for a 30-minute free scoping call.
Talk to a Cloud Lead →Disabled or Incomplete Logging
Logging gaps are not visible in normal operations. They become visible at incident response (no forensic trail) and at audit (no evidence). Common patterns: CloudTrail enabled in one region but not multi-region or organisation-wide, S3 buckets without server access logs or object-level logging, VPC Flow Logs disabled or sampled, Azure Activity Logs not exported to Log Analytics, GCP audit logs disabled at the project level, Kubernetes audit logs not enabled.
Detection: CSPM tools surface all of these. AWS Config managed rule cloudtrail-enabled, multi-region-cloudtrail-enabled, cloud-trail-log-file-validation-enabled. Azure Policy initiatives include 'Enable Azure Monitor for VMs' and similar. The fix is to centralise to a logging account or workspace and enforce via policy.
Metadata API and SSRF Exposure
Cloud metadata APIs (AWS IMDSv1 at 169.254.169.254, Azure Instance Metadata Service at 169.254.169.254, GCP metadata server at metadata.google.internal) provide temporary credentials and configuration to workloads. SSRF (Server-Side Request Forgery) in an application allows an attacker to query the metadata API and retrieve those credentials, leading to direct cloud access with the workload's IAM role.
Mitigation: AWS, enforce IMDSv2 (session-token required) which breaks the typical SSRF pattern. Azure, the IMDS requires the Metadata: true header which mitigates many SSRF patterns by default. GCP metadata server requires Metadata-Flavor: Google header. Beyond that, fix the SSRF in the application, restrict outbound egress from compute to known destinations, and monitor for metadata API calls from unexpected sources.
CSPM Tooling and Remediation Workflow
Continuous CSPM (Cloud Security Posture Management) catches misconfigurations as they happen, not at the next quarterly review. AWS Security Hub, Microsoft Defender for Cloud and GCP Security Command Center are the cloud-native CSPM options. Third-party CSPM (Wiz, Prisma Cloud, Orca, Lacework, Sysdig) add unified multi-cloud view, deeper graph analysis (attack path identification across services) and richer auto-remediation playbooks.
Whichever tool, the operational pattern matters more than the product choice: findings are routed to owners with SLAs by severity (critical 24 hours, high 7 days, medium 30 days), auto-remediation handles low-risk findings (rotate access keys older than 90 days, re-enable Block Public Access), and recurring findings get prevention via policy enforcement so they cannot reoccur. Without an operational pattern, CSPM produces dashboards that nobody acts on.
Frequently Asked Questions
What is the most common cloud misconfiguration?
Across our engagements: overpermissive IAM is most common (almost every account), open security groups on management ports is second, and public storage exposure is third (less common after default tightening, but high-impact when found).
Do CSPM tools find everything?
CSPM is excellent for known-pattern misconfigurations and known-control gaps. They do not replace external pentest, which simulates the actual attacker walking through configurations and discovering chained issues that single-finding tools miss. CSPM plus periodic pentest is the right combination.
How much does CSPM cost?
AWS Security Hub, Microsoft Defender for Cloud and GCP Security Command Center pricing scales by resource count. Third-party CSPM is typically per-cloud-resource per-month, ranging from a few thousand USD per month for small estates to six-figure USD per year for large enterprises. Cost-benefit is strong for any organisation past a single-team single-account scale.
Can misconfigurations be remediated automatically?
Yes for low-risk fixes (rotate stale keys, enable Block Public Access on net-new buckets, enforce default encryption). High-risk fixes (closing a security group, modifying an IAM policy) usually need human review because they can break workloads. Most CSPM tools support 'suggest then apply with approval' workflows.
How does this map to ISO 27001, SOC 2 and DPDP?
Every misconfiguration class maps to one or more controls in ISO/IEC 27001:2022 Annex A (A.5, A.8 families), SOC 2 CC6 logical access plus CC7 system operations, and DPDP Act Section 8 reasonable security safeguards. Codesecure delivers cloud audit reports with explicit control-to-finding mapping for compliance teams.
Do you do cloud misconfiguration assessments?
Yes. Codesecure runs cloud configuration audits as standalone engagements (4 to 6 weeks for mid-size estates) or as part of broader cloud pentest. Reports include findings, control mapping, severity-prioritised remediation, and a roadmap for CSPM implementation if not already in place.
Find Your Cloud Misconfigurations Before The Attacker Does
Codesecure delivers cloud configuration audits, CSPM implementation and cloud pentest across AWS, Azure and GCP for Indian SaaS, fintech and enterprise customers. ISO/IEC 27001:2022 certified delivery, named consultants, fixed-price proposals.
