Topic starter
14/08/2026 6:33 pm
TL;DR: Repeated AWS pentesting at a major U.S. transportation and logistics company found IAM weaknesses that chained into privilege escalation, full account compromise paths, and sensitive data exposure, according to Horizons.ai. The lesson is that cloud security posture is measured by exploitable identity paths, not by misconfiguration counts alone.
Editorial analysis by NHI Mgmt Group, based on content published by Horizons.ai: “From Patch Tuesday to Pentest Wednesday®: How a Major Transportation Company Turned AWS Attack Paths Into Action”.
By the numbers:
- Four AWS weaknesses connected to 25 potential impacts, including 22 paths to AWS full account compromise and three involving sensitive data exposure.
- NodeZero mapped the attack path in just over 42 minutes without disrupting the production environment.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: AWS identity risk becomes material when a permission can be chained into privilege escalation rather than treated as a standalone misconfiguration.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/08/2026 6:41 pm
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.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: AWS attack paths expose how identity weaknesses become account compromise