Skip to content

AWS_PARENT_ACCOUNT

Copy page

Summary

Forestall ACL Alias AWS_PARENT_ACCOUNT
AD Alias N/A
Affected Object Types Account → IAM User/Role/Group/Policy
Exploitation Certainty Low
AD Attribute N/A
Attribute GUID N/A
AD Right N/A

Description

AWS_PARENT_ACCOUNT is a structural edge directed parent → child that marks the single AWS account that directly owns an IAM identity:

  • (AWSAccount)-[AWS_PARENT_ACCOUNT]->(AWSIAMUser | AWSIAMRole | AWSIAMGroup | AWSIAMPolicy)

Every IAM entity is scoped to exactly one account and carries that account’s 12-digit ID in its ARN. This edge records that ownership as its own relation, one level of the containment picture rather than the whole chain. It runs parallel to AWS_PARENT, which threads the full hierarchy from the organization root down through OUs to the account. Keeping the account-to-identity link on a dedicated label lets a query reach an identity’s account without walking that chain.

The account is the isolation boundary in AWS. Which account holds an identity decides whether lateral movement needs a cross-account trust, which Service Control Policies apply, and how far a compromised credential can reach. The edge is not exploitable on its own. Its value is that it lets a query pin an identity to its account in one hop without walking the organization hierarchy.

Identification

Read the owning account straight from an entity’s ARN, or confirm the current caller’s account:

# Account ID from an entity ARN (arn:aws:iam::<account-id>:user/<name>)
aws iam get-user --user-name TargetUser --query 'User.Arn' --output text | cut -d: -f5
# The account behind the current credentials
aws sts get-caller-identity --query Account --output text

Forestall ISPM creates this edge during IAM collection by grouping each identity by its account ID and linking it back to the matching AWSAccount node.

Mitigation

  • Use separate accounts per environment and workload so the account boundary is a meaningful containment line.
  • Apply SCPs at the OU level to hold account-wide guardrails regardless of in-account IAM policy.
  • Prefer role assumption or federation over long-lived user access keys in accounts that host sensitive workloads.

Detection

Account ownership is static and raises no events by itself. Watch for identity lifecycle changes inside accounts where none are expected:

  • CreateUser, DeleteUser
  • CreateRole, DeleteRole
  • CreateGroup, DeleteGroup

References

Was this page helpful?

Thank you for your feedback.