For years, security teams have operated on a comfortable assumption: build one solid cloud security checklist, apply it across providers, and you're covered. Intruder's 2026 Cloud Security Index just put that assumption in the ground. After analyzing misconfiguration data from 3,000 organizations spanning AWS, Azure, and Google Cloud, the finding is stark — the risk profiles across providers have almost nothing in common.
This matters because most multi-cloud security programs were built on the lowest-common-denominator model: a single policy-as-code baseline, a single CSPM rule pack, a single audit checklist stretched across three fundamentally different platforms. The data says that approach doesn't reduce risk — it redistributes it. You end up over-controlled in areas where your provider rarely fails and blind in the areas where it fails constantly.
If your organization runs workloads in more than one cloud — and if you're reading this in 2026, statistically you do — your misconfiguration exposure is provider-specific, and your detection and remediation strategy needs to be as well.
What the Data Actually Shows
The core insight from the Index is that each cloud provider fails in its own characteristic way, driven by differences in default configurations, IAM models, and service architecture:
- AWS environments skew toward identity and access misconfigurations — overly permissive IAM policies, long-lived access keys, public S3 exposure, and security groups opened to
0.0.0.0/0. AWS's granular, customer-managed-everything model means the blast radius of a misstep is enormous and the defaults are rarely in your favor. - Azure environments concentrate risk around identity plane weaknesses — excessive Entra ID role assignments, legacy authentication left enabled, storage accounts with public network access, and management ports exposed on NSGs. Azure's deep integration with the enterprise identity stack means misconfigurations often bridge cloud and on-prem trust boundaries.
- Google Cloud environments show a different failure shape again — overly broad IAM bindings at the project level, firewall rules permitting ingress from any source, publicly accessible Cloud Storage buckets, and default service accounts with far more privilege than workloads need.
The practical consequence: an organization that has hardened its AWS IAM posture cannot assume any of that work translated to its Azure tenant. The failure modes don't overlap. The detections shouldn't either.
Why This Keeps Happening
Three root causes show up consistently in our own IR and assessment work, and the Index data reflects them:
- Default configurations differ per provider. AWS S3 buckets defaulted to private years ago but access point and ACL permutations still trip teams up. Azure storage has its own public access hierarchy. GCP's default service accounts are over-privileged by design. Each requires provider-native knowledge.
- IAM models are not portable. AWS policies, Azure RBAC/Entra roles, and GCP IAM bindings express privilege in completely different grammars. A "least privilege" audit that works in one cloud is meaningless in another.
- Unified tooling flattens the signal. Generic CSPM rule packs treat "publicly exposed resource" as one finding type. In practice, the path an attacker takes from a public S3 bucket versus a public Azure storage account versus a public GCP bucket differs — and so does the telemetry you need to catch exploitation.
Exploitation Status and Real-World Impact
This is not a theoretical exposure. Cloud misconfiguration remains one of the most reliably exploited initial access vectors we see in incident response. The typical chain doesn't involve a zero-day — it involves an attacker enumerating your provider's public attack surface (bucket names, storage account names, exposed metadata endpoints, permissive firewall rules) faster than your audit cycle catches it. Automated scanning of cloud IP ranges and storage endpoints is continuous and commoditized; a resource made public at 09:00 is often being probed before lunch.
The urgency the Index data creates is organizational, not patch-based: there is no CVE to remediate here. The vulnerability is the process assumption that one checklist covers three clouds.
Detection & Response
Because this is a technical exposure class with concrete observable telemetry, the detections below target the misconfiguration events — the moments a resource becomes dangerous — rather than generic posture findings. Catching the change is faster and cheaper than catching the breach.
Sigma Rules
The following rules target high-fidelity cloud audit events: public exposure of storage and the creation of overly permissive network access. These are mapped to provider-native log sources and should be tuned to your change-management windows.
---
title: AWS S3 Bucket Public Access Block Disabled or Public Policy Applied
id: 3c9f2a71-5b84-4e19-a6d2-7f0c1b8e4a55
status: experimental
description: Detects removal of S3 Block Public Access settings or application of a public bucket policy, a leading AWS misconfiguration pattern identified in the 2026 Cloud Security Index.
references:
- https://thehackernews.com/2026/09/your-cloud-security-checklist-doesnt.html
- https://attack.mitre.org/techniques/T1530/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.collection
- attack.t1530
logsource:
product: aws
service: cloudtrail
detection:
selection_api:
eventName:
- PutBucketAcl
- PutBucketPolicy
- DeletePublicAccessBlock
- PutPublicAccessBlock
filter_block_public:
requestParameters.publicAccessBlockConfiguration.BlockPublicAcls: 'true'
condition: selection_api and not filter_block_public
falsepositives:
- Intentional public content hosting via change-controlled pipelines
level: high
---
title: Azure Storage Account or Network Security Group Made Publicly Accessible
id: 8e1d4b60-2c73-4f58-b391-6a5e0d9c2f17
status: experimental
description: Detects Azure Activity events that enable public network access on storage accounts or create NSG rules permitting inbound traffic from any source, reflecting Azure-specific misconfiguration risk patterns.
references:
- https://thehackernews.com/2026/09/your-cloud-security-checklist-doesnt.html
- https://attack.mitre.org/techniques/T1530/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.collection
- attack.t1530
logsource:
product: azure
service: activitylogs
detection:
selection_storage:
operationName: 'MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE'
properties.requestbody|contains:
- '"publicNetworkAccess":"Enabled"'
selection_nsg:
operationName: 'MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/SECURITYRULES/WRITE'
properties.requestbody|contains:
- '"sourceAddressPrefix":"*"'
- '"sourceAddressPrefix":"0.0.0.0/0"'
- '"sourceAddressPrefix":"Internet"'
condition: selection_storage or selection_nsg
falsepositives:
- Legitimate public-facing storage for static web content under change control
level: high
---
title: GCP Firewall Rule Opened to Any Source or Public IAM Binding Added
id: 5a7b3c92-1f46-4d82-9e05-3c6b8a2d7e91
status: experimental
description: Detects GCP audit events creating firewall rules with 0.0.0.0/0 source ranges or IAM policy bindings granting allUsers/allAuthenticatedUsers access, key GCP misconfiguration patterns.
references:
- https://thehackernews.com/2026/09/your-cloud-security-checklist-doesnt.html
- https://attack.mitre.org/techniques/T1530/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.collection
- attack.t1530
- attack.defense_evasion
logsource:
product: gcp
service: gcp.audit
detection:
selection_fw:
methodName:
- 'v1.compute.firewalls.insert'
- 'v1.compute.firewalls.patch'
request.sourceRanges|contains: '0.0.0.0/0'
selection_iam:
methodName: 'SetIamPolicy'
request.policy.bindings.members|contains:
- 'allUsers'
- 'allAuthenticatedUsers'
condition: selection_fw or selection_iam
falsepositives:
- Deliberate public API endpoints behind load balancers with explicit design review
level: high
KQL — Microsoft Sentinel Hunt Queries
These queries assume cloud audit logs are ingested into Sentinel — AWS CloudTrail via the AWS connector, Azure Activity natively, and GCP audit logs via the GCP connector or CEF/Syslog forwarding.
// Hunt 1: Cloud resources made publicly accessible across AWS, Azure, and GCP
// Union pattern for multi-cloud tenants ingesting into a single Sentinel workspace
let awsPublic = AWSCloudTrail
| where EventName in ("PutBucketAcl", "PutBucketPolicy", "DeletePublicAccessBlock", "AuthorizeSecurityGroupIngress")
| where parse_json(RequestParameters).ipPermissions has "0.0.0.0/0"
or EventName == "DeletePublicAccessBlock"
| project TimeGenerated, Provider="AWS", EventName, UserIdentityUserName, SourceIpAddress, AWSRegion, RequestParameters;
let azurePublic = AzureActivity
| where OperationNameValue =~ "MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/SECURITYRULES/WRITE"
or (OperationNameValue =~ "MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE" and Properties has "publicNetworkAccess")
| where Properties has "0.0.0.0/0" or Properties has "\"*\"" or Properties has "Enabled"
| project TimeGenerated, Provider="Azure", OperationNameValue, Caller, CallerIpAddress, Properties;
union awsPublic, azurePublic
| summarize Events=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
by Provider, EventName, UserIdentityUserName, SourceIpAddress
| order by LastSeen desc;
// Hunt 2: Privilege escalation signals — broad IAM grants and long-lived credential creation
SecurityEvent
| where EventID == 4728 // Member added to global group (on-prem bridge risk for hybrid Azure)
| extend CloudContext = "EntraID-Hybrid"
| union (
AWSCloudTrail
| where EventName in ("CreateAccessKey", "AttachUserPolicy", "PutRolePolicy", "CreateRole")
| where parse_json(RequestParameters) has "\"*\"" or EventName == "CreateAccessKey"
| project TimeGenerated, EventName, UserIdentityUserName, SourceIpAddress, UserIdentityArn
)
| summarize Actions=count(), DistinctSources=dcount(SourceIpAddress)
by EventName, UserIdentityUserName, bin(TimeGenerated, 1h)
| where Actions > 3
| order by TimeGenerated desc;
Velociraptor VQL — Endpoint Hunt for Cloud Credential Exposure
When a misconfiguration incident is suspected, the follow-on question is whether cloud credentials on endpoints or build agents were exposed or harvested. This hunt looks for cloud CLI credential artifacts being accessed by unexpected processes — a common post-exploitation behavior after an attacker pivots from a misconfigured resource to an identity.
-- Hunt for processes accessing cloud credential stores outside of legitimate CLI tooling
SELECT Pid,
Name,
CommandLine,
Exe,
Username,
CreateTime
FROM pslist()
WHERE (
CommandLine =~ '(?i)(\.aws.credentials|\.aws.config|\.azure.accessTokens|\.config.gcloud|credentials.db|application_default_credentials)'
OR Exe =~ '(?i)(aws_access_key|service-account.*\.json)'
)
AND NOT Exe =~ '(?i)(aws-cli.aws|aws.exe|az.cmd|az.ps1|gcloud|terraform|pulumi)'
Also worthwhile: a targeted artifact for credential files themselves to establish exposure scope during IR.
-- Enumerate cloud credential artifacts on endpoints to scope potential exposure
SELECT FullPath,
Size,
Mtime,
Ctime
FROM glob(globs=string(a='C:/Users/*/.aws/credentials') + ',' +
string(a='C:/Users/*/.azure/*') + ',' +
string(a='/home/*/.aws/credentials') + ',' +
string(a='/home/*/.config/gcloud/application_default_credentials.json'),
accessor='file')
ORDER BY Mtime DESC
Hardening & Verification Script
The following audit script checks for the most impactful misconfiguration classes the Index highlights. Run it per provider from a controlled automation identity — not from an admin workstation.
#!/bin/bash
# Cloud misconfiguration audit — AWS, Azure, GCP high-impact checks
# Run with read-only audit credentials; output feeds your CSPM/ticketing pipeline
echo "=== AWS: S3 buckets without Block Public Access ==="
for bucket in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do
status=$(aws s3api get-public-access-block --bucket "$bucket" 2>/dev/null)
if [ -z "$status" ]; then
echo "EXPOSED: $bucket has no Block Public Access configuration"
fi
done
echo "=== AWS: Security groups open to 0.0.0.0/0 on admin ports ==="
aws ec2 describe-security-groups \
--query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`] && (FromPort==`22` || FromPort==`3389`)]].[GroupId,GroupName]' \
--output table
echo "=== AWS: Access keys older than 90 days ==="
aws iam generate-credential-report && sleep 5
aws iam get-credential-report --query 'Content' --output text | base64 -d | \
awk -F',' 'NR>1 && $9!="N/A" && $9!="access_key_1_last_rotated" {print $1, $9}'
echo "=== Azure: Storage accounts with public network access enabled ==="
az storage account list --query '[?publicNetworkAccess==`Enabled`].[name,resourceGroup]' -o table
echo "=== Azure: NSGs permitting inbound from Any ==="
az network nsg list --query '[].{NSG:name,RG:resourceGroup}' -o json | while read -r nsg; do
name=$(echo "$nsg" | jq -r '.NSG'); rg=$(echo "$nsg" | jq -r '.RG')
az network nsg rule list --nsg-name "$name" --resource-group "$rg" \
--query '[?sourceAddressPrefix==`*` && direction==`Inbound` && access==`Allow`].[name,destinationPortRange]' -o table
done
echo "=== GCP: Firewall rules open to 0.0.0.0/0 ==="
gcloud compute firewall-rules list \
--filter="sourceRanges:0.0.0.0/0 AND direction=INGRESS AND disabled=false" \
--format="table(name, network, allowed[].map().firewall_rule().list())"
echo "=== GCP: IAM bindings granting allUsers or allAuthenticatedUsers ==="
for project in $(gcloud projects list --format='value(projectId)'); do
gcloud projects get-iam-policy "$project" --format=json 2>/dev/null | \
jq -r --arg p "$project" '.bindings[] | select(.members[] | test("allUsers|allAuthenticatedUsers")) | "\($p): \(.role)"'
done
Remediation: Building Provider-Specific Defense
There is no patch here — the fix is architectural and procedural. Based on the Index findings and our own multi-cloud IR experience, prioritize the following:
1. Split Your Baseline by Provider — Immediately
Retire the single unified checklist. Maintain three distinct hardening baselines (CIS Benchmarks for AWS, Azure, and GCP are the obvious starting point, but tune them to your organization's actual misconfiguration history). If your CSPM data shows you fail on AWS IAM and Azure identity but pass GCP checks consistently, weight your control investment accordingly. The Index's core lesson is that your failure profile is not generic — your baseline shouldn't be either.
2. Enforce Preventive Guardrails, Not Just Detective Findings
- AWS: Deploy Service Control Policies denying
s3:PutBucketAclwith public principals and blockingec2:AuthorizeSecurityGroupIngresswith0.0.0.0/0on ports 22/3389 outside approved accounts. Enforce S3 Block Public Access at the organization level. - Azure: Use Azure Policy (deny effect) on
Microsoft.Storage/storageAccounts/publicNetworkAccessand NSG rules withsourceAddressPrefix: *. Disable legacy authentication via Conditional Access policies tenant-wide. - GCP: Apply Organization Policy constraints:
constraints/storage.publicAccessPrevention,constraints/compute.restrictXpnProjectLienRemovalwhere applicable, and restrictiam.allowedPolicyMemberDomainsto your identity domain. Replace default service accounts with per-workload identities.
3. Shift Detection to the Change Event
As the Sigma rules above illustrate, the highest-fidelity signal is the API call that creates the exposure — not a periodic scan finding hours later. Wire CloudTrail, Azure Activity Log, and GCP Admin Activity audit logs into your SIEM and alert on the mutation, not just the state.
4. Kill Long-Lived Credentials
AWS access keys older than 90 days, Azure service principal secrets with no expiry, and GCP service account keys downloaded to laptops are the connective tissue between a misconfiguration and a breach. Rotate aggressively; prefer OIDC-based workload identity federation everywhere your pipelines allow it.
5. Validate With Adversary Emulation
Run provider-specific attack-path validation quarterly. Tools and techniques that enumerate public storage, test IAM privilege escalation paths, and probe metadata endpoints will show you whether your guardrails actually hold — per provider, not in aggregate.
6. Track Metrics Per Provider
Mean time to remediate a public-exposure finding, count of IAM policy violations, and credential age distribution — reported per cloud, not rolled up. Aggregate dashboards are exactly how the "checklist works" illusion survives.
The Bottom Line
The 2026 Cloud Security Index confirms what practitioners who've worked multi-cloud IR have known anecdotally for years: AWS fails like AWS, Azure fails like Azure, and GCP fails like GCP. A single security checklist doesn't just underperform across three different failure profiles — it actively creates false confidence in the areas where your provider is most likely to let you down.
Rebuild your baselines per provider. Alert on the mutation events, not the posture scans. And measure your program's health the same way the data was collected — one cloud at a time.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.