Linux Kernel eBPF Monitoring Rootkit Threats and Evasion Techniques

Why eBPF Became Central to Linux Runtime Security

eBPF became central to Linux runtime security because it lets defenders observe what the kernel is doing in real time. Instead of relying on logs written after an event happens, security tools can capture process execution, file access, and network connections directly inside the kernel as they occur. That changed how Linux runtime monitoring works.

Security platforms attach eBPF probes to tracepoints and system calls, collecting events as the kernel handles them and streaming that kernel telemetry to user-space analysis engines. Those engines evaluate the activity and decide whether something looks suspicious.

Most modern runtime tools rely on this model. Falco, Cilium Tetragon, and KubeArmor all use eBPF probes to watch system behavior from inside the kernel rather than trying to reconstruct activity later from logs.

Because the instrumentation runs at the kernel level, eBPF security monitoring sees events before user-space software can hide them or filter them out. 

Researchers have also examined this architecture in depth. Work on eBPF runtime monitoring research describes pipelines where kernel probes continuously stream telemetry into external analysis engines designed to detect anomalies across running workloads.

Over time, that telemetry pipeline became the backbone of modern Linux kernel security tools. This also means attackers have started looking for ways to interfere with it.

How eBPF Monitoring Pipelines Work

Most runtime monitoring built on eBPF follows the same event pipeline. Activity occurs inside the kernel, probes capture the event, and the resulting telemetry is forwarded to the user space, where the monitoring engine evaluates it.

The flow usually looks like this:

Kernel Event

• A process executes, opens a file, or creates a network connection
• The kernel triggers a tracepoint or syscall hook

eBPF Probe

• The attached eBPF program collects metadata about the event
• Process ID, command, file path, and other execution context

Ring Buffer Transport

• The probe writes the event into the BPF ring buffer (a shared memory queue used to move events from the kernel to user-space monitoring tools).
• The buffer acts as the communication channel between kernel space and user space

User-Space Analysis

• A monitoring engine reads events from the buffer
• Detection logic evaluates whether the behavior is suspicious

This pipeline creates a single point where telemetry leaves the kernel and becomes visible to monitoring systems. If events are filtered or dropped before they reach the ring buffer, the monitoring engine continues running but receives incomplete data.

That boundary between kernel event generation and ring buffer submission is exactly where some rootkits attempt to interfere.

Why Rootkits Target Observability Systems

Kernel rootkits are designed to operate without being detected, which means their success depends less on what they can execute and more on whether monitoring systems can see the activity. Once malicious code reaches kernel space, hiding the evidence becomes the primary objective.

Modern Linux runtime monitoring tools made that harder by observing activity directly inside the kernel. Security platforms attach probes that capture process execution, file access, and network events as they occur, then forward that telemetry to detection engines in user space.

Rootkits have started adapting to that model by targeting the telemetry path instead of trying to hide every action individually. One technique involves intercepting the bpf_ringbuf_submit function that eBPF programs use to push events into the ring buffer. When a rootkit filters or drops those events before they reach the buffer, the activity still occurs on the system, but the monitoring engine never receives the record that would trigger an alert.

Other stealth techniques avoid the monitoring hooks entirely. The “Curing” proof-of-concept demonstrated how attackers could use io_uring asynchronous I/O paths to perform operations that bypass traditional syscall tracing, which allows file operations and other actions to occur without triggering the probes many monitoring tools depend on.

These techniques expose a structural problem in kernel security monitoring because rootkits and detection systems operate at the same privilege level. When both the attacker and the monitoring system run inside the kernel, the rootkit has the ability to manipulate the telemetry pipeline that security tools depend on to understand system behavior.

The SPiCa Experiment and eBPF Telemetry Evasion

The SPiCa project explores what happens when kernel malware begins manipulating the eBPF telemetry pipeline itself. Researchers tested the approach against the Singularity LKM rootkit, focusing on whether monitoring systems could still detect activity when a rootkit attempts to filter events before they leave the kernel.

The design relies on a cross-view monitoring model that collects system signals from two independent perspectives and compares the results. Platform engineers may recognize the pattern because it resembles the sidecar architecture used in service meshes, where a sidecar (a small helper process that runs alongside an application to handle tasks like logging, security, or networking without modifying the application itself) observes the workload from outside the main process and reports behavior independently.

SPiCa applies the same idea at the kernel level. Instead of trusting a single telemetry stream, the system introduces a second observer that monitors activity through a separate perspective and compares the output against the primary monitoring pipeline. You can think of it as a sidecar for the kernel, watching the same system activity while reporting through an independent path that a rootkit cannot easily manipulate.

The experiment demonstrates several techniques that expose weaknesses in rootkit telemetry filtering.

PID Obfuscation to Bypass Rootkit Filters

The Singularity rootkit attempts to suppress telemetry by filtering out events associated with specific process identifiers. Many rootkits rely on this approach because monitoring systems often include the PID in kernel event metadata, which allows malware to drop events tied to protected processes.

SPiCa avoids this filter by masking process identifiers with a 64-bit XOR value (a simple mathematical transformation that hides the original value) derived from /dev/urandom, a Linux system source used to generate random numbers, before the telemetry enters the monitoring pipeline.

• Kernel events still contain the process identifier
• The identifier is XOR-masked before the event is exported
• The monitoring system reverses the mask in userspace

Because the rootkit expects predictable PID values, the masked identifiers appear as random data and pass through the filtering logic.

Filtering Weakness in Rootkit Event Suppression

Rootkit filtering mechanisms typically depend on recognizable values such as known PIDs or command names. When SPiCa injects masked identifiers into the telemetry stream, the filtering logic fails to recognize the events it was designed to remove.

The result is simple but effective. The event reaches the user space normally, the monitoring system decodes the identifier, and the activity becomes visible again.

Hardware Validation Using Non-Maskable Interrupts

SPiCa also introduces a hardware verification signal using CPU non-maskable interrupts (NMIs). These interrupts originate from the processor itself and cannot be disabled by software running in the kernel.

• NMIs generate a high-frequency system heartbeat
• The signal confirms CPU activity independently of kernel telemetry
• The monitoring system compares hardware activity with reported events

If the kernel telemetry indicates that no suspicious processes are running but the hardware observer shows active execution associated with hidden workloads, the discrepancy reveals that something inside the kernel is manipulating the telemetry pipeline.

Cross-View Monitoring Exposes Telemetry Manipulation

The key idea behind the SPiCa experiment is differential monitoring. Software telemetry from eBPF probes represents one view of system behavior, while hardware signals such as NMIs provide another. When those views disagree, the mismatch indicates that the telemetry pipeline may be compromised.

The experiment highlights an important shift in Linux runtime security. If attackers can interfere with kernel telemetry, monitoring systems may need independent signals outside the software pipeline to verify that the system is reporting events honestly.

Why This Matters

If a rootkit filters a process event before it reaches the ring buffer, the monitoring system never receives the record that something happened. The malicious process can continue running on the system, but the security dashboard remains green and shows zero alerts because the event was removed before the monitoring tool could see it.

Hardware Signals vs Software Telemetry

Software monitoring inside the kernel can be manipulated. Hardware signals are much harder to fake.

The SPiCa experiment uses CPU non-maskable interrupts (NMIs) as an independent signal. These interrupts originate from the processor and fire at a fixed rate, typically around
f = 1000\ \text{Hz}
which creates a continuous hardware heartbeat that kernel software cannot disable. That difference matters when telemetry becomes unreliable.

The security implication is straightforward. If the monitoring system reports that no suspicious processes are running but the hardware signal shows continuous CPU activity, the mismatch reveals that something inside the kernel is suppressing telemetry.

Why Linux Runtime Security Can’t Fully Trust Kernel Telemetry

The SPiCa experiment highlights both the strength and the weakness of modern Linux runtime monitoring. eBPF-based systems provide deep visibility into process execution, file access, and network behavior while maintaining low overhead, which is why the model became widely adopted across container security and cloud runtime protection tools.

The research also shows that most monitoring platforms depend on a telemetry pipeline that can be manipulated inside the kernel. If a rootkit filters events before they reach the ring buffer or user-space analysis engine, the monitoring system continues running normally while the activity it relies on is silently removed from the event stream.

Some of these blind spots already exist in production environments. Operations performed through io_uring asynchronous I/O paths can bypass traditional syscall tracing used by many monitoring tools, and kernel malware that intercepts functions responsible for exporting eBPF events can suppress telemetry before it leaves the kernel.

The Falco kernel event monitoring documentation explains that runtime detection relies on kernel-generated events being exported to the user space, where security rules evaluate system activity. When those events are filtered or modified inside the kernel, the monitoring engine receives an incomplete view of the system.

For Linux defenders, the practical takeaway is straightforward. eBPF monitoring remains extremely valuable, but it should not be treated as a single source of truth. Combining kernel telemetry with other signals, such as Linux Security Module hooks or hardware indicators, makes it significantly harder for attackers to hide activity inside the kernel monitoring pipeline.

The Future of Linux Rootkit Detection

Linux rootkits have always tried to hide inside the operating system. What is changing now is where they hide. Instead of only masking processes or files, newer techniques focus on manipulating the monitoring systems that defenders rely on to understand what the kernel is doing.

Research like SPiCa shows how fragile that assumption can be. When a rootkit interferes with the telemetry pipeline, the monitoring tools may still be running normally while the events they depend on are filtered or suppressed before reaching user space. That basically changes the security model for Linux runtime monitoring.

Defenders can no longer assume that kernel telemetry represents the full picture of system activity. Monitoring systems increasingly need independent signals that verify what the software reports, whether that comes from hardware mechanisms such as NMIs, deeper kernel hooks like Linux Security Modules, or other observation paths that operate outside the standard event pipeline.

The direction is becoming clearer as these experiments evolve. Linux runtime security is moving toward a trust but verify model where software telemetry is treated as one signal among several, and independent observers are used to confirm that the kernel is reporting events honestly.