AWS IAM role can assume roles in any account
Description
AlphaSOC detected the creation or modification of an AWS IAM policy that grants
permissions to assume IAM roles in any AWS account without proper restrictions.
IAM policies control what actions principals (users, roles, or groups) can
perform, and the sts:AssumeRole action allows a principal to obtain temporary
security credentials for a specified role.
While cross-account role assumption is a legitimate AWS feature used for
federated access, service integrations, and multi-account architectures, overly
permissive policies with wildcard resource specifications (such as
arn:aws:iam::*:role/* or *) allow the holder to assume roles in any AWS
account globally, not just within the organization.
Threat actors may create such policies to establish persistence mechanisms, gain
access to external AWS accounts if role trust policies are misconfigured, or
prepare for lateral movement across account boundaries. This pattern is
particularly concerning when the policy lacks restrictive conditions on
aws:ResourceAccount, aws:ResourceOrgID, or aws:ResourceOrgPaths that would
limit role assumption to known accounts or organizational units.
Impact
IAM policies allowing role assumption in any AWS account create security risks by enabling threat actors to exploit misconfigured trust policies in external accounts. If an attacker obtains credentials for a principal with such a policy, they can enumerate and attempt to assume roles across any AWS account where the role's trust policy permits the principal's account or ARN.
This enables lateral movement beyond the compromised organization into partner accounts, vendor environments, or any misconfigured public role. Adversaries can leverage this for privilege escalation if they discover roles with broader permissions than their current access level, establish persistent backdoor access paths that bypass normal authentication controls, or use assumed role credentials to obscure their activities across multiple accounts.
The overly permissive policy also violates the principle of least privilege and may violate compliance requirements that mandate restricted cross-account access controls. Organizations face risks of data exfiltration from connected accounts, unauthorized resource manipulation across account boundaries, and difficulty in auditing and attribution when attackers chain role assumptions through multiple accounts.
Severity
| Severity | Condition |
|---|---|
Informational | AWS IAM role can assume roles in any account |
Investigation and Remediation
Review AWS CloudTrail logs to identify the policy creation or modification
event, focusing on PutGroupPolicy, PutRolePolicy, PutUserPolicy,
CreatePolicy, or CreatePolicyVersion actions. Examine the IAM principal that
created the policy, including their username or role ARN, source IP address,
user agent, and timestamp to determine if the activity was authorized. Retrieve
the policy document from the CloudTrail request parameters and analyze the
resource specification in statements granting sts:AssumeRole, sts:*, or *
permissions to identify whether wildcards allow assumption of roles in any
account. Verify whether the policy includes restrictive conditions using
aws:ResourceAccount, aws:ResourceOrgID, or aws:ResourceOrgPaths keys that
would limit role assumption to known accounts or organizational boundaries.
If the policy is overly permissive and unauthorized, immediately modify it to
specify explicit role ARNs or restrict the resource pattern to only roles within
your AWS organization using conditions like aws:ResourceOrgID. Use
aws iam get-policy-version and aws iam get-group-policy,
aws iam get-role-policy, or aws iam get-user-policy to retrieve current
policy documents for analysis.
Check if the overly permissive policy has been attached to any additional
principals and review CloudTrail logs for sts:AssumeRole actions by affected
principals to determine if the permission was exploited. Revoke any compromised
credentials that created the policy and rotate access keys for affected IAM
users.
Implement IAM policy validation using AWS IAM Access Analyzer or custom AWS
Config rules to detect and alert on policies with wildcard resources for
sensitive actions like sts:AssumeRole.
Apply Service Control Policies (SCPs) at the AWS Organizations level to prevent creation of overly permissive policies across all accounts. Establish change management procedures requiring review and approval for IAM policy modifications that grant cross-account access permissions.
Known False Positives
- Infrastructure-as-code deployments or IAM policy templates using broad permissions as initial configurations before restriction
- Centralized identity management solutions that legitimately require cross-account role assumption capabilities
- Security tools or compliance scanners that assume roles across multiple accounts for auditing
- Service accounts for multi-account AWS Organizations management that need broad role assumption permissions