Cloud security assessment: what misconfiguration chains look like in practice
Geert WarmenbolApril 29, 2026
Key takeaways
Cloud misconfigurations that produce breaches are almost never isolated errors: they are chains where one misconfiguration provides access, a second allows privilege escalation, and a third permits data movement without detection.
IAM roles with permissions to modify their own policies, or to attach additional policies, create privilege escalation paths that automated CSPM tools flag as informational findings while manual assessment treats as critical attack paths.
CloudTrail logging gaps on specific API call categories, particularly data-plane events on S3 and Lambda invocations, mean that an attacker operating in those surfaces leaves no audit trail in environments that have management-plane logging enabled and treat that as complete coverage.
In Vulnox cloud assessments, the most commonly exploitable misconfiguration chain began with an overly permissive IAM role on a compute instance, not with a public storage bucket, which is the misconfiguration most organizations are actively monitoring.
Service control policies in AWS Organizations set permission guardrails but do not prevent misconfigurations within the permissions they allow: an SCP that prohibits leaving the region still permits every misconfiguration possible inside that region.
TL;DR
Cloud security assessments that check configurations in isolation produce a list of misconfigurations. The ones that matter are the sequences. An IAM role that is overly permissive is a finding. The same IAM role attached to a compute instance that processes external input, in an environment where CloudTrail data-plane logging is disabled and no S3 bucket policy prevents cross-account access, is a breach path. The difference between a finding list and a breach path analysis is whether the assessment models what an attacker does with each misconfiguration rather than just documenting that it exists.
The environment that passed every automated check
A 300-person SaaS company had AWS Security Hub enabled across all accounts, GuardDuty active, and a third-party CSPM tool running continuous configuration checks. Their security posture dashboard showed green across the primary compliance frameworks. Two weeks before a scheduled external audit, they engaged Vulnox for a cloud penetration test. The CSPM had been running for eight months. The Security Hub findings had been triaged and the critical and high items remediated. The security team believed the automated tooling had the environment covered.
Manual assessment found a privilege escalation path from a developer IAM role to administrator access in under four hours. The developer role had been granted iam:AttachRolePolicy to allow developers to attach logging policies to Lambda functions during troubleshooting. That permission also allows attaching AdministratorAccess to any role the developer can assume. The CSPM had flagged the iam:AttachRolePolicy permission as an informational finding eleven weeks prior. It had been reviewed, assessed as low risk in context, and marked as accepted. The manual assessment demonstrated what accepting that finding actually meant operationally by walking the escalation path end to end.
How misconfiguration chains work and why they survive tooling
Automated cloud security tools evaluate configurations against known misconfiguration signatures: public S3 buckets, unrestricted security groups, missing encryption, absent MFA. Each finding is evaluated independently against a rule. The tool does not model what an attacker does with a combination of findings because it has no mechanism for simulating attacker decision-making across a finding set. A misconfiguration chain requires the attacker to hold one capability and use it to acquire another, then use the combined capabilities to reach data. That sequence is invisible to tools that assess each configuration in isolation.
Example
The privilege escalation path in the SaaS environment above required three configurations to exist simultaneously: iam:AttachRolePolicy on the developer role, a role the developer could assume that did not itself have administrator access, and an absence of a service control policy preventing policy attachment in the member account. Each of those configurations was individually assessed by the CSPM. The iam:AttachRolePolicy finding was marked accepted. The assumable role was within normal configuration. The SCP gap was in the management account, which was in a different scan scope. No single tool evaluated the three together as a chain. The manual assessment did.
CloudTrail logging has a distinction that most organizations miss operationally: management events and data events are separate logging categories with separate cost implications. Management events log API calls that create, modify, and delete AWS resources. Data events log operations on resource contents, specifically S3 object operations (GetObject, PutObject, DeleteObject) and Lambda function invocations. The default CloudTrail configuration logs management events. Data events are disabled by default because they generate significantly higher log volume in active environments. An environment with CloudTrail enabled and data events disabled has complete visibility into who created which S3 bucket and zero visibility into who downloaded which objects from that bucket. That is the logging gap that makes data exfiltration from S3 forensically invisible in environments that believe they have comprehensive audit trails.
What cloud assessments find that automated tools do not
Assessment base: Vulnox cloud security assessment data across SMB and mid-market clients, 2023-2024
Privilege escalation paths from application roles through IAM permission combinations
In cloud penetration tests, privilege escalation paths from non-administrator roles to effective administrator access appeared in the majority of assessed environments. The paths consistently used combinations of IAM permissions that each appeared reasonable in isolation: iam:PassRole combined with the ability to create Lambda functions produces a path to any role that can be passed to Lambda; iam:CreatePolicyVersion on an existing policy allows replacing the policy document with one that grants any permissions. CSPM tools flag individual permissions with escalation potential as informational or medium findings. The manual assessment converts those findings into demonstrated exploitation paths.
An informational CSPM finding that has been accepted without demonstrated exploitation analysis has not been risk-assessed. It has been triaged. The difference matters when the finding is a component of an escalation path. Accepting iam:AttachRolePolicy as low risk requires knowing what roles can be assumed by the principal that holds it and what policies could be attached to those roles. That analysis requires modeling the permission graph, not reading the finding description.
S3 data-plane logging absent in environments with sensitive data buckets
A financial services client had CloudTrail management events logged to a centralized logging account. Their security team cited CloudTrail as their primary audit mechanism. Assessment found that data events were disabled on all S3 buckets including those containing customer financial records. The security team was aware that data events generated additional cost but had not connected that cost decision to the forensic implication: if data was exfiltrated from those buckets, the logging infrastructure would show that the bucket existed and that IAM policies permitted access, but would contain no record of whether objects had been downloaded or by whom.
Disabling S3 data-plane logging is a cost decision that is simultaneously a forensic capability decision. In a breach scenario involving S3 data access, the absence of data event logs means the organization cannot determine whether data was exfiltrated, cannot scope a notification obligation, and cannot provide regulators with evidence of what was or was not accessed. The cost of enabling data event logging on sensitive buckets should be evaluated against the cost of a breach investigation conducted without that evidence.
EC2 instance metadata service v1 enabling credential theft from SSRF
In assessed environments running EC2 instances, IMDSv1 was enabled in a consistent pattern despite IMDSv2 being available and recommended. IMDSv1 allows any HTTP client on the instance, including a server-side request forgery payload, to query the metadata service and retrieve the IAM role credentials attached to the instance. IMDSv2 requires a session token obtained through a PUT request, which SSRF attacks using GET requests cannot retrieve. The migration from IMDSv1 to IMDSv2 requires a code change in any application that queries instance metadata directly, which is the operational reason most environments had not completed it. The security implication is that any SSRF vulnerability in an application running on those instances provides immediate access to the instance IAM role credentials.
IMDSv1 exposure is the connector between application-layer vulnerabilities and cloud infrastructure access. An SSRF vulnerability that appears to have limited impact in isolation, because the application is in a restricted network segment, becomes a path to IAM credential theft when the instance runs IMDSv1. The cloud assessment finding and the application security finding need to be evaluated together to understand the actual blast radius of either.
Cross-account trust relationships granting broad access to development accounts
A multi-account AWS organization had production and development account separation. The cross-account IAM trust relationship from the development account to the production account had been configured to allow developers to assume a role for debugging purposes. The role in the production account had been intended as read-only. At some point in the preceding 18 months, the role policy had been expanded to include S3 write access for a specific debugging workflow and had not been reverted. The development account did not have the same security controls as production. Any developer with access to the development account could assume a role in production with write access to production S3 buckets.
Cross-account trust relationships extend the security perimeter of the trusted account to include the security posture of the trusting account. A production account with strong security controls that trusts a development account with weaker controls has effectively inherited the weaker posture for any permission granted through the trust. Assessing production account security without reviewing the accounts that can assume roles into production produces an incomplete picture.
The public S3 bucket finding that was not the problem
Common belief
Public S3 bucket exposure is the cloud misconfiguration that produces data breaches. It is the finding most organizations actively monitor, most CSPM tools prioritize, and most cloud security checklists address first. An environment with no public S3 buckets has addressed the primary cloud data exposure risk.
What we found
In cloud penetration tests where the engagement included both automated CSPM review and manual exploitation testing, the data access paths that produced the most significant findings were through IAM privilege escalation from application roles, not through public storage. The public bucket findings had been remediated. The IAM permission graph had not been modeled. The organization had fixed the visible problem and left the exploitable one.
Public S3 buckets are visible and therefore get fixed. The misconfigurations that produce actual data exfiltration in assessed environments are the ones that require an authenticated identity to exploit: overly permissive IAM roles on compute instances, cross-account trust relationships with excessive permissions, and absent data-plane logging that makes exfiltration forensically invisible. These require an attacker to have some initial access to exploit, which means they require a more capable attacker than automated opportunistic scanning. They also require a more sophisticated assessment to find than a public bucket check.
The cloud attack surfaces most assessments do not cover
Lambda function environment variables containing credentials
Lambda functions frequently receive credentials through environment variables set during deployment. These credentials are visible in plaintext to any principal with lambda:GetFunctionConfiguration permission, which is often granted broadly for operational purposes. An IAM principal that cannot access Secrets Manager or Parameter Store directly may be able to retrieve the same credentials by reading the Lambda environment variables of a function that fetches them.
CloudFormation stack outputs containing sensitive values
CloudFormation stacks that output ARNs, endpoints, or in some cases credentials as stack outputs make those values readable by any principal with cloudformation:DescribeStacks permission. Stack outputs are frequently used to share values between nested stacks during deployment and are not cleaned up after the deployment completes. Sensitive values persist in stack outputs indefinitely.
Overly permissive S3 bucket policies granting access to any authenticated AWS principal
S3 bucket policies that use Principal: * with a condition requiring authentication (aws:PrincipalAccount or aws:PrincipalIsAWSService) are sometimes written with the intent to restrict access but produce the opposite effect. A bucket policy that grants access to any authenticated AWS principal grants access to every AWS account in existence, not just the organization's accounts. This misconfiguration does not trigger public bucket alerts because the bucket is not publicly accessible without authentication.
Resource-based policies on KMS keys allowing cross-account decrypt
KMS key policies that include cross-account principals for legitimate decryption purposes may accumulate entries for accounts that no longer require access, for accounts belonging to former vendors or partners, or for overly broad principal specifications. Data encrypted with a KMS key is only as protected as the key policy. An assessment of encrypted data storage that does not review the key policy for the encryption key has not assessed the actual access control on that data.
Where cloud security assessment is heading
IAM permission graph analysis will become a required component of cloud security audits under major compliance frameworks within two years, driven by breach disclosures that trace to privilege escalation paths that CSPM tools had flagged as informational.
The current compliance audit approach to IAM is checklist-based: is MFA enabled, are root credentials unused, are access keys rotated. None of those checks detect privilege escalation paths. As breach disclosures become more technically specific and as investigators reconstruct escalation paths that ran through CSPM-accepted findings, the gap between what compliance audits verify and what attackers exploit will become documented and specific. Framework updates will follow.
Confidence: highSOC 2 criteria or ISO 27001 supplementary controls explicitly requiring IAM permission graph analysis or escalation path modeling by 2027.S3 data-plane logging will become a mandatory control for buckets containing personal data under GDPR enforcement guidance within two years, following a post-breach investigation in which the absence of object-level logging prevented the organization from determining whether data was exfiltrated.
GDPR Article 32 requires appropriate technical measures including the ability to ensure ongoing confidentiality and to restore data access promptly. A breach investigation that cannot determine whether personal data was accessed because object-level logging was disabled leaves the data controller unable to fulfill Article 33 notification obligations accurately. DPAs that conduct post-breach investigations and encounter this logging gap will cite it in enforcement decisions. The citation will produce guidance.
Confidence: mediumA published DPA enforcement decision citing absence of S3 data-plane logging as a contributing factor in an Article 32 finding by end of 2026.
Why CSPM tools produce security theater at scale
CSPM tools are useful for what they do: continuous configuration monitoring against known misconfiguration signatures. The problem is that organizations use them as a substitute for assessment rather than as a complement to it. A CSPM dashboard that shows 94% compliance against a CIS benchmark tells you that 6% of the benchmark items are misconfigured. It does not tell you whether any combination of the 94% that passed produces an exploitable attack path. The iam:AttachRolePolicy permission in the SaaS environment above was not a CSPM failure. It was flagged. It was reviewed. It was accepted. The failure was treating acceptance of an informational finding as equivalent to understanding the operational risk of that finding. An assessment that demonstrates the escalation path end to end produces a different organizational response than a dashboard finding marked accepted.
Counterargument
The counterargument is that continuous CSPM coverage across an entire cloud environment provides breadth that periodic manual assessment cannot. That is correct. A quarterly penetration test does not catch a misconfiguration introduced by a deployment three weeks after the test. Continuous tooling does. The answer is not CSPM or manual assessment. It is both, with clear understanding of what each covers and an explicit process for converting CSPM findings that involve escalation-relevant permissions from accepted to validated through manual exploitation testing.
One thing to do this week
Pull the IAM policies for every role attached to EC2 instances and Lambda functions in your environment and look for any of these permissions: iam:AttachRolePolicy, iam:PutRolePolicy, iam:CreatePolicyVersion, iam:PassRole, sts:AssumeRole with a wildcard resource. For each permission found, identify which roles that principal can assume and what policies it could attach or modify. You are not looking for a misconfiguration in isolation. You are looking for whether a combination of permissions on a compute role produces a path to escalated privilege. If you find one, it is not an informational finding. It is a demonstrated escalation path waiting for an initial foothold.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionShadow IT Discovery
shadow IT discovery guidanceNIST Cybersecurity Framework 2.0
NIST Cybersecurity Framework
Frequently Asked Questions
Why do cloud security misconfigurations produce breaches when each individual misconfiguration appears low risk?
Individual cloud misconfigurations are evaluated by automated tools in isolation against known signatures. A breach path requires combining multiple findings: one misconfiguration provides initial access, a second allows privilege escalation, a third permits data movement without detection. No single tool evaluates the sequence because tooling has no mechanism for modeling attacker decision-making across a finding set. In Vulnox cloud assessments, the most common exploitable chains began with an IAM role permission that had been reviewed and accepted as informational, combined with an assumable role and an absent logging category that made the escalation forensically invisible.
What is the difference between CloudTrail management events and data events and why does it matter for breach investigation?
CloudTrail management events log API calls that create, modify, and delete AWS resources. Data events log operations on resource contents, including S3 object downloads, uploads, and deletions, and Lambda function invocations. Data events are disabled by default because they generate significantly higher log volume. An environment with management events enabled has complete visibility into who created which S3 bucket and zero visibility into who downloaded which objects from it. In a breach involving S3 data access, absent data-plane logging means the organization cannot determine whether data was exfiltrated, cannot scope a notification obligation, and cannot provide regulators with evidence of what was accessed.
How does IMDSv1 on EC2 instances connect application vulnerabilities to cloud infrastructure compromise?
IMDSv1 allows any HTTP client on an EC2 instance, including a server-side request forgery payload, to query the instance metadata service and retrieve the IAM role credentials attached to the instance. IMDSv2 requires a session token obtained through a PUT request, which SSRF attacks using GET requests cannot retrieve. An SSRF vulnerability in an application running on an IMDSv1 instance provides immediate access to the instance IAM role credentials, converting an application-layer finding into cloud infrastructure access. The two findings need to be evaluated together to understand the actual blast radius of either.
Why do service control policies in AWS Organizations not prevent cloud misconfigurations?
Service control policies set permission guardrails that limit the maximum permissions available in member accounts. They do not prevent misconfigurations within the permissions they allow. An SCP that prohibits leaving a specific region still permits every IAM misconfiguration, storage policy error, and logging gap possible inside that region. SCPs are a boundaries control, not a configuration correctness control. An assessment finding that an SCP is in place tells you what the environment cannot do. It does not tell you whether what the environment can do is correctly configured.
What IAM permissions create privilege escalation paths that CSPM tools flag as informational?
IAM permissions with privilege escalation potential that commonly appear as informational CSPM findings include iam:AttachRolePolicy (allows attaching any policy including AdministratorAccess to a role), iam:PutRolePolicy (allows replacing an inline policy with one granting any permissions), iam:CreatePolicyVersion (allows creating a new policy version with different permissions), iam:PassRole combined with the ability to create Lambda or EC2 resources (allows passing a high-privilege role to a new resource), and sts:AssumeRole with wildcard resources (allows assuming any role that does not restrict its trust policy). Each is individually reasonable in operational context. Each is a component of documented escalation paths when combined with an assumable role.
What cloud security surfaces do CSPM tools and automated scans miss that manual assessment finds?
CSPM tools and automated scans miss privilege escalation paths that require modeling permission combinations across multiple IAM principals, S3 bucket policies that use authenticated-principal conditions that grant access to all AWS accounts rather than just the organization, Lambda function environment variables containing credentials readable through lambda:GetFunctionConfiguration, CloudFormation stack outputs persisting sensitive values after deployment completes, KMS key policies with accumulated cross-account entries for accounts that no longer require access, and cross-account trust relationships where the trusting account has weaker security controls than the trusted account. Manual assessment models what an attacker does with a combination of findings rather than evaluating each configuration in isolation.
Related Articles
API security assessment: what automated tools miss and manual testing finds
Automated API security tools find the vulnerabilities they were designed to look for. The findings that matter in real assessments, broken object-level authorization, JWT algorithm confusion, and unauthenticated internal endpoints, require a tester who understands what the API is supposed to do before probing what it actually does.
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.