Adversaries may modify the kernel to automatically execute programs on system boot. Loadable Kernel Modules (LKMs) are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. For example, one type of module is the device driver, which allows the kernel to access hardware connected to the system. [1]
When used maliciously, LKMs can be a type of kernel-mode Rootkit that run with the highest operating system privilege (Ring 0). [2] Common features of LKM based rootkits include: hiding itself, selective hiding of files, processes and network activity, as well as log tampering, providing authenticated backdoors and enabling root access to non-privileged users. [3]
Kernel extensions, also called kext, are used for macOS to load functionality onto a system similar to LKMs for Linux. They are loaded and unloaded through kextload and kextunload commands. Since macOS Catalina 10.15, kernel extensions have been deprecated on macOS systems.[4]
Adversaries can use LKMs and kexts to covertly persist on a system and elevate privileges. Examples have been found in the wild and there are some open source projects. [5] [6] [7] [8][9] [10][11] [12]
| ID | Name | Description |
|---|---|---|
| S0502 | Drovorub |
Drovorub can use kernel modules to establish persistence.[13] |
| S0468 | Skidmap |
Skidmap has the ability to install several loadable kernel modules (LKMs) on infected machines.[12] |
| ID | Mitigation | Description |
|---|---|---|
| M1049 | Antivirus/Antimalware |
Common tools for detecting Linux rootkits include: rkhunter [14], chrootkit [15], although rootkits may be designed to evade certain detection tools. |
| M1038 | Execution Prevention |
Application control and software restriction tools, such as SELinux, KSPP, grsecurity MODHARDEN, and Linux kernel tuning can aid in restricting kernel module loading.[16][17][18][19][20] Since macOS High Sierra 10.13, Secure Kernel Extension Loading (SKEL) can also be used to restrict the loading of kernel modules.[21] |
| M1026 | Privileged Account Management |
Limit access to the root account and prevent users from loading kernel modules and extensions through proper privilege separation and limiting Privilege Escalation opportunities. |
| ID | Data Source | Data Component |
|---|---|---|
| DS0017 | Command | Command Execution |
| DS0022 | File | File Creation |
| File Modification | ||
| DS0008 | Kernel | Kernel Module Load |
Loading, unloading, and manipulating modules on Linux systems can be detected by monitoring for the following commands: modprobe, insmod, lsmod, rmmod, or modinfo [22] LKMs are typically loaded into /lib/modules and have had the extension .ko ("kernel object") since version 2.6 of the Linux kernel. [23]
Adversaries may run commands on the target system before loading a malicious module in order to ensure that it is properly compiled. [3] Adversaries may also execute commands to identify the exact version of the running Linux kernel and/or download multiple versions of the same .ko (kernel object) files to use the one appropriate for the running system.[12] Many LKMs require Linux headers (specific to the target kernel) in order to compile properly. These are typically obtained through the operating systems package manager and installed like a normal package. On Ubuntu and Debian based systems this can be accomplished by running: apt-get install linux-headers-$(uname -r) On RHEL and CentOS based systems this can be accomplished by running: yum install kernel-devel-$(uname -r)
On macOS, monitor for execution of kextload commands and user installed kernel extensions performing abnormal and/or potentially malicious activity (such as creating network connections). Monitor for new rows added in the kext_policy table. KextPolicy stores a list of user approved (non Apple) kernel extensions and a partial history of loaded kernel modules in a SQLite database, /var/db/SystemPolicyConfiguration/KextPolicy.[24][25][26]