Singularity: bypassing Linux rootkit detection in Elastic Defend via trusted_pids

Singularity: bypassing Linux rootkit detection in Elastic Defend via trusted_pids

Researcher 0xMatheuZ demonstrated how the Singularity LKM rootkit can bypass multiple detection layers in Elastic Defend 9.5 — from YARA scanning of .ko files to eBPF monitoring of module loading. In a test environment with Elastic Defend 9.5.2, 0 alerts were generated.

The most interesting part — bypassing eBPF Elastic Defend monitors kernel module loads through the tp_btf/module_load eBPF program. In version 9.5, taint_flags was added to the event: after the module’s init function completes, Elastic reads mod->taints, and the Kernel Module Loaded with Tainting Flags rule triggers when the taint_flags field is present. However, before collecting data,the eBPF program checks the current process's TGID against an internal hash map: elastic_ebpf_events_trusted_pids If the TGID is found there, the program exits without generating an event. The researcher used this behavior as a bypass: the loader locates the required BPF map at runtime and temporarily adds its own TGID before loading the module via finit_module, then removes it.

The result is the following chain: Loader TGID → trusted_pids → finit_module → eBPF hook exits early → module_load event is not created → the Elastic rule is not triggered In other words, this is not simply about hiding taint_flags: the event never reaches the detection system at all.

Other detection layers Bypassing eBPF alone is not enough. Elastic also detected Singularity in other ways: • YARA detected .ko files by their strings, function names, and other indicators — the author added source-code obfuscation, renaming functions, files, and the module, and hiding sensitive strings; • an older syslog rule caught module verification failed ... tainting kernel — the rootkit filters this string; • the .ko creation rule responded to the appearance of a kernel object on disk — building it in /var/lib/dkms/, which is on Elastic’s exclusion list, made it possible to avoid this detection; In addition, the module hides itself from lsmod, /proc/modules, and /sys/module/, and filters its name from dmesg. In the test, combining these techniques allowed Singularity to be loaded while Elastic Defend 9.5.2 was running without triggering any alerts.

The author has not yet published the loader implementing the trusted_pids bypass.

Article: https://matheuzsecurity.github.io/hacking/elastic-trusted-pid-bypass/

Tool: https://github.com/MatheuZSecurity/Singularity