Kernel module loaded
A kernel module was loaded or unloaded (insmod, modprobe, rmmod).
What it detects
A kernel module was loaded or unloaded (insmod, modprobe, rmmod). Code in a module runs in ring 0, below every user-space control on the host: a loadable kernel module rootkit can hide its own files and processes from ls and ps, hide network connections from netstat, and survive reboot through /etc/modules-load.d. It is also how an attacker unloads something in their way — rmmod against a monitoring module, or modprobe -r against a driver an investigator would otherwise read.
Matches on the program name, which reaches both shapes auditd records this in: a SYSCALL record naming comm=insmod, and an EXECVE record whose argv[0] is modprobe.
MITRE ATT&CK mapping
- T1547.006Boot or Logon Autostart Execution: Kernel Modules and Extensions· Persistence
False positives and triage
On most hosts this is overwhelmingly benign and frequent. modprobe runs at boot, on hotplug, on the first use of a filesystem or network protocol, and udev calls it constantly — a busy server can load hundreds of modules without anyone touching it. The signal is not the command, it is the context around it:
* Who ran it. A module loaded by udev/systemd during boot is routine; the same command from an interactive shell with a login uid behind it, hours after boot, is not. * Where the module came from. insmod ./rootkit.ko from a user's home directory or /tmp is a different event from modprobe nf_conntrack. * Whether it is an unload. rmmod is far rarer than a load, and unloading a security or auditing module is defence evasion.
Tune by suppressing the module names your build actually loads at boot rather than by lowering the severity — the technique is high impact and the rule is deliberately broad because the parser cannot see the module path on the EXECVE record alone.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 50%. Source: rules/linux/kernel_module_loaded.yaml, licensed under the Apache License 2.0.
id: linux.persistence.kernel_module_loaded
version: 1.0.0
status: stable
severity: high
confidence: 0.5
platforms: [linux]
mitre_techniques: [T1547.006]
description: |
A kernel module was loaded or unloaded (`insmod`, `modprobe`, `rmmod`). Code in a
module runs in ring 0, below every user-space control on the host: a loadable
kernel module rootkit can hide its own files and processes from `ls` and `ps`,
hide network connections from `netstat`, and survive reboot through
`/etc/modules-load.d`. It is also how an attacker unloads something in their way —
`rmmod` against a monitoring module, or `modprobe -r` against a driver an
investigator would otherwise read.
Matches on the program name, which reaches both shapes auditd records this in: a
SYSCALL record naming `comm=insmod`, and an EXECVE record whose argv[0] is
`modprobe`.
match:
process_name_any:
- insmod
- modprobe
- rmmod
false_positive_guidance: |
On most hosts this is overwhelmingly benign and frequent. `modprobe` runs at boot,
on hotplug, on the first use of a filesystem or network protocol, and udev calls it
constantly — a busy server can load hundreds of modules without anyone touching it.
The signal is not the command, it is the context around it:
* Who ran it. A module loaded by udev/systemd during boot is routine; the same
command from an interactive shell with a login uid behind it, hours after boot,
is not.
* Where the module came from. `insmod ./rootkit.ko` from a user's home directory or
/tmp is a different event from `modprobe nf_conntrack`.
* Whether it is an unload. `rmmod` is far rarer than a load, and unloading a
security or auditing module is defence evasion.
Tune by suppressing the module names your build actually loads at boot rather than
by lowering the severity — the technique is high impact and the rule is deliberately
broad because the parser cannot see the module path on the EXECVE record alone.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.