eBPF Escapes: When Your Monitoring Tool Becomes the Ultimate Rootkit 🕵️

In the landscape of 2026, the Linux kernel is no longer a static gatekeeper; it is a dynamic, programmable playground. At the heart of this transformation is eBPF (extended Berkeley Packet Filter). Once a humble tool for filtering network packets, eBPF has evolved into the “superpower” of cloud-native observability, networking, and security. It powers the world’s most advanced service meshes, high-performance firewalls, and deep-system monitors.

However, as the old security adage goes: with great power comes great exploitability. While legitimate tools like Cilium, Tetragon, and Pixie use eBPF to protect clusters, a new generation of “eBPF Escapes” has emerged. In 2025 and early 2026, researchers have seen a surge in eBPF-based rootkits—malicious programs that leverage the kernel’s own “safety-checked” bytecode to hide files, steal credentials, and redirect traffic with near-total invisibility.

This article explores the mechanics of eBPF rootkits, the vulnerabilities in the eBPF verifier, and how your most trusted monitoring tool could be the very thing that blinds you to an intrusion.

1. The Architecture of Control: Why eBPF is the Perfect Weapon

To understand how eBPF becomes a rootkit, one must understand why it was built. Traditionally, changing kernel behavior required writing a Kernel Module (LKM). This was dangerous; a single bug could crash the entire system (a “Kernel Panic”).

eBPF changed this by introducing a Sandboxed Virtual Machine inside the kernel. It allows developers to:

• Write Code in a restricted C-like language.
• Verify Safety via an “eBPF Verifier” that ensures the code doesn’t loop infinitely or access illegal memory.
• Just-In-Time (JIT) Compile the code into native machine instructions for near-zero overhead.
• Attach to Hooks like syscalls, tracepoints, or network events.

The Attacker’s Perspective

For an attacker, eBPF is superior to traditional rootkits for three reasons:

Persistence without Reboots: eBPF programs can be loaded and unloaded dynamically.

Safety from Detection: Traditional EDR (Endpoint Detection and Response) tools look for suspicious files or processes. eBPF programs live in the kernel’s memory space, often leaving no trace on the disk.

Legitimate Masquerading: Because so many security tools (like Falco or Datadog) use eBPF, a malicious eBPF program can easily hide in the noise of legitimate kernel probes.

2. Weaponizing the Hook: How eBPF Rootkits Manipulate Reality

An eBPF rootkit doesn’t break the system; it warps its perception. By hooking into critical kernel functions, an attacker can change what the OS reports to the user.

A. Hiding Files and Processes (The getdents64 Hook)

The most common way to hide a rootkit is to hook the sys_getdents64 syscall. This is the function the kernel uses to list files in a directory.

The Attack: When you run ls or ps, the kernel calls getdents64. A malicious eBPF program (attached via a fexit or kretprobe hook) intercepts the list of files before it reaches user-space.

The Result: The eBPF program scans the list, identifies any filenames or Process IDs (PIDs) associated with the malware, and deletes them from the buffer. The user sees a “clean” directory, while the malware continues to run in plain sight.

B. Network Redirection (XDP and TC Hooks)

eBPF operates at the XDP (eXpress Data Path) level—the lowest point in the network stack, before the packet even reaches the Linux firewall (iptables/nftables).

The Attack: Rootkits like LinkPro (discovered in late 2025) use XDP to listen for “Magic Packets.” These are specially crafted TCP packets (e.g., a specific window size or sequence number) that act as a “Wake-on-LAN” for the malware.

The Result: The rootkit can intercept C2 (Command and Control) traffic and drop the packets so they never show up in tcpdump or Wireshark. It can also redirect traffic to a hidden proxy, exfiltrating data without the local network stack ever knowing a connection was made.

C. Credential Theft (Uprobes and PAM)

Attackers can use uprobes (User-level Probes) to hook functions inside shared libraries like libpam.so (the Linux Pluggable Authentication Module).

The Attack: Tools like Pamspy hook the pam_get_authtok function.

The Result: Every time a user types a password for sudo, ssh, or a local login, the eBPF program captures the cleartext password and stores it in an eBPF Map (a kernel-resident data structure) for the attacker to retrieve later.

3. Breaking the “Bouncer”: The eBPF Verifier Bypass

The only thing standing between a developer and a kernel-wrecking bug is the eBPF Verifier. It is the “bouncer” of the kernel, performing static analysis to ensure memory safety. However, the verifier is a complex piece of software, and like all software, it has bugs.

The find_equal_scalars Vulnerability

In a major 2024 security audit by the NCC Group, researchers identified logic flaws in how the verifier tracks “scalar” values (integers).

The Exploit: An attacker can write an eBPF program that uses complex bitwise operations (AND, OR, XOR) to trick the verifier into thinking a register contains a safe value (e.g., 0 to 64), when in reality, it contains a large value (e.g., a memory address).

The Escape: Once the verifier is tricked, the JIT compiler produces code that allows the eBPF program to read and write arbitrary kernel memory. This is the “Holy Grail” for an attacker, turning a sandboxed program into a full-scale kernel exploit.

Logic Flaws vs. Feature Abuse

Not all eBPF escapes require a “vulnerability.” Many leverage the kernel’s own helper functions. For example, bpf_probe_write_user is a legitimate function used by debuggers to modify memory. An attacker can use this to inject a “root” user into the /etc/passwd buffer in memory as it’s being read by the login process, without ever touching the actual file on disk.

4. The Visibility Gap: Why Traditional Security is Blind

Why can’t your high-priced EDR tool find these rootkits? The answer lies in the Visibility Gap.

Feature	Traditional Malware	eBPF Rootkit
Disk Footprint	Binary files in /usr/bin or /tmp	Resides only in Kernel Memory
Syscall Logs	Visible in auditd or syslog	Hooks the logging functions themselves
Network Traffic	Visible to iptables and tcpdump	Intercepted at the XDP/Driver level
Detection	File signatures/Hashes	“Signless” bytecode execution

In 2026, most EDRs are still focused on user-space. They monitor process trees and file modifications. An eBPF rootkit, however, is a “ghost in the machine.” It doesn’t create a new process; it just changes how existing processes behave.

If you ask the kernel, “Is there a process named ‘backdoor’?”, the kernel (which is now under the control of the rootkit) simply says, “No.”

5. Case Study: The 2025 LinkPro Outbreak

The most sophisticated example of an eBPF escape to date is LinkPro, a rootkit discovered in October 2025 targeting AWS-hosted Kubernetes clusters.

Initial Access: Attackers exploited a vulnerability in a Jenkins server (CVE-2024-23897) to gain initial access.

Deployment: Instead of a standard shell, they deployed a malicious Docker image containing eBPF modules.

Kernel Hooking: LinkPro loaded two modules. One hooked sys_bpf—the syscall used to load other eBPF programs. This allowed the rootkit to hide its own presence from tools like bpftool.

Stealth C2: The rootkit remained dormant until it received a “Magic TCP SYN” packet with a specific window size (54321). Only then would it open a reverse shell, making it impossible to detect via standard port scanning.

LinkPro demonstrated that eBPF is not just a tool for local persistence; it is a tool for cloud-native lateral movement.

6. How to Defend Your Kernel in 2026

If the verifier can be bypassed and the hooks can be hidden, is there any hope for defenders? Yes, but it requires a shift from “Legacy Security” to “Kernel-Aware Security.”

1. Hardening the Kernel Configuration

The first line of defense is restricting who can load eBPF programs.

Disable Unprivileged BPF: Ensure kernel.unprivileged_bpf_disabled = 1 is set. This prevents non-root users from loading any BPF code.

Limit Capabilities: Use Linux Capabilities to ensure only specific services (like your monitoring agent) have CAP_BPF and CAP_PERFMON.

2. Runtime Integrity Monitoring (Tetragon and Tracee)

Ironically, the best way to fight an eBPF rootkit is with better eBPF. Tools like Tetragon (by Cilium) use eBPF to monitor the state of the kernel itself.

Signature Enforcement: In 2026, many organizations have moved to Signed eBPF Programs. The kernel is configured to only load BPF bytecode that has been cryptographically signed by a trusted authority (like the security team).

BTF Integrity: Monitoring BPF Type Format (BTF) data can reveal when a rootkit has modified kernel structures to hide its maps.

3. Forensic Enumeration

Security teams should regularly run “Kernel Snapshots.”

bpftool: Use bpftool prog show to list all loaded programs. If there are programs with no associated name or PID, investigate immediately.

Memory Forensics: In high-security environments, hypervisor-level memory analysis (using tools like Volatility 3) can identify eBPF programs that have hooked sys_bpf to hide from bpftool.

4. Watch for “Magic Packets”

Modern firewalls should be configured to look for “Anomalous Header Values.” eBPF rootkits often use non-standard TCP flags or window sizes for activation. Behavioral AI in 2026 firewalls is now specifically tuned to detect these “low-frequency, high-intent” packets.

7. Conclusion: The Dual-Use Nature of the Modern Kernel

As we move further into 2026, the battle for the Linux kernel will only intensify. eBPF is a classic “dual-use” technology—a breakthrough for performance and observability that doubles as the ultimate toolkit for sophisticated actors.

For organizations, the takeaway is clear: You cannot trust what you cannot verify. If you rely on eBPF for your monitoring and security, you must also secure the eBPF subsystem itself. The very tool that gives you “X-ray vision” into your containers can, if compromised, become a blindfold that hides a predator in your core.

Is your kernel programmable? Yes. But the question is: who is doing the programming?