AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN
Description
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.
Query · kuery
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 not system\:serviceaccount\:kube-system\:aws-load-balancer-controller) and source.as.organization.name:(* and not (Amazon* or AMAZON*))
Investigation fields
Pivot points the source recommends for triage.
@timestampuser.nameuser_agent.originalsource.ipsource.geo.city_namesource.geo.country_namesource.as.organization.namesource.as.numberaws.cloudtrail.user_identity.arnaws.cloudtrail.user_identity.typeaws.cloudtrail.user_identity.access_key_idaws.cloudtrail.resources.arnaws.cloudtrail.resources.typeevent.actionevent.outcomecloud.account.idcloud.region
Known false positives
- Traffic may leave the cluster via corporate proxies, VPNs, or non-AWS NAT providers that populate a non-Amazon ASN organization name while still being legitimate. AWS IP ranges are also labeled with other organization strings (for example `AMAZON-02`); this rule only excludes `Amazon.com, Inc.` per the match condition—tune with additional approved ASNs, CIDRs, or known automation identities if needed.
Analyst notes
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, andevent.outcomefor a successful STS assume. - Review
user.name,aws.cloudtrail.user_identity.arn, role trust (aws.cloudtrail.resources, request parameters forroleArn/roleSessionName), and OIDCsub/audif present in CloudTrail. - Compare
source.ip,source.geo.*, andsource.as.organization.nameto 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.namevalues 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.