A new technique was demonstrated that evades Elastic Defend in the Singularity Linux rootkit by suppressing telemetry from the product’s kernel-module load monitoring.
The research documented by matheuzsecurity shows how a rootkit loader can abuse Elastic’s trusted_pids eBPF map to prevent a module-load event from being generated while a malicious Linux kernel module is inserted.
Elastic Defend has used a BPF-based module_load event since approximately version 8.14. In version 9.5.0, Elastic added a taint_flags field to the event and introduced a corresponding EQL rule, “Kernel Module Loaded with Tainting Flags.”
Linux Rootkit Abuses Elastic trusted_pids eBPF Map
The field is collected from the kernel module’s taint state after its initialization routine runs, helping defenders identify unsigned, externally built, or otherwise tainted modules.
The researcher tested the technique against Elastic Defend 9.5.2 on Ubuntu running the 6.8.0-138-generic kernel.
According to the analysis, the Elastic eBPF tracing program checks whether the process responsible for loading a module exists in an internal hash map associated with trusted process IDs.
If the process is present, the BPF program exits before collecting module metadata or creating a telemetry event. Rather than relying on a fixed map identifier, the proof-of-concept reportedly dynamically identifies the relevant Elastic BPF program and map.
This matters because map identifiers can change after an Elastic agent restart. By temporarily marking the loader process as trusted before the kernel module load operation, the rootkit can reportedly avoid the module_load event that feeds Elastic’s taint-based detection rule.
The bypass addresses only one layer of detection. Singularity also targets file-based and log-based security controls. Elastic’s YARA scanning can detect known rootkit strings, symbols, function names, and code patterns in kernel module files before they are loaded.
The project’s source obfuscation component reportedly randomizes identifiers, renames source files, and alters recognizable strings to reduce static signature matches.
A separate legacy Elastic rule monitors syslog records for the kernel message generated when an unsigned module taints the system. The research claims Singularity filters relevant kernel log output to reduce the chance that Filebeat forwards the tainting message to Elastic.
In addition, the researcher highlighted exclusions in Elastic’s kernel-module creation detection logic, including paths commonly used by DKMS for legitimate third-party driver builds.
Matheuzsecurity stated that a broader challenge for Linux endpoint detection is that telemetry pipelines can be compromised when attackers with sufficient privileges manipulate the kernel-level mechanisms that produce security events.
Rootkit operators do not necessarily need to disable an endpoint agent outright; suppressing a specific event source may be enough to blind an individual analytic.
Defenders should treat trusted-process maps, eBPF program attachments, kernel-module creation paths, and agent telemetry gaps as high-value inspection points.
Security teams should also correlate endpoint events with independent evidence, including kernel audit logs, Secure Boot and module-signing policy, package-management records, filesystem integrity monitoring, and centralized log collection.
Elastic customers should review whether trusted PID handling can be abused by untrusted processes, investigate unexpected eBPF map modifications, and ensure that exclusions for legitimate driver workflows do not become a reliable hiding location for malicious .ko files.
Give your security team the visibility and context to investigate suspicious activity faster and contain threats before business impact grows. Strengthen Your Investigations with ANY.RUN
