Cloud Security Platform
A single, cloud-native platform for workload compliance and security across the entire infrastructure stack, throughout the application lifecycle.
Threat Stack Oversight (SOC)
Reduce mean-time-to-respond with 24/7/365 monitoring and alert escalation from the Threat Stack Security Operations Center.
Threat Stack Insight
Improve your cloud security posture with deep security analytics and a dedicated team of Threat Stack experts who will help you set and achieve your security goals.
Modern Environment Security
File Integrity Monitoring
Intrusion Detection
Container & Kubernetes Security
ThreatML - with Supervised Learning
Cloud Compliance Overview
DevSecOps Security
Microservice Security
Insider Threat Detection
AWS Security
Fargate Security Monitoring
CloudTrail Monitoring
AWS Graviton2 / Arm Support
Integrations
Security Research Center
Customers
Case Studies & Testimonials
Video Overview
Reviews
View Resource Center
Blog
Cloud security tips, insights, and ideas.
Newsroom
Stay up to date with the latest press releases, news, and events from Threat Stack.
Watch a sophisticated cloud attack and learn the necessary steps to prepare yourself.
Please enable JavaScript in your browser for better use of the website, some features like forms and videos use Javascript in order to display the elements.
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®.
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.
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.
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.
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.
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.
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.