Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DevSecCon Boston 2018: Inside an enterprise breach by Sam Bisbee


Published on

DevSecCon Boston 2018: Inside an enterprise breach by Sam Bisbee

Published in: Technology
  • Be the first to comment

  • Be the first to like this

DevSecCon Boston 2018: Inside an enterprise breach by Sam Bisbee

  1. 1. Today’s discussion ● Why is AWS unique and what is this intel based on? ● Where AWS leveraged attacks started -- tired of hearing about S3 bucket leaks? ● Observed bad actors’ growing AWS sophistication in attacks Sam Bisbee Chief Security Officer Threat Stack
  2. 2. Note on the intelligence & data ● All intelligence and data is from production customer environments and has therefore been anonymized ● Certain technical details have been modified that do not change the analysis or intelligence ● Data and technical details from multiple breaches have been combined in this report - we are not discussing a single observed customer breach
  3. 3. Never forget... ● AWS APIs are accessible anywhere with a set of credentials (Access Key) ○ This means your infrastructure control plane is always on the Internet ● Therefore, AWS API or console access is the equivalent of physical data center access ● Access Keys can be scoped to specific source IP addresses, but this is isolated to the key itself, it does not create a firewall policy for your AWS APIs
  4. 4. Types of breaches 1. Opportunistic - scanning infrastructure of any organization, generic objectives a. Ex., scan entire AWS IP address space for common vulnerabilities, performing basic initial exploit with minimal follow on activity b. Objective may simply be to extend the botnet for higher rental fees, cryptojacking, etc. c. Lots of automation, lowering investment for positive ROI on low value targets 2. Persistent - attempting to gain specific objectives in specific organizations a. Higher value objectives, so typically leverage automation and manual work b. Likely recon their target heavily so loud activity is minimal
  5. 5. Where the attacks started ● Credential theft - admin user/pass or AWS Access Key, used to spin up EC2 instances or gain direct data access to S3 and RDS ● Persistence - create new credentials and Access Keys, leverage AssumeRole and IAM misconfiguration complexity ○ Ex., Code Spaces shutdown after AWS console was ransomed in 2014 ● AWS Service Use - mostly traditional AWS services like IAM, EC2, and S3 ○ EC2 focus was primarily LaunchInstance, creating new EC2 servers that the botnet was extended to, and configuring Security Groups (firewalls)
  6. 6. Growing Sophistication ● Began observing mid-to-late 2016, gaining momentum in 2017 ● Attacks crossing the membrane between AWS APIs and hosts multiple times ● Leveraging lesser known or often forgotten EC2/IAM attributes ○ EC2 instances have IAM roles ○ EC2 instance metadata service: curl ● Chaining multiple AWS APIs with traditional network attacks ○ Ex., launch EC2 server in database server subnet with user data script that “phones home” to attack infrastructure for manual control
  7. 7. Example Kill Chain Assembled from Multiple Breaches of Production AWS Environments
  8. 8. Credential theft from laptop, git, etc.
  9. 9. AWS persistence
  10. 10. Launch malicious EC2 host
  11. 11. Achieve network persistence
  12. 12. Lateral network movement (traditional)
  13. 13. Objective achieved: RDS root access
  14. 14. Key Takeaways ● Attackers aren’t always persisting to dive deeper into the host ● It’s important to monitor your entire infrastructure, not just your important data, for the full story - this barely scratches forensics! ● Attackers aren’t always looking for large amounts of data ● Data can be exfiltrated directly thru AWS APIs, not just your LAN and hosts, so your strategy must cover both
  15. 15. Read more about this attack and how Threat Stack can help: