DevSecCon Boston 2018: Inside an enterprise breach by Sam Bisbee

2. 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

3. 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

4. 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

5. 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

6. 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)

7. 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 http://169.254.169.254
● 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

8. Example Kill Chain
Assembled from Multiple Breaches of
Production AWS Environments

9. Credential theft from laptop, git, etc.

10. AWS persistence

11. Launch malicious EC2 host

12. Achieve network persistence

13. Lateral network movement (traditional)

14. Objective achieved: RDS root access

15. 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

16. Read more about this attack and how
Threat Stack can help:
https://www.threatstack.com/cloud-attack