Tia N.List

Reported by 2 outlets

Singularity Rootkit Bypasses Elastic Defend eBPF Module Load Detection

hot0.0
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
gbhackers.comcyberpress.org first seen 41d ago

Timeline

  1. 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 .

  2. 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

Covered in

digest 2026-09-03

Source on GitHub