Reported by 2 outlets
Singularity Rootkit Bypasses Elastic Defend eBPF Module Load Detection
Why this score
- Breadth
- 1.00 / 2.0 · 2 sources
- Authority
- 1.20 / 2.0 · best outlet weight
- Severity
- 0.50 / 5.0 · CVSS + content signals
- Velocity
- 0.00 / 2.0 · updates in 48h
- Pickup speed
- 0.60 / 0.6 · time to second source
- Recency
- × 0.00 temporal multiplier
- Community
- + 0.00 / 1.5 · reddit signal
- Score
- 0.0 / 10 = base × recency + community
Timeline
-
original reporting
Singularity Rootkit Bypasses Elastic Defend eBPF Module Load Detection
gbhackers.com · 41d ago · September 2nd, 2026
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 […] The post Singularity Rootkit Bypasses Elastic Defend eBPF Module Load Detection appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform .
-
update from cyberpress.org
Linux Rootkit Abuses Elastic trusted_pids eBPF Map to Bypass Module Load Detection
cyberpress.org · 41d ago · September 2nd, 2026
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. Without evasion (Source: matheuzsecurity) 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 ch