Detecting SSRF events on AWS using Splunk
summary
Recreates a 2019 SSRF that queries the EC2 metadata endpoint 169.254.169.254 to steal temporary credentials, uses those creds to create admin user and persist, and results in roughly 100 million customer records exposed (notably ~140k SSNs and ~80k bank numbers). Demonstrates tools and gaps: Splunk Stream and web logs detect the initial probe an hour and a half before GuardDuty; CloudTrail holds the stepwise API calls; Security Hub and GuardDuty surface some alerts; Splunk ES, Data Manager and Phantom SOAR enable hunting and automated response.
AI-written summary · about
chapters (21)
- 0:00Intro
- 0:19Who am I
- 3:39What is SSRF
- 5:33SSRF attack details
- 7:13How did I recreate the attack
- 7:43Discovery
- 10:15Admin access
- 11:48What did I do
- 13:05AWS Shared Responsibility Model
- 14:22What AWS told us
- 15:19What did CloudTrail say
- 16:08What didnt say anything
- 18:57Data Manager
- 20:05Data Flow
- 21:24Ecosystem
- 22:13Memes
- 23:13Screenshot
- 25:40Keep alive
- 29:17Risk Object
- 30:12Using Enterprise Security
- 31:24Summary
related talks
44mCloud Metadata Abuse
20mFantastic AWS Attacks and Where to Find Them
24mAnalytics-based investigation & automated response
16mLessons from the SOC: Analyzing and remediating cloud attack paths
44mEXPOSURE: The 5th Annual RSAC SOC Report
55mStreamline security analysis with Amazon Detective
29mAutomating Threat Detection and Remediation
40mFighting Financial Crimes as an SRE