eBPF:
Security's Best Tool and Its Worst Nightmare.

What eBPF Is

Extended Berkeley Packet Filter is a Linux kernel subsystem that allows user-space programs to load bytecode into the kernel and attach it to hooks — system calls, network events, kernel functions, hardware performance counters, and user-space probes. Attached eBPF programs execute in a sandboxed virtual machine within the kernel context, without requiring kernel module privileges, and can collect data, filter packets, or enforce policies with near-zero overhead.

The eBPF verifier — a component of the kernel that checks eBPF programs before loading — prevents programs that could crash the kernel or violate memory safety. This safety model is what makes eBPF attractive for production security tooling: you can attach comprehensive monitoring to a production system without the stability risk of a traditional kernel module.

Defensive Use Cases

eBPF-based security tools represent the current state of the art for cloud-native runtime detection. The key tools in the ecosystem:

• Falco (CNCF): Uses eBPF or kernel module probes to collect system call events and evaluate them against a rule engine. Supports container context enrichment — events include the container ID, pod name, and namespace of the process that made the syscall.
• Tetragon (Cilium/Isovalent): More granular than Falco, Tetragon can observe kernel function calls, not just syscalls. Supports in-kernel enforcement — eBPF programs can return policy decisions that cause the kernel to kill or SIGKILL a process before it completes a prohibited operation.
• Pixie: eBPF-based observability for application-layer protocols — automatically traces HTTP, gRPC, PostgreSQL, and other protocols without requiring application instrumentation.
• Cilium: Network policy enforcement via eBPF, replacing iptables with kernel-level filtering that operates at the socket layer and supports identity-aware policies.

The defensive eBPF advantage over traditional host-based IDS is that monitoring is kernel-level and therefore cannot be evaded by application-layer evasion techniques. A process cannot hide a connect() syscall from an eBPF program attached to sys_connect — the syscall must pass through the hook to execute.

Offensive eBPF

The offensive use of eBPF by attackers has grown significantly as the technique has become more accessible. eBPF rootkit proof-of-concept code is publicly available, and production-capable eBPF-based offensive tools have been observed in threat actor toolkits. The barrier to entry is root access on the host — which is obtainable via container escape vulnerabilities, service account token theft, or direct host compromise.

Offensive eBPF capabilities documented in public research and observed in the wild include credential harvesting, process hiding, network traffic manipulation, and detection evasion — all implemented as eBPF programs that run at kernel level with no user-space footprint.

eBPF Rootkit Capabilities

An attacker who can load eBPF programs on a host can implement any of the following:

• Credential harvesting: Attach to sys_read on file descriptors corresponding to terminal inputs, SSH connections, or PAM authentication libraries. Capture passwords and tokens as they are typed or processed in memory. No disk-based keylogger required — the capture happens in kernel memory.
• Process hiding: Hook the getdents64 syscall (used by tools like ps and directory listing to enumerate processes) and filter out attacker-controlled process entries from the results. The process exists in the kernel's process table but does not appear in user-space enumeration.
• Network traffic interception: Attach to XDP (eXpress Data Path) or TC (Traffic Control) hooks to intercept, modify, or redirect network packets before they reach the application layer. Man-in-the-middle within the same host without any detectable TCP connection.
• File system manipulation: Hook vfs_read to return falsified contents for specific files — for example, returning clean versions of modified configuration files to hide backdoor configurations from audit tools.
• eBPF tool evasion: Hook the eBPF syscall itself to filter out eBPF events sent to detection tools. An eBPF rootkit that can intercept the events sent by a defensive eBPF tool like Falco can suppress its own activities from Falco's event stream.

Evading eBPF Monitoring

The most sophisticated eBPF rootkits implement direct detection evasion against eBPF-based security tools. The technique exploits the fact that eBPF programs communicate with user space through ring buffers or perf events. A malicious eBPF program attached at higher priority (lower hook priority number) than the defensive tool's program can process the same event and suppress it from reaching the defensive tool's buffer — a targeted event filter that operates transparently within the kernel.

This technique is well understood in the research community and represents a fundamental limitation of eBPF-based detection: a sufficiently privileged attacker who loads eBPF programs after a defensive tool has loaded can potentially blind that tool. Defences include kernel lockdown mode (prevents loading eBPF programs after a certain point), integrity measurement of the BPF program map, and out-of-band monitoring that is harder to target (hardware-based tracing, separate monitoring infrastructure).

Hardening Against eBPF Attacks

1. Block CAP_BPF and CAP_SYS_ADMIN in container seccomp profiles: Container workloads that do not need eBPF capabilities should have them removed from their effective capability set. Add bpf to your seccomp filter's blocked syscall list for standard application containers.
2. Enable kernel lockdown mode where possible: Linux kernel lockdown mode (available in kernel 5.4+) restricts the ability to load unsigned kernel code and eBPF programs in integrity mode. This prevents post-boot eBPF program loading without appropriate signatures.
3. Use BPF LSM to restrict eBPF program loading: BPF LSM hooks allow security modules to enforce policy on eBPF program loading, including which users and processes are permitted to load programs and attach them to which hooks.
4. Monitor BPF program loads as a high-value security event: Every bpf(BPF_PROG_LOAD) syscall should be logged and reviewed. Unexpected eBPF program loads — from processes other than your known security tools — are a high-severity indicator of either a rootkit installation or an exploitation in progress.
5. Implement defence in depth that does not rely solely on eBPF: eBPF-based security monitoring can be subverted by eBPF-based attacks. Supplement eBPF monitoring with network-level monitoring (out-of-band NetFlow, VPC flow logs), cloud provider audit logs, and periodic static analysis of the running system's state from a trusted out-of-band management plane.
6. Treat root access on any node as a full cluster compromise: The realistic response to confirmed eBPF rootkit installation is to treat the compromised node as fully controlled by the attacker. Rotate all credentials that were accessible from that node, inspect all containers that ran on it for exfiltration indicators, and rebuild the node from a clean image.