AWS attack paths expose how identity weaknesses become account compromise

At a glance

What this is: This is an analysis of repeated AWS pentesting that showed how IAM weaknesses can be combined into privilege escalation, full account compromise paths, and sensitive data exposure.

Why it matters: It matters because cloud security teams need to prioritise exploitable identity relationships and attack paths, not just inventory misconfigurations or isolated permission findings.

By the numbers:

• At least 25 AWS pentests were conducted as part of the broader security validation program.
• Four AWS weaknesses connected to 25 potential impacts, including 22 paths to AWS full account compromise and three involving sensitive data exposure.
• 102 weaknesses were mitigated, with only one remaining open in one AWS testing view.
• NodeZero mapped the attack path in just over 42 minutes without disrupting the production environment.

Context

AWS identity weaknesses become more serious when permissions can be chained into an attack path with real impact. In this case, the primary governance gap was not a single misconfiguration but the absence of a repeatable way to test what an attacker could actually do with identities, roles, and permissions inside a live cloud environment.

For IAM teams, that shifts the operational question from “what is misconfigured?” to “which identity relationships are exploitable?” Repeated validation is what turns cloud posture from a static checklist into an evidence-based control loop that can confirm whether remediation really closes the path.

Key questions

Q: What breaks when AWS IAM findings are treated as isolated misconfigurations?

A: You miss the way permissions combine into a usable attack path. A harmless-looking IAM action can become dangerous when it connects to role trust, credential creation, or STS assumptions. The right unit of analysis is the reachable path to privilege escalation or data exposure, not the finding count alone.

Q: When should cloud teams prioritise attack-path validation over configuration review?

A: Prioritise attack-path validation when the question is not simply compliance but whether an attacker can escalate privileges or reach sensitive data. Configuration review is useful for hygiene, but validation is what proves business impact. If the environment is changing frequently, path testing should carry more weight.

Q: What do teams get wrong when they try to identify AWS IAM privilege escalation paths?

A: A common mistake is focusing only on obvious checks like missing MFA while missing deeper misconfigurations in role trust, policy versioning, or service-to-service access. Teams also underestimate how many exploit paths depend on resource context outside IAM itself. Effective assessment requires testing the full permission graph, not just scanning for isolated risky settings.

Q: How should teams respond when repeated pentesting shows new AWS attack paths?

A: Treat the new path as evidence that identity or policy drift has reopened exposure. Reassess the specific permissions, role relationships, and account boundaries that changed, then re-test after remediation. The goal is not to reduce findings in the abstract, but to keep the same compromise outcome from being reproducible.

Technical breakdown

How AWS IAM permissions become attack paths

AWS IAM risk is rarely about one bad setting in isolation. Attackers look for permission combinations that let them move from one identity context to another, especially where roles, temporary credentials, and access-key creation interact. In this article, the notable example was a path involving iam:CreateAccessKey, which can let a principal create credentials for another IAM user if permissions are overly broad. That matters because the attack surface is not the permission alone, but the reachable sequence of actions once that permission exists alongside other identity and STS conditions.

Practical implication: Map IAM permissions as sequences, not snapshots, so you can identify compound paths before an attacker does.

Why repeated pentesting exposes exploitable cloud drift

Repeated testing matters because cloud environments are not static. Identities, policies, applications, and resources change over time, so a path that was closed during one assessment can reopen later through policy drift or new permission relationships. The article shows the value of rerunning tests after remediation because validation is only meaningful if the same attacker outcome can no longer be reproduced. This is less about finding more findings and more about proving that a specific compromise path has been removed.

Practical implication: Treat remediation as incomplete until a repeat test proves the exploitable path no longer exists.

Why attack-path validation is different from configuration review

Configuration review tells you whether a setting deviates from a policy baseline. Attack-path validation tells you whether that deviation can be chained into privilege escalation, account compromise, or data exposure. That difference is crucial in AWS because apparently minor permission choices can produce material impact when combined with role assumption, temporary credentials, or access key creation. For defenders, the unit of analysis has to be reachable impact, not just isolated misconfiguration counts.

Practical implication: Prioritise the permissions that create reachable compromise, not the largest pile of low-context findings.

Threat narrative

Attacker objective: The attacker objective is to move from weak AWS identity conditions to privileged account compromise and sensitive data exposure.

1. Entry was not described as an intrusion into a compromised host but as exploitable access through AWS IAM weaknesses and policy combinations.
2. Credential and permission exposure enabled the attacker path, including conditions involving AWS users, IAM policies, STS, and CreateAccessKey.
3. Escalation occurred when those permissions could be chained into privilege escalation and a potential full account compromise path.
4. Impact included potential sensitive data exposure and control of the AWS account if the path were executed end to end.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Exploitability, not misconfiguration count, is the real cloud security metric. A long list of AWS findings does not tell defenders which issues can be chained into privilege escalation or account compromise. The operational question is whether identities, roles, and permissions can be combined into a reachable attack path. That is why repeated validation is more useful than static review alone, because it measures whether an adversary can still get somewhere meaningful.

Identity relationships in AWS are the control plane attackers actually abuse. The article’s CreateAccessKey example shows how a single permission can become dangerous only when it sits inside a broader relationship between users, STS, and IAM policy scope. That is a governance problem, not just a configuration problem. Practitioners should treat identity linkage as the primary unit of cloud risk analysis.

Attack-path testing closes the gap between posture and outcome. Cloud programmes often report configuration status, but business risk depends on whether a bad setting reaches sensitive data or account control. Testing that proves an exploitable path is gone gives security teams a stronger basis for prioritisation, because it ties remediation to outcomes rather than to abstract hygiene.

Repeatable cloud validation is now part of identity governance, not just pentesting. When repeated AWS tests show 102 weaknesses mitigated and only one remaining open, the message is that governance has to prove continued closure as the environment changes. That shifts teams toward continuous verification of IAM scope, not one-off audit comfort.

Cloud identity governance must be measured by reachable blast radius. A policy may look acceptable on paper and still allow privilege escalation under the right conditions. The named concept here is identity blast radius: the amount of control an attacker can reach once an AWS identity weakness is chained with other permissions. Practitioners should use that concept to decide which findings deserve immediate attention.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Identity Security Posture Management (ISPM) Guide

What this signals

Identity blast radius: AWS teams need to measure how far a principal can move once permissions are chained, because the useful question is no longer whether a policy is clean but whether it is exploitable. That makes attack-path testing a governance control as much as a security test.

Repeated validation gives practitioners a better signal than a one-time review because cloud identity risk drifts as roles, STS relationships, and permissions change. If the same compromise path can still be reproduced after remediation, the control was not actually closed.

The wider lesson for cloud IAM programmes is that exposure is often created through third-party-linked identity sprawl as much as through direct administrator mistakes, and the blast radius is defined by what an attacker can reach, not what the policy intended.

For practitioners

• Model AWS permissions as attack paths Trace how users, roles, STS sessions, and permissions combine into reachable compromise paths instead of reviewing each control in isolation.
• Prioritise CreateAccessKey-style permissions Review permissions that can mint or expand credentials, especially where one identity can create access for another or assume broader privileges.
• Repeat validation after every remediation cycle Re-test the same AWS scenarios after fixes so you can prove the exploit chain is gone rather than assuming a policy change solved it.
• Track reachable impact, not just misconfigurations Use findings that map to full account compromise or sensitive data exposure as the primary prioritisation signal for cloud IAM work.

Key takeaways

• AWS identity risk becomes material when a permission can be chained into privilege escalation rather than treated as a standalone misconfiguration.
• The article shows 22 paths to full account compromise and three sensitive data exposure paths, which is why reachability matters more than finding counts.
• Repeated testing matters because remediation only counts when the same attack path can no longer be reproduced.

Key terms

• Attack path: A sequence of identities, permissions, systems, and data stores that an attacker can traverse after obtaining trusted access. In practice, attack paths matter more than single accounts because they show how a low-risk identity can become a route to high-value exposure.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Repeated Validation: Repeated validation is the practice of re-testing a live environment after remediation to confirm the same attack outcome is no longer achievable. It turns cloud security from a one-time assessment into a continuous proof of control effectiveness, which is especially important where identities and permissions change frequently.
• Privilege Escalation: An attack technique where a compromised identity, often an NHI with initially limited permissions, exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.