Eks — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/eks/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioMon, 01 Jun 2026 10:09:54 +0000AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASNhttps://feed.craftedsignal.io/briefs/2026-06-aws-assume-role-external-asn/Mon, 01 Jun 2026 10:09:54 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-06-aws-assume-role-external-asn/Detects successful AWS AssumeRoleWithWebIdentity where the caller identity is a Kubernetes service account and the source autonomous system organization is not Amazon.com, Inc., potentially indicating a stolen or misused service-account token being used off-cluster.This detection identifies potentially malicious activity related to AWS IAM Roles for Service Accounts (IRSA) in EKS. It focuses on instances where a Kubernetes service account successfully assumes an IAM role using AssumeRoleWithWebIdentity, but the request originates from an autonomous system organization that is not Amazon.com, Inc.. This scenario suggests that a service account token might have been compromised and is being used from outside the expected AWS-managed or associated network. This can occur due to exfiltration of the JWT token, misrouted network traffic, or use of unauthorized operator tooling. The rule aims to detect initial access attempts via misuse of valid cloud accounts, specifically Kubernetes service accounts used to assume IAM roles.

Attack Chain

  1. A Kubernetes service account is created within an EKS cluster.
  2. The service account is configured with an IAM role through IRSA, establishing a trust relationship.
  3. An attacker gains access to the service account’s projected token, potentially through a vulnerability within the cluster or compromised credentials.
  4. The attacker uses the stolen service account token to call the AWS STS AssumeRoleWithWebIdentity API.
  5. The AssumeRoleWithWebIdentity request originates from an external network, identified by a source ASN that is not associated with Amazon.
  6. AWS STS validates the token and, due to the valid trust relationship, grants temporary IAM credentials.
  7. The attacker uses the temporary IAM credentials to access AWS resources, potentially leading to data exfiltration or further lateral movement within the AWS environment.
  8. The attacker attempts to compromise other workloads within the AWS account or pivot to other cloud environments.

Impact

Successful exploitation can lead to unauthorized access to AWS resources, data exfiltration, and further compromise of the cloud environment. The impact includes potential data breaches, disruption of services, and financial losses due to unauthorized resource usage. Detecting this activity is crucial as it signifies a breach of trust and a potential compromise of the Kubernetes service account and associated IAM role. A successful attack can compromise critical AWS infrastructure and data.

Recommendation

  • Deploy the following Sigma rules to your SIEM to detect suspicious AssumeRoleWithWebIdentity activity from external ASNs. Tune the rules based on your environment’s known egress paths and approved ASNs.
  • Review and harden the trust policies associated with IAM roles used by Kubernetes service accounts to restrict access based on expected OIDC sub and aud claims, as described in the AWS documentation (https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html).
  • Investigate any alerts generated by the Sigma rules, focusing on validating the source IP, ASN organization, and Kubernetes service account associated with the AssumeRoleWithWebIdentity request, as per the triage steps in the rule documentation.
  • Monitor AWS CloudTrail logs for AssumeRoleWithWebIdentity events with event.outcome:success and unusual source.ip addresses.
]]>highadvisoryawscloudtrailiameksirsainitial-access