AWS STS Role Assumption by Service
Identifies when a service has assumed a role in AWS Security Token Service (STS). Services can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a New Terms rule that identifies when a service assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2021/05/17"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2024/11/07"
6
7[rule]
8author = ["Elastic", "Austin Songer"]
9description = """
10Identifies when a service has assumed a role in AWS Security Token Service (STS). Services can assume a role to obtain
11temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege
12escalation. This is a [New
13Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that identifies
14when a service assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS
15resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or
16lateral movement within an AWS environment.
17"""
18false_positives = [
19 "AWS administrators or automated processes might regularly assume roles for legitimate administrative purposes.",
20 "AWS services might assume roles to access AWS resources as part of their standard operations.",
21 "Automated workflows might assume roles to perform periodic tasks such as data backups, updates, or deployments.",
22]
23from = "now-9m"
24index = ["filebeat-*", "logs-aws.cloudtrail-*"]
25language = "kuery"
26license = "Elastic License v2"
27name = "AWS STS Role Assumption by Service"
28note = """## Triage and Analysis
29
30### Investigating AWS STS Role Assumption by Service
31
32This rule identifies instances where AWS STS (Security Token Service) is used to assume a role, granting temporary credentials for AWS resource access. While this action is often legitimate, it can be exploited by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment.
33
34#### Possible Investigation Steps
35
36- **Identify the Actor and Assumed Role**:
37 - **User Identity**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` fields to determine who initiated the `AssumeRole` action.
38 - **Role Assumed**: Check the `aws.cloudtrail.flattened.request_parameters.roleArn` field to confirm the assumed role and ensure it aligns with expected responsibilities.
39 - **Session Name**: Observe the `aws.cloudtrail.flattened.request_parameters.roleSessionName` for context on the session's intended purpose, if available.
40
41- **Analyze the Role Session and Duration**:
42 - **Session Context**: Look at the `aws.cloudtrail.user_identity.session_context.creation_date` to understand when the session began and check if multi-factor authentication (MFA) was used, indicated by the `aws.cloudtrail.user_identity.session_context.mfa_authenticated` field.
43 - **Credential Validity**: Examine the `aws.cloudtrail.flattened.request_parameters.durationSeconds` for the credential's validity period.
44 - **Expiration Time**: Verify `aws.cloudtrail.flattened.response_elements.credentials.expiration` to determine when the credentials expire or expired.
45
46- **Inspect the User Agent for Tooling Identification**:
47 - **User Agent Details**: Review the `user_agent.original` field to identify the tool or SDK used for the role assumption. Indicators include:
48 - **AWS SDKs (e.g., Boto3)**: Often used in automated workflows or scripts.
49 - **AWS CLI**: Suggests command-line access, potentially indicating direct user interaction.
50 - **Custom Tooling**: Unusual user agents may signify custom or suspicious tools.
51 - **Source IP and Location**: Evaluate the `source.address` and `source.geo` fields to confirm if the access source aligns with typical access locations for your environment.
52
53- **Contextualize with Related Events**:
54 - **Review Event Patterns**: Check surrounding CloudTrail events to see if other actions coincide with this `AssumeRole` activity, such as attempts to access sensitive resources.
55 - **Identify High-Volume Exceptions**: Due to the potential volume of `AssumeRole` events, determine common, legitimate `roleArn` values or `user_agent` patterns, and consider adding these as exceptions to reduce noise.
56
57- **Evaluate the Privilege Level of the Assumed Role**:
58 - **Permissions**: Inspect permissions associated with the assumed role to understand its access level.
59 - **Authorized Usage**: Confirm whether the role is typically used for administrative purposes and if the assuming entity frequently accesses it as part of regular responsibilities.
60
61### False Positive Analysis
62
63- **Automated Workflows and Applications**: Many applications or scheduled tasks may assume roles for standard operations. Check user agents and ARNs for consistency with known workflows.
64- **Routine IAM Policy Actions**: Historical data may reveal if the same user or application assumes this specific role regularly as part of authorized operations.
65
66### Response and Remediation
67
68- **Revoke Unauthorized Sessions**: If unauthorized, consider revoking the session by adjusting IAM policies or permissions associated with the assumed role.
69- **Enhance Monitoring and Alerts**: Set up enhanced monitoring for high-risk roles, especially those with elevated privileges.
70- **Manage Exceptions**: Regularly review and manage high-frequency roles and user agent patterns, adding trusted ARNs and user agents to exception lists to minimize alert fatigue.
71- **Incident Response**: If malicious behavior is identified, follow incident response protocols, including containment, investigation, and remediation.
72
73### Additional Information
74
75For more information on managing and securing AWS STS, refer to the [AWS STS documentation](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) and AWS security best practices.
76"""
77references = ["https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html"]
78risk_score = 21
79rule_id = "93075852-b0f5-4b8b-89c3-a226efae5726"
80severity = "low"
81tags = [
82 "Domain: Cloud",
83 "Data Source: AWS",
84 "Data Source: Amazon Web Services",
85 "Data Source: AWS STS",
86 "Resources: Investigation Guide",
87 "Use Case: Identity and Access Audit",
88 "Tactic: Privilege Escalation",
89]
90timestamp_override = "event.ingested"
91type = "new_terms"
92
93query = '''
94event.dataset: "aws.cloudtrail"
95 and event.provider: "sts.amazonaws.com"
96 and event.action: "AssumeRole"
97 and event.outcome: "success"
98 and aws.cloudtrail.user_identity.type: "AWSService"
99 and not aws.cloudtrail.user_identity.invoked_by: (
100 "config.amazonaws.com" or
101 "securityhub.amazonaws.com" or
102 "sso.amazonaws.com"
103 )
104'''
105
106[rule.investigation_fields]
107field_names = [
108 "@timestamp",
109 "aws.cloudtrail.user_identity.type",
110 "aws.cloudtrail.resources.arn",
111 "aws.cloudtrail.resources.type",
112 "source.address",
113 "aws.cloudtrail.user_identity.invoked_by",
114 "aws.cloudtrail.flattened.request_parameters.roleArn",
115 "aws.cloudtrail.flattened.request_parameters.roleSessionName",
116 "event.action",
117 "event.outcome",
118 "cloud.region",
119 "aws.cloudtrail.request_parameters",
120 "aws.cloudtrail.response_elements"
121]
122
123[[rule.threat]]
124framework = "MITRE ATT&CK"
125[[rule.threat.technique]]
126id = "T1548"
127name = "Abuse Elevation Control Mechanism"
128reference = "https://attack.mitre.org/techniques/T1548/"
129
130
131[rule.threat.tactic]
132id = "TA0004"
133name = "Privilege Escalation"
134reference = "https://attack.mitre.org/tactics/TA0004/"
135[[rule.threat]]
136framework = "MITRE ATT&CK"
137[[rule.threat.technique]]
138id = "T1550"
139name = "Use Alternate Authentication Material"
140reference = "https://attack.mitre.org/techniques/T1550/"
141[[rule.threat.technique.subtechnique]]
142id = "T1550.001"
143name = "Application Access Token"
144reference = "https://attack.mitre.org/techniques/T1550/001/"
145
146
147
148[rule.threat.tactic]
149id = "TA0008"
150name = "Lateral Movement"
151reference = "https://attack.mitre.org/tactics/TA0008/"
152
153[rule.new_terms]
154field = "new_terms_fields"
155value = ["aws.cloudtrail.resources.arn", "aws.cloudtrail.user_identity.invoked_by"]
156[[rule.new_terms.history_window_start]]
157field = "history_window_start"
158value = "now-14d"
Triage and Analysis
Investigating AWS STS Role Assumption by Service
This rule identifies instances where AWS STS (Security Token Service) is used to assume a role, granting temporary credentials for AWS resource access. While this action is often legitimate, it can be exploited by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment.
Possible Investigation Steps
-
Identify the Actor and Assumed Role:
- User Identity: Review the
aws.cloudtrail.user_identity.arn
andaws.cloudtrail.user_identity.type
fields to determine who initiated theAssumeRole
action. - Role Assumed: Check the
aws.cloudtrail.flattened.request_parameters.roleArn
field to confirm the assumed role and ensure it aligns with expected responsibilities. - Session Name: Observe the
aws.cloudtrail.flattened.request_parameters.roleSessionName
for context on the session's intended purpose, if available.
- User Identity: Review the
-
Analyze the Role Session and Duration:
- Session Context: Look at the
aws.cloudtrail.user_identity.session_context.creation_date
to understand when the session began and check if multi-factor authentication (MFA) was used, indicated by theaws.cloudtrail.user_identity.session_context.mfa_authenticated
field. - Credential Validity: Examine the
aws.cloudtrail.flattened.request_parameters.durationSeconds
for the credential's validity period. - Expiration Time: Verify
aws.cloudtrail.flattened.response_elements.credentials.expiration
to determine when the credentials expire or expired.
- Session Context: Look at the
-
Inspect the User Agent for Tooling Identification:
- User Agent Details: Review the
user_agent.original
field to identify the tool or SDK used for the role assumption. Indicators include:- AWS SDKs (e.g., Boto3): Often used in automated workflows or scripts.
- AWS CLI: Suggests command-line access, potentially indicating direct user interaction.
- Custom Tooling: Unusual user agents may signify custom or suspicious tools.
- Source IP and Location: Evaluate the
source.address
andsource.geo
fields to confirm if the access source aligns with typical access locations for your environment.
- User Agent Details: Review the
-
Contextualize with Related Events:
- Review Event Patterns: Check surrounding CloudTrail events to see if other actions coincide with this
AssumeRole
activity, such as attempts to access sensitive resources. - Identify High-Volume Exceptions: Due to the potential volume of
AssumeRole
events, determine common, legitimateroleArn
values oruser_agent
patterns, and consider adding these as exceptions to reduce noise.
- Review Event Patterns: Check surrounding CloudTrail events to see if other actions coincide with this
-
Evaluate the Privilege Level of the Assumed Role:
- Permissions: Inspect permissions associated with the assumed role to understand its access level.
- Authorized Usage: Confirm whether the role is typically used for administrative purposes and if the assuming entity frequently accesses it as part of regular responsibilities.
False Positive Analysis
- Automated Workflows and Applications: Many applications or scheduled tasks may assume roles for standard operations. Check user agents and ARNs for consistency with known workflows.
- Routine IAM Policy Actions: Historical data may reveal if the same user or application assumes this specific role regularly as part of authorized operations.
Response and Remediation
- Revoke Unauthorized Sessions: If unauthorized, consider revoking the session by adjusting IAM policies or permissions associated with the assumed role.
- Enhance Monitoring and Alerts: Set up enhanced monitoring for high-risk roles, especially those with elevated privileges.
- Manage Exceptions: Regularly review and manage high-frequency roles and user agent patterns, adding trusted ARNs and user agents to exception lists to minimize alert fatigue.
- Incident Response: If malicious behavior is identified, follow incident response protocols, including containment, investigation, and remediation.
Additional Information
For more information on managing and securing AWS STS, refer to the AWS STS documentation and AWS security best practices.
References
Related rules
- AWS STS Role Assumption by User
- AWS IAM Assume Role Policy Update
- AWS IAM AdministratorAccess Policy Attached to User
- AWS IAM Customer-Managed Policy Attached to Role by Rare User
- AWS STS GetCallerIdentity API Called for the First Time