AWS_IN_ACCOUNT
Summary
FSProtect ACL Alias
AWS_IN_ACCOUNT
Edge Type
Relationship
Affected Object Types
IAM Users, IAM Roles, IAM Groups, AWS Accounts
Exploitation Certainty
Certain
AWS IAM Action / Condition
Relationship visibility via iam:GetUser, iam:GetRole, sts:GetCallerIdentity
Description
AWS_IN_ACCOUNT represents that an IAM entity (user, role, or group) belongs to a specific AWS account.
An AWS account is the fundamental isolation boundary in the AWS environment. Every IAM entity — users, roles, groups, and policies — is scoped to exactly one account and carries that account's 12-digit account ID in its ARN. This account boundary governs:
The default scope of IAM permissions (intra-account by default).
Which principals can be referenced in resource-based policies and trust policies.
The applicability of Service Control Policies (SCPs) from AWS Organizations.
This edge is not directly exploitable, but it is critical for constructing complete attack graphs. Knowing which account an entity belongs to determines:
Whether cross-account trust relationships are needed to move laterally.
Whether SCPs from a parent organizational unit restrict what permissions the entity can exercise even if IAM policies would otherwise allow them.
The blast radius of a compromised identity — a misconfigured role in a production account has a different impact than one in a sandbox account.
Identification
AWS CLI
Identify the current caller's account and identity:
Retrieve account details for a user (includes the account's ARN):
Extract the account ID from any ARN:
List all IAM users in the current account (confirming account scope):
List all IAM roles in the current account:
AWS Console
Open IAM → Users or Roles → select any entity.
The ARN field shows
arn:aws:iam::<account-id>:user/<name>— the 12-digit segment is the account ID.Open Account Settings (top-right user menu → Security credentials) to view the account alias and ID for the current session.
In AWS Organizations (if available), the Accounts list shows the account name, ID, and organizational placement.
Exploitation
There is no direct exploit path for this edge. AWS_IN_ACCOUNT represents a structural membership relationship.
The security significance lies in what other edges originate from the identified account — particularly whether entities within the account have overly permissive intra-account IAM policies, or whether the account's trust relationships allow lateral movement from or to other accounts.
Mitigation
Use separate AWS accounts per environment (production, staging, development) and per workload boundary to limit blast radius.
Apply SCPs at the organizational unit level to enforce account-wide guardrails regardless of IAM policy configuration.
Avoid long-term credentials (IAM user access keys) in accounts where role assumption or identity federation is available.
Tag accounts consistently and enforce tagging policies via AWS Organizations to maintain visibility into which account hosts what workloads.
Detection
Account membership is static and does not generate audit events by itself. However, the following CloudTrail events are relevant for tracking changes to entities within an account:
CreateUser,DeleteUserCreateRole,DeleteRoleCreateGroup,DeleteGroup
Monitor for new entity creation in accounts where no changes are expected:
References
Last updated
Was this helpful?