AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN

edit

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN

edit

Detects successful AssumeRoleWithWebIdentity where the caller identity is a Kubernetes service account and the source autonomous system organization is present but not Amazon.com, Inc. EKS workloads that obtain IAM credentials via IAM Roles for Service Accounts (IRSA) normally reach STS from AWS-managed or AWS-associated networks; the same identity from a clearly external ASN can indicate a stolen or misused projected service-account token being exchanged for IAM credentials off-cluster.

Rule type: query

Rule indices:

filebeat-*
logs-aws.cloudtrail-*

Severity: high

Risk score: 73

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
Domain: Identity
Data Source: AWS
Data Source: Amazon Web Services
Data Source: AWS CloudTrail
Use Case: Threat Detection
Tactic: Initial Access
Resources: Investigation Guide

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN

IRSA maps a Kubernetes service account to an IAM role via OIDC. CloudTrail records AssumeRoleWithWebIdentity with user.name like system:serviceaccount:<namespace>:<sa>. If geolocation/ASN enrichment shows a non-Amazon source organization while the identity is still a cluster service account, validate whether the token could have been used outside the cluster (exfiltrated JWT, misrouted traffic, or operator tooling).

Possible investigation steps

Confirm event.action, event.provider, and event.outcome for a successful STS assume.
Review user.name, aws.cloudtrail.user_identity.arn, role trust (aws.cloudtrail.resources, request parameters for roleArn / roleSessionName), and OIDC sub / aud if present in CloudTrail.
Compare source.ip, source.geo.*, and source.as.organization.name to known cluster egress, NAT gateways, and approved operator networks.
In Kubernetes: map the service account to workloads and audit activity around the event time (exec, secret access, new deployments).

False positive analysis

Egress through third-party security stacks or multi-cloud connectors can change how ASN organization is attributed.
Expand exclusions for known source.as.organization.name values used by your egress path.

Response and remediation

If unauthorized: revoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce service account and role permissions.

Additional information

Rule query

edit

data_stream.dataset:aws.cloudtrail and
 event.provider:sts.amazonaws.com and
 event.action:AssumeRoleWithWebIdentity and
 event.outcome:success and user.name:system\:serviceaccount\:* and
 source.as.organization.name:(* and not (Amazon* or AMAZON*))

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Initial Access
- ID: TA0001
- Reference URL: https://attack.mitre.org/tactics/TA0001/
Technique:
- Name: Valid Accounts
- ID: T1078
- Reference URL: https://attack.mitre.org/techniques/T1078/
Sub-technique:
- Name: Cloud Accounts
- ID: T1078.004
- Reference URL: https://attack.mitre.org/techniques/T1078/004/

« AWS EC2 Stop, Start, and User Data Modification Correlation AWS Lateral Movement from Kubernetes SA via AssumeRoleWithWebIdentity »