Files
sigma-rules/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml
T
Isai 8eb32f96ce Update privilege_escalation_sts_role_chaining.toml (#5180)
- changed rule from esql to new_terms. While details are limited in telemetry, the noise is evident. We've also gotten complaints about the noise from our own infosec team, prompting this tuning. Changes to a new terms rule will reduce noise by over 90% when tested against prod data.
- This originally only triggered for role chaining within a single AWS account, so excluded common cross-account role assumption. However, I am unable to apply a filter for that with KQL but the benefits to creating new-terms rule outweigh the benefits of keeping that exclusion with esql.
- looks for unique combination of `aws.cloudtrail.user_identity.session_context.session_issuer.arn` (originating role) and `aws.cloudtrail.resources.arn`(target role). Because the only identity type we are concerned with here are `AssumedRole` types, we don't have the same new_terms field limitations as with other rules that also must consider `IAMUser` types. So these fields will suffice.
- added highlighted fields
- added index pattern. rule is compatible with filebeat
- updated the investigation guide and description and description

Note: I may consider creating a broader BBR rule, with the same criteria just not new terms, as a way of capturing all instances of role chaining for investigative purposes

Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
2025-10-06 11:29:41 -04:00

177 lines
8.7 KiB
TOML

[metadata]
creation_date = "2024/10/23"
integration = ["aws"]
maturity = "production"
updated_date = "2025/10/02"
[rule]
author = ["Elastic"]
description = """
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).
"""
false_positives = [
"""
Role chaining can be used as an access control. Ensure that this behavior is not part of a legitimate operation
before taking action.
""",
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS STS Role Chaining"
note = """
## 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) and `aws.cloudtrail.resources.arn` (the target role).
- **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).
- **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, use `aws.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 other `geo` 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](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.
- **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` or `resources.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](https://github.com/aws-samples/aws-incident-response-playbooks/): NIST-aligned templates for evidence, containment, eradication, recovery, post-incident.
- [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/): Practical response steps for account and IAM misuse scenarios
- AWS IAM Best Practices: [AWS docs](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 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 = [
"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts",
"https://www.uptycs.com/blog/detecting-anomalous-aws-sessions-temporary-credentials",
"https://hackingthe.cloud/aws/post_exploitation/role-chain-juggling/",
]
risk_score = 47
rule_id = "ba5a0b0c-b477-4729-a3dc-0147c2049cf1"
severity = "medium"
tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: Amazon Web Services",
"Data Source: AWS STS",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Tactic: Privilege Escalation",
"Tactic: Lateral Movement",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.dataset : "aws.cloudtrail" and
event.provider : "sts.amazonaws.com" and
event.action : "AssumeRole" and
aws.cloudtrail.user_identity.type : "AssumedRole" and
event.outcome : "success"
'''
[rule.investigation_fields]
field_names = [
"@timestamp",
"user_agent.original",
"source.ip",
"user.name",
"aws.cloudtrail.user_identity.session_context.session_issuer.arn",
"aws.cloudtrail.user_identity.arn",
"aws.cloudtrail.user_identity.type",
"aws.cloudtrail.user_identity.access_key_id",
"aws.cloudtrail.resources.arn",
"aws.cloudtrail.resources.type",
"event.action",
"event.outcome",
"aws.cloudtrail.recipient_account_id",
"aws.cloudtrail.resources.account_id",
"cloud.region",
"aws.cloudtrail.request_parameters",
"aws.cloudtrail.response_elements"
]
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"
[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"
[[rule.threat.technique.subtechnique]]
id = "T1550.001"
name = "Application Access Token"
reference = "https://attack.mitre.org/techniques/T1550/001/"
[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[rule.new_terms]
field = "new_terms_fields"
value = ["aws.cloudtrail.user_identity.session_context.session_issuer.arn", "aws.cloudtrail.resources.arn"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-10d"