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