eBPF for Production Detection: What It Catches That EDR Misses

Cybersecurity

eBPF lets you instrument the kernel without writing kernel modules. For Linux production hosts, it catches a class of attack that traditional EDR cannot see. The four detection rules we deploy on every engagement.

By Arjun Raghavan, Security & Systems Lead, BIPI · February 12, 2026 · 7 min read

Most enterprise EDR products on Linux are user-space agents that read /proc, audit logs, or hook syscalls via ptrace. They catch the obvious — process executions, file writes — and miss anything that bypasses standard syscalls or runs at a level the agent cannot observe. eBPF closes that gap by giving you in-kernel programmable instrumentation at the syscall, network, and tracepoint level.

Falco, Tetragon, and Cilium-tetragon are the three production-grade eBPF runtime security frameworks we deploy. The framework choice matters less than the rules. Below: the four eBPF detection rules we ship on every engagement and what each one catches that older EDR cannot.

Rule 1: shell spawned by long-running service

An attacker who exploits a web server has to spawn a shell somewhere. The web server (nginx, apache, postgres) does not normally spawn /bin/bash or /bin/sh. eBPF can hook execve and inspect the parent process tree at the moment of the spawn.

Falco rule equivalent: 'spawned shell by service binary'. Tunes for the false positives (cron jobs, deployment hooks). Real attacker behaviour after RCE always passes through this rule because shell spawn is unavoidable.

Rule 2: writes to sensitive paths from unexpected processes

Files like /etc/passwd, /etc/shadow, /root/.ssh/authorized_keys, and crontab files have a small set of legitimate writers. Anything outside that set is suspicious. eBPF hooks the open syscall and the write syscall to capture path + writing process.

User-space EDR can do this with audit subsystem, but eBPF catches writes that bypass audit (some persistence techniques use io_uring, which audit historically missed). eBPF programs can hook io_uring as well.

Rule 3: outbound network from unexpected processes

Postgres talks to its replicas. nginx talks to upstream backends. Most processes have a small set of expected network destinations. An eBPF program at the connect syscall logs every outbound connection by process. The rule alerts on any connection from a process to a destination not on the process's allowlist.

This is the rule that most reliably catches reverse shells, C2 callbacks, and post-exploitation tools that need to phone home.

Rule 4: privilege escalation via setuid / capability change

Modern Linux exploits often involve gaining additional capabilities (CAP_SYS_ADMIN, CAP_NET_ADMIN) or transitioning user IDs (setuid). eBPF tracepoints for these transitions log the process, the new credential set, and the trigger. Combined with the parent-process tree, the rule catches setuid binaries used for privilege escalation, kernel-exploit-driven uid transitions, and namespace breakouts.

Performance overhead

The fear about eBPF is that kernel-level instrumentation will tank performance. In practice, with correctly written probes (no unbounded loops, no long-running per-event handlers), the overhead on a typical web server is under 1 percent CPU. Falco, Tetragon, and Cilium-tetragon publish their overhead numbers; verify on your workload during the pilot.

Deployment recipe

1. Pilot on a non-production node for two weeks. Watch the false-positive rate.
2. Tune the rules to under 5 false positives per node per day. Most tuning is allowlisting legitimate process behaviours.
3. Roll out to production in waves. 5 percent of fleet, then 25, then 100.
4. Connect the eBPF event stream to your SIEM. Real-time alerting on the four rules.
5. Quarterly review of the rule set against new MITRE ATT&CK techniques. Add rules as new attack patterns emerge.

Closing

eBPF is the most significant new defensive primitive for Linux runtime security in a decade. The rules are not exotic — they are the same detection ideas that Windows EDR has had for years, finally available on Linux without kernel modules and without the performance cost of older approaches. Teams not running eBPF detection in 2026 are missing the layer of the stack where most modern Linux attacks become visible.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.