> 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_full_control.md). # AWS\_FULL\_CONTROL ## Summary | | | | -------------------------- | ------------------------------------------------------------------------------------- | | **Forestall ACL Alias** | AWS\_FULL\_CONTROL | | **Edge Type** | Attack Path | | **Affected Object Types** | IAM User, IAM Role, IAM Group, IAM Policy, Identity Center, Permission Set, SSO Group | | **Exploitation Certainty** | Certain | | **AWS IAM Action** | `*` (all AWS actions, god mode) | ## Description `AWS_FULL_CONTROL` is emitted when a principal (User or Role) holds an `Allow` policy statement whose `Action` is the wildcard `*`. That is every AWS action across every service. This is AWS's god-mode edge. It is broader than [`AWS_IAM_FULL_CONTROL`](https://docs.forestall.io/fsprotect/edges/aws/aws_iam_full_control), which covers only `iam:*`. A principal with `Action: "*"` can perform any IAM operation and any operation in any other AWS service: EC2, S3, STS, Lambda, Organizations, and everything else. A single `*` statement subsumes every individual escalation primitive across all services, so Forestall ISPM collapses them into this one edge. When this edge is present, the per-action escalation edges (e.g., `AWS_CREATE_DELETE_ACCESS_KEY`, `AWS_ATTACH_USER_POLICY`, `AWS_IAM_FULL_CONTROL`) are **not** emitted for the same statement. `AWS_FULL_CONTROL` alone signals that every attack path is open, IAM and non-IAM alike. ### Edge Scope A policy statement qualifies when its `Action` is `*` with `Effect: Allow`. The target objects depend on the statement's `Resource`: * **`Resource: "*"`** (or unscoped): full control over every IAM object in the account graph. All users, roles, groups, policies. * **Specific `Resource` ARNs**: full control over only the objects those ARNs resolve to. Self-edges are not emitted. A principal controlling itself is not an attack path. ## Identification ### via AWS CLI ```bash # List all policies attached to a user aws iam list-attached-user-policies --user-name aws iam list-user-policies --user-name # Get policy document, look for Action: "*" aws iam get-policy-version \ --policy-arn \ --version-id $(aws iam get-policy --policy-arn \ --query 'Policy.DefaultVersionId' --output text) # List all policies attached to a role aws iam list-attached-role-policies --role-name # Simulate whether a principal has unrestricted access aws iam simulate-principal-policy \ --policy-source-arn \ --action-names "iam:CreateUser" "s3:PutObject" "ec2:RunInstances" "sts:AssumeRole" ``` ## Exploitation `Action: "*"` hands you every escalation primitive at once, in IAM and beyond. Each IAM primitive has its own edge page with the exact commands, mitigation, and detection. Pick the path that fits the target. ### IAM User You can create a fresh access key on the target user for persistent programmatic access. See the [`AWS_CREATE_ACCESS_KEY`](https://docs.forestall.io/fsprotect/edges/aws/aws_create_access_key) edge for complete abuse details. You can set or reset the user's console password to log in as them directly. See the [`AWS_CREATE_LOGIN_PROFILE`](https://docs.forestall.io/fsprotect/edges/aws/aws_create_login_profile) and [`AWS_UPDATE_LOGIN_PROFILE`](https://docs.forestall.io/fsprotect/edges/aws/aws_update_login_profile) edges for complete abuse details. You can attach an administrator-equivalent managed policy to the user. See the [`AWS_ATTACH_USER_POLICY`](https://docs.forestall.io/fsprotect/edges/aws/aws_attach_user_policy) edge for complete abuse details. You can write a permissive inline policy directly on the user. See the [`AWS_PUT_USER_POLICY`](https://docs.forestall.io/fsprotect/edges/aws/aws_put_user_policy) edge for complete abuse details. You can add the user to a privileged group to inherit its permissions. See the [`AWS_ADD_MEMBER`](https://docs.forestall.io/fsprotect/edges/aws/aws_add_member) edge for complete abuse details. ### IAM Role You can rewrite the role's trust policy to allow yourself to assume it, then assume the role directly. See the [`AWS_UPDATE_TRUST_AND_ASSUME`](https://docs.forestall.io/fsprotect/edges/aws/aws_update_trust_and_assume) and [`AWS_ASSUME_ROLE`](https://docs.forestall.io/fsprotect/edges/aws/aws_assume_role) edges for complete abuse details. You can attach an administrator-equivalent managed policy to the role. See the [`AWS_ATTACH_ROLE_POLICY`](https://docs.forestall.io/fsprotect/edges/aws/aws_attach_role_policy) edge for complete abuse details. You can write a permissive inline policy directly on the role. See the [`AWS_PUT_ROLE_POLICY`](https://docs.forestall.io/fsprotect/edges/aws/aws_put_role_policy) edge for complete abuse details. ### IAM Group You can add yourself, or any principal you control, to the group to inherit its permissions. See the [`AWS_ADD_MEMBER`](https://docs.forestall.io/fsprotect/edges/aws/aws_add_member) edge for complete abuse details. You can attach an administrator-equivalent managed policy to the group. See the [`AWS_ATTACH_GROUP_POLICY`](https://docs.forestall.io/fsprotect/edges/aws/aws_attach_group_policy) edge for complete abuse details. You can write a permissive inline policy directly on the group. See the [`AWS_PUT_GROUP_POLICY`](https://docs.forestall.io/fsprotect/edges/aws/aws_put_group_policy) edge for complete abuse details. ### IAM Policy You can push a new, permissive policy version and set it as the default, so every principal already attached to the policy inherits the new grant. See the [`AWS_CREATE_POLICY_VERSION`](https://docs.forestall.io/fsprotect/edges/aws/aws_create_policy_version) and [`AWS_SET_DEFAULT_POLICY_VERSION`](https://docs.forestall.io/fsprotect/edges/aws/aws_set_default_policy_version) edges for complete abuse details. ### IAM Identity Center (SSO) `Action: "*"` includes `sso:*`, so it subsumes SSO full control the same way it subsumes IAM full control. When `AWS_FULL_CONTROL` is present, the separate [`AWS_SSO_FULL_CONTROL`](https://docs.forestall.io/fsprotect/edges/aws/aws_sso_full_control) edge is **not** emitted. The god-mode edge already covers it. The SSO control plane only answers from the Organizations management account or an Identity Center delegated-administrator account, so these paths open when the principal lives in such an account. You can assign a privileged permission set to an SSO principal you control and take over the target account. See the [`AWS_SSO_ASSIGN_PERMISSION_SET`](https://docs.forestall.io/fsprotect/edges/aws/aws_sso_assign_permission_set) edge for complete abuse details. You can rewrite a permission set's policies so every account it is assigned to inherits the new grant. See the [`AWS_SSO_UPDATE_PERMISSION_SET`](https://docs.forestall.io/fsprotect/edges/aws/aws_sso_update_permission_set) edge for complete abuse details. You can add an SSO principal you control to a privileged SSO group to inherit its assignments. See the [`AWS_SSO_ADD_MEMBER`](https://docs.forestall.io/fsprotect/edges/aws/aws_sso_add_member) edge for complete abuse details. Over the SSO plane this edge targets the Identity Center instance, its Permission Sets, and its SSO groups. It is not drawn to individual SSO users, which are endpoints rather than pivots. Because the grant is not limited to IAM, the same identity can also act directly in every other service, including S3, EC2, STS, Lambda, and Organizations. Those paths fall outside this edge, but they are open all the same. ## Mitigation 1. Do not grant `Action: "*"` in IAM policy statements. Scope actions to the specific services and operations each principal needs. 2. Apply **permission boundaries** to IAM users and roles to cap effective permissions even when policies are overly broad. 3. Use **Service Control Policies (SCPs)** at the Organizations level to deny `*` for non-administrative accounts. 4. Enable **AWS IAM Access Analyzer** to surface policies that grant wildcard actions. 5. Periodically audit IAM policies attached to users, roles, and groups for wildcard action patterns. ## Detection Monitor these CloudTrail events to catch exploitation of full control: | Event | Description | Key Fields | | --------------------------------------------------- | ------------------------------------ | --------------------------------------------------------------- | | `iam:CreateAccessKey` | New programmatic credentials created | `userAgent`, `requestParameters.userName` | | `iam:CreateLoginProfile` / `iam:UpdateLoginProfile` | Console password created or changed | `requestParameters.userName` | | `iam:AttachUserPolicy` / `iam:AttachRolePolicy` | Managed policy attached | `requestParameters.policyArn` | | `iam:UpdateAssumeRolePolicy` | Trust policy modified on a role | `requestParameters.roleName` | | `iam:CreatePolicyVersion` | New policy version created | `requestParameters.policyArn`, `requestParameters.setAsDefault` | | `iam:SetDefaultPolicyVersion` | Policy default version changed | `requestParameters.policyArn`, `requestParameters.versionId` | | `iam:AddUserToGroup` | User added to a group | `requestParameters.groupName`, `requestParameters.userName` | Alert when the caller is not a known automation role or break-glass account. Because `Action: "*"` covers non-IAM services too, also watch for high-risk events elsewhere, such as `s3:PutObject`, `ec2:RunInstances`, and `sts:AssumeRole`. ## References * [AWS IAM Actions Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html) * [AWS IAM Privilege Escalation - Rhino Security Labs](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) * [AWS IAM Permission Boundaries](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) * [AWS Service Control Policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) * [CloudTrail Event Reference - IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html)