AWS IAM Inline Policy Added to a Group

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

AWS IAM Inline Policy Added to a Group

edit

Identifies an inline policy added to an IAM group via PutGroupPolicy. An inline policy attached to a group grants its permissions to every current and future member of that group. Adversaries can abuse this to escalate privileges (grant elevated permissions to a group they belong to, or will add themselves to) and to establish persistence through a durable, membership-based grant that is easy to overlook. Group inline policies are uncommon compared to managed-policy attachments, so their creation by an unexpected principal warrants review.

Rule type: query

Rule indices:

  • logs-aws.cloudtrail-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Domain: Identity
  • Data Source: AWS
  • Data Source: Amazon Web Services
  • Data Source: AWS IAM
  • Use Case: Threat Detection
  • Tactic: Privilege Escalation
  • Tactic: Persistence
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating AWS IAM Inline Policy Added to a Group

PutGroupPolicy embeds an inline permissions policy directly on an IAM group. Because the policy applies to all members of the group, it is an effective way to broadly grant permissions — and, for an adversary, to escalate privileges or persist while drawing less attention than attaching a well-known managed policy such as AdministratorAccess. Group inline policies are relatively rare, which makes their creation a useful signal.

Possible investigation steps

  • Identify the actor in aws.cloudtrail.user_identity.arn, aws.cloudtrail.user_identity.type, and aws.cloudtrail.user_identity.session_context.session_issuer.arn, and review source.ip / user_agent.original to determine how the change was made.
  • Inspect aws.cloudtrail.request_parameters for the targeted groupName, the policyName, and the policyDocument to assess what permissions were granted (look for broad Action/Resource of *, IAM, or data-access permissions).
  • Enumerate the group’s current members to understand who immediately gains the new permissions, and whether the actor is or could become a member.
  • Confirm whether the change aligns with an approved access request, onboarding, or deployment.
  • Correlate with recent activity by the same principal, such as group creation, adding users to the group, or other IAM modifications that may form an escalation chain.

False positive analysis

  • Approved access governance and infrastructure-as-code may add group inline policies. Confirm the change is expected and exclude known administration roles or automation on aws.cloudtrail.user_identity.arn after validation.

Response and remediation

  • If the change is unauthorized, remove the inline policy from the group (DeleteGroupPolicy) and review which members used the granted permissions while it was in place.
  • Rotate or restrict credentials for the principal if compromise is suspected, and constrain iam:PutGroupPolicy to a small set of trusted administrators.

Additional information

Rule query

edit
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "iam.amazonaws.com"
    and event.action: "PutGroupPolicy"
    and event.outcome: "success"
    and not aws.cloudtrail.user_identity.type: "AWSService"
    and not user_agent.original: (*terraform* or *pulumi* or *ansible*)
    and not aws.cloudtrail.user_identity.arn: (*terraform* or *pulumi* or *ansible*)
    and not source.as.organization.name: (Amazon* or AMAZON* or Google*)
    and not source.address: ("cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com")

Framework: MITRE ATT&CKTM