AWS attack paths expose how identity weaknesses become account compromise

At a glance

What this is: This is a cloud security analysis showing that AWS IAM weaknesses can be combined into real attack paths that lead to privilege escalation, account compromise, and data exposure.

Why it matters: It matters because IAM, cloud security, and NHI teams need to evaluate whether identities and permissions can actually be abused, not just whether configurations look clean on paper.

By the numbers:

• 25 AWS pentests conducted as part of a, part of a 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.
• In just over 42 minutes, NodeZero safely mapped how an attacker could progress through AWS STS, connected roles, discovered users, and IAM policies to an exploitable weakness.

👉 Read Horizons.ai's blog on AWS attack paths and account compromise risk

Context

AWS IAM is the set of identities, roles, policies, and permissions that determine what cloud actors can do. This article focuses on the gap between finding a misconfiguration and proving that an attacker can chain it into compromise, which is the difference between theoretical exposure and operational risk.

For IAM and cloud security teams, the key question is whether identities can be combined into an attack path that reaches privileged actions or sensitive data. The company used repeated validation to turn cloud risk into a measurable workflow, which is more mature than a one-time assessment and more realistic than relying on configuration snapshots alone.

The article is also a reminder that distributed environments hide important assets and permissions until they are exercised in context. That is typical of large hybrid estates, where visibility alone does not answer the governance question of what the attacker can actually reach.

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: Why do AWS permissions create account compromise risk even without malware?

A: Because attackers can abuse legitimate identity mechanics. If a principal can create credentials, change trust relationships, or assume a stronger role, the cloud platform may hand over power through normal authorization flows. That is why cloud compromise often starts as a permissions problem, not a code execution problem.

Q: How do security teams know whether AWS remediation actually worked?

A: They retest the same attack path after the change. If the path to escalation or sensitive data is no longer reachable, the fix is real. If a new combination of identities and permissions recreates the route, the programme has only reduced visible noise, not actual exposure.

Q: How should organisations reduce AWS identity blast radius?

A: By limiting which identities can create credentials, alter trust, or assume privilege, and by validating those relationships continuously as the environment changes. The objective is not perfect configuration hygiene. It is shrinking the number of reachable paths that can lead from a low-value identity to account control.

Technical breakdown

How AWS IAM permissions become an attack path

AWS IAM risk often appears harmless when viewed as isolated permissions. The problem is that permissions such as iam:CreateAccessKey, UpdateLoginProfile, or UpdateAssumeRolePolicy can be combined with identity discovery and role enumeration to create a path from a low-value foothold to elevated access. In practice, the attacker is not exploiting one misconfiguration, but the relationship between identities, trust policies, STS paths, and privilege boundaries. That is why cloud attack-path analysis matters more than configuration review alone: the exploitable object is the chain, not the control in isolation.

Practical implication: model AWS permissions as chained abuse paths, not as separate review items.

Why privilege escalation in AWS is often identity-driven

Privilege escalation in AWS is frequently driven by identity relationships rather than vulnerabilities in code or infrastructure. If a principal can create credentials, update role trust, or assume a more privileged role, the environment may allow a controlled escalation without malware or exploit code. This is a classic NHI problem because the attacker is borrowing legitimate identity mechanics. The security lesson is that cloud compromise is often an authorization problem, where the policy graph enables movement that the defender did not intend.

Practical implication: inspect role trust, credential creation, and assumption permissions together during cloud reviews.

Why repeated validation changes cloud security governance

A one-off pentest gives a snapshot, but cloud identity risk is dynamic because permissions, workloads, and relationships change continuously. Repeated validation shows whether a fixed weakness has actually been removed and whether a new combination of permissions reopened the path later. That makes the testing model closer to governance than point-in-time assurance. For practitioners, the important distinction is between a mitigated finding and a closed attack path, because the latter is what matters for operational risk.

Practical implication: verify remediation by retesting the attack path, not by closing tickets alone.

Threat narrative

Attacker objective: The attacker objective is to turn ordinary AWS identity access into privileged control of the account and exposure of sensitive data.

1. Entry begins with access to AWS identities and IAM policies that can be enumerated inside the environment, creating the starting point for attack-path discovery.
2. Escalation occurs when permissions such as iam:CreateAccessKey, role trust changes, and STS assumptions allow the actor to move from ordinary access to higher privilege.
3. Impact follows when the attacker can potentially reach full AWS account compromise or sensitive data exposure through the chained identity path.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Attack-path visibility is now the real control plane for AWS identity risk. The article shows that isolated IAM findings only became meaningful when they were chained into actions that could lead to account compromise. That is the right frame for NHI governance in cloud estates: a permission matters only when it can be operationalised by an attacker. Practitioners should treat attack-path evidence as the governing unit of risk, not the raw misconfiguration count.

Standing trust in cloud identity is the weakness attackers exploit first. AWS environments often assume that credentials, roles, and policies can be reviewed independently and remediated later. This article shows that attacker value comes from combining them quickly into privilege escalation paths, which means the governance issue is not a single bad permission but the persistence of usable identity relationships. Security teams need to judge whether trust boundaries are actually breaking attack chains.

Cloud validation must prove closure, not just improvement. The company’s repeated testing model is more mature than periodic audit-style assessment because it checks whether remediation actually removed the exploitable path. That is the practical standard for NHI and IAM programmes in dynamic cloud estates. If the same path can be recreated after a change, the control did not close the risk.

Identity blast radius is the concept practitioners should adopt for AWS estates. The useful question is not which AWS controls are misconfigured, but how far an attacker can travel once one identity is abused. That lens connects IAM, privilege escalation, and sensitive data exposure into a single governance problem. Practitioners should prioritise controls that shrink blast radius, because that is where account compromise becomes containable.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader breach lens, see 52 NHI Breaches Analysis for real-world patterns where identity exposure became operational compromise.

What this signals

Identity blast radius now matters more than static cloud posture. In environments where AWS permissions change as fast as workloads, the question is not whether a role exists but how far it can be abused before detection. Teams that already link findings to attack paths will be better positioned to align cloud governance with NIST SP 800-53 Rev 5 Security and Privacy Controls and Zero Trust thinking.

Cloud validation is becoming a governance loop, not a point-in-time test. Repeated attack-path testing gives security leaders a way to prove that remediation changed outcomes, which is the operational standard many IAM programmes still lack. The next maturity step is to connect validation results to access lifecycle decisions, especially where Top 10 NHI Issues expose overprivilege and exposure persistence.

Attack-path closure is the metric that should sit beside remediation counts. The programme signal is simple: if the path can be recreated, the exposure still exists. That mindset also aligns well with the OWASP Non-Human Identity Top 10, because privileged identity relationships are what make cloud compromise scalable.

For practitioners

• Map AWS identity attack paths before remediating findings Group IAM permissions, role trust policies, and STS assumptions into end-to-end attack paths so you can see which identities enable escalation and which only create noise.
• Prioritise permissions that enable credential creation or role takeover Review actions such as credential creation, login profile changes, and role trust updates as high-risk because they can convert ordinary access into privileged access.
• Retest after every cloud change Re-run validation after policy, role, or workload changes to confirm that the exploitable path is actually closed and has not reappeared through a new permission combination.
• Measure remediation by attack-path closure Track whether a path to sensitive data or account compromise is no longer reachable, rather than reporting only the number of findings reduced.

Key takeaways

• AWS IAM weaknesses become materially important when they can be chained into a reachable attack path.
• Repeated validation is stronger than static assessment because it proves whether remediation actually removed compromise routes.
• Practitioners should measure cloud identity security by blast radius and path closure, not by the number of findings alone.

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.
• 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.
• 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.

What's in the full article

Horizons.ai's full blog covers the operational detail this post intentionally leaves for the source:

• The specific AWS IAM permission combinations that created the tested escalation paths.
• The before-and-after remediation sequence showing how 102 weaknesses were reduced to one open item in one view.
• The broader validation workflow across cloud, internal, external, and web application environments.
• The threat-actor mapping that linked findings to known adversary techniques.

👉 Horizons.ai's full post covers the AWS pathing details, mitigation progress, and repeated validation results.

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 building or maturing an IAM programme, it is worth exploring.