Beyond the Kernel: Detecting and Defending Against eBPF-Based Rootkits

Introduction

For the past several years, Extended Berkeley Packet Filter (eBPF) has been hailed as a revolutionary technology for the Linux kernel. By allowing developers to run sandboxed, high-performance programs directly inside the kernel without modifying kernel source code or loading dangerous Kernel Modules (LKMs), eBPF has transformed network monitoring, observability, and security. Popular tools like Cilium, Falco, and Tetragon rely heavily on eBPF to gain unparalleled visibility into system behavior.

However, the cyber security landscape is defined by a constant arms race. The very features that make eBPF a dream for defenders—its deep kernel integration, efficiency, and stealth—also make it an ideal playground for advanced attackers. Today, we are seeing a significant rise in eBPF-based rootkits. These stealthy, user-space-controlled threats bypass traditional Endpoint Detection and Response (EDR) agents, modify system calls on the fly, and hide from classic forensic investigation tools.

In this post, we will dissect how eBPF rootkits operate, examine real-world evasion mechanics, and provide security practitioners and forensic analysts with actionable blueprints to hunt, detect, and neutralize these advanced threats.

The Dual-Use Dilemma: Why eBPF is Perfect for Malware

Historically, writing a Linux rootkit required developing a Loadable Kernel Module (LKM). While effective, LKMs are notoriously unstable. A minor bug in an LKM can cause a kernel panic, crashing the target system and instantly alerting administrators. Furthermore, modern Linux distributions implement strict kernel-signing requirements, making it increasingly difficult to load unsigned modules.

eBPF elegantly bypasses these hurdles. Because the kernel uses an internal eBPF Verifier, any loaded eBPF program is guaranteed to be safe in terms of execution—it cannot crash the host system, access arbitrary memory, or loop infinitely. For an attacker, this is a dream come true: a guaranteed-stable, highly privileged backdoor inside the operating system kernel.

“By utilizing eBPF, attackers can execution-proof their kernel payloads while simultaneously evading traditional signature-based detection mechanisms that monitor file systems and classic LKM loading actions.”

The Anatomy of an eBPF Intrusion

To deploy an eBPF rootkit, an attacker must first obtain root or CAP_BPF (and often CAP_SYS_ADMIN) privileges on the target system. Once administrative access is achieved, the rootkit can inject helper programs into various kernel hook points. These hooks can intercept system calls, modify network packets, or alter the data returned to user-space tools like ps, ls, or netstat.

How eBPF Rootkits Evade Detection

To understand how to defend against these tools, we must look closely at their manipulation techniques. Let us walk through the most common tactics used by modern eBPF malware.

1. System Call Hooking and Memory Modification

An eBPF program can hook into the entry point of system calls (such as sys_enter_execve or sys_enter_getdents64). By using helper functions like bpf_probe_write_user, the rootkit can actively overwrite buffer data in user space.

For example, if an administrator types ls /var/log, the system executes the getdents64 system call to list the directory contents. An eBPF program hooked to this call can intercept the output buffer, scan for specific malicious filenames (e.g., its own source files), and remove them from the list before the data is returned to the user. To the administrator, the directory appears completely clean.

2. Stealthy Network Exfiltration

By hooking into traffic control (TC) or socket filters, an eBPF rootkit can inspect every packet passing through the network interface. Attackers can leverage this to build highly resilient, passive backdoors. The rootkit can listen for a specific “magic packet” sequence (such as a custom ICMP payload). When detected, it triggers a reverse shell back to the attacker’s Command and Control (C2) server—all without opening a standard listening port that would show up on ss or netstat.

3. Bypassing Traditional Audit Daemons

Classic security auditing systems like auditd monitor user-space actions and system calls. However, because eBPF programs execute directly within the kernel execution flow and can modify data *after* it has been audited but *before* it is processed, they can easily blind standard monitoring tools. This class of attack is known as a Time-of-Check to Time-of-Use (TOCTOU) vulnerability, weaponized at the kernel level.

Forensic Hunting: How to Detect eBPF Malware

If eBPF rootkits can hide files, processes, and network connections, how do we find them? Standard troubleshooting tools will fail you, but the Linux kernel provides specialized subsystems to audit eBPF itself.

Step 1: Inventorying Running eBPF Programs

Your first line of defense is bpftool, the official utility for inspecting the eBPF subsystem. To list all currently loaded eBPF programs on a suspected host, run the following command as root:

sudo bpftool prog show

This command outputs a list of all loaded eBPF programs, their types (e.g., kprobe, tracepoint, xdp), and their unique IDs. Look for anomalies such as:

• Programs with generic or randomized names.
• Unexpected kprobe or tracepoint attachments to sensitive system calls like sys_enter_write or sys_enter_execve.
• Programs loaded without accompanying metadata or source references.

Step 2: Inspecting eBPF Maps

eBPF programs use “maps” (key-value stores in kernel memory) to share data with user-space control programs. Attackers use these maps to send configuration updates or retrieve exfiltrated data. To view all active maps, run:

sudo bpftool map show

Once you identify a suspicious map ID, you can dump its contents to inspect the payload or configuration:

sudo bpftool map dump id <map_id>

If you see IP addresses, hidden file paths, or suspicious shell command strings stored inside these maps, you have likely uncovered an active rootkit.

Step 3: Checking the System Log for eBPF Loading

The Linux kernel logs loading events for eBPF programs. You can query journalctl or check /var/log/syslog for suspicious bpf syscall invocations:

journalctl -g "bpf"

Look for unauthorized users or processes calling the bpf() system call, especially during times of suspected compromise.

Defensive Hardening: Securing the eBPF Subsystem

Detecting an active intrusion is critical, but preventing the unauthorized deployment of eBPF programs is the ultimate goal. Implement the following hardening measures to lock down your Linux environments:

1. Disable Unprivileged eBPF: By default, modern Linux kernels restrict eBPF loading to privileged users, but you should verify this setting. Ensure that unprivileged users cannot load eBPF programs by setting the corresponding sysctl parameter:
   sysctl -w kernel.unprivileged_bpf_disabled=1
2. Restrict CAP_BPF and CAP_SYS_ADMIN: Implement strict principle-of-least-privilege rules. Only allow trusted, highly containerized system services to possess these Linux capabilities.
3. Implement Kernel Runtime Security Monitoring: Use robust, eBPF-aware security platforms like Tetragon or Falco. Ironically, the best way to monitor malicious eBPF is to use a secure, trusted eBPF-based security agent that actively monitors the sys_bpf system call and flags unauthorized program loading events.
4. Enforce Locked-Down Kernels: If your servers run in a highly static environment where custom eBPF is not required, consider compiling your Linux kernels with CONFIG_BPF_SYSCALL=n or utilizing Linux Security Modules (LSMs) like SELinux or AppArmor to block access to the bpf() system call entirely for non-system processes.

Conclusion

As eBPF continues to dominate the cloud-native and modern Linux landscape, it is inevitable that threat actors will refine their ability to exploit it. eBPF-based rootkits represent a paradigm shift in Linux malware, moving the battleground from basic file-system signatures deep into the runtime execution paths of the kernel.

By understanding how these tools hook into system operations, utilizing advanced utilities like bpftool, and proactively hardening system configurations, security administrators and forensic examiners can stay one step ahead of the adversary. The key to modern system security is visibility—and that means keeping a watchful eye on the very tools designed to watch over us.