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).
Elastic rule (View on GitHub)
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"
Triage and analysis
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.
Investigating AWS STS Role Chaining
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
).
Possible investigation steps
- Review Alert Context: Investigate the alert, focusing on
aws.cloudtrail.user_identity.session_context.session_issuer.arn
(the calling role) andaws.cloudtrail.resources.arn
(the target role). - Determine scope and intent. Check
aws.cloudtrail.recipient_account_id
andaws.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, useaws.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 othergeo
fields to assess if the activity originates from expected regions or network ranges.
False positive analysis
- 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.
Response and remediation
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
orresources.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.
Additional information
- 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.
Setup
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
References
Related rules
- AWS STS AssumeRole with New MFA Device
- AWS First Occurrence of STS GetFederationToken Request by User
- AWS IAM API Calls via Temporary Session Tokens
- AWS STS Role Assumption by Service
- AWS STS Role Assumption by User