AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN

This detection rule identifies instances of successful AWS AssumeRoleWithWebIdentity calls originating from a Kubernetes service account but not from an Amazon-managed Autonomous System Number (ASN). The primary concern is the potential compromise or misuse of projected service account tokens. Kubernetes service accounts can be mapped to IAM roles through OIDC using IRSA (IAM Roles for Service Accounts). Typically, these credential requests originate from within AWS-managed or associated networks. However, if a request with a Kubernetes service account identity originates from an external ASN (i.e., not Amazon.com, Inc.), it raises suspicion that the token might have been exfiltrated and is being used from an unauthorized location. This rule is designed to highlight such anomalies, prompting further investigation into possible token theft or misconfiguration.

Attack Chain

1. Attacker gains unauthorized access to a Kubernetes service account token within a compromised pod or through other means.
2. Attacker exfiltrates the service account token from the Kubernetes cluster.
3. The attacker uses the exfiltrated token to call the AWS STS AssumeRoleWithWebIdentity API.
4. The AssumeRoleWithWebIdentity call is made from a network with an ASN organization name that is not Amazon.com, Inc..
5. AWS CloudTrail logs the successful AssumeRoleWithWebIdentity event, including details about the user, source IP, and ASN organization.
6. The compromised IAM role is used to perform unauthorized actions within the AWS environment.
7. These actions could include data exfiltration, resource modification, or further lateral movement within the cloud infrastructure.

Impact

A successful attack of this nature can lead to significant security breaches within an AWS environment. An attacker leveraging stolen service account tokens can gain unauthorized access to sensitive resources, leading to data breaches, service disruption, or financial loss. This is especially concerning for organizations heavily reliant on Kubernetes and AWS, as it can undermine the security of their cloud-native applications and infrastructure. While the number of affected organizations is unknown, the potential impact on those targeted can be severe, leading to substantial remediation costs and reputational damage.

Recommendation

• Deploy the Sigma rule AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN to your SIEM and tune for your environment.
• Investigate any alerts generated by the Sigma rule by following the investigation steps in the rule’s note field.
• Expand the source.as.organization.name exclusions in the Sigma rule for known and trusted egress paths if needed.
• Enable geolocation/ASN enrichment for your AWS CloudTrail logs to accurately identify the source of AssumeRoleWithWebIdentity calls.
• Regularly review and rotate IRSA trust relationships to minimize the impact of compromised service account tokens.
• Revoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce service account and role permissions if unauthorized access is suspected.