Lateral movement: Understanding the core concept

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:

• AWS: Suppose an attacker gains control over an EC2 instance. They could then use the instance's role to call the AWS Systems Manager (SSM) API, specifically ssm:SendCommand, to execute commands on other EC2 instances that are managed by SSM. This allows the attacker to move laterally within the AWS environment, potentially accessing sensitive data or systems without being directly granted permission to those resources.
• Azure: In Azure, an attacker who has compromised a VM could exploit the Managed Identity feature, if enabled, to gain access tokens for Azure services that the VM's identity is authorized to access. By requesting tokens from the Azure Instance Metadata Service, the attacker could then use these tokens to access other Azure services like Azure Storage or Azure SQL Database, effectively moving laterally to access other resources within the Azure environment.
• GCP: An attacker with initial access to a GCP Compute Engine instance could exploit the instance's permissions to access Google Cloud APIs. For example, if the compromised instance has permissions to access Google Cloud Storage, the attacker could use the gcloud command-line tool or Google Cloud's client libraries to access or manipulate data in Cloud Storage buckets. This could allow the attacker to move laterally by accessing data and resources not directly connected to the initially compromised instance, but accessible through the cloud environment's permission model.

A practical case study: Navigating cloud security threats

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:

Curling the IMDS: Credential access

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.

Security group verification

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.

Lateral movement: Infiltrating the network

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.

Target instance compromise: Credential escalation

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.

S3 data breach

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.

RDS database compromise

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. 

Data exfiltration

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.

Conclusion

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.

Permissions required to execute this attack

• ec2:DescribSecurityGroups
• ec2:AuthorizeSecurityGroupIngress
• ec2-instance-connect:SendSshPublicKey
• s3:ListBucket
• s3:GetObject
• s3:ListObjects
• rds:CreateDBSnapshot

You might also like…

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.