Add rootkit detection

Rootkits

Functionality

Hiding files, directories, and entries from in-memory structures from the system's user is arguably the most critical function that rootkits implement. This prevents the user from visually identifying malicious files by intercepting function calls, replacing binaries or removing entries from in-memory kernel structures.

• Data hiding - sys_getdents, readdir, fopen ...
• Process hiding - replace ps, hide files in /proc, intercept sys_kill, find_task_by, ...
• Connection hiding - replace ip, intercept libpcap, hide files in /proc, intercept tcp_seq_show, fopen ...

Backdoors

• Trigger Backdoors - e.g., hook on sys_accept, wait for trigger metadata, and establish a reverse shell
• Command and control - establish connections at regular intervals
• Authentication - attack PAM and enable auth of pseudo users
• Local privilege escalation - rootkits require elevated privileges for installation, it's granting privileges to other processes from an already privileged standpoint (setuid, setgid), kernel based rootkits will hook them into any system call

Additional functionality

• Catch detection processes - hook on libc function execve to catch the execution of rootkit detection tools and unload and undo actions and reinsert after execution is done
• Manupulate logging - remove any hints on the rootkit
• Spoof process maps - remove themselves from /proc/<pid>/maps
• Patch preload file path - remove /etc/ld.so.preload and patch the dynamic linker' binary use a different path for preloading

User Space Rootkits

Application Level Rootkits

Target system applications for outputting status information to the user, replacement of binaries, persistence by replacing binaries: integrity based scans (dm-verity, fs-verity) and chiseled RO rootfs

Dynamic Linker Rootkits

Target system libraries by replacing them with own implementations, abusing LD_PRELOAD, persistence by using /etc/ld.so.preload , unset LD_PRELOAD, no shell, chiseled RO rootfs

Kernel Space Rootkits

LKM and eBPF

First step is to getting the rootkit code run inside the kernel, most of the rootkits do that by loading themselves via LKM. Alternative is to load an eBPF program. LKMs are hidden by deleting themselves from specific kernel structures like

• mod_list: a linked list used notably by lsmod to list the current loaded LKMs
• mod_tree: an RB tree used for address-to-module correspondence
• mkobj: used to make LKMs appear in the /sys virtual filesystem
  Persistence by having entries in /etc/modules or /etc/modules-load.d/ and copy on the rootfs
  LKRG

System Calls and Interrupts

• replace function pointers in the system call table
• replace the entire system call table by modifying the interrupt handler
• insert and unconditional jump operation at the start of a system call to a different function
• use ftrace to catch execution and redirect to a different function
• use prebuilt eBPF hooks

VFS

additional abstraction layer, also enables the creation of pseudo-files, rootkits hook functions from these file systems to manipulate their output

Detection

The issue names no repository files, tests, or detection entry points. Start by reading the existing Rust project structure and determine where system-level checks belong; the issue is complete only when a defined rootkit-detection scope and verification approach are agreed.