In 2024, the Dirty Pipe follow-on variants showed attackers exploiting kernel-level misconfigurations within seconds of landing on a host. Traditional log-based detection caught them after the damage. eBPF — Extended Berkeley Packet Filter — lets you hook directly into the Linux kernel and catch malicious behavior as it happens, not after the fact.
What eBPF Actually Does for Security
eBPF lets you run sandboxed programs inside the Linux kernel without modifying kernel source or loading custom modules. Think of it as a tap on your kernel’s nervous system. Security tools use it to trace syscalls, monitor network connections, and watch file access — all with microsecond latency and minimal overhead.
The ecosystem has matured fast. Tools like Falco, Tetragon, and the BCC toolkit all use eBPF under the hood. You can also write raw eBPF probes with bpftrace — a high-level tracing language that feels like awk for your kernel.
Detecting Privilege Escalation in Real Time
One of the most valuable things you can do with eBPF is watch for setuid and setgid syscall patterns that signal privilege escalation. An attacker who lands a shell as www-data and then calls setuid(0) after exploiting a local vuln is doing exactly this.
Run this one-liner with bpftrace — a kernel tracing tool that compiles eBPF programs from a C-like scripting language:
# On prod-web-01 (192.0.2.14) as root
bpftrace -e '
tracepoint:syscalls:sys_enter_setuid {
printf("[ALERT] setuid(%d) called by PID %d (%s) UID %d\n",
args->uid, pid, comm, uid);
}'Within seconds of running that on your host, you might see output like this:
[ALERT] setuid(0) called by PID 31847 (python3) UID 33
[ALERT] setuid(0) called by PID 31847 (python3) UID 33PID 31847 is a python3 process running as UID 33 — that is www-data on a Debian-based system — and it is calling setuid(0) to try to become root. That is not normal web server behavior. Ever.
Your next move: kill that PID immediately, then check /proc/31847/cmdline and /proc/31847/exe before the process exits to get the full command and binary path. Correlate the timestamp with your web access logs to find the initial exploit request.
Tracing Outbound Connections from Unexpected Processes
Post-exploitation, attackers almost always phone home. A compromised nginx worker spawning a reverse shell to an external IP is a classic indicator. eBPF can catch the connect() syscall before the TCP handshake even completes.
Use the execsnoop and tcpconnect tools from the BCC toolkit — a collection of pre-built eBPF scripts for performance and security analysis:
# Install BCC tools on Ubuntu
apt install bpfcc-tools -y
# Watch all outbound TCP connections system-wide
/usr/sbin/tcpconnect-bpfcc -P 0Output during an active compromise might look like this:
PID COMM IP SADDR DADDR DPORT
31902 sh 4 192.0.2.14 203.0.113.88 4444
31902 sh 4 192.0.2.14 203.0.113.88 4444
31905 curl 4 192.0.2.14 203.0.113.99 80A bare sh process connecting out to 203.0.113.88 on port 4444 is a textbook reverse shell. The curl call two seconds later is likely the attacker staging a second-stage payload. You have the PID, the parent process, and the destination IP — everything you need to block at the firewall and begin forensics.
Cross-reference that PID with ps auxf to find its parent. If the parent is nginx or php-fpm, you have confirmed remote code execution. Isolate the host, snapshot the disk, and rotate all credentials that were accessible from that server.
Putting It Together: A Lightweight Monitoring Stack
Running raw bpftrace one-liners manually does not scale. For production, layer these tools:
- Tetragon (by Cilium) — deploys as a Kubernetes DaemonSet or systemd service, ships pre-built eBPF policies for common attack patterns, and streams JSON events you can pipe straight into your SIEM.
- Falco — rule-based alerting engine with an eBPF driver; write rules in YAML to fire on exactly the syscall patterns you care about.
- bpftrace — keep it available for ad-hoc investigation during an active incident. It is your scalpel.
The key architectural point: eBPF observability runs in kernel space. An attacker who only has a userland shell cannot tamper with your probes the way they can delete logs in /var/log. That asymmetry is what makes eBPF-based detection so durable.
What To Do Now
Install bpftrace on one Linux host you control right now — apt install bpftrace or dnf install bpftrace — and run the setuid detection one-liner from the first example while you trigger a test sudo su in another terminal. Watch your own privilege escalation appear in the output. Once you have seen it fire on a known-good event, you will immediately understand why this belongs in your production detection stack.
