Singularity Rootkit: How eBPF Trust Mechanisms Are Being Bypassed

The battle for kernel-level dominance in Linux environments has entered a sophisticated new phase. Recent disclosures by security researcher 0xMatheuZ have unveiled the inner workings of the Singularity rootkit, a tool specifically engineered to blind one of the industry's most prominent endpoint detection and response (EDR) solutions: Elastic Defend. By targeting the very mechanisms used to ensure system observability, Singularity demonstrates a critical vulnerability in how modern security tools handle trusted processes.

The failure of traditional telemetry

For several versions, Elastic Defend has relied on a BPF-based event mechanism to monitor Linux kernel module loads, a feature present since approximately version 8.14. With the introduction of version 9.5, Elastic added a taint_flags field to its module-load events. This was designed to flag unsigned or externally built kernel modules that could compromise the integrity of the running kernel.

However, the effectiveness of these controls is absolute only if the telemetry reaches the detection engine. In a controlled test environment using Ubuntu with kernel version 6.8 and Elastic Defend 9.5.2, loading the Singularity rootkit without any modifications was an alarm bell for the system, triggering 76 distinct alerts. These alerts were a mix of YARA detections targeting the module on disk and runtime BPF monitoring. For an attacker, this volume of noise is unacceptable, leading to the development of a multi-layered evasion strategy.

Exploiting the trust map loophole

The core of the Singularity bypass is not a brute-force attack on the EDR, but a surgical exploitation of its logic. To prevent system performance degradation and reduce false positives, Elastic’s embedded module_load eBPF program checks if the current process identifier (PID) exists within a specific map of trusted process IDs. If the process is found in this map, the BPF program exits early.

By exiting early, the program fails to generate the endpoint event that would normally feed into the taint-flag detection rule. Singularity leverages this by dynamically locating the BPF map. Because map IDs can change whenever the Elastic agent restarts, the rootkit loader does not rely on a fixed identifier. Instead, it searches for the map, temporarily registers itself as a trusted process, loads the malicious module, and then removes its entry to leave no trace. This allows the rootkit to slip past the telemetry layer without ever disabling the security software entirely.

Beyond BPF: Evading YARA and behavioral rules

While the eBPF bypass handles the runtime detection, the rootkit must still survive the initial disk scan. Elastic employs YARA rules—such as Linux_Rootkit_Generic and Linux_Rootkit_BrokePKG—to identify common rootkit patterns and function names. To counter this, 0xMatheuZ implemented a sophisticated obfuscation pipeline.

The evasion strategy involves several technical layers:

• Symbol Randomization: Intelligent randomization of function and file names to break signature-based detection.
• Module Fragmentation: Breaking the module into fragments combined with XOR encoding and in-memory loading via memfd_create.
• Ftrace Obfuscation: Renaming functions within the Ftrace framework to hide hooking activities.
• Path Mimicry: Placing generated kernel objects in directories associated with DKMS (Dynamic Kernel Module Support), exploiting a broad exclusion in Elastic's creation rules.

These techniques ensure that the .ko file does not trigger behavioral alerts for suspicious file creation, as the system assumes the activity is part of a legitimate third-party driver build process.

The broader impact on Linux observability

The Singularity research is part of a larger trend where attackers move from avoiding EDRs to actively manipulating their internal state. As noted in research available at matheuzsecurity.github.io, this is a shift from avoidance to poisoning. By walking into the EDR and rewriting its monitoring state, attackers can create blind spots that are virtually invisible to the security operations center (SOC).

This approach is not limited to Elastic. Similar vulnerabilities have been explored in other eBPF-based sensors like Falco, where the absence of security_bpf_map enforcement allows for BPF map poisoning. When the security tool trusts the kernel's reporting, but the kernel is being manipulated by a rootkit, the resulting telemetry is a fabrication.

The Singularity rootkit does not attempt to turn off Elastic Defend entirely. Instead, it takes advantage of an internal trust mechanism intended to reduce noise and avoid generating unnecessary telemetry from legitimate processes.

Technical breakdown of the evasion chain

The sophistication of Singularity lies in its staged execution. It begins with an automated obfuscation workflow that transforms recognizable strings into unrecognizable data. Once the obfuscated loader is executed, it performs a search for the BPF map IDs. This dynamic discovery is crucial for persistence across agent restarts.

Once the loader has successfully registered its PID as trusted, it initiates the kernel module load. Because the eBPF hook exits early, the taint_flags are never evaluated. The rootkit then proceeds to filter kernel log output and conceal its own module from the system's module list, effectively becoming a ghost in the machine. Detailed analysis of these bypasses can be found via gbhackers.com, highlighting the fragility of trusted-process exclusions.

Global implications for enterprise infrastructure

For businesses operating large-scale Linux environments in the USA, UK, and global markets, the Singularity rootkit serves as a warning about the limits of eBPF-based security. Many enterprises rely on the assumption that kernel-level telemetry is an immutable source of truth. This research proves that if an attacker gains sufficient privileges to interact with BPF maps, that truth can be edited.

In the US and UK, where critical infrastructure and financial services rely heavily on automated EDR responses, the risk is not just data theft but the loss of visibility. If a rootkit can suppress telemetry, an organization may remain unaware of a breach for months, as the security dashboard continues to report a healthy system. This necessitates a shift toward Zero Trust at the kernel level, where trust is not granted based on a PID map but is continuously verified through hardware-backed integrity checks or external monitoring.

Furthermore, the exploitation of DKMS paths suggests that overly broad exclusions in security policies are a primary attack vector. Organizations should review their EDR exclusion lists and move toward more granular, identity-based controls rather than path-based exclusions, which are easily spoofed by advanced threats.

FAQ

Sources: Gbhackers, Matheuzsecurity (2) ·