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 rule looks for role chaining activity happening within a single account, to eliminate false positives produced by common cross-account behavior.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/10/23"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/01/15"
  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 AWS CLI or API.
 11While this a recognized functionality in AWS, role chaining can be abused for privilege escalation if the subsequent assumed role provides additional privileges.
 12Role 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.
 13This rule looks for role chaining activity happening within a single account, to eliminate false positives produced by common cross-account behavior.
 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 before taking action.
 18    """,
 19]
 20from = "now-6m"
 21language = "esql"
 22license = "Elastic License v2"
 23name = "AWS STS Role Chaining"
 24note = """## Triage and analysis
 25
 26> **Disclaimer**:
 27> 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.
 28
 29### Investigating AWS STS Role Chaining
 30
 31AWS 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.
 32
 33### Possible investigation steps
 34
 35- 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.
 36- 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.
 37- 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.
 38- 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.
 39- 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.
 40- 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.
 41
 42### False positive analysis
 43
 44- 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.
 45- 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.
 46- 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.
 47- 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.
 48- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
 49
 50### Response and remediation
 51
 52- Immediately revoke the temporary credentials associated with the detected AssumeRole activity to prevent further unauthorized access.
 53- Conduct a thorough review of the AWS CloudTrail logs to identify any additional suspicious activities or roles assumed using the compromised credentials.
 54- Isolate the affected AWS resources and accounts to prevent lateral movement and further privilege escalation within the environment.
 55- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
 56- Implement stricter IAM policies and role permissions to limit the ability to assume roles unnecessarily, reducing the risk of privilege escalation.
 57- Enhance monitoring and alerting for AssumeRole activities, especially those involving temporary credentials, to detect similar threats in the future.
 58- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future response efforts.
 59
 60## Setup
 61
 62The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 63references = [
 64    "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts",
 65    "https://www.uptycs.com/blog/detecting-anomalous-aws-sessions-temporary-credentials",
 66    "https://hackingthe.cloud/aws/post_exploitation/role-chain-juggling/",
 67]
 68risk_score = 47
 69rule_id = "ba5a0b0c-b477-4729-a3dc-0147c2049cf1"
 70severity = "medium"
 71tags = [
 72    "Domain: Cloud",
 73    "Data Source: AWS",
 74    "Data Source: Amazon Web Services",
 75    "Data Source: AWS STS",
 76    "Use Case: Threat Detection",
 77    "Tactic: Persistence",
 78    "Tactic: Privilege Escalation",
 79    "Tactic: Lateral Movement",
 80    "Resources: Investigation Guide",
 81]
 82timestamp_override = "event.ingested"
 83type = "esql"
 84
 85query = '''
 86from logs-aws.cloudtrail-* metadata _id, _version, _index
 87
 88// filter for AssumeRole API calls where access key id is a short term token beginning with ASIA
 89| 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*"
 90
 91// keep only the relevant fields
 92| 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
 93'''
 94
 95
 96[[rule.threat]]
 97framework = "MITRE ATT&CK"
 98[[rule.threat.technique]]
 99id = "T1548"
100name = "Abuse Elevation Control Mechanism"
101reference = "https://attack.mitre.org/techniques/T1548/"
102
103
104[rule.threat.tactic]
105id = "TA0004"
106name = "Privilege Escalation"
107reference = "https://attack.mitre.org/tactics/TA0004/"
108[[rule.threat]]
109framework = "MITRE ATT&CK"
110[[rule.threat.technique]]
111id = "T1550"
112name = "Use Alternate Authentication Material"
113reference = "https://attack.mitre.org/techniques/T1550/"
114[[rule.threat.technique.subtechnique]]
115id = "T1550.001"
116name = "Application Access Token"
117reference = "https://attack.mitre.org/techniques/T1550/001/"
118
119
120[rule.threat.tactic]
121id = "TA0008"
122name = "Lateral Movement"
123reference = "https://attack.mitre.org/tactics/TA0008/"
124[[rule.threat]]
125framework = "MITRE ATT&CK"
126
127[rule.threat.tactic]
128id = "TA0003"
129name = "Persistence"
130reference = "https://attack.mitre.org/tactics/TA0003/"
...
toml

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.

AWS 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.

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule.
  • Immediately revoke the temporary credentials associated with the detected AssumeRole activity to prevent further unauthorized access.
  • Conduct a thorough review of the AWS CloudTrail logs to identify any additional suspicious activities or roles assumed using the compromised credentials.
  • Isolate the affected AWS resources and accounts to prevent lateral movement and further privilege escalation within the environment.
  • Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
  • Implement stricter IAM policies and role permissions to limit the ability to assume roles unnecessarily, reducing the risk of privilege escalation.
  • Enhance monitoring and alerting for AssumeRole activities, especially those involving temporary credentials, to detect similar threats in the future.
  • Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future response efforts.

The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

References

Related rules

to-top