Why Cloud Security Scanners Miss Attack Chains: An IAM Example

During a recent Software Secured internal research session, a cloud review uncovered what appeared to be a harmless IAM policy attached to a low-privileged user. It wasn't flagged as critical because, on its own, it wasn't.

Three API calls later, that same user had full administrator access to the AWS account.

The interesting part wasn't the IAM policy itself. It was the attack chain that connected several individually low-risk permissions into a complete privilege-escalation path.

As more infrastructure is generated by AI coding assistants, such chained cloud attacks become increasingly important to identify. This article explains why attack-chain analysis matters, where automated cloud security tools fall short, and why manual Secure Cloud Reviews uncover risks that scanners often miss.

Why Cloud Security Scanners Miss Attack Chains 

Cloud security tools like ScoutSuite are genuinely useful. Point one at an AWS account, and it will return a list of misconfigurations, overly permissive IAM policies, unencrypted resources, exposed credentials, and other vulnerabilities, typically ranked by severity.

What they don't show is how those individual vulnerabilities combine into an attack chain.

A permission that allows a user to create an IAM role isn't inherently dangerous. Neither is the ability to attach a managed policy to that role. Neither is the ability to assume a role you created. Each permission individually may appear reasonable and even necessary for a developer's day-to-day work. Combined, however, they create an attack path that allows an attacker to escalate from a low-privileged user to full administrator access.

This is the same principle Software Secured has long applied to web and API penetration testing: attackers rarely succeed because of a single vulnerability. They succeed by chaining together multiple weaknesses that, in isolation, appear low risk. That same attack-chain methodology is equally valuable in cloud security. Rather than evaluating IAM policies, networking rules, and service configurations as independent vulnerabilities, a manual Secure Cloud Review examines how they interact to identify the paths a real attacker could exploit.

How a Cloud Attack Chain Becomes Administrator Access

Here's a simplified version of the actual escalation path demonstrated internally, using a throwaway AWS user created specifically to show the concept:

Step 1: Create a role.

The compromised (or over-permissioned) user can create a new IAM role. That role's trust policy is set to trust the attacker's own user, meaning the attacker will be allowed to assume it later. On its own, this role has zero permissions attached. It's just a role that exists.

Step 2: Attach an admin policy to that role.

Using a second permission, the attacker attaches AWS's own AdministratorAccess managed policy to the role they just created. Still, at this point, the attacker's original user has no more access than before.

Step 3: Assume the role.

The attacker requests temporary credentials for the role they created and populated. AWS hands over valid, active administrator credentials.

Zero permissions to full admin, in three API calls, using nothing but legitimate AWS functionality working exactly as designed.

In real engagements, this pattern is rarely this clean. Client environments often have defenses in place, for example, a rule requiring new role names to start with an approved prefix such as dev-. But that only constrains the name, not what the role can do, so an attacker can name their role dev-metrics-sync and move on. The underlying chain logic doesn't change. The same three-step pattern also generalizes to GCP and Azure equivalents. 

One practical wrinkle worth flagging for anyone running these tests: clients frequently grant testers only read-only or security-auditor access, not full admin, which means you can't always click through the console to prove impact the way a demo can. AWS's IAM policy simulator (accessible via the CLI) fills that gap, letting a tester ask, "Can this user perform this action against this resource?" and get a definitive answer that documents the vulnerability without requiring destructive proof-of-concept execution.

Why This Belongs in Cloud Reviews, Not Just Pentests

Attack chains are most commonly discussed in the context of penetration testing, where testers move from an initial foothold to progressively higher levels of access by combining multiple weaknesses. The same mindset applies equally well to cloud environments. IAM permissions, networking rules, service configurations, and identity relationships rarely become critical in isolation. The real risk emerges when they interact in ways that create an exploitable path.

Many cloud security tools and even some cloud audits stop at identifying individual vulnerabilities. Attack-chain analysis goes one step further by asking how a real attacker could combine those vulnerabilities.

That is the difference between running a scanner and getting a real secure cloud review. A scanner produces a list of vulnerabilities. A chain-aware review explains how those vulnerabilities could be combined into a realistic attack path, demonstrates the potential impact, and prioritizes remediation based on actual risk rather than individual severity scores.

The same principle is explored from the application-security perspective in Attack Chains: The Hidden Weakness in Modern API & Web Application Security, which explains how attackers chain together seemingly minor application vulnerabilities. For readers interested in the mechanics of AWS privilege escalation itself, AWS Privilege Escalation: IAM, Service & AI Threats provides a comprehensive technical deep dive into IAM, service-based, and AI-era escalation techniques.

This article takes a different perspective. It explores why attack-chain analysis is becoming increasingly important during cloud security reviews, particularly as AI-generated infrastructure introduces more complex permission relationships.

As infrastructure becomes increasingly AI-generated, reviewers are no longer evaluating only what developers intentionally built. They're evaluating combinations of permissions and configurations that may never have been fully reasoned through by a human. 

The AI Angle: Who's Actually Writing Your IAM Policies Now? 

The attack chain above depends on one starting condition: a policy that appears reasonable enough to have been approved but unintentionally enables the first step in an exploit path. Historically, a human wrote that policy, reviewed it, and could explain why it existed. 

Increasingly, that's no longer true. AI coding assistants now generate a substantial share of infrastructure-as-code, producing Terraform modules, IAM policies, and cloud configurations in seconds. While these tools can dramatically improve developer productivity, they generate resources one prompt at a time. They don't reason about how newly created permissions interact with all existing identities, policies, and services across an AWS account. That's exactly where attack chains emerge. 

• Code-quality researchers have found that AI-authored code carries more security vulnerabilities than human-written code, with the gap widening for certain high-risk vulnerability classes.
• Independent testing of AI-generated code has found a large share introduces at least one known security vulnerability when the prompt doesn't explicitly ask for secure output.
• Analysis of AI-generated Terraform specifically has found recurring patterns: wildcard IAM actions, public-by-default storage resources, and missing encryption, largely because the AI defaults to the simplest configuration that satisfies the literal prompt rather than the most restrictive one that satisfies the underlying intent.

Taken together, these vulnerabilities point to the same conclusion: AI can generate infrastructure that is functionally correct while still introducing combinations of permissions and configurations that create exploitable attack paths. 

None of this means AI-assisted infrastructure code is inherently unsafe to use. It means the review burden hasn't gone away; it's shifted. A developer who accepts a 200-line AI-generated Terraform module because it has no syntax errors and passes a terraform plan is checking a different thing than "is this policy safe in combination with everything else in this account." Terraform validate and terraform plan verify syntax and state changes. They don't verify security posture. That requires someone or something to reason about the chain.

This is the gap chain-aware manual review is built to close, and why it matters more as the infrastructure being reviewed is never fully reasoned through by a human in the first place.

What This Means for Engineering Teams Building AI-Assisted Infrastructure 

A few practical takeaways from all of this, for teams shipping AI-assisted infrastructure code:

1. Don't treat "no errors" as "no risk." A terraform apply with a clean plan output tells you the resource will be created as specified. It tells you nothing about whether that resource, combined with everything already in the account, opens an escalation path.
2. Review IAM changes for what they enable, not just what they grant. The riskiest permissions in this demo (create a role, attach a policy, assume a role) are each mundane individually. The risk lives entirely in the combination.
3. Policy-as-code guardrails (OPA, Sentinel, SCPs) are valuable, but they shouldn't be viewed as a substitute for attack-chain analysis. While they can enforce many security rules, some AWS actions and permission models don't lend themselves to fine-grained contextual restrictions, making it difficult to express every security intent in policy alone. As a result, it's still important to review how permissions combine across identities, roles, and services, rather than relying solely on preventative guardrails. Software Secured explores these limitations in more detail in its research on which AWS actions are and aren't blockable. 
4. Get a chain-aware review, not just a scan, before AI-authored infrastructure reaches production at scale. The value of a manual reviewer here isn't finding the individual misconfiguration (a scanner can do that). It's recognizing the combination that turns three unremarkable permissions into full admin access.
5. Think in relationships, not resources. Cloud environments are built from identities, permissions, services, and trust relationships. Reviewing each resource independently is no longer enough. As AI accelerates infrastructure creation, security reviews need to focus on how those components interact to create or prevent attack paths.

FAQ

Can automated cloud security scanners detect attack chains?

Generally, no. Tools like ScoutSuite, Prowler, and similar scanners are effective at surfacing individual misconfigurations, but they report vulnerabilities independently rather than modeling how those vulnerabilities combine into an exploitable path. Identifying a multi-step privilege escalation chain typically requires a human reviewer to validate and connect individual vulnerabilities.

What's the difference between a secure cloud review and a penetration test?

A secure cloud review is a configuration-focused audit of your cloud environment (IAM policies, storage, networking, and service configurations), closer to an expert-led assessment than an active exploitation exercise. A penetration test more broadly simulates an attacker working against a live application or network. Both benefit from attack-chain analysis, but a cloud review specifically targets configuration-level escalation paths like the one described here.

Does AI-generated Terraform or IAM code introduce more security risk than human-written code?

Industry research suggests AI-generated infrastructure code has a higher rate of security vulnerabilities than human-written code, particularly with permissive defaults such as wildcard IAM actions and public-by-default storage resources. This doesn't make AI-assisted IaC unsafe to use, but it does mean that the same or greater level of manual security review is necessary before deployment.

How do you prove a privilege escalation path when you only have read-only cloud access?

AWS's IAM policy simulator (via the CLI's simulate-principal-policy command, or GCP/Azure equivalents) lets a tester check whether a given identity can perform a specific action on a specific resource without actually executing that action. This produces documentable proof of an escalation path even when testers are restricted to auditor-level access, which is common in client engagements.

Want to know whether your cloud environment has an escalation path like this one? Book a consultation to learn more about Software Secured's Secure Cloud Review.