Full Report
In this third blog post, we will discuss lateral movement risks from the cloud to Kubernetes. We will explain attacker TTPs, and outline best practices for cloud builders and defenders to help secure their cloud environments and mitigate risk.
Analysis Summary
# Tool/Technique: Cloud-to-Kubernetes Lateral Movement Vectors
## Overview
The analyzed methodology describes how adversaries leverage compromised credentials and misconfigurations within cloud environments (AWS, GCP, Azure) to achieve lateral movement into managed Kubernetes clusters (EKS, GKE, AKS). This primarily involves exploiting cloud Identity and Access Management (IAM) keys, misconfigured container registries, and exposed kubeconfig files to gain authenticated access to Kubernetes resources.
## Technical Details
- Type: Technique / Configuration Abuse
- Platform: AWS (EKS), GCP (GKE), Azure (AKS), Cloud Workloads (VMs, Serverless), Kubernetes Clusters
- Capabilities: Generating working `kubeconfig` files, authenticating to managed Kubernetes APIs, achieving cluster administrative privileges.
- First Seen: Not specified (Based on analysis of contemporary cloud configurations)
## MITRE ATT&CK Mapping
Since this describes *how* an attacker moves laterally using existing cloud components rather than a single piece of malware, the mappings focus on credential access and initial access/persistence within the target system.
- **TA0006 - Credential Access**
- T1552 - Unsecured Credentials
- T1552.006 - Credentials from Cloud Storage
- **TA0001 - Initial Access** (Gaining access to the cluster)
- T1133 - External Remote Services (Using compromised cloud identity to reach the K8s API)
- **TA0004 - Privilege Escalation** (Gaining `system:masters` or admin equivalent)
- T1068 - Exploitation for Privilege Escalation (Exploiting misconfigured RBAC/IAM bindings)
## Functionality
### Core Capabilities
1. **IAM Cloud Key Exploitation:** Compromising long-term cloud keys (AWS Access Keys, GCP tokens, Azure Service Principal credentials) associated with identities holding high-privilege Kubernetes access.
2. **Kubeconfig Generation:** Utilizing compromised cloud credentials to programmatically generate a functioning `kubeconfig` file necessary to interact with the managed Kubernetes API server.
3. **Authentication Bypass (AKS Specific):** Exploiting the use of local accounts with Kubernetes RBAC in AKS, where even minimal permissions to list cluster credentials can lead to generating a `kubeconfig` granting `system:masters` access.
### Advanced Features
1. **CSP-Specific Access Mapping:** Leveraging how each CSP maps cloud roles to Kubernetes RBAC:
* **AWS EKS:** Identities that create the cluster automatically receive `system:masters` permissions via the control plane RBAC.
* **GCP GKE:** Admin privileges at the Project/Folder level via IAM can translate to full admin privileges inside the cluster unless restricted by native RBAC.
2. **Container Registry Abuse:** Accessing and potentially manipulating container images stored in cloud registries (ECR, GCR, GAR) which could contain secrets or custom deployment artifacts used for initialization or persistence within the cluster.
## Indicators of Compromise
The IoCs focus on the presence of accessible assets or patterns of interaction rather than specific malware artifacts.
- File Hashes: N/A (Focus is on configuration/credentials)
- File Names: `kubeconfig` file possession, cleartext AWS access keys, GCP OAuth tokens, Azure service principal credentials.
- Registry Keys: N/A
- Network Indicators: Initial API connection attempts to EKS, GKE, or AKS control planes using credentials sourced from compromised cloud workloads.
- Behavioral Indicators:
* Cloud workloads querying IAM roles/metadata associated with EKS/GKE/AKS cluster administration.
* Creation of new bearer tokens or client certificates within Kubernetes post-compromise.
* High volume of API calls to the K8s API server originating from unexpected cloud identities.
## Associated Threat Actors
The techniques described (leveraging cloud identity mapping to compromise managed K8s) are characteristic of sophisticated actors targeting cloud-native infrastructure, often seen in advanced persistent threats (APT) or financially motivated groups focusing on cloud resource takeover. Specific named actors are not provided by the text, but the vectors are common in modern cloud exploitation.
## Detection Methods
Detection should focus on cloud configuration posture and unusual API usage.
- Signature-based detection: Not easily applicable for credential abuse techniques.
- Behavioral detection: Monitoring for cloud identities performing actions that generate K8s configuration artefacts or directly connecting to the K8s API server with newly acquired credentials. Specifically, detecting attempts to enumerate or retrieve cluster credentials from CSP metadata services using compromised keys.
- YARA rules if available: N/A
## Mitigation Strategies
Mitigation focuses heavily on secure configuration and access hygiene relating to cloud identities and Kubernetes integration.
- **Secure Kubeconfig Storage:** Never store `kubeconfig` files in cleartext, especially on cloud workloads (VMs, containers).
- **Cloud Identity Hardening:**
* Review and strictly limit highly privileged IAM/AAD identities that have cluster creation or administrative access rights to managed K8s services.
* Prefer short-lived credentials via IAM roles over long-term access keys stored on resources.
* **AKS Specific:** Prefer AAD authentication with Kubernetes/Azure RBAC over using local accounts tied to `crd-id` certificates, as AAD flows trigger browser-based authentication, mitigating direct kubeconfig abuse.
* **Registry Security:** Ensure that cloud container registries (GCR buckets, GAR repositories) are not publicly exposed and that access is locked down using the principle of least privilege via IAM policies, actively preventing public access principals (`allUsers`, `allAuthenticatedUsers`).
## Related Tools/Techniques
- Compromise of Cloud Metadata Services
- Use of cloud SDKs for credential processing
- Misconfiguration of AWS `aws-auth` ConfigMap
- Exploiting IAM Roles for Service Accounts (IRSA in EKS) if applicable (not detailed but relevant context).