Rootkit Detection

Rootkit Detection

A rootkit is malware designed to hide its presence from standard system tools. A compromised server running a rootkit may show clean output from ps, ls, and netstat while actively being used for crypto mining, DDoS, or data exfiltration. Rootkit detection tools use techniques the rootkit cannot hide from — checking kernel-level data directly, looking for discrepancies between what different tools report, and comparing against known-good checksums.

What is a rootkit?

Normal system:
  ps command → kernel → shows all processes → you see everything

System with kernel rootkit:
  ps command → kernel (hooked by rootkit) → hides rootkit processes
  → you see only "clean" processes

Detection approach:
  - Read /proc directly (rootkit may not hook this)
  - Compare network connections from different sources
  - Check for known rootkit file signatures
  - Compare binary checksums against package database

Using rkhunter

sudo apt install -y rkhunter

# Update rkhunter database first
sudo rkhunter --update
sudo rkhunter --propupd    # Create baseline of current file properties

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

rkhunter output categories

[ Rootkit checks ]
  Rootkit 'Adore Ng' : Not found
  Rootkit 'Ana rootkit' : Not found
  ...

[ File properties checks ]
  /usr/bin/ps             [ OK ]
  /usr/bin/ls             [ OK ]

[ Warnings ]
  Warning: The SSH configuration option 'PermitRootLogin' is set to 'yes'
  Warning: Hidden file found: /dev/.udev

# View only warnings from last scan
sudo grep "\[ Warning \]" /var/log/rkhunter.log

# Run rkhunter daily via cron
echo "0 3 * * * root /usr/bin/rkhunter --cronjob --report-warnings-only" | sudo tee /etc/cron.d/rkhunter

Using chkrootkit

sudo apt install -y chkrootkit

# Run a scan
sudo chkrootkit

chkrootkit output

ROOTDIR is `/'
Checking `amd'...                          not found
Checking `basename'...                     not infected
Checking `chsh'...                         not infected
Checking `cron'...                         not infected
Checking `lkm'...                          not tested
# "not infected" is good; "INFECTED" needs immediate investigation

# Run only specific tests
sudo chkrootkit -t lkm    # Check for loadable kernel module rootkits

# Run both tools for cross-verification
sudo rkhunter --check --skip-keypress 2>/dev/null | grep -i "warning\|error"
sudo chkrootkit 2>/dev/null | grep -i "INFECTED\|suspicious"

Manual indicators of compromise

# Check for discrepancies that rootkits often cause:

# 1. Compare process list from /proc vs ps output
ls /proc | grep -E "^[0-9]+$" | wc -l    # Processes in /proc
ps aux | wc -l                             # Processes from ps
# Significant difference may indicate hidden processes

# 2. Check for unexpected network connections
ss -tunap    # All connections
# Look for: connections to unknown IPs, unexpected listening services

# 3. Check for recently modified system binaries
find /bin /sbin /usr/bin /usr/sbin -mtime -7 -type f 2>/dev/null

# 4. Check for unexpected kernel modules
lsmod | grep -v "$(cat /proc/modules | awk '{print $1}')"

# 5. Check debsums for binary integrity
sudo apt install -y debsums
sudo debsums -c 2>/dev/null | head -20    # Report changed files vs dpkg database

Responding to a detection

⚠️ WARNING: If you detect a rootkit, do NOT try to clean the system. A rootkit compromises the entire operating system — you cannot trust any tool on the system, including the rootkit detector. The correct response is: take a forensic disk image (for investigation), revoke all credentials that were accessible on the server (SSH keys, API keys, database passwords), provision a new clean server, restore data from a backup predating the compromise, and investigate how the server was compromised to prevent recurrence.

Conclusion

Run rootkit scans with rkhunter and chkrootkit regularly — ideally daily via cron on production servers. Many findings are false positives (configuration warnings, not actual rootkits) — establish a baseline right after installation and focus on new warnings. The most reliable indicator of compromise is discrepancy between different reporting mechanisms (processes in /proc vs ps, network connections from different tools). If you find a real rootkit, the server is untrusted: rebuild, don't remediate.