Cloud Attack
Over the past two years, the Threat Stack Security Team has observed strong evidence of malicious actors leveraging the unique characteristics of public cloud environments to launch or hide their breaches. The following page shows an example of a common attack pattern observed by the Threat Stack Cloud Security Platform®.
See It In Action
Step 1:
Gain Access Via Access Keys
In attacks of this nature, the first step many bad actors take is to leverage stolen API Keys. Stolen keys are preferred because their use appears legitimate and often goes undetected. To obtain these keys, attackers use a variety of methods, including stealing keys from employee laptops with malware, or farming from open-source code websites like GitHub, where employees accidentally upload their API Keys. Once the actor confirms that the API Keys work, they want to ensure that they can regain access, even if someone in Security or Ops terminates their stolen Access Key. To do so, they could create new keys, IAM roles, or use another method to create a way to persist.
Step 2:
Check Permissions and Attempt Persist
Once the actor successfully enters the environment via the infrastructure APIs, they look to see whether they have direct access to the resources they need, such as an RDS database or S3 bucket. In addition to trying to access S3 data, an attacker will try and start an EC2 instance so that they can persist on the network itself.
Step 3:
Leverage EC2 with Insecure Configuration
When they discover they cannot access the RDS database or S3 buckets directly, they start to utilize their EC2 access. In this case, the actor launches EC2 instances inside the environment. Because of poor Security Group configuration in the environment, these hosts are equally as trusted as any other legitimate host on their network. Many organizations trust all traffic within their network boundary, so this gives the attacker the ability to consider lateral movement.
Step 4:
Login to EC2
After they’ve identified or launched the EC2 instance with an insecure IAM role policy, they log in. The actor has now established a beachhead in the environment’s network, allowing them to recon and scan the network that they’ve breached.
Step 5:
Move Laterally Across Hosts
The actor proceeds to move laterally from this initial rogue EC2 instance, scanning and exploiting as they compromise other hosts in the network. EC2 instances are granted IAM permissions when they launch, which in some cases can give them legitimate access to AWS managed services like S3 or RDS.
Step 6:
Land on Host Sufficient Permissions and Extract Data from RDS
Once the actor has landed on a host with the necessary IAM permissions, or with database credentials on the host, the actor can perform the necessary RDS API calls (or SQL commands) to access the database with the target data. From here, they can exfiltrate it either directly through the terminal or through their chain of compromised hosts to avoid Data Loss Prevention tools.
About This Attack
Over the past two years, the Threat Stack Security Team has observed strong evidence of malicious actors leveraging the unique characteristics of public cloud environments to launch or hide their breaches. The above diagram shows an example of a common attack pattern observed by the Threat Stack Cloud Security Platform®. The attacker traverses back and forth from the infrastructure control plane to host level in order to obtain valuable data.
Interested in Intrusion Detection with Threat Stack?