Finding the Needles in a Haystack: Identifying Suspicious Behaviors...
summary
AWS uses eBPF to instrument the kernel for eBPF syscall tracing, capturing process creation, file, network and DNS events and enriching them with container and pod context to detect C2, Tor clients and crypto miners. Agents avoid reading user memory to prevent TOCTOU races (no user-space reads), emit events of about ~1 KB per event with high volume, and send them to a cloud backend that applies threat intel, stateless and stateful rules. Example detection: runtime file download → new binary executed (SHA256 match) → connect to known mining pool.
AI-written summary · about
chapters (22)
- 0:00Intro
- 0:32The challenges
- 1:17Different approaches
- 2:55Introducing Extended Berkeley Packet Filter (eBPF)
- 4:36How it works
- 5:32Linux kernel diagram
- 6:18How GD is using eBPF
- 6:59Getting started with eBPF
- 8:26eBPF Advantages & Disadvantages
- 9:38Common eBPF use cases
- 10:09eBPF @ Amazon
- 11:54Why eBPF for GuardDuty
- 13:19System Call Tracing with eBPF
- 16:49System Call Tracing - Avoiding Race Conditions
- 19:52Rich Container and Process Context
- 21:00Collected Metadata Kernel and Userspace
- 22:08Monitored Events
- 25:10On-Host Versus Backend Processing
- 26:40Example Scenario Command Injection Exploitation
- 27:24Example Scenario Detections
- 29:20Actionable Detections
- 30:31Summary
related talks
29mRuntime Security at Scale With EBPF: Hybrid Detection and Root Cause…
21mNext-Gen K8s Threat Hunting: GenAI & eBPF
23mTracking Files across the operating system using eBPF
36meBPF for Runtime Security
57mPreventing Attacks at Scale
20mThink eBPF for Kernel Security Monitoring
29mFinding the Needle in a Haystack: Tenant-Level Network...
34mHow Clusters Fail Under Attack and How We Detect It at Runtime with eBPF signals