For AI agents: A markdown version of this page is available at https://docs.datadoghq.com/security/default_rules/def-000-jr2.md. A documentation index is available at /llms.txt.

Failed attempt to elevate privileges via multiple AWS roles

Goal

Detects an IAM principal that calls ListRoles and then generates a high volume of failed AssumeRole or UpdateAssumeRolePolicy attempts across many distinct role targets within the evaluation window. An alert fires when role discovery is followed by that failed cross-role activity beyond the rule’s configured threshold.

Strategy

This rule monitors management events where @eventSource is iam.amazonaws.com and @evt.name is ListRoles, paired in the same window with either repeated failed AssumeRole operations or repeated failed UpdateAssumeRolePolicy operations. Failures are identified when @error.kind is present on those API calls. The detection ties the activity to a single @userIdentity.arn. For AssumeRole, it measures how many distinct @requestParameters.roleArn values appear among failures; for UpdateAssumeRolePolicy, it measures how many distinct @requestParameters.roleName values appear among failures. Principals that combine broad role listing with many distinct failed targets surface for review. That pattern is consistent with automated or manual attempts to find and assume or reconfigure higher-privilege roles after enumerating what exists in the account.

Triage & Response

  • Verify whether {{@userIdentity.arn}} is a person, CI/CD role, or integration that is expected to manage or assume IAM roles in the account.
  • Review the ListRoles event and surrounding timeline to confirm it precedes the burst of failed AssumeRole or UpdateAssumeRolePolicy calls from the same principal.
  • Examine failed AssumeRole events for the distinct {{@requestParameters.roleArn}} values involved and whether they match legitimate automation targets or broad role attempts.
  • Examine failed UpdateAssumeRolePolicy events for the distinct {{@requestParameters.roleName}} values involved and whether bulk policy edits align with authorized change workflows.
  • Check CloudTrail for successful AssumeRole or policy changes from the same principal immediately after the failures to determine if escalation eventually succeeded.
  • Determine whether recent IAM or trust-policy changes could explain mass denials versus unexpected use of the principal’s credentials.