Security researcher has disclosed a technique used by the Singularity Linux rootkit to evade Elastic Defend by suppressing module-load telemetry to avoid detection across multiple layers.
This research highlights how trusted-process exclusions in endpoint eBPF monitoring can become significant targets for advanced kernel-level threats.
According to the report, Elastic Defend has monitored Linux kernel module loads through a BPF-based event mechanism since approximately version 8.14.
The release of Elastic Defend 9.5 introduced a taint_flags field to its module-load event, enabling a rule designed to identify potentially unsafe, unsigned, or externally built kernel modules that taint the running kernel.
Singularity Rootkit Bypasses Elastic Defend
The researcher identified several distinct detection controls that could trigger alerts when a rootkit kernel object is compiled, written to disk, or loaded:
In a test environment running Elastic Defend 9.5.2 on Ubuntu with kernel version 6.8, loading Singularity without modifications reportedly generated 76 alerts. Most of these were attributed to YARA detections against the rootkit module on disk, while others originated from Elastic’s runtime BPF monitoring.
The core bypass exploits Elastic’s handling of trusted processes. Elastic’s embedded module_load eBPF program checks whether the current process identifier exists in a map used for trusted process IDs before gathering module-load information.
If the loading process is classified as trusted, the BPF program exits early, preventing the generation of the endpoint event that feeds into Elastic’s taint-flag detection rule. This omission prevents the relevant detection from receiving the telemetry needed to evaluate whether a loaded module has tainted the kernel.
The researcher 0xMatheuZ indicated that the rootkit loader dynamically locates the appropriate BPF map rather than relying on a fixed identifier, since map IDs can change when the Elastic agent restarts. This method enables the loader to temporarily register itself as trusted before initiating module load, then remove its entry afterward.
This design is especially noteworthy because it 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.
The Singularity rootkit’s evasion strategy also reportedly includes source code obfuscation to reduce YARA detections. The obfuscator randomizes function and file names, alters the generated module name, and transforms recognizable strings that defenders may use in their signatures.
The report describes an additional tactic of exploiting a broad exclusion in Elastic’s kernel-module creation detection rule. This rule excludes paths associated with DKMS, a common Linux framework for building third-party drivers.
By placing generated kernel objects in a DKMS-related directory, the rootkit can potentially evade behavioral alerts for suspicious .ko file creation.
Moreover, Singularity is said to filter kernel log output and conceal its module from common Linux interfaces such as `lsmod`, `/proc/modules`, and `/sys/module`.
These findings underscore the risks of relying on telemetry exclusions without adequately restricting who can modify or influence the trusted-process state. Organizations should review endpoint-agent protections around BPF maps, trusted process decisions, kernel module loading controls, and DKMS build directories.
Defenders should correlate module-load activity with kernel integrity signals, audit `finit_module` and related system calls, monitor unexpected BPF object interactions, and alert on processes accessing endpoint security BPF maps.
Detection engineering should avoid automatically treating excluded build paths as benign, particularly in systems where an attacker may already compromise root-level access.
Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.
