AWS STS Role Chaining

  1[metadata]
  2creation_date = "2024/10/23"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/10/02"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies role chaining activity. Role chaining is when you use one assumed role to assume a second role through the
 11AWS CLI or API. While this a recognized functionality in AWS, role chaining can be abused for privilege escalation if
 12the subsequent assumed role provides additional privileges. Role chaining can also be used as a persistence mechanism as
 13each 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).
 14"""
 15false_positives = [
 16    """
 17    Role chaining can be used as an access control. Ensure that this behavior is not part of a legitimate operation
 18    before taking action.
 19    """,
 20]
 21from = "now-6m"
 22index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 23language = "kuery"
 24license = "Elastic License v2"
 25name = "AWS STS Role Chaining"
 26note = """
 27## Triage and analysis
 28
 29> **Disclaimer**:
 30> 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.
 31
 32### Investigating AWS STS Role Chaining
 33
 34Role 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`). 
 35
 36### Possible investigation steps
 37
 38- **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).  
 39- **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).  
 40- **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).  
 41- **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.
 42- **Validate legitimacy.** Contact the account or service owner to confirm if the chaining was expected (for example, automation pipelines or federated access flows).  
 43- **Geography & source.** Review `cloud.region`, `source.address`, and other `geo` fields to assess if the activity originates from expected regions or network ranges.  
 44
 45### False positive analysis
 46
 47- **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.  
 48- **Automation and scheduled tasks.** CI/CD systems or monitoring tools may assume roles frequently. Validate by `userAgent` and historical behavior.  
 49- **Test/dev environments.** Development accounts may generate experimental chaining patterns. Tune rules or exceptions to exclude low-risk accounts.  
 50
 51### Response and remediation
 52
 53**1. Immediate steps**
 54- **Preserve evidence.** Export triggering CloudTrail events (±30 minutes) into a restricted evidence bucket. Include session context, source IP, and user agent.  
 55- **Notify owners.** Contact the owners of both roles to validate intent.  
 56
 57**2. Containment (if suspicious)**
 58- **Revoke temporary credentials.** [Revoke Session Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) if possible, or attach [AWSDenyALL policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html) to the originating role.  
 59- **Restrict risky roles.** Apply least-privilege policies or temporarily deny `sts:AssumeRole` for suspicious principals.  
 60- **Enable monitoring.** Ensure CloudTrail and GuardDuty are active in all regions to detect further chaining.  
 61
 62**3. Scope and hunt**
 63- Search for additional AssumeRole activity by the same `issuer.arn` or `resources.arn` across other accounts and regions.  
 64- Look for privilege escalation attempts (for example, IAM `AttachRolePolicy`, `UpdateAssumeRolePolicy`) or sensitive data access following the chain.  
 65
 66**4. Recovery & hardening**
 67- Apply least privilege to all roles, limiting trust policies to only required principals.  
 68- Enforce MFA where possible on AssumeRole operations.  
 69- Periodically review role chaining patterns to validate necessity; remove unused or risky trust relationships.  
 70- Document and tune new terms exceptions for known, legitimate chains.  
 71
 72### Additional information
 73 
 74- [AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/): NIST-aligned templates for evidence, containment, eradication, recovery, post-incident. 
 75- [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/): Practical response steps for account and IAM misuse scenarios
 76- AWS IAM Best Practices: [AWS docs](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) for reducing risk from temporary credentials.  
 77
 78## Setup
 79
 80The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
 81"""
 82references = [
 83    "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts",
 84    "https://www.uptycs.com/blog/detecting-anomalous-aws-sessions-temporary-credentials",
 85    "https://hackingthe.cloud/aws/post_exploitation/role-chain-juggling/",
 86]
 87risk_score = 47
 88rule_id = "ba5a0b0c-b477-4729-a3dc-0147c2049cf1"
 89severity = "medium"
 90tags = [
 91    "Domain: Cloud",
 92    "Data Source: AWS",
 93    "Data Source: Amazon Web Services",
 94    "Data Source: AWS STS",
 95    "Use Case: Threat Detection",
 96    "Tactic: Persistence",
 97    "Tactic: Privilege Escalation",
 98    "Tactic: Lateral Movement",
 99    "Resources: Investigation Guide",
100]
101timestamp_override = "event.ingested"
102type = "new_terms"
103
104query = '''
105    event.dataset : "aws.cloudtrail" and 
106    event.provider : "sts.amazonaws.com" and 
107    event.action : "AssumeRole" and 
108    aws.cloudtrail.user_identity.type : "AssumedRole" and 
109    event.outcome : "success" 
110'''
111
112[rule.investigation_fields]
113field_names = [
114    "@timestamp",
115    "user_agent.original",
116    "source.ip",
117    "user.name",
118    "aws.cloudtrail.user_identity.session_context.session_issuer.arn",
119    "aws.cloudtrail.user_identity.arn",
120    "aws.cloudtrail.user_identity.type",
121    "aws.cloudtrail.user_identity.access_key_id",
122    "aws.cloudtrail.resources.arn",     
123    "aws.cloudtrail.resources.type",   
124    "event.action",
125    "event.outcome",
126    "aws.cloudtrail.recipient_account_id",
127    "aws.cloudtrail.resources.account_id",
128    "cloud.region",
129    "aws.cloudtrail.request_parameters",
130    "aws.cloudtrail.response_elements"
131]
132
133[[rule.threat]]
134framework = "MITRE ATT&CK"
135[[rule.threat.technique]]
136id = "T1548"
137name = "Abuse Elevation Control Mechanism"
138reference = "https://attack.mitre.org/techniques/T1548/"
139
140
141[rule.threat.tactic]
142id = "TA0004"
143name = "Privilege Escalation"
144reference = "https://attack.mitre.org/tactics/TA0004/"
145[[rule.threat]]
146framework = "MITRE ATT&CK"
147[[rule.threat.technique]]
148id = "T1550"
149name = "Use Alternate Authentication Material"
150reference = "https://attack.mitre.org/techniques/T1550/"
151[[rule.threat.technique.subtechnique]]
152id = "T1550.001"
153name = "Application Access Token"
154reference = "https://attack.mitre.org/techniques/T1550/001/"
155
156
157
158[rule.threat.tactic]
159id = "TA0008"
160name = "Lateral Movement"
161reference = "https://attack.mitre.org/tactics/TA0008/"
162[[rule.threat]]
163framework = "MITRE ATT&CK"
164
165[rule.threat.tactic]
166id = "TA0003"
167name = "Persistence"
168reference = "https://attack.mitre.org/tactics/TA0003/"
169
170[rule.new_terms]
171field = "new_terms_fields"
172value = ["aws.cloudtrail.user_identity.session_context.session_issuer.arn", "aws.cloudtrail.resources.arn"]
173[[rule.new_terms.history_window_start]]
174field = "history_window_start"
175value = "now-10d"