Detect IAM Privilege Escalation in AWS CloudTrail

title: AWS IAM Privilege Escalation via Policy Modification
id: 9d2b4f60-7c11-4e83-bb6a-5e1a9f3c7d02
status: experimental
description: >
  Detects IAM actions commonly chained for privilege escalation — attaching a
  managed policy to a user, injecting an inline policy, creating a new policy
  version, or weakening the account password policy. Alerting fidelity is highest
  when scoped to principals that do not normally perform IAM administration.
references:
  - https://attack.mitre.org/techniques/T1098/
author: LogTriage
date: 2026/06/22
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventSource: 'iam.amazonaws.com'
    eventName:
      - 'AttachUserPolicy'
      - 'AttachRolePolicy'
      - 'PutUserPolicy'
      - 'PutRolePolicy'
      - 'CreatePolicyVersion'
      - 'CreatePolicy'
      - 'DeleteAccountPasswordPolicy'
      - 'UpdateAssumeRolePolicy'
  filter_known_admins:
    userIdentity.arn|contains:
      - ':role/PlatformAdmin'
      - ':role/iam-ci'
  condition: selection and not filter_known_admins
falsepositives:
  - Sanctioned IAM administration by platform/CI roles (add them to filter_known_admins)
  - Landing-zone / account bootstrap provisioning
level: high
tags:
  - attack.privilege_escalation
  - attack.persistence
  - attack.t1098

What this rule detects

In AWS, privilege escalation usually means an identity granting itself (or a controlled identity) permissions beyond its intended scope. In CloudTrail that shows up as a small set of IAM-modifying API calls — attaching a managed policy, injecting an inline policy, creating a new policy version, or weakening the account password policy — performed by a principal that has no business doing IAM administration.

This Sigma rule fires on those iam.amazonaws.com event names except when the caller is a known platform/CI admin role (the filter_known_admins allowlist you maintain).

Detection logic

The durable pattern here is “allowlist the admins, flag the rest.” Trying to enumerate every malicious IAM sequence is a losing game; instead, the rule treats sensitive IAM writes as alert-worthy from any principal outside your sanctioned IAM-administration roles. Populate filter_known_admins with your real IAM team and CI roles.

For higher confidence, look at the sequence: privilege escalation commonly chains AssumeRole → AttachUserPolicy/PutUserPolicy → CreateAccessKey. LogTriage groups a principal’s events into a session and maps the chain to ATT&CK so the whole escalation reads as one incident.

Validated against a real sample

Validated against cloudtrail_iam_escalation.json (shipped with LogTriage), which contains an AssumeRole followed by AttachUserPolicy, CreatePolicy, and DeleteAccountPasswordPolicy from a compromised contractor identity. The rule fires on that sample and stays silent on the matching benign operations log.

False positives

Your IAM team and CI/CD pipelines legitimately perform these actions — that’s exactly what filter_known_admins is for. Account bootstrap and landing-zone provisioning can also trip it; scope by account and time window during known provisioning events.