Singularity Linux Rootkit Sidesteps Elastic Defend’s eBPF Module‑Load Checks

A security researcher has uncovered a method used by the Singularity Linux rootkit to evade detection by Elastic Defend, the popular endpoint protection platform that relies on eBPF to monitor kernel activity. By suppressing the telemetry that reports module loads, the rootkit can remain hidden across several layers of the security stack.

Elastic Defend employs an eBPF‑based module‑load sensor that watches for the insertion of kernel modules, a common indicator of malicious activity. When a new module is loaded, the sensor generates an event that is forwarded to the cloud‑based analytics engine, where it can trigger alerts or automated responses. This approach has been praised for its low overhead and deep visibility into the operating system.

The researcher found that Singularity leverages a trusted‑process exclusion mechanism built into many eBPF monitoring solutions. By executing the module‑loading code under a process that the system has been configured to trust, the rootkit can prevent the eBPF hook from emitting the usual load event. In effect, the kernel sees the operation as legitimate, and the telemetry pipeline remains silent.

Because the omission occurs at the point of data collection, downstream analytics never receive the signal that a new, potentially malicious module has entered the kernel. This creates a blind spot not only for Elastic Defend but also for any security product that depends on the same telemetry source. The ability to suppress module‑load events therefore represents a significant escalation in stealth capability for Linux‑based threats.

The discovery highlights a broader tension in modern endpoint security: the reliance on trusted‑process lists to reduce noise can be turned against the defender. While exclusions help limit false positives, they also provide an easy avenue for attackers to hide malicious behavior if they can co‑opt a whitelisted process. Researchers and vendors are now re‑examining how to balance visibility with performance without opening such loopholes.

Going forward, Elastic and other vendors are expected to update their eBPF policies to incorporate additional verification steps, such as cross‑checking module signatures or correlating load events with process ancestry. The research community, meanwhile, is calling for more transparent auditing of exclusion rules and for the development of defensive techniques that can detect when trusted‑process boundaries are being abused. As Linux continues to gain market share on servers and workstations, the pressure to secure the kernel’s most privileged operations grows ever more urgent.