AWS privilege escalation paths: what IAM teams need to know

TL;DR: Independent testing against 16 known AWS attack paths found that unrestricted environments remained exploitable while Cloud Permissions Firewall controls blocked all 16 scenarios, including privilege escalation, persistence, and lateral movement paths, according to Sonrai Security. The result reinforces that cloud least privilege must be enforced at execution time, not only described in policy.

NHIMG editorial — based on content published by Sonrai Security: Independent Testing Confirms Sonrai’s Cloud Permissions Firewall Blocks Real AWS Attack Paths

By the numbers:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

Questions worth separating out

Q: How should teams stop AWS privilege escalation without breaking cloud operations?

A: Teams should identify the few AWS actions that enable escalation or persistence, then require just-in-time approval for those actions only.

Q: Why do over-privileged cloud identities create such a large attack surface?

A: Over-privileged cloud identities make ordinary administrative actions dangerous because an attacker can chain them into key creation, policy changes, session access, or code modification.

Q: What do security teams get wrong about least privilege in AWS?

A: They often treat least privilege as a policy state rather than an execution control.

Practitioner guidance

• Map privilege escalation chains to specific AWS actions Identify which IAM, Lambda, Systems Manager, and Bedrock AgentCore permissions can be combined into escalation, persistence, or pivoting paths, then block the highest-risk actions first.
• Replace standing privilege with just-in-time approvals Require approval for access key creation, role policy attachment, login profile changes, session start, and code update actions so privileged use is task-scoped rather than persistent.
• Extend access reviews beyond human-style roles Review service permissions, orchestration layers, and AI service actions as part of the same cloud identity governance process, because attackers move through service paths as easily as through identities.

What's in the full article

Sonrai Security's full blog post covers the operational detail this post intentionally leaves for the source:

• The full scenario list of 16 tested attack paths, including which AWS services each path touched.
• The specific high-risk permissions that were gated for approval during the lab validation.
• The protected-service breakdown for IAM, Systems Manager, Lambda, and Bedrock AgentCore.
• The testing methodology used by Software Secured to compare unrestricted and protected environments.

👉 Read Sonrai Security's analysis of AWS attack paths and cloud privilege controls →

AWS privilege escalation paths: what IAM teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →