As the cloud security landscape continues to shift and expand, it's imperative for organizations to stay ahead of potential threats that lurk within its complex structure. This post focuses on a nuanced lateral movement strategy that leverages the ec2-instance-connect:SendSSHPublicKey API, a tool that, while designed for convenience, can be twisted into a vulnerability by adept attackers. Through the seemingly simple act of injecting a temporary SSH public key into a compromised EC2 instance, adversaries can weave through cloud environments with alarming ease.
Join us as we unpack this method, piece by piece, to illuminate its impact on cloud infrastructure and arm security teams with the knowledge needed to fortify their digital fortresses against such cunning exploits.
Lateral movement refers to the techniques that attackers use to progressively navigate through a network, gaining access to additional systems and information. It's like a burglar slipping into a house and quietly moving from room to room, finding ways to bypass locked doors to reach the most valuable possessions without alerting anyone inside. It's a critical phase in an attack lifecycle, enabling threat actors to extend their reach from an initial foothold to high-value targets. In the context of cloud environments, lateral movement can take various forms:
Think of an EC2 instance as a locked house in the vast neighborhood of the cloud. Hackers have different tricks to get in. Some keep guessing the lock code (that's brute force) until they get it right. Others trick the house into opening the door for them, thinking they're someone else (like Server Side Request Forgery (SSRF) does). And then, there are those who use known weak spots in the lock that haven't been fixed yet (these are the CVEs). Each method has the same goal: to sneak inside the EC2 'house'. Here, we will explore how the ec2-instance-connect:send-ssh-public-key API is used by a threat actor to move laterally and end up exfiltrating data:
After successfully brute-forcing their way inside the EC2 instance ‘jenkins-test’, the attacker exploits the Instance Metadata Service (IMDS) to obtain temporary security credentials associated with the IAM role ‘EC2-Devs’ attached to the EC2 instance. By executing a simple curl command to the IMDS, they extract credentials that provide them with additional privileges within the AWS environment.
From the compromised EC2 instance, the attacker then initiates a series of commands to identify a new target EC2 instance in the environment named ‘dev-integration-prod’, its attached security group(s), and its instance profile. They then verify the security groups governing the target EC2 instance (dev-integration-prod) permits SSH traffic from the EC2 instance they’re on (jenkins-test). This step ensures that their lateral movement is not hindered by network access controls.
They employ the ec2-instance-connect:send-ssh-public-key API to push a temporary SSH public key from the ‘jenkins-test’ instance to the ‘dev-integration-prod’ instance. This maneuver is critical for lateral movement within the cloud environment.
Upon successfully SSH-ing into the target EC2 instance ‘dev-integration-prod’ within 60 seconds of pushing the temporary SSH public key, the attacker repeats the process of curling the IMDS for the credentials of the ‘DataStoresAdmin’ role. This time, they acquire a different set of temporary security credentials, escalating their access level within the AWS infrastructure.
Using the new credentials, the attacker gains access to S3 buckets. They then proceed to download sensitive files, searching for valuable data. It is not uncommon for such files to inadvertently contain configuration details or even direct credentials for other AWS services.
Among the stolen data, the attacker discovers a file named 'rds_password.txt' stored in an S3 bucket that contains credentials for an RDS database instance. After conducting further reconnaissance to identify the RDS instance, they establish a connection to this critical asset within the cloud environment to assess the value of the data.
Having infiltrated the RDS instance and confirmed the data, the attacker begins the process of data exfiltration through shared snapshots to their own AWS account using the ‘DatasStoresAdmin’ role credentials. This stage represents the culmination of the Attack Path, where the attacker accesses and extracts sensitive information, achieving their ultimate objective.
The ec2-instance-connect:send-ssh-public-key API is often missed but it's important for cloud safety. It's like a hidden door that bad actors can use to sneak around in cloud systems. This shows how important it is to always be on the lookout and make sure rules for who can access what (IAM policies), how different parts of the cloud are separated (network segments), and keeping an eye on cloud activities are all done right. As cloud systems get more complex, security pros need to stay ahead and be smarter than those trying to break in. It's not just about protecting each piece; it's about making the whole cloud system strong against clever attacks that might not be obvious at first.
Blog: Mastering Cloud Security: Understanding Attack Paths & Risks: This resource emphasizes the importance of recognizing attack vectors to bolster your defense against potential breaches.
Blog: Uptycs and AWS: Advanced Data Security Services, Integrations & Solutions: Discover how Uptycs’ deep integration with AWS enhances visibility, threat detection, and compliance for AWS customers.
Blog: Strengthening Cloud Workload Security with AWS Systems Manager Integration: Uncover how integrating Uptycs with AWS Systems Manager can automate the deployment of Uptycs sensors, reducing operational overhead and enhancing security.
Product Brief: Uptycs for AWS Security: Get a comprehensive overview of how Uptycs secures AWS environments, from macOS to EKS, covering cloud security posture management and more.
Follow Uptycs on LinkedIn and Twitter.