AWS Built a Security Tool. It Introduced a Security Risk.

(If you missed the previous parts of this trust policy blog series, we recommend reading parts one and two first)

In the previous post of this series, we explored four dangerous misconceptions regarding how to securely set up cross-account access in AWS environments.

In this final post of the series, we’ll walk through a real-world case where even AWS got it wrong. Their Account Assessment for AWS Organizations tool, designed to audit resource-based policies for risky cross-account access, ironically introduced cross-account privilege escalation risks due to flawed deployment instructions. Specifically, customers were effectively encouraged to deploy the tool in lower-sensitivity accounts, creating risky trust paths from insecure environments into highly sensitive ones.

We’ll share how we discovered the issue, the risks it introduced, how AWS fixed it, and what affected organizations should do to detect and remediate it.

How it started

While investigating a critical privilege escalation risk involving an IAM role in a customer’s AWS environment, we discovered a role present in both their production and management accounts, each of which trusted two roles in their development account:

These were the details of the privilege escalation risk (sensitive info redacted):

Examining the permissions of that role in the production and management accounts, we found it had access to several sensitive IAM and data-related API calls, including:

• iam:ListRoles (lists all IAM roles, helping an attacker identify privileged and vulnerable roles)
• iam:ListPolicies (reveals all IAM policies, exposing potential misconfigurations)
• secretsmanager:ListSecrets (lists all stored secret names, identifying potential targets)
• s3:ListAllMyBuckets (enumerates all S3 buckets, exposing potential sensitive data locations)
• kms:ListKeys (lists all encryption keys, indicating what is being encrypted)
• kms:GetKeyPolicy (retrieves key policies, which could reveal weak or misconfigured access controls)
• … and more (full policy here)

These permissions were granted on all resources (resource: "*"), making them particularly dangerous if compromised.

The organization's dev account had weaker security, making this role assumption path a major risk. An attacker compromising a trusted role in dev could immediately gain these permissions in production and management. Combined with other misconfigurations - such as exposed IAM roles, secret names, KMS keys, or public S3 buckets - this could help lead to compromise of the organization's most sensitive accounts.

This was already a serious risk, but what we found next revealed that this misconfiguration was not unique to this organization - it was actually inadvertently encouraged by AWS itself.

Account Assessment for AWS Organizations

The names of these roles were somewhat quirky, and hinted they were part of some automated system. A quick search led us to Account Assessment for AWS Organizations, a tool developed by AWS and published in the AWS Solutions Library.

According to its official documentation, the tool is designed to “centrally evaluate and manage AWS accounts within your AWS Organizations”, helping users better understand account dependencies. AWS lists its primary use cases as mergers and acquisitions, security audits, centralized policy explorer and management account transitions.

So, why was it deployed insecurely?

Given that this tool was built by AWS to audit resource-based cross-account access, we initially assumed the misconfiguration was a deployment error by the customer. However, after reviewing the documentation, we realized that AWS’s deployment instructions unintentionally encouraged insecure setups, making it highly likely that users would deploy the tool in a way that introduced privilege escalation risks.

The tool follows a hub-and-spoke architecture:

• A hub role is deployed in a designated hub account.
• Spoke roles are deployed in all other accounts to be assessed, trusting the hub role for access.

This design allows the hub role to assume the spoke roles across all accounts, aggregating security data across the organization.

When checking AWS's official deployment guidance, we were surprised to see the following instruction:

"Hub stack - Deploy to any member account in your AWS Organization except the Organizations management account."

This is the root cause of the issue - AWS explicitly recommended not deploying the hub in the management account, without clarifying the security implications of the other possible choices.

Why this is a major security risk

Let’s back up a bit and explain why this instruction, without any clarification, was so problematic.

As we covered in the previous blog, allowing a role in a less secure account to assume roles in more sensitive accounts creates a privilege escalation risk.

By design, the hub role must access all spoke accounts. Since AWS prohibited using the management account as the hub, customers were forced to deploy the hub in a less secure account - often a development, sandbox, or similarly low-sensitivity account. In deployed organizations, this led to the creation of a direct trust path from a lower-security account to higher-security accounts like production, PCI-DSS environments, and even the management account itself.

The following diagram visualizes the problem:

In the case we investigated, the customer deployed the hub role in their development account, which:

1. (Reasonably) had weaker security controls than production or management.
2. Had full access to assume spoke roles across all accounts, including sensitive ones such as the management and production accounts

This meant that if an attacker compromised the development account, they could pivot into the management account - make it much easier to gain control over the entire AWS organization.

AWS strongly advises against running workloads in the management account, so simply deploying the hub there is not an ideal solution either. Instead, the only relatively safe option is to choose an account which is as secure as the management account, such as a centralized DevOps or Infrastructure account with strict access controls.

However, some organizations don’t necessarily have such an account, meaning any deployment inherently introduces risk. The problem isn't just where to deploy the hub - it's that AWS's default recommendation pushed organizations into an insecure setup without any reference to the security implications of this choice.

Implications for affected organizations

Any organization that deployed this tool following AWS’s instructions (before they were fixed on 2025-01-28) with the hub role deployed in an account less secure than the management account - and hasn’t removed it - is at risk.

For affected orgs, the hub account (where the hub role is deployed) becomes a high-value target. If an attacker compromises this role, whether through direct access or privilege escalation, they can assume spoke roles across all linked accounts - including highly sensitive environments such as management and production.

Once inside, they can:

• Enumerate IAM roles, trust policies, and permissions, identifying weak points.
• List all S3 buckets and secret names, mapping out valuable data targets.
• Access KMS key policies, which may reveal misconfigured encryption controls.

Additionally, the tool’s predefined role names make it even easier for attackers to exploit. If an attacker gains access to any AWS account within an affected organization, they can easily identify whether the tool is deployed and know the exact role names that can be assumed from the hub account. This reduces the effort needed to escalate privileges and pivot into high-value environments.

Detecting and remediating

Here are two methods to determine if your organization is affected:

• Use the AWS Console to manually search the IAM role page in any suspected accounts for the hub and spoke roles. These roles contain the strings ScanSpokeResource and AccountAssessment-Spoke-ExecutionRole in their names accordingly.
• Run the following AWS CLI command to check if the tool is deployed in a given account: aws iam list-roles --query "Roles[?contains(RoleName, 'ScanSpokeResource') || contains(RoleName, 'AccountAssessment-Spoke-ExecutionRole')]"

If the tool is deployed - Check to see when the tool was deployed by examining the roles’ CreateDate property. If deployed before 2025-01-28, we strongly recommend removing the current deployment unless the hub role is already in a high-security account (such as a dedicated Infrastructure or DevOps account).

1. Uninstall the tool by deleting the CloudFormation stacks for the Hub, Spoke, and Org-Management components. See AWS’s official uninstallation guide for more instructions.
2. Redeploy carefully - if the tool is still needed, deploy the hub role in an account with security equivalent to the management account to prevent privilege escalation risks.

Reporting and resolution

After identifying this issue, we reported it to AWS Security, highlighting the serious risks created by the tool’s deployment guidance. AWS promptly reviewed our findings, acknowledged the security concern, and engaged with us to determine how best to update the documentation to prevent future misconfigurations.

Based on this engagement, AWS revised the documentation to explicitly advise customers to deploy the hub role in a high-security account to match the sensitivity of the accounts being assessed:

‍

We thank the AWS Security team, who were highly responsive, open to feedback, and committed to improving customer security. They took the issue seriously from the start, worked with us to determine the best way to update the documentation, and delivered a clear and effective fix - ensuring organizations deploying this tool can avoid unintended privilege escalation risks in the future.

Reporting timeline

• 2024-12-11 - Discovery of the problematic documentation.
• 2024-12-12 - Initial report to AWS Security.
• 2025-01-02 - AWS acknowledges the issue and begins considering documentation changes.
• 2025-01-05 - We emphasize the importance of correcting the instructions.
• 2025-01-07 - AWS confirms documentation updates are needed.
• 2025-01-13 - 2025-01-17 - Discussion on how to revise the documentation.
• 2025-01-28 - AWS publishes updated documentation with security fixes.
• 2025-04-28 - Findings and resolution publicly shared in this blog post.

Wrapping up

Throughout this blog series, we explored how trust policy risks can slip into even well-managed AWS environments - sometimes through overlooked technical details, subtle misconceptions, or even official tooling. Securing trust relationships is less about following a checklist and more about developing a deeper understanding of how trust mechanisms actually behave in real-world environments.

We hope this series helped shed light on some of the hidden challenges around trust policies. Thanks for reading!

‍

‍

Token Security's machine-first identity security platform detects trust policy risks, including risky cross-account trust policies, whether caused by AWS tooling, human error, or overlooked configurations.

Want to see how it works? Book a demo and let us show you how we help organizations stay ahead of these risks.

‍