AWS STS Role Chaining

edit

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.

Rule type: esql

Rule indices: None

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

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

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Setup

edit

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

Rule query

edit
from logs-aws.cloudtrail-* metadata _id, _version, _index

// filter for AssumeRole API calls where access key id is a short term token beginning with ASIA
| 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*"

// keep only the relevant fields
| 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

Framework: MITRE ATT&CKTM