Linux Rootkits: Hooking Evolution and Defensive Implications

What Happened

Recent analyses show a shift in Linux rootkit design toward kernel‑level hooking via eBPF and io_uring, replacing older shared‑object hijacking methods. These new techniques allow attackers to embed malicious logic directly into the kernel without loading traditional loadable kernel modules.

Rootkit Taxonomy

Rootkits can be classified by execution context: user‑space, kernel‑space, and hybrid. User‑space rootkits modify library loading (LD_PRELOAD) or replace shared objects. Kernel‑space rootkits alter kernel data structures, intercept system calls, or inject malicious code. Hybrid approaches combine both to maximize stealth.

Hooking Techniques

• Shared‑object hijacking – replacing or preloading libraries to intercept user‑space calls.
• Loadable kernel module (LKM) hooking – modifying the syscall table or function pointers.
• eBPF program injection – attaching custom bytecode to kernel probes or tracepoints.
• io_uring hook exploitation – inserting malicious callbacks into the asynchronous I/O subsystem.

Impact on Defenders

These techniques bypass many traditional security tools. Kernel‑space hooks can suppress audit logs, hide processes, and alter kernel memory, making detection reliant on low‑level integrity checks. eBPF and io_uring hooks are especially opaque, as they run in the kernel but are not visible in standard module listings.

What to Do

• Implement kernel integrity verification (e.g., dm‑verity, signed kernel modules).
• Audit eBPF programs with tools like bpftool and monitor for unexpected BPF maps.
• Validate syscall table integrity and compare against known‑good baselines.
• Enable kernel audit logs for syscalls and tracepoints, and correlate with user‑space activity.
• Apply timely kernel updates and patch known hooking vulnerabilities.