rkhunter: Detect Rootkits and System Compromise on Linux Servers

What is rkhunter?

rkhunter (Rootkit Hunter) is an open-source host-based rootkit detection tool for Linux. It works by scanning for known rootkit signatures, suspicious file attributes, hidden files and processes, network backdoors, SUID/SGID files outside expected locations, and deviations from expected system binary hashes. Unlike antivirus software, rkhunter focuses specifically on rootkits — malicious software that hides its presence by modifying system binaries, kernel modules, or process tables. It compares system binary hashes against a stored baseline and checks system utilities for known rootkit-specific behaviors. rkhunter generates warnings that must be evaluated by a knowledgeable analyst — the ability to distinguish genuine findings from false positives is the core operational skill.

Syntax

rkhunter --check
rkhunter --check --sk          # Skip user interaction
rkhunter --update              # Update rootkit signatures
rkhunter --propupd             # Update file property database
rkhunter --check --rwo         # Report warnings only
rkhunter --check 2>&1 | tee /var/log/rkhunter_$(date +%Y%m%d).log

--check runs a full scan. --sk (skip keypress) enables non-interactive execution for automated runs. --update downloads the latest rootkit signature database. --propupd updates rkhunter’s file property database (run this after legitimate package updates to prevent false positives). --rwo reduces output to warnings only — the most useful mode for routine monitoring.

Key Options and Flags

Common Use Cases

Run a Full Rootkit Scan and Review Warnings

The primary use case: run a scan after suspecting compromise, after a security incident, or as part of routine monitoring. Review every WARNING in the output — most will be false positives on a clean system, but each must be evaluated individually. A warning on a critical system binary that cannot be explained by a recent package update is a high-priority investigation item.

rkhunter --update
rkhunter --check --sk --rwo 2>&1 | tee /var/log/rkhunter_$(date +%Y%m%d).log
cat /var/log/rkhunter_$(date +%Y%m%d).log

Configure Automated Daily Scans with Email Alerting

rkhunter is most valuable as a continuous monitoring tool, not a one-time scan. A daily cron job that runs the scan, updates signatures, and emails any warnings provides automated detection of newly installed rootkits or suspicious system changes.

# /etc/cron.daily/rkhunter-scan
#!/bin/bash
/usr/bin/rkhunter --update --nocolors --sk 2>&1 > /dev/null
RESULT=$(/usr/bin/rkhunter --check --nocolors --sk --rwo 2>&1)
if [ -n "$RESULT" ]; then
  echo "$RESULT" | mail -s "rkhunter WARNING on $(hostname)" admin@example.com
fi

Update File Property Database After Package Updates

Every time you update packages with apt or yum, the binary hashes change. Without updating rkhunter’s property database, the next scan will generate false positive warnings for every updated binary. Always run rkhunter --propupd after package updates to keep the baseline current.

apt upgrade -y && rkhunter --propupd
# or
yum update -y && rkhunter --propupd

# Verify the property database was updated
rkhunter --list props | head -20

Security Relevance: Distinguishing False Positives from Real Indicators

Practical Examples

Full scan with output analysis and false positive identification

# Update signatures
rkhunter --update

# Run full scan, capture output
rkhunter --check --sk 2>&1 | tee /tmp/rkhunter_full.log

# Extract only warnings
grep -A 2 'Warning:' /tmp/rkhunter_full.log

# For each warning, cross-validate with package manager
debsums $(dpkg -S /path/to/warned/file 2>/dev/null | cut -d: -f1) 2>/dev/null

The complete analysis workflow: run scan with full output capture, extract warnings, and cross-validate each warned file against the package manager. If debsums (or rpm -V) reports the file as unmodified, the rkhunter warning is a false positive from a configuration anomaly. If debsums also reports a failure, the file has been modified outside the package manager — a critical finding.

Whitelist a known false positive in rkhunter.conf

# View the current warning
rkhunter --check --sk --rwo 2>&1 | grep 'Warning'

# Add to whitelist in /etc/rkhunter.conf
# For a binary false positive:
grep SCRIPTWHITELIST /etc/rkhunter.conf
# Add: SCRIPTWHITELIST=/path/to/false/positive

# For a property database warning:
rkhunter --propupd FILE=/path/to/file

Whitelisting persistent false positives reduces noise and ensures genuine warnings stand out. Document every whitelist entry with a justification comment in rkhunter.conf. Review whitelisted items periodically — a legitimate file that has been compromised since whitelisting will continue to be suppressed.

Check rkhunter log for historical warnings

cat /var/log/rkhunter.log | grep -E '(Warning|\[ Rootkit |Hidden)'
grep -c 'Warning' /var/log/rkhunter.log
tail -100 /var/log/rkhunter.log | grep Warning

The rkhunter log accumulates across multiple runs. Reviewing the historical log reveals whether a warning is new (sudden appearance after a period of clean scans is more suspicious) or persistent (likely a known false positive). A spike in warning count should trigger immediate investigation.

Troubleshooting Common Issues

Summary

rkhunter provides automated rootkit detection and binary integrity verification that complements AIDE and manual checks. Its value is in continuous daily monitoring — a rootkit installed tonight will generate warnings in tomorrow’s scan. The critical operational practice is maintaining an up-to-date property database (run –propupd after every package update), reviewing all warnings rather than dismissing them, and cross-validating concerning findings with the package manager’s own hash verification tools.

• Run rkhunter --propupd after every package update — stale databases generate false positives that mask genuine warnings
• Each WARNING requires individual evaluation — cross-validate with debsums or rpm -V before concluding a file is compromised
• Schedule daily runs with --rwo and email alerting — a daily report with no warnings provides operational confidence; any warnings break that baseline