2. Lesson 1 - Get acquainted with AWS ( sort of )
Objective 1:
● Understand the confusing world of AWS
● Identify the primary offerings
● Learn who to follow for new updates
● Understand security concerns
● Look at a couple of mega breaches
Identify
Services
3. AWS is Vast
● ~ 175 Products at the time of writing
● Super confusing names
○ AWS Systems Manager Session Manager
● Various and sundry ways to
misconfigure every single option
6. What’s our defense strategy?
1. Take a principles approach
2. Focus on commonality
3. Learn from mistakes
4. Keep trying
5. Community
Picture taken by user:Poppy in June 2005. Picture taken from the meadow
7. Focus on areas of primary technology
Compute Network Storage Databases Identity
Data
Exchange
Logs Metrics
Primary Focus
Secondary
Focus
(Tools)
8. Apply Security Principles
Least Privilege Defense in Depth Keep it Simple
Know your system
Strong
Authentication
https://infosec.mozilla.org/fundamentals/security_principles.html
We’ll have some call outs from these
9. Myth
I have to be an expert at
every AWS Service to
defend the cloud.
11. So what are the primary offerings?
( my opinion not official AWS copy )
Compute Storage Networking
12. So what are the primary offerings?
( my opinion not official AWS copy )
Database
Data
Exchange
Foundation &
Tools
13. So what are the primary offerings?
( my opinion not official AWS copy )
14. Stay relevant
● Who to follow
○ https://twitter.com/0xdabbad00
○ https://twitter.com/quinnypig
○ https://twitter.com/jeffbarr
● Blogs for your area
○ https://aws.amazon.com/blogs/security/
17. Famous Data Breaches - ( not comprehensive )
● 2014 Code Spaces - leaked access key causes dissolution of business
● 2017 Uber data breach - access keys leaked in private repo
● 2018 Tesla - Hackers mine bitcoins overly permissive app
● 2019 CapitalOne - S3 Bucket exposure exposes 80,000 bank
accounts and over 1,000,000 ID numbers
● 2020 Prestige - S3 Bucket exposure of millions of travel records for
customers of Expedia, Travelocity, etc
18. Codespaces Response focus on traditional IR
SSH Keys
Instance Passwords
Access Key Pair
( Admin )
Leaked to Github
Attacker persists
in various and
stealthy ways.
● Creating
accounts
● STS Tokens
Deletes all the
infra and data Game over
19. Lessons Learned
● Access Keys will kill you before you kill the password
○ Attackers scanned for and leveraged keys very quickly
● Incident response needs to take into account cloud native tactics
○ Attackers pivoted to sophisticated persistence ( they know the platform better
than the user
● Being in the cloud itself is not a backup strategy
○ The attackers deleted all the data but it didn’t exist elsewhere
20. Uber Breach
● Hackers stole data for 57 million customers ( PII )
Attackers get
Access to
private git repo
Find AWS
Access Keys
Leverage to
exfil data
21. Lessons Learned
● Access Keys will kill you before you kill the password
○ Attackers found access keys in a private repo ( private repos are not password
stores )
● The breach was detected but not reported
● There was a pattern of incidents here for the same system
● Systems used access keys instead of other methods to gain access
22. Tesla Breach
● Bitcoin Mining and Espionage
Kubernetes
Console
AWS Access
Key Pair
( overly
permissive )
Bitcoin Miners
And spying
24. Lessons Learned
● Access Keys will kill you before you kill the password
○ Attackers found access keys in a kubernetes cluster they were too privileged
● The breach was in a dev/test environment with a lack of governance
● Exposed ancillary data for prototypes
● Attackers tried to evade detection by understanding detection
mechanisms ( govern CPU usage, use CloudFlare for hiding )
25. Capital One Breach
● Misconfigured WAF, Pivot to Credentials (SSRF), Data Exfil from S3
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
http://169.254.169.254/latest/user-data
26. Lessons Learned
● Misconfiguration allowed SSRF ( Server side request forgery )
○ Pivot to calls to localhost metadata server
● Credentials for the instance were overly permissive
● Detection capabilities were not adequate to prevent breach
28. Least Privilege Defense in Depth
Strong
Authentication
These can all be attributed to principals failures
Overly permissive
No guardrails on
access
No 2FA or
authentication of
requestor
Lack of detection
Lack of human
response
29. These can all be attributed to principals failures
Simple systems
are “knowable”
Misconfiguration
is the second
largest threat to
access key leaks
Keep it Simple
Know your system
31. Apply Defense in Depth / Strong Authentication
● Really protect those access
keys. Assume breach in design
● Safeguard the metadata
server. Assume breach in IAM
● Detect changes and analyze.
Guardrails approach
32. Know your system
● Keep it simple by making the
cloud smaller. Disable things
we don’t use.
● Understand how to detect and
respond to classes of attacks
practically
33. Questions
Find your favorite AWS Cloud breach and share a good write up in the
discord channel. Bonus points if the initial vector isn’t a leaked access
key or SSRF ;)
