Five auditd Rules That Catch Kernel Module Rootkits Before They Load

A well-written kernel module rootkit hides its own processes, intercepts system calls, and filters its files from directory listings. Once loaded, the rootkit controls what the operating system reports — which means your standard detection tools report exactly what the attacker wants them to report.

The detection window is the moment BEFORE the module loads. The attacker must execute insmod, modprobe, or write to /sys/module to load their module into the kernel. That operation is visible to auditd because auditd hooks into the kernel’s audit framework at a level below the rootkit’s control — the audit event is generated before the module’s init function runs.

These five rules create an audit trail for every kernel module operation on your Linux hosts. Forward the events to your SIEM and build correlation rules on top of them.

The rules

Rule 1: Monitor module loading syscalls

-a always,exit -F arch=b64 -S init_module -S finit_module -k module_load

This catches every kernel module load regardless of which tool performs it. init_module is the underlying syscall behind insmod. finit_module is the file-descriptor variant used by modprobe. The -k module_load key tags every event for SIEM filtering.

Rule 2: Monitor module removal

-a always,exit -F arch=b64 -S delete_module -k module_unload

Attackers who load a rootkit module, use it to establish persistence through other means, and then unload it to reduce their footprint will trigger this rule. A module load followed by an unload within minutes — especially outside a maintenance window — warrants investigation.

Rule 3: Watch the modules directory

-w /lib/modules/ -p wa -k module_files

Legitimate kernel modules live in /lib/modules/$(uname -r)/. An attacker staging a rootkit binary in this directory (to survive reboots via a modified /etc/modules or modprobe.d entry) will trigger a write alert on this path.

Rule 4: Watch modprobe configuration

-w /etc/modprobe.d/ -p wa -k modprobe_config

Persistence through module auto-loading requires a configuration entry in /etc/modprobe.d/. This rule catches the attacker creating or modifying the configuration file that ensures their rootkit loads on every boot.

Rule 5: Watch the modules load list

-w /etc/modules -p wa -k modules_list
-w /etc/modules-load.d/ -p wa -k modules_list

The /etc/modules file and /etc/modules-load.d/ directory list modules that load at boot. An attacker appending their rootkit module name to either location gets caught by this rule before the next reboot executes the persistence.

What to correlate in your SIEM

The raw auditd events tell you WHAT happened. Correlation tells you WHETHER it is a threat.

High confidence alert: module_load event where the module path is NOT under /lib/modules/$(uname -r)/ — a module loaded from /tmp, /dev/shm, or any non-standard location is almost certainly malicious.

Medium confidence alert: module_load event outside a change management window. Legitimate module loading happens during patching, kernel updates, and driver installation — not at 3 AM on a Tuesday.

Investigation trigger: module_load followed by module_unload within 10 minutes on the same host. This pattern suggests the attacker loaded a module to perform an action (establish persistence, hook syscalls) and then removed it to reduce the forensic footprint.

The gap these rules close

Without these rules, a rootkit that loads successfully becomes invisible to process monitoring, file integrity checks, and network detection — because it controls the kernel’s response to all three. With these rules, the LOAD event is captured in the audit log and forwarded to the SIEM before the rootkit can interfere. The attacker’s one unavoidable action becomes your detection opportunity.

Deploy these five rules to every Linux host in your environment. The total performance impact is negligible — module operations happen infrequently on production systems, so the audit overhead is near zero. The detection value is disproportionately high.