Cloud Team Detects Kubernetes-to-AWS Privilege Escalation Through Contextual Investigation
Summary
A cloud response team traced suspicious AWS activity to an exploited application on an EC2 instance, where Kubernetes pod access to IMDS enabled attackers to take over the instance’s IAM role.
Key points
- An EC2 instance IAM role was used from an irregular source IP and then queried multiple EC2 instances and Security Groups.
- Environmental baselines helped identify the role as belonging to an EC2 instance running an EKS pod, making otherwise potentially routine actions suspicious.
- CloudTrail, VPC Flow logs, and host forensic evidence linked the activity to an exposed application and subsequent access to the Instance Metadata Service (IMDS).
- A recently published remote-code-execution vulnerability in the application had reportedly been exploited hours before the IAM role was compromised.
- A newly deployed internet-facing service shared a subnet and Security Group with the vulnerable application, changing its exposure.
- The case study emphasizes contextual detection, rapid investigation, vulnerability management, and production application segregation.
Article Details
- Defense Focus
- Detect and rapidly investigate privilege escalation from a Kubernetes pod or EC2 instance to AWS control-plane access, using environment-specific behavioral baselines and cross-cloud context.
- Detection Methods
- Flag an EC2 instance IAM role being used from an irregular source IP address.
- Detect reconnaissance when the role queries multiple EC2 instances and Security Groups, and assess the activity against environmental inventory baselines.
- Correlate role activity with the instance and EKS pod associated with that role.
- Investigate whether the Instance Metadata Service was accessed shortly before the reconnaissance activity.
- Data Sources
- CloudTrail logs
- VPC Flow logs
- EC2 instance forensic artifacts
- Local OS logs
- Environmental inventory baselines
- Platforms
- AWS
- EKS
- Defensive Actions
- Triage anomalous role activity to determine whether it has a legitimate explanation, then rapidly investigate potential compromise.
- Review and restrict Kubernetes pod access to the host EC2 instance's Instance Metadata Service.
- Apply vulnerability management to open-source applications, especially newly disclosed vulnerabilities.
- Segregate production applications and avoid placing an internet-facing service in a subnet where it can lead to exposure of a vulnerable application through shared Security Group changes.
MITRE ATT&CK
T1190 · Exploit Public-Facing ApplicationA recently published remote code execution vulnerability in an open-source application on the EC2 instance was successfully exploited before the instance IAM role was compromised.T1552.005 · Cloud Instance Metadata APIThe attacker accessed the EC2 Instance Metadata Service from the instance, enabling access to the instance IAM role.T1580 · Cloud Infrastructure DiscoveryThe compromised role queried multiple EC2 instances and Security Groups in apparent reconnaissance.
Vendors
Products
CloudTrailPulling the thread of initial suspicious events, the team was able to leverage context from CloudTrail logs, VPC Flow logs, and forensic artifacts from the EC2 instance, to quickly put the pieces of the puzzle together.EKSon environmental inventory baselines identified the role as one belonging to an EC2 instance running an EKS pod. This fact was key to the attack being detected early – actions which may be common or legitimate whenKubernetesrecent months, our research team has observed a rise in attempts to escalate privileges from access to Kubernetes clusters to cloud control planes, creating significant risks for many organizations. As containersVPC Flow Logsthe thread of initial suspicious events, the team was able to leverage context from CloudTrail logs, VPC Flow logs, and forensic artifacts from the EC2 instance, to quickly put the pieces of the puzzle together. Due