AWS STS Role Chaining

  1[metadata]
  2creation_date = "2024/10/23"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/07/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 rule looks for role
 14chaining activity happening within a single account, to eliminate false positives produced by common cross-account
 15behavior.
 16"""
 17false_positives = [
 18    """
 19    Role chaining can be used as an access control. Ensure that this behavior is not part of a legitimate operation
 20    before taking action.
 21    """,
 22]
 23from = "now-6m"
 24language = "esql"
 25license = "Elastic License v2"
 26name = "AWS STS Role Chaining"
 27note = """## 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
 34AWS Security Token Service (STS) allows temporary, limited-privilege credentials for AWS resources. Role chaining involves using one temporary role to assume another, potentially escalating privileges. Adversaries exploit this by gaining elevated access or persistence. The detection rule identifies such activity by monitoring specific API calls and access patterns within a single account, flagging potential misuse.
 35
 36### Possible investigation steps
 37
 38- Review the AWS CloudTrail logs to identify the source of the AssumeRole API call by examining the aws.cloudtrail.user_identity.arn field to determine which user or service initiated the role chaining.
 39- Check the cloud.region field to understand the geographical context of the activity and assess if it aligns with expected operational regions for your organization.
 40- Investigate the aws.cloudtrail.resources.account_id and aws.cloudtrail.recipient_account_id fields to confirm that the role chaining activity occurred within the same account, as cross-account role chaining is not flagged by this rule.
 41- Analyze the aws.cloudtrail.user_identity.access_key_id to verify that the access key used is a temporary token starting with "ASIA", indicating the use of temporary credentials.
 42- Assess the permissions associated with the roles involved in the chaining to determine if the subsequent role provides elevated privileges that could be exploited for privilege escalation or persistence.
 43- Correlate the timing of the AssumeRole events with other security events or alerts to identify any suspicious patterns or activities that may indicate malicious intent.
 44
 45### False positive analysis
 46
 47- Cross-account role assumptions are common in many AWS environments and can generate false positives. To mitigate this, ensure the rule is configured to only monitor role chaining within a single account, as specified in the rule description.
 48- Automated processes or applications that frequently assume roles for legitimate purposes may trigger false positives. Identify these processes and create exceptions for their specific access patterns or user identities.
 49- Scheduled tasks or scripts that use temporary credentials for routine operations might be flagged. Review these tasks and whitelist their access key IDs if they consistently follow a predictable and secure pattern.
 50- Development and testing environments often involve frequent role assumptions for testing purposes. Exclude these environments from monitoring or adjust the rule to account for their unique access behaviors.
 51- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
 52
 53### Response and remediation
 54
 55- Immediately revoke the temporary credentials associated with the detected AssumeRole activity to prevent further unauthorized access.
 56- Conduct a thorough review of the AWS CloudTrail logs to identify any additional suspicious activities or roles assumed using the compromised credentials.
 57- Isolate the affected AWS resources and accounts to prevent lateral movement and further privilege escalation within the environment.
 58- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
 59- Implement stricter IAM policies and role permissions to limit the ability to assume roles unnecessarily, reducing the risk of privilege escalation.
 60- Enhance monitoring and alerting for AssumeRole activities, especially those involving temporary credentials, to detect similar threats in the future.
 61- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future response efforts.
 62
 63## Setup
 64
 65The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 66references = [
 67    "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts",
 68    "https://www.uptycs.com/blog/detecting-anomalous-aws-sessions-temporary-credentials",
 69    "https://hackingthe.cloud/aws/post_exploitation/role-chain-juggling/",
 70]
 71risk_score = 47
 72rule_id = "ba5a0b0c-b477-4729-a3dc-0147c2049cf1"
 73severity = "medium"
 74tags = [
 75    "Domain: Cloud",
 76    "Data Source: AWS",
 77    "Data Source: Amazon Web Services",
 78    "Data Source: AWS STS",
 79    "Use Case: Threat Detection",
 80    "Tactic: Persistence",
 81    "Tactic: Privilege Escalation",
 82    "Tactic: Lateral Movement",
 83    "Resources: Investigation Guide",
 84]
 85timestamp_override = "event.ingested"
 86type = "esql"
 87
 88query = '''
 89from logs-aws.cloudtrail-* metadata _id, _version, _index
 90
 91// filter for AssumeRole API calls where access key id is a short term token beginning with ASIA
 92| where event.dataset == "aws.cloudtrail" and event.provider == "sts.amazonaws.com" and event.action == "AssumeRole" and aws.cloudtrail.resources.account_id == aws.cloudtrail.recipient_account_id and aws.cloudtrail.user_identity.access_key_id like "ASIA*"
 93
 94// keep only the relevant fields
 95| keep aws.cloudtrail.user_identity.arn, cloud.region, aws.cloudtrail.resources.account_id, aws.cloudtrail.recipient_account_id, aws.cloudtrail.user_identity.access_key_id
 96'''
 97
 98
 99[[rule.threat]]
100framework = "MITRE ATT&CK"
101[[rule.threat.technique]]
102id = "T1548"
103name = "Abuse Elevation Control Mechanism"
104reference = "https://attack.mitre.org/techniques/T1548/"
105
106
107[rule.threat.tactic]
108id = "TA0004"
109name = "Privilege Escalation"
110reference = "https://attack.mitre.org/tactics/TA0004/"
111[[rule.threat]]
112framework = "MITRE ATT&CK"
113[[rule.threat.technique]]
114id = "T1550"
115name = "Use Alternate Authentication Material"
116reference = "https://attack.mitre.org/techniques/T1550/"
117[[rule.threat.technique.subtechnique]]
118id = "T1550.001"
119name = "Application Access Token"
120reference = "https://attack.mitre.org/techniques/T1550/001/"
121
122
123
124[rule.threat.tactic]
125id = "TA0008"
126name = "Lateral Movement"
127reference = "https://attack.mitre.org/tactics/TA0008/"
128[[rule.threat]]
129framework = "MITRE ATT&CK"
130
131[rule.threat.tactic]
132id = "TA0003"
133name = "Persistence"
134reference = "https://attack.mitre.org/tactics/TA0003/"