> For the complete documentation index, see [llms.txt](https://docs.forestall.io/fsprotect/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.forestall.io/fsprotect/edges/aws/aws_in_account.md). # 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: ```bash aws sts get-caller-identity ``` Retrieve account details for a user (includes the account's ARN): ```bash aws iam get-user --user-name TargetUser \ --query 'User.{Arn:Arn,UserId:UserId,CreateDate:CreateDate}' ``` Extract the account ID from any ARN: ```bash # ARN format: arn:aws:iam:::user/ aws iam get-user --user-name TargetUser --query 'User.Arn' --output text \ | cut -d: -f5 ``` List all IAM users in the current account (confirming account scope): ```bash aws iam list-users --query 'Users[*].[UserName,Arn]' --output table ``` List all IAM roles in the current account: ```bash aws iam list-roles --query 'Roles[*].[RoleName,Arn]' --output table ``` ### AWS Console 1. Open **IAM** → **Users** or **Roles** → select any entity. 2. The **ARN** field shows `arn:aws:iam:::user/` — 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: ```bash aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=CreateUser \ --query 'Events[*].{Time:EventTime,Actor:Username,Resource:Resources[0].ResourceName}' ``` ## References * * * * --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.forestall.io/fsprotect/edges/aws/aws_in_account.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.