How to Detect and Remove Rootkits on Linux: A Sysadmin’s Complete Guide

A rootkit is silently running on one of your production servers right now. You don’t know it yet. That’s exactly how rootkits work—they’re designed to hide from standard monitoring, escalate privileges, and persist across reboots. If you manage Linux systems in any capacity, you need to know how to detect and remove rootkits. This isn’t paranoia; it’s fundamental security hygiene.

The challenge with rootkits is that they operate at kernel level, giving attackers the ability to manipulate what your standard tools report. When you run ps aux, you might not see the malicious process. When you check open ports with netstat, the backdoor connection might be invisible. This is why standard detection tools miss them—and why you need a layered approach to rootkit detection and removal.

In this guide, we’ll walk through practical, real-world techniques to identify rootkits on your Linux systems, verify their presence, and remove them safely without losing data or stability.

Understanding Rootkits and Why Detection Is Hard

Before jumping into tools and commands, let’s understand what we’re dealing with. A rootkit is malware that gains root-level access to a system and actively hides its presence. Unlike a regular compromise where an attacker merely has shell access, a rootkit has kernel-level control.

Types of Linux Rootkits

Kernel-based rootkits are the most dangerous. They modify kernel code or load a kernel module that intercepts system calls. This allows them to:

• Hide processes from ps, top, and /proc
• Conceal files and directories from ls and directory listings
• Hide network connections from netstat and ss
• Intercept file operations to hide malicious binaries
• Hide users and login attempts from authentication logs

User-space rootkits operate without kernel modification. They replace standard utilities like ls, ps, netstat, and authentication binaries with modified versions. While less powerful than kernel rootkits, they’re easier to install and can still completely compromise a system.

Bootkit/firmware rootkits exist below the OS level, persisting in BIOS or UEFI firmware. These are rare on production Linux systems but nearly impossible to detect without specialized firmware analysis tools.

The fundamental challenge: if a rootkit controls the kernel or core system utilities, how can you trust any tool running on that system? This is why detection requires multiple approaches and tools that operate outside the compromised system’s normal execution environment.

Step 1: Initial Reconnaissance and Baseline Comparison

Your first line of defense is knowing what a clean system looks like. If you don’t have a baseline, you’re essentially blind.

Create a System Baseline

Before running detection tools, gather data that you can compare against known-good baselines:

# Get a list of running processes with detailed information
ps auxww > /tmp/baseline_processes.txt

# List all loaded kernel modules
lsmod > /tmp/baseline_modules.txt

# Get all network connections and listening ports
ss -tulpn > /tmp/baseline_network.txt
netstat -tulpn >> /tmp/baseline_network.txt

# List all cron jobs
crontab -l > /tmp/baseline_cron.txt
find /etc/cron* -type f > /tmp/baseline_cronjobs.txt

# Get loaded shared libraries
ldconfig -p > /tmp/baseline_libs.txt

# Check for LD_PRELOAD hooks
cat /etc/ld.so.preload > /tmp/baseline_ldpreload.txt 2>/dev/null

The ss (socket statistics) command is more reliable than netstat on modern systems, though including both is good practice.

Check for Obvious Signs of Compromise

# Look for recently modified system binaries
find /bin /sbin /usr/bin /usr/sbin -mtime -7 -ls

# Check for suspicious cron jobs (check all users)
for user in $(cut -f1 -d: /etc/passwd); do
  echo "=== Cron jobs for $user ==="
  crontab -l -u $user 2>/dev/null
done

# Look for suspicious entries in system startup
cat /etc/rc.local
ls -la /etc/init.d/
ls -la /etc/systemd/system/

# Check /tmp and /var/tmp for suspicious files
ls -lart /tmp/
ls -lart /var/tmp/

# Look for LD_PRELOAD hooks (common rootkit technique)
cat /etc/ld.so.preload 2>/dev/null

If you see files modified outside your change windows, unfamiliar services, or odd entries in system startup files, you’ve likely got a compromise.

Step 2: Deploy Professional Rootkit Detection Tools

Now let’s move to specialized tools designed specifically for rootkit detection. These are your heavy hitters.

CHKROOTKIT: The Industry Standard

CHKROOTKIT is a shell script that scans for signs of rootkits by comparing system behavior against known malicious patterns. It’s been in active development for decades and is trusted by enterprise Linux administrators.

Installation:

# On Ubuntu/Debian
sudo apt-get install chkrootkit

# On CentOS/RHEL
sudo yum install chkrootkit

# Or build from source
cd /opt
wget http://www.chkrootkit.org/chkrootkit.tar.gz
tar xzf chkrootkit.tar.gz
cd chkrootkit-*
make sense

Running CHKROOTKIT:

# Run full scan (takes 10-30 minutes depending on system size)
sudo chkrootkit

# Run specific test
sudo chkrootkit -x sniffer

# Output to file for later analysis
sudo chkrootkit > /tmp/chkrootkit_report.txt 2>&1

# Run with verbose output
sudo chkrootkit -v

Understanding the output:

INFECTED: [filename]              # Suspicious file found
SUSPECT: [filename]               # Needs manual review
Not Infected: [check name]        # Clean

Focus on any INFECTED or SUSPECT results. CHKROOTKIT checks for:

• Promiscuous interfaces (sniffer detection)
• Suspicious processes and loaded modules
• Modified system binaries
• Rootkit signatures in kernel memory
• Suspicious shell histories
• Inet d and Inet configuration anomalies

RKHUNTER: Signature-Based Detection

RKHUNTER (Rootkit Hunter) complements CHKROOTKIT with signature-based detection and system integrity checking.

Installation:

# Ubuntu/Debian
sudo apt-get install rkhunter

# CentOS/RHEL
sudo yum install rkhunter

# From source
cd /opt
wget https://sourceforge.net/projects/rkhunter/files/rkhunter/1.4.6/rkhunter-1.4.6.tar.gz
tar xzf rkhunter-1.4.6.tar.gz
cd rkhunter-1.4.6
sudo ./installer.sh --install

Configure and run:

# Update the rootkit signature database
sudo rkhunter --update

# Run a full system scan
sudo rkhunter --check --skip-keypress

# Generate a report
sudo rkhunter --check --skip-keypress > /tmp/rkhunter_report.txt 2>&1

# Check only specific areas
sudo rkhunter --check --rootkit-dir /path/to/dir --skip-keypress

RKHUNTER maintains whitelists in /etc/rkhunter.conf. After your first run, you’ll likely need to whitelist legitimate items to reduce false positives:

# Common legitimate entries that trigger warnings
ALLOWHIDDENDIR=/sys
ALLOWHIDDENDIR=/proc/.hidden
ALLOWDEVFILE=/dev/shm/.test

lynis: Comprehensive Security Auditing

While not exclusively a rootkit detector, lynis is invaluable for security assessment and includes rootkit checks within its broader auditing framework.

# Installation
sudo apt-get install lynis

# Run system audit
sudo lynis audit system

# Audit and log results
sudo lynis audit system -q > /tmp/lynis_report.txt

# Audit specific categories
sudo lynis audit system --tests rootkits,malware,networking

OSSEC: Log Analysis and Anomaly Detection

OSSEC detects rootkits through behavioral analysis—watching for suspicious system calls, unusual process behavior, and log anomalies that indicate compromise.

# Installation on Ubuntu/Debian
sudo apt-get install ossec-hids

# Installation on CentOS/RHEL
sudo yum install ossec-hids

# After installation, configure and start
sudo /var/ossec/bin/ossec-control start

# Monitor alerts in real-time
sudo tail -f /var/ossec/logs/alerts/alerts.log

Step 3: Advanced Detection Techniques

If standard tools don’t reveal anything but you suspect a rootkit, use deeper analysis techniques.

Comparing Binary Checksums Against Known-Good Copies

Rootkits often modify system binaries. Compare your system binaries against a known-clean repository.

# Create checksums of critical binaries
sha256sum /bin/* /sbin/* /usr/bin/* /usr/sbin/* > /tmp/binary_checksums.txt

# Later, verify they haven't changed
sha256sum -c /tmp/binary_checksums.txt | grep "FAILED"

# On a clean system, export a baseline and compare
sha256sum /bin/ls /bin/ps /sbin/init > /tmp/baseline_critical.txt

# On potentially compromised system
sha256sum /bin/ls /bin/ps /sbin/init > /tmp/current_critical.txt

diff /tmp/baseline_critical.txt /tmp/current_critical.txt

Examining Kernel Modules Suspiciously

# List all loaded kernel modules
lsmod

# Check when each module was loaded
cat /proc/modules | awk '{print $1, $3}' | sort

# Examine a suspicious module
cat /sys/module/[module_name]/sections/.text

# Use modinfo to check module details
modinfo [module_name]

# Look for modules without source
find /lib/modules/$(uname -r) -name "*.ko" -type f -exec ls -lt {} + | head -20

Rootkits often load unsigned or unusual kernel modules. Check /proc/modules and lsmod output for anything that:
– Doesn’t appear in your documentation
– Has unusual dependencies
– Loads at unexpected times

Memory Analysis with Volatility

For deep forensics, analyze system memory. This requires tools like Volatility, which can be installed from the Udemy IT Courses platform for learning:

# Dump system memory (requires access to /dev/mem, works on older systems)
sudo dd if=/dev/mem of=/tmp/memory.dump bs=1M

# Analyze with volatility (requires Linux profile)
volatility -f /tmp/memory.dump --profile=Linux_Kernel_Version linux_memmap

Modern kernels restrict direct /dev/mem access. Use pm-utils or LiME (Linux Memory Extractor) instead:

# Using LiME for safe memory acquisition
git clone https://github.com/504ensicsLabs/LiME.git
cd LiME/src
make -C /lib/modules/$(uname -r)/build M=$(pwd) modules
sudo insmod lime.ko path=/tmp/memory.dump format=dump

# Then analyze with Volatility

Step 4: Removing Rootkits Safely

Removal is where most administrators make mistakes. Do this wrong and you’ll either leave the rootkit behind or destroy system functionality.

The Safe Removal Procedure

1. Isolate the system

# Disconnect from network (most critical step)
sudo ip link set eth0 down
# Or use firewall rules if network disconnection isn't possible
sudo ufw default deny incoming
sudo ufw default deny outgoing

2. Boot from clean media

Never remove rootkits while running from the compromised system:

# Create a bootable USB with a clean Linux distribution
# On a clean machine:
sudo dd if=ubuntu-22.04-live-server-amd64.iso of=/dev/sdX bs=4M

# Then boot the compromised system from this USB
# Mount the affected filesystem
sudo mkdir -p /mnt/infected
sudo mount /dev/sda1 /mnt/infected

3. Identify malicious files from outside the system

# With filesystem mounted, scan from clean environment
sudo chkrootkit -r /mnt/infected

sudo rkhunter --check --skip-keypress -r /mnt/infected --report-warnings-only

# Look for suspicious files
find /mnt/infected -mtime -7 -type f -ls | grep -v "/mnt/infected/var/log"

4. Document and remove malicious components

# Remove suspicious kernel modules found
cd /mnt/infected/lib/modules/$(uname -r)/kernel
rm suspicious_module.ko

# Remove rootkit binaries
rm /mnt/infected/path/to/rootkit/binary

# Remove cron jobs
vi /mnt/infected/var/spool/cron/crontabs/root

# Remove systemd services
rm /mnt/infected/etc/systemd/system/suspicious-service.service

5. Verify the removal

# Rescan the mounted filesystem
sudo chkrootkit -r /mnt/infected
sudo rkhunter --check --skip-keypress -r /mnt/infected

# Check for suspicious files modified around compromise time
find /mnt/infected -mtime -7 -type f -newer /mnt/infected/var/log/lastlog

Handling Persistent Compromises

If the rootkit has modified core system libraries or the kernel itself, removal requires more aggressive action:

# Check for kernel modifications
sudo cat /proc/kallsyms | grep -i "suspicious_function"

# For UEFI firmware compromise, check with:
sudo efibootmgr
sudo mokutil --list-enrolled

# If kernel compromise is confirmed, you may need:
# 1. Fresh kernel installation
sudo apt-get remove linux-image-$(uname -r)
sudo apt-get install linux-image-generic

# 2. Filesystem rebuild
# Be very careful - this should only be done with confirmed threats

Recovering from Rootkit Removal

After removal, your system needs hardening:

# Update all packages
sudo apt-get update && sudo apt-get upgrade

# Restore system integrity
sudo aide --init
sudo aide --update

# Reset file permissions to defaults
find /bin /sbin /usr/bin /usr/sbin -type f -exec chmod 755 {} \;

# Review and remove suspicious cron jobs
sudo crontab -e

# Check for suspicious kernel modules
lsmod | wc -l  # Compare to baseline

# Verify network configuration
sudo ss -tulpn

# Restart essential services
sudo systemctl restart ssh
sudo systemctl restart syslog

Automated Rootkit Detection with Scheduled Scans

Set up continuous monitoring to catch future compromises:

# Create a daily scan script
sudo nano /usr/local/bin/daily_rootkit_scan.sh

#!/bin/bash
REPORT_DIR="/var/log/rootkit-scans"
DATE=$(date +%Y%m%d_%H%M%S)

mkdir -p $REPORT_DIR

/usr/sbin/chkrootkit > $REPORT_DIR/chkrootkit_$DATE.log 2>&1
/usr/sbin/rkhunter --check --skip-keypress > $REPORT_DIR/rkhunter_$DATE.log 2>&1

# Alert on findings
if grep -q "INFECTED\|SUSPECT" $REPORT_DIR/chkrootkit_$DATE.log; then
  echo "ALERT: Rootkit scanner found issues on $(hostname)" | \
    mail -s "Rootkit Detection Alert" [email protected]
fi

# Set executable
sudo chmod +x /usr/local/bin/daily_rootkit_scan.sh

# Add to crontab (run at 2 AM daily)
sudo crontab -e
# Add: 0 2 * * * /usr/local/bin/daily_rootkit_scan.sh

Store scan reports in a location that’s automatically backed up and monitored.

Comparison: Rootkit Detection Tools

*RKHUNTER requires configuration tuning to reduce false positives

Prevention: Stop Rootkits Before They Arrive

Detection and removal are critical, but prevention is better:

# 1. Disable unnecessary kernel modules
echo "blacklist uvcvideo" | sudo tee -a /etc/modprobe.d/blacklist.conf

# 2. Implement SELinux or AppArmor
sudo apt-get install apparmor apparmor-utils
sudo aa-enforce /usr/sbin/sshd

# 3. Use mandatory access controls
sudo apt-get install aide
sudo aide --init

# 4. Limit sudo access
# Review /etc/sudoers regularly
sudo visudo

# 5. Monitor system calls with auditd
sudo apt-get install auditd
sudo auditctl -l  # List current rules

Conclusion: A Layered Approach Is Essential

Detecting and removing rootkits requires paranoia and thoroughness. No single tool catches everything. A complete rootkit detection strategy combines:

1. Regular baselines of system state and behavior
2. Multiple specialized tools (CHKROOTKIT, RKHUNTER, lynis)
3. Behavioral monitoring (OSSEC, auditd) for ongoing detection
4. Safe removal procedures including clean-boot analysis
5. Prevention measures that make rootkit installation harder in the first place

When you discover a rootkit, the isolation-and-scan approach from clean media is non-negotiable. Trusting anything running on a rootkit-infected system is literally impossible—that’s the whole point of rootkits.

Most importantly: maintain regular backups, keep your systems updated, and monitor logs religiously. Rootkits depend on silence. Make silence impossible.