Full Report
In this second blog post, we will discuss lateral movement risks from Kubernetes to the cloud. We will explain attacker TTPs, and outline best practices for security practitioners and cloud builders to help secure their cloud environments and mitigate risk.
Analysis Summary
# Tool/Technique: Kubernetes-to-Cloud Lateral Movement Techniques
## Overview
This summary details the techniques and procedures (TTPs) leveraged by adversaries to achieve lateral movement from compromised managed Kubernetes (K8s) clusters to the underlying cloud provider infrastructure (AWS, GCP, or Azure). The focus is on exploiting misconfigurations related to the Instance Metadata Service (IMDS), IAM/AAD identities, and the potential for container escape.
## Technical Details
- Type: Technique/Attack Vector
- Platform: Managed Kubernetes Services (EKS, GKE, AKS) in major Cloud Service Providers (CSPs)
- Capabilities: Exploiting node identities for API access, privilege escalation, reconnaissance, and denial of service.
- First Seen: Ongoing/Evolving threat, leveraged by groups like TeamTNT.
## MITRE ATT&CK Mapping
This analysis draws from techniques related to initial access, lateral movement, and credential access within the container environment:
- **TA0008 - Lateral Movement**
- **T1550 - Use Alternate Authentication Material**
- **T1550.005 - Cloud Instance Metadata Service** (Specifically IMDS abuse)
- **TA0006 - Credential Access**
- **T1552 - Unsecured Credentials**
- **T1552.006 - Cloud Instance Metadata Service**
- **TA0004 - Privilege Escalation**
- **T1078 - Valid Accounts**
- **T1078.004 - Cloud Accounts**
- **TA0007 - Discovery**
- **T1087 - Account Discovery**
- **T1087.004 - Cloud Accounts**
- **TA0011 - Command and Control**
- **T1105 - Ingress Tool Transfer** (Related to pod escape scenario for deploying further tools)
## Functionality
### Core Capabilities
- **Instance Metadata Service (IMDS) Querying:** Compromised containers query the IMDS endpoint (typically 169.254.169.254) to retrieve the pre-defined IAM/AAD identity credentials assigned to the worker node.
- **Identity Assumption:** Adversaries use the retrieved temporary credentials to assume the IAM/AAD identity associated with the worker node, gaining the identity's permissions within the CSP environment.
- **Cloud Resource Access:** Once assumed, the identity is leveraged to access external cloud resources such as storage buckets, databases, and management APIs.
### Advanced Features
- **Exploitation of Default Roles:** Attackers capitalize on overly permissive default roles assigned to nodes (e.g., GCP's Compute Engine default service account with the basic editor role).
- **Cloud-Specific Reconnaissance:** Utilizing inherited node policies to map cloud resources:
- **AWS (EKS):** Using `AmazonEKSWorkerNodePolicy` to map the entire cloud network (listing EC2 instances, security groups, AMIs, IPs, VPCs).
- **AWS (EKS):** Using `AmazonEC2ContainerRegistryReadOnly` to enumerate container registries for hidden secrets.
- **AWS (EKS):** Using `AmazonEKS_CNI_Policy` to potentially launch a Denial of Service attack by removing instance network interfaces.
- **Pod Escape:** Advanced attackers may utilize pod escape to gain higher privileges needed to execute lateral movement TTPs more effectively.
## Indicators of Compromise
The indicators are primarily behavioral, focused on API calls originating from within a pod destined for the IMDS endpoint.
- File Hashes: N/A (Focus is on behavior)
- File Names: N/A
- Registry Keys: N/A
- Network Indicators:
- Traffic directed to the link-local address `169.254.169.254` from within a container or pod.
- Behavioral Indicators:
- Unauthorized use of cloud provider APIs (e.g., `ec2:DescribeInstances`, `s3:ListAllMyBuckets`) originating from a container workload identity.
- Network calls from pods attempting to communicate with the IMDS endpoint.
## Associated Threat Actors
- TeamTNT
## Detection Methods
- Signature-based detection: Specific signatures for known binaries or exploitation patterns used in conjunction with pod-to-cloud attacks (though limited against custom TTPs).
- Behavioral detection: Monitoring for network traffic originating from container IP spaces destined for link-local addresses like 169.254.169.254. Detecting unusual API calls made by identities associated with Kubernetes worker nodes.
- YARA rules: Not explicitly mentioned in the context, but custom rules could target suspicious scripts or binaries dropped in compromised containers attempting IMDS harvesting.
## Mitigation Strategies
1. **Implement Least Privilege K8s RBAC:** Strictly control what service accounts can access within the cluster, limiting escalation paths.
2. **Use Identity Federation (Avoid Long-Term Keys):** Utilize managed identity integration features: IAM Roles for Service Accounts (IRSA) in EKS, Workload Identity in GKE, or Azure AD Workload Identity in AKS. This ensures pods assume temporary credentials tied to their service account instead of relying on long-term keys or node roles directly.
3. **Avoid Storing Long-Term Cloud Keys:** Never store long-term access keys in K8s secrets or container images.
4. **Remediate Critical Vulnerabilities:** Regularly scan and patch publicly exposed containers which serve as the entry point for attackers.
5. **Curb Network Access with Network Policies:** Implement Kubernetes Network Policies to restrict pod-to-pod and pod-to-external traffic, preventing compromised pods from reaching the IMDS endpoint or other internal/external resources by default.
## Related Tools/Techniques
- Pod Escape (Used to gain necessary privileges for lateral movement)
- Abuse of IAM/AAD identities associated with Managed Kubernetes constructs.