Deprecation Notice (April 15, 2026): This rule is deprecated in favor of the Kernel rootkit installation attack correlation rule, which combines multiple rootkit-related signals into a single, higher-fidelity detection. Customers will automatically benefit from the improved correlation-based detection without any action required.

What happened

The process {{ @process.comm }} modified the kernel module file {{ @file.path }}, potentially to establish persistence or gain elevated privileges.

Goal

Kernel modules can be used to automatically execute code when a host starts up. Attackers sometimes use kernel modules to gain persistence on a particular host, ensuring that their code is executed even after a system reboot. Kernel modules can also help attackers gain elevated permissions on a system.

Loading a malicious kernel module is a type of rootkit. Rootkits often create backdoor access and hide evidence of themselves. This includes process, file, and network activity.

Strategy

Kernel modules are loaded from the /lib/modules directory in Linux. This detection watches for all new files created under that directory.

Triage and response

1. Check the name of the new kernel module created.
2. Check which user or process created the module.
3. If the new kernel module is not expected, contain the host or container and roll back to a known good configuration. Initiate the incident response process.

Requires Agent version 7.27 or greater