> 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_add_member.md). # AWS\_ADD\_MEMBER ## Summary | | | | ------------------------------ | -------------------------------------------- | | **Forestall ACL Alias** | AWS\_ADD\_MEMBER | | **Edge Type** | Attack Path | | **Affected Object Types** | IAM Users, IAM Groups | | **Exploitation Certainty** | Certain | | **AWS IAM Action / Condition** | `iam:AddUserToGroup` on the target IAM group | ## Description `AWS_ADD_MEMBER` is the ability to add an IAM user to an IAM group, picking up every permission the group carries through managed and inline policies. An attacker who controls a low-privilege user can: * Add themselves (or another compromised user) to a privileged group. * Inherit `AdministratorAccess`, `PowerUserAccess`, or any other broad policies attached to that group. * Use those permissions to exfiltrate data, plant backdoors, or escalate further. Unlike `AWS_CREATE_ACCESS_KEY` (credential theft) or `AWS_UPDATE_LOGIN_PROFILE` (console takeover), this edge grants permissions without touching credentials. Credential-layer detection misses it. See also [`AWS_IN_GROUP`](https://docs.forestall.io/fsprotect/edges/aws/aws_in_group) for the resulting membership relationship. ## Identification ### AWS CLI Check whether a principal has `iam:AddUserToGroup` on a specific group: ```bash aws iam simulate-principal-policy \ --policy-source-arn arn:aws:iam::123456789012:user/AnalystUser \ --action-names iam:AddUserToGroup \ --resource-arns arn:aws:iam::123456789012:group/AdminGroup ``` List all groups and their attached policies to find high-value targets: ```bash aws iam list-groups --query 'Groups[].GroupName' --output text ``` ```bash aws iam list-attached-group-policies --group-name AdminGroup ``` Enumerate current members of a group: ```bash aws iam get-group --group-name AdminGroup \ --query 'Users[].UserName' --output table ``` ### AWS Console * Open **IAM** -> **User groups** -> select a privileged group. * Open the **Users** tab to review current members. * Review who holds policies with `iam:AddUserToGroup` permissions by checking **Permissions** on candidate users/roles. ## Exploitation Add the attacker-controlled user to a privileged group: ```bash aws iam add-user-to-group \ --user-name AttackerUser \ --group-name AdminGroup ``` Verify group membership was applied: ```bash aws iam list-groups-for-user --user-name AttackerUser ``` The user now has all permissions from the group's policies. Changes take effect immediately, with no session restart needed. ## Mitigation * Restrict `iam:AddUserToGroup` to a dedicated IAM administration role with MFA enforcement. * Apply SCPs to prevent unrestricted group membership changes outside approved pipelines. * Regularly audit IAM group memberships, especially for groups with `AdministratorAccess` or wide-scope policies. * Prefer temporary role assumption (STS) over group-based long-lived permissions for elevated tasks. * Use AWS IAM Identity Center permission sets rather than IAM groups where possible. ## Detection Monitor CloudTrail for group membership changes: * **Event source**: `iam.amazonaws.com` * **Event name**: `AddUserToGroup` Example lookup: ```bash aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=AddUserToGroup ``` Key investigation signals: * The added user is the same as the caller (self-escalation). * The target group has policies with `*` actions or `AdministratorAccess`. * Event occurs outside normal provisioning windows or CI/CD pipelines. * Followed closely by `CreateAccessKey` or `AssumeRole` calls from the same user. ## References * * * * *