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

  1. Open IAMUsers or Roles → select any entity.

  2. The ARN field shows arn:aws:iam::<account-id>:user/<name> — the 12-digit segment is the account ID.

  3. Open Account Settings (top-right user menu → Security credentials) to view the account alias and ID for the current session.

  4. 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, DeleteUser

  • CreateRole, DeleteRole

  • CreateGroup, DeleteGroup

Monitor for new entity creation in accounts where no changes are expected:

References

Last updated

Was this helpful?