Loading

AWS STS Role Chaining

Identifies role chaining activity. Role chaining is when you use one assumed role to assume a second role through the AWS CLI or API. While this a recognized functionality in AWS, role chaining can be abused for privilege escalation if the subsequent assumed role provides additional privileges. Role chaining can also be used as a persistence mechanism as each AssumeRole action results in a refreshed session token with a 1 hour maximum duration. This is a new terms rule that looks for the first occurance of one role (aws.cloudtrail.user_identity.session_context.session_issuer.arn) assuming another (aws.cloudtrail.resources.arn).

Rule type: new_terms
Rule indices:

  • filebeat-*
  • logs-aws.cloudtrail-*

Rule Severity: medium
Risk Score: 47
Runs every:
Searches indices from: now-6m
Maximum alerts per execution: ?
References:

Tags:

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

Version: ?
Rule authors:

  • Elastic

Rule license: Elastic License v2

Role chaining occurs when a role assumed with temporary credentials (AssumeRole) is used to assume another role. While supported by AWS, chaining can increase risk of Privilege escalation, if the second role grants broader permissions; and Persistence, since each chained AssumeRole refreshes the session with up to 1-hour duration. This new terms rule triggers on the first observed combination of one role (aws.cloudtrail.user_identity.session_context.session_issuer.arn) assuming another (aws.cloudtrail.resources.arn).

  • Review Alert Context: Investigate the alert, focusing on aws.cloudtrail.user_identity.session_context.session_issuer.arn (the calling role) and aws.cloudtrail.resources.arn (the target role).

  • Determine scope and intent. Check aws.cloudtrail.recipient_account_id and aws.cloudtrail.resources.account_id fields to identify whether the chaining is Intra-account (within the same AWS account) or Cross-account (from another AWS account).

  • Check role privileges. Compare policies of the calling and target roles. Determine if chaining increases permissions (for example, access to S3 data, IAM modifications, or admin privileges).

  • Correlate with other activity. Look for related alerts or CloudTrail activity within ±30 minutes: policy changes, unusual S3 access, or use of sensitive APIs. Use aws.cloudtrail.user_identity.arn to track behavior from the same role session, use aws.cloudtrail.user_identity.session_context.session_issuer.arn to track broader behavior from the role itself.

  • Validate legitimacy. Contact the account or service owner to confirm if the chaining was expected (for example, automation pipelines or federated access flows).

  • Geography & source. Review cloud.region, source.address, and other geo fields to assess if the activity originates from expected regions or network ranges.

  • Expected role chaining. Some organizations use role chaining as part of multi-account access strategies. Maintain an allowlist of known issuer.arn - target.arn pairs.
  • Automation and scheduled tasks. CI/CD systems or monitoring tools may assume roles frequently. Validate by userAgent and historical behavior.
  • Test/dev environments. Development accounts may generate experimental chaining patterns. Tune rules or exceptions to exclude low-risk accounts.

Immediate steps

  • Preserve evidence. Export triggering CloudTrail events (±30 minutes) into a restricted evidence bucket. Include session context, source IP, and user agent.
  • Notify owners. Contact the owners of both roles to validate intent.

Containment (if suspicious)

  • Revoke temporary credentials. Revoke Session Permissions if possible, or attach AWSDenyALL policy to the originating role.
  • Restrict risky roles. Apply least-privilege policies or temporarily deny sts:AssumeRole for suspicious principals.
  • Enable monitoring. Ensure CloudTrail and GuardDuty are active in all regions to detect further chaining.

Scope and hunt

  • Search for additional AssumeRole activity by the same issuer.arn or resources.arn across other accounts and regions.
  • Look for privilege escalation attempts (for example, IAM AttachRolePolicy, UpdateAssumeRolePolicy) or sensitive data access following the chain.

Recovery & hardening

  • Apply least privilege to all roles, limiting trust policies to only required principals.
  • Enforce MFA where possible on AssumeRole operations.
  • Periodically review role chaining patterns to validate necessity; remove unused or risky trust relationships.
  • Document and tune new terms exceptions for known, legitimate chains.
  • AWS IR Playbooks: NIST-aligned templates for evidence, containment, eradication, recovery, post-incident.
  • AWS Customer Playbook Framework: Practical response steps for account and IAM misuse scenarios
  • AWS IAM Best Practices: AWS docs for reducing risk from temporary credentials.

The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

event.dataset : "aws.cloudtrail" and
event.provider : "sts.amazonaws.com" and
event.action : "AssumeRole" and
aws.cloudtrail.user_identity.type : "AssumedRole" and
event.outcome : "success"

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK