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

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

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.

1. 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.

2. 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.

3. 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.

4. 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